kvncviewer - a VNC viewer (not only) for Kobos

[nomeata]

I’m wondering: Does kvncviewer actually make use of the 16 levels of greyscale display provided by the Aura HD?

[nomeata]

Also, it seems that white is not fully white. Any idea why that may be?

[nomeata]

I tried to take a screenshot to show the issues that I still seem to have (white is not fully white, and everything involving not-fully-black-pixels, especially pictures is blurred), but when I copy the contents of /dev/fb0 and look at the image on my laptop, everything is white and crisp.

Is there a problem with too much dynamic in an eInk display? Or maybe too many refreshes?

[nomeata]

Update: It seems that the noise is an artefact from VNC compression. Attached is a dump from /dev/fb0 converted to PNG, and you can clearly see noise around anti-aliased fonts and pictures. This comes out horribly on the Kobo.

Maybe I can use VNC in a lossless format somehow? Have not yet figured out how, though.

[nomeata]

With -encodings Hextile passed to the vnc client the image gets better, but grey scales are still wrong. It seems that kvncviewer uses the wrong pixel layout. And indeed, koreader (which works great) uses B.TYPE_BBRGB16 in ffi/framebuffer_linux.lua.

Unfortunately, when I change that in kvncviewer, the whole screen layout breaks. Maybe I should try to change more of these files.

Hans-Werner, are these files taken from koreader, or do they have another, common source? Dou you know what was modified in these files for kvncviewer?

[hawhill]

I'm on a week of holiday currently, so I can't give appropriate answer, unfortunately.

A first look tells me that you're quite right. I used the koreader implementation for the vncviewer, but probably an early version, which was fixed in the meantime. Probably, the whole blitbuffer.lua and framebuffer_linux.lua should be updated from the koreader code.

I think I mistook the Kobo framebuffer layout for a 16bit grayscale buffer at first, only to later realize that it is in fact RGB16.

[nomeata]

Ok, got it to work:

* I replaced ffi/blitbuffer.lua and ffi/framebuffer_linux.lua by the version in koreader
* In vncviewer.lua, I replaced blitbuffer.TYPE_BBBGR32, by blitbuffer.TYPE_BBRGB32.

I’m not exactly sure what that means, and what I broke for others.

[hawhill]

Great, I'll see to putting those changes into the repository - in a few days. Thank you for the valuable feedback! The code still needs a bit more love, I think. There's some bug in the event handling code that leads to a lock-up sometimes, IIRC.

[hawhill]

Changes are back in the repository - and I also fixed a bug. In a few days, I'll probably update the compiled version in the OP. Until then, you need to compile yourself.

[MoyoWa]

Hi Hawhill,

First, thank you for all of your work on this.

I have gotten the kncviewer up and running on a PW2 and had a few questions.

It is fairly blinky and difficult to use as a monitor, as it blinks through black as a full refresh every few seconds. I found a lot of variables in vncviewer.lua, einkfb_h.lua, etc that look like they pertain to what I would want to tweak, but I do not know which ones to start with.

I'd like to have smoother transitions, and also partial refresh, such that only the thing that is changing on my screen has to update.

I see the variable fx_update_partial = 0, in einkfb_h.lua, and the various waveforms to choose from in vncviewer.lua, for example, but not sure what to change them to (1? GL16_FAST?). I'm also guessing that refresh_full_every_256th_pxup = 512 may have something to do with it.

If you could give any guidance here as to which variables in which files I can experiment with and in what way, it would be much appreciated.

Thank you thank you!

oh, and I am using Vine Server on OS X, so not sure how much of my lag is due to RFB....

[hawhill]

Well, try the "-fast" switch first. Also, I just added a commit to the sources that will allow to pass "0" as an option to the "-refreshFullAfterPixels" switch in order to disable full refreshes completely. For starters, experiment with higher values as parameter for that switch (like, say, 100). In the background that will fiddle with the value of refresh_full_every_256th_pxup. Oh, and try with "-waitRefresh 150" (or so - default is 250). If you prefer to dive into the code, that is of course fine with me, too :-) Just wanted to tell you that there are command line switches that might lead to preferable behaviour.

But in the end, you will probably adapt your desktop to the display technology, too. Disabling all flashy things, stop cursor blinking, use high contrast theme etc.pp. - it's e-ink, after all.

[MoyoWa]

Yup, I had changed my laptop to grayscale and higher contrast.

I didn't know about the command line switches, so that may help. Does that require recompiling the code tho? Or are they executed via the terminal while vncviewer is running? Unfortunately, I don't have access to an environment where I can build right now, so looking for the easier tweaks...

Thank you so much for your reply!

[hawhill]

No, you don't need to recompile anything - even when changing the code, actually, since most of it is Lua code which is compiled just-in-time, so it's enough to change the .lua files and you're set. In fact, you could probably update an older binary (compiled) version by just adding in more current Lua files.

For most of the command line switches, they work in earlier versions. I only added the possibility to set the "0" option to disable full refreshes alltogether. You can probably give a very, very large number there and have the same effect.

Those are command line switches for the vnc viewer, so you add them at the point where you call/start the viewer.

[Rizla]

I plan to try this on FW 3.15. Would that be okay or would it be preferable to downgrade the FW to an earlier version?

[hawhill]

I don't think it has any dependencies whatsoever to any firmware stuff.