Onyx Boox as monitor

[mdp]

Originally Posted by SnowRipple

@mdp Do you think that incorporating hdmi port into Max and replacing Wifi or usb connection with hdmi cable will provide a big improvement in refresh rate? [...]

Since you are asking me directly I can throw my 2 cents ; )
In short: of course, I can't wait to see it done.

Some numbers: a base HDMI allows for roughly 500 MB/s. A USB 2.0, for maybe 35 MB/s.
An uncompressed video can easily need 200 MB/s. But with state of the art compression, that can become roughly between 0.05 MB/s and 0.5 MB/s. (BTW: that makes NX interesting: it encodes using video compression... As you may know, the Nomachine NX client does not work on the Onyx firmware, and anyway the server does not transmit perfect timing.)

Video (screen) through USB can certainly be done: it is BTW a specialty of DisplayLink, and non "desktop remote" technology based solutions are probably doing something similar.

So, it's a matter of implementation (retrieving data, compressing data etc.). But if you have raw power and specialized hardware, you do not need clever tricks (edit: although USB remains interesting and important as a backup, for flexibility, to cover those devices without HDMI-in - notably, the existing ones - etc.)

[tracey1]

any news on the new E-reader that is rumored to come with hdmi ? Wasnt it supposed to come this fall or something ?

[vdp]

Originally Posted by mdp

First, the nice (to the interested) surprise.

Please find attached a modification of com.iiordanov.freebVNC customized for the EPD displays:

@mdp: BTW, did you encounter any problems when building bVNC? I've tried to compile https://github.com/iiordanov/remote-desktop-clients, following the instructions in BUILDING, but there are errors such as:

12 is less than minimum platform for arm (14)
Failed: ${ndkdir}/build/tools/make_standalone_toolchain.py --api "${android_api}" --arch "${arch}" --install-dir "${toolchain}" (line 367)
~/devel/onyx/remote-desktop-clients/eclipse_projects/bVNC ~/devel/onyx/remote-desktop-clients
Android NDK: android-12 is unsupported. Using minimum supported version android-14.    
Android NDK: WARNING: APP_PLATFORM android-14 is higher than android:minSdkVersion 8 in ./AndroidManifest.xml. NDK binaries will *not* be comptible with devices older than android-14. See https://android.googlesource.com/platform/ndk/+/master/docs/user/common_problems.md for more information.    
Android NDK: ERROR:jni/src/Android.mk:usb: LOCAL_SRC_FILES points to a missing file    
Android NDK: Check that jni/src/../libs/deps/x86/root/lib/libusb-1.0.a exists  or that its path is correct

