Onyx Boox as monitor

[mdp]

About the mouse emulation through touchscreen solution:
we should probably benefit from multitouch, to emulate right button, mouse wheel etc.
Iordanov's bVNC is a good lesson about those controls (two-fingers tap = right mouse button; two-fingers swipe = mouse wheel ...)

[sogaiu]

I've been thinking of adapting the script to try using Android devices as tablet input devices for PCs, macs, etc. I know such things exist already, but it seemed worth trying out to see how good it could be. The idea of emulating right mouse button, wheel, etc. sounds like it would be useful for the tablet input idea too.

So are you thinking to encode multitouch info in each log line then?

[mdp]

Originally Posted by sogaiu

I've been thinking of adapting the script to try using Android devices as tablet input devices for PCs, macs, etc.

But how? Would the device also represent the desktop contents? If so, how to do it better than bVNC?

Originally Posted by sogaiu

So are you thinking to encode multitouch info in each log line then?

Yes, probably so. I do not want to flood the log, but probably also adding the second finger, up and down, is cheap and effective.

[mdp]

Originally Posted by mdp

we should probably benefit from multitouch, to emulate right button, mouse wheel etc.

It works... Sogaiu, we have RMB and wheel up/down (well calibrated with proportional swipes).
Two-finger-tap = Right Mouse Button
Two-finger-swipe = Mouse Wheel (the longer, the more)

I'll clean it up a bit before posting.

EDIT: and I fixed that "double function call" on corners: it was reacting at both tap-down and tap-up.

EDIT2: meanwhile, I shall post the short and simple java code added to the Onyx application (funny for me, because I just wrote this, since the actual work I do low level)... It will be useful for clarity in exchanges to Onyx.

[sogaiu]

Originally Posted by mdp

But how? Would the device also represent the desktop contents? If so, how to do it better than bVNC?

The idea is just to use an Android device as a tablet for another machine (e.g. think what "tablets" artists / designers use as input devices). There is no intention to display the desktop contents. It just happens that the script seems very close to being able to do this technically so it seems worth seeing what the set up is capable of.