I could probably try to understand what the build scripts are doing and where it goes wrong, but I don't have much experience with Android NDK/SDK, and I'd rather not spend too much time on this if I can help it. If you could give me some directions, that would be great.
There is a version of AndroidVNC, on which bVNC is based, with much more human-friendly build process (https://github.com/binkybear/androidVNC), but it seems bVNC's screen update routines are more optimized.

BTW, did you publish the source code of your modifications somewhere (GitHub would be nice )?

FWIW, I want to make minor changes to the client, so that I can do things like refreshing the display, switching to fullscreen and A2 mode, using keyboard shortcuts.

[mdp]

Originally Posted by vdp

@mdp: BTW, did you encounter any problems when building bVNC? [...]

Hi vdp, well met. Actually, I did not build it from source. When you do not need extensive work, it is much more efficient to operate on the dalvik itself ( `apktool -d ...`, patch resources and/or smali, `apktool -b ...`).
When you want to check what was updated, you may use `diff` (on the desktop, `meld`) over the decoded (through apktool) packages, "before- and after the cure".
I am attaching here the extra code / the modifications I made to
/com/iiordanov/freebVNC/input/RemoteVncPointer.smali
( As you will see, inside method processPointerEvent(IIIIZZZZI)Z , between it seems line 226 and line 228, I retrieved pointer x, y, framebuffer width and height and I called a new method isTapOnCorners(IIII)V , which checks if the tap occurred within 100px of any corner and if so calls another new method doEpdRefresh()V , which verifies that at least 2 seconds have passed since last forced refresh and if so, does the magic - gets the surface object and passes it to the refreshScreen method of the Onyx sdk, which you must add in the smali files tree. )
To change the jpeg and compression parameters was much simpler - just change the values (I cannot find the right file now, it should be related to "tigervnc").

Addendum: if you are not yet comfortable with dalvik/smali, you can compile some java code for Android and check the output smali, and paste it "intelligently" in the actual code you need to patch.
I probably have done it myself with that "if ((x<100 || x>(w-100)) && (y<100 || y>(h-100)))" that becomes those conditionals at the beginning of method "isTapOnCorners", out of sheer laziness...

[mdp]

But the real matter, if you want to research into remote desktop for the Onyx, is different: it is assessing why the usb connection crashes under heavy load, and fixing (or working around) that.
A few details: tested x11vnc server + bVNC client on a high end tablet, it works perfectly (maybe RDP would give more the illusion of "local use", but that's really not necessary, just an extra); it would use a peak of 20Mbit and an average of 10Mbit under forced heavy load (peak of 8Mbit and average a bit below that for normal heavy load i.e. playing a movie).*
On an Onyx tablet, "heavy" load may crash the connection, hence I choke it with wondershaper. The i86 was kind of stable with around a 2Mbit choke; the MaxCarta is more flexible, but still unstable towards the 10+Mbit. Thus, full screen refresh - ordinary situations such as scrolling a document - is laggy.
I am not sure about what causes the instabilty.

* Scrolling pages of text (20Mbit peak, 10Mbit average when done continuously) changes comparatively more pixel on the screen than playing a movie (8Mbit).

[vdp]

Thank you for the detailed instructions on using apktool! It may come handy- I will try it when I get some free time, likely this weekend. I think I'd still prefer to work with the original Java sources though, and learning about Android's VM will probably require as much or greater time/effort "investment" as figuring out how to compile the app, anyway.

So far, I've only tried using bVNC with my M96 Plus, and it seemed reasonably responsive. Well, of course the experience is not as smooth as typing in your local text editor, but is still tolerable, especially in A2 mode. Scrolling through web pages also seemed acceptable, IIRC. AndroidVNC, on top of which bVNC is built, is more laggy. I've only skimmed through the commit log, but it seems bVNC's author made improvements such as implementing TightVNC encoding, and optimizing the frame buffer handling. I've been using @hawhill's setup, w/ Xvnc + x2vnc, BTW (https://www.mobileread.com/forums/sh...d.php?t=150434). I think Max Carta's screen has ~3.67 times more pixels, so as you say maybe the crippled USB becomes a bottleneck- I see http://ereader-store.de/en/77-onyx-boox-max-carta.html lists the interface as 12 megabit per second(if Mb actually means megabit that is). Have you tried to use the WiFi instead- they claim to support 802.11n, so the bandwidth should be much higher than 12Mb/s?
Has anyone tried the xrdp server with an onyx device yet, BTW? I'd be curious how it compares with VNC- bVNC supports RDP I think.

[mdp]

Originally Posted by vdp

Thank you for the detailed instructions on using apktool!

For them to be detailed, you need at least information about re-signing:

apktool d original_app_package.apk
# do your things on code and resources... 
apktool b decoded_apk_directory -o updated_app_package.apk
jarsigner -sigalg SHA1withRSA -digestalg SHA1 -keystore /your/android/apk/keystore/somekey.keystore updated_app_package.apk somealias

The "sigalg" and "digestalg" for the signing command `jarsigner` have recently become mandatory (lacking that notion already may waste a lot of your time).

Originally Posted by vdp

learning about Android's VM will probably require as much or greater time/effort "investment" as figuring out how to compile the app, anyway

But that is knowledge that can be exported to any Android app, and (note) not just those of which you have source code. As mentioned, suppose e.g. - really, just as an example that you could meet in the future - you only wanted to change the hardcoded compression parameters in bVNC... You should have an idea sufficient to orient yourself, a working knowledge. And, it is a backup strategy in case you have difficulties the other, more canonical way.

Originally Posted by vdp

I've been using @hawhill's setup, w/ Xvnc + x2vnc

This is precious, I'll try that. For quick reference, as you know, I have been mostly using x11vnc as a server.

Originally Posted by vdp

lists the interface as 12 megabit per second(if Mb actually means megabit that is)

Interesting, because that is a USB1.1 while I swear that somewhere else the interface of the MaxCarta is listed as a USB2. In that case (USB1.1), that 12 is megabit/s. Note that USB2 would be nominal 480Mbit/s. This would explain a lot. I would say that experiencing interface crashes on the Onyx is still possible at that speed - speed that would probably be enough for good VNC experience btw.

Originally Posted by vdp

Has anyone tried the xrdp server with an onyx device yet

I checked that, though not fully - preliminary investigation showed that it would still use VNC under the hood, though probably not necessarily (see: «Xrdp uses Xvnc or X11rdp to manage the X session» at www.xrdp.org). The advantage of RDP is that (is /when/) it does not just dump "images" (partial screenshots of the updated areas) in the network...

Edit/Addendum:

Originally Posted by vdp

Have you tried to use the WiFi instead- they claim to support 802.11n, so the bandwidth should be much higher than 12Mb/s?

I have not tried - WiFi should use more energy than cable (I do not have the numbers), and battery should be a concern... But your suggestion opens to interesting caveats:
-- 802.11b means ~6 Mbit/s, which is halfish USB1.1 (I read it also conflicts with BlueTooth in the radio ranges, interesting);
-- 802.11g should mean a very variable rate, which can reach 20Mbit/s or 30Mbit/s, and should be good for the purpose (it should be the target, sought of bandwidth);
-- 802.11n: double the above.
You can get either half the USB connection or double or more...

[mdp]

I tried again to see if I could prevent the usb based network connection to crash - symptom, the connection is interrupted and changes to the property "sys.usb.config" - including just removing the USB cable - freeze the tablet, which then requires manual power-off and restart.
Of the logs, dmesg and logcat reveal no issue as the network crashes.
I tried limiting the bandwidth on the tablet instead of on the desktop, using `iptables` as Mansour Behabadi teaches (the commands below* are basically the heart of his network bandwidth limiter com.oxplot.bradybound), but still no cigar.
Limiting the bandwidth (to useful / interesting speed rates) seems to delay the crash of the connection, but it does not prevent it.
I cannot understand what makes it crash.

It would already be useful to understand how to restore the network connection after it crashes (without rebooting).

* 12345 in the commands below are the limit imposed to the amount of packets per second.

iptables  -I INPUT   1                -m state --state ESTABLISHED -p 6 -m length --length 30:10000 -m hashlimit --hashlimit-name CSTMLMTR --hashlimit-above 12345/s -j DROP >/dev/null && echo CSTMLMTR
iptables  -I FORWARD 1 -d 192.0.0.0/8 -m state --state ESTABLISHED -p 6 -m length --length 30:10000 -m hashlimit --hashlimit-name CSTMLMTR --hashlimit-above 12345/s -j DROP >/dev/null && echo CSTMLMTR

[vdp]

Not an expert, but sounds like some sort of low-level(kernel driver or hardware) problem to me. I haven't experienced something like this on M96, but I a) only tried VNC for a few minutes and b) experimented mostly w/ text entry, so maybe the usb net utilization wasn't as high as in your case.

I'd still be interested to hear about using the WiFi for this, if someone has time to try. At the very least this will show if, the USB problems aside, the CPU is powerful enough to handle the bigger screen.

[mdp]

Originally Posted by vdp

I'd still be interested to hear about using the WiFi for this, if someone has time to try.

Do not forget that the Boox Max also has BlueTooth 4... ; )
The most energy conservative per quality wins.

Originally Posted by vdp

At the very least this will show if, the USB problems aside, the CPU is powerful enough to handle the bigger screen.

USB crashes aside, I think the CPU proved to be more than enough powerful. The experience was much better on the high end tablet tests, though. A good consolidated configuration is needed to do fair comparisons. One point, the latency: local update vs remote update can be distant by seconds.

P.S.: @vdp, I tried the x2vnc trick (desktop extension, or transfer of local keyboard and mouse, to pair with "non mirroring" VNC servers) you reported... Nice and potentially very useful (necessary in some configurations). But I recommend that you try x11vnc. Another "screen mirroring" solution is x0vncserver (but I only tried it yesterday).

[mdp]

(Can anybody find a way to make "BlueTooth tethering" appear? I cannot yet understand how to set a BlueTooth PAN network on the the Android side)

EDIT: made it.
To create a BlueTooth Personal Area Network, com.silentlexx.bluetoothpan works.
But, although the BT dongle used stated that it could go BT3 and BT4, which have high speed, I was bound to a connection of 2Mbit. So, working but slow. Looked stable though.
I tested x1vnc + bVNC on this connection, it worked well. But still not the target.

[mdp]

I also tried WiFi (for the x1vnc + bVNC combo). I must have misconfigured something, because the connection was again around 2½Mbit.
Usable, and (of course - that slow) stable, but much worse than through USB.
There is a good chance that the driver of the WiFi dongle I used is not good enough: tomorrow I will try with other machines.

[eReader fan]

I run a VNC and a Teamviewer server from a Raspberry and I connect to it with a Onyx M96 and a Onyx C67ML. I was thinking about selling my M96 and buying a N96 for the extra 515MB of Ram it would supose because I thought I need more ram for making it more smooth, but reading in your chat you say it needs more CPU for being more smooth. Are you ure of it? At least with the C67ML, which has 1.2Ghz dual corre and 512MB of Ram, it says it needs more memory with Teamviewer.

The other big issue I have with my Vnc&Teamviewer sessions is mouse pinter. I have to drag my finger in the screen until I put the mouse wherre I want. Do you have the same issue or there is a way to point where your finger touch?

[mdp]

Originally Posted by eReader fan

I run a VNC and a Teamviewer server from a Raspberry and I connect to it with a Onyx M96 and a Onyx C67ML.

You mean you used TeamViewer Host? If TeamViewer now released a full remote desktop server, which does not require contacting other entities online to work, it would be very great news. Did it work in an isolated network (Raspberry ⇔ Onyx and no Internet)?

Originally Posted by eReader fan

The other big issue I have with my Vnc&Teamviewer sessions is mouse pinter. I have to drag my finger in the screen until I put the mouse wherre I want. Do you have the same issue or there is a way to point where your finger touch?

Using x11vnc I have no trouble with the mouse. Sometimes (on some configurations) I would tap on the screen to make the pointer appear, then I would normally move it with the mouse device.

[mdp]

Originally Posted by eReader fan

I thought I need more ram for making it more smooth, but reading in your chat you say it needs more CPU for being more smooth. Are you ure of it?

I enabled the CPU/process values overlay: my published customized bVNC uses 1.5 units of CPU and 4.3 under the load of showing a played movie. Note that the Max Carta (1.8.2) hardly goes below 1 when on but idle. Since the i.MX6 SoloLite is single core, probably yes, more processing power would help : )

Originally Posted by eReader fan

At least with the C67ML, which has 1.2Ghz dual corre and 512MB of Ram, it says it needs more memory with Teamviewer.

Sorry, what says that?


[Content about local TeamViewer moved below]