Yes, probably so. I do not want to flood the log, but probably also [adding the second finger, up and down, is cheap and effective.

Sounds good.

BTW, while observing the logcat output over a number of sessions, I eventually noticed "chatty" entries:

https://stackoverflow.com/questions/...expire-message

These seem to come about some time later -- that is, my impression is that I wouldn't see them initially, but later invocations of adb logcat would show them (perhaps there is post-munging?). Are you familiar with this "chatty" phenomenon?

[mdp]

Originally Posted by sogaiu

The idea is just to use an Android device as a tablet for another machine (e.g. think what "tablets" artists / designers use as input devices). There is no intention to display the desktop contents. It just happens that the script seems very close to being able to do this technically so it seems worth seeing what the set up is capable of

Well, that's pretty easy then: you just create and Android application that displays a black screen and logs taps the way I did it for the Onyx Monitor application.
But you will probably have a problem in lag (very small but it is there).
And what about pressure?

[sogaiu]

Originally Posted by mdp

Well, that's pretty easy then: you just create and Android application that displays a black screen and logs taps the way I did it for the Onyx Monitor application.

Right.

But you will probably have a problem in lag (very small but it is there).
And what about pressure?

For the first, I thought I'd try it to see how usable / unusable it might be -- don't know until I try

For the second, it appears that info might be available via MotionEvent (getPressure, getHistoricalPressure, etc.), so if it turns out to be for the Max 2, may be it might also be passed along like the other info is already.

[mdp]

As per the previous comments, I further modified the "Monitor" application and the script from Sogaiu to transform logged touch events into mouse events, to allow for "right mouse button" and "mouse wheel".

One finger tap → Left mouse button (also allows drag, or "touch, swipe, release")
Two fingers tap → Right mouse button if immediately released, Mouse wheel if swipe.

@Sogaiu, I took the liberty to make a few changes around, I hope it is not a problem. I did not make the changes relevant to dekstop extension yet - for now, it assumes desktop clone.

[Waiting4somethin]

In your hdmi monitor touchscreen video there seems to be a lot of jerky, slow movements (e.g. attempting to move window at 0:06 takes a whole second to update window position) except from about 1:30 to 1:40 or thereabouts when you’re scrolling a document.

I thought the monitor mode was in fast refresh mode by default?

[mdp]

Originally Posted by Waiting4somethin

In your hdmi monitor touchscreen video there seems to be a lot of jerky, slow movements (e.g. attempting to move window at 0:06 takes a whole second to update window position)

Counted, it took 0.8s from command (releasing the touch) to screen update. It is, in practice, quite usable.
Yes, as a matter of facts I am not sure about the reason of that delay, and where it comes from (which part of the system is taking time).
That was of course Greyscale Update mode: in A2 mode the delay is still there (though I have not counted).

It would be possible to display objects on the screen move during drag, instead of being rendered only in the final position - but I did not catch the "finger move" events, to keep the system (namely, the amount of data dumped in the log, used to retrieve the events) as slim as possible.

Originally Posted by Waiting4somethin

except from about 1:30 to 1:40 or thereabouts when you’re scrolling a document.

I thought the monitor mode was in fast refresh mode by default?

Because in that part (around 1:30 to 1:40) I am using A2, to demonstrate fast update.

The monitor mode is in A2/Fast mode by default, and the video shows instead mostly GU mode, because A2 is inadequate for normal use. A2 is for watching things move, not for reading screen content.

I was not especially attentive towards keeping A2 on when moving things on the screen - I focused on demonstrating operation in GU mode, which is more novel (since the original software forces A2).

[sogaiu]

Originally Posted by mdp

@Sogaiu, I took the liberty to make a few changes around, I hope it is not a problem.

No problem

BTW, I keep encountering the difficulty that the "mirror" display option is greyed out in my environment (Xfce). I don't seem to have a reliable way to get mirroring to work -- by default things end up in "extended". When I manage to get mirroring working again, I intend to test.

[sogaiu]

A quick note -- with the latest set up, the pointer appears to the north-west of where the stylus is placed (more north than west).

I've been tweaking things with xrandr to get mirroring to work so I suppose it's possible there's something weird on my end:

xrandr --output eDP1 --auto --primary
xrandr --output HDMI1 --auto
xrandr --output HDMI1 --auto --same-as eDP1

May be it's that "--same-as" part...I notice that the pointer won't move to certain areas of the Max 2 with this set up.

Edit: the invisble border issue was addressed by using calling xrandr with the appropriate output and --panning 2104x1560

[Waiting4somethin]

Originally Posted by mdp

That was of course Greyscale Update mode: in A2 mode the delay is still there (though I have not counted).

It would be possible to display objects on the screen move during drag, instead of being rendered only in the final position - but I did not catch the "finger move" events, to keep the system (namely, the amount of data dumped in the log, used to retrieve the events) as slim as possible.

Okay I see, thanks for clarifying that—move events are not captured except final position, so it creates a false impression of lag, but there is also an odd delay?

It was just confusing from an outside perspective, if the lag was from the mod, software, or refresh setting, and if the mod utilized the speed advantage of the hdmi port, compared to say, vnc speed (which is reported to be slow). Moving objects seem to be the easiest markers to measure response.

[ballballb]

Hi all, I am going to buy this machine for writing my thesis.
What I concern is the speed of the screen as a second monitor.
Is there anyone use it for writing in MS Words? Is the speed acceptable? Would you recommend it?
(sorry, I didn't read the previous posts)

[mdp]

Originally Posted by ballballb

concern is the speed

It's subjective. I had a desktop session even today, it's doable. You get used to it.

> sorry, I didn't read the previous posts
When you will really be into it, it's best for you if you skim through it and get practical info about the state of the progress we are in.