Updated Vnc Viewer For Sharp Roms, New features added to keypebble Options

[TimW]

I've been using keypebble but was getting frustrated at the lack of support for the newer encodings - so I went ahead and added them. I can't build for opie devices ATM so this release is for Sharp based ROMs only. Some features are a little experimental so this is not yet a full release.

You can get it here:
teakettle.ipk

The name-change (to teakettle) is temporary so you can keep keypebble installed alongside it just in case you have problems. Once I get it stable it'll become just a mod to keypebble. It appears as VNC Viewer2 on your Applications tab. If you do run keypebble alongside it, remember to turn off the new encodings in teakettle before opening up keypebble as the configuration file is shared and I believe keypebble will actually request some of the encodings it can't handle if they are enabled from teakettle.

If you could let me know how you get on and if there are any other features you want added, I'd be grateful.

From the README:

Additions to keypebble by Tim Wentford
======================================

1) Added ZRLE, zlib, hextile, CoRRE and RRE encoding support.

2) Added a "Fit remote desktop to local screen" scale method (set the
scale factor to 0 to see it in action).

3) Modified the way that the refresh rate is used to more closely
match the use documented in the rfb standard.

4) Added a "Request Refresh Now" and "Set Refresh Rate Slower/Faster"
items to the corner menu (I like to slow the refresh rate down when
I'm monitoring stuff, but to speed it back up when I'm controlling
it).

5) Modified the scaling mechanism to avoid missing pixels when
rectangles which aren't a multiple of the scale factor arrive (the
screen still gets "fuzzy" when this happens but it looks better
than the missing lines to me).

6) Added an experimental "Auto" mode to choose the preferred encoding
automatically based on an approximate measure of how long a screen
refresh would take.

7) Tried to improve the interactivity during a long refresh (I'm not
sure if I've succeeded in this so I haven't done it throughout - if
you want to experiment replace the call to start the timer in
endRect with a direct call to doOneRect: if it works, let me know
and I'll extend it to work better with hextile and ZRLE encodings
(by using the timer between tiles as well as between rectangles)).

8) Added local cursor encoding. This is supposed to save on bandwidth
by allowing the server to send updates to the cursor shape so that
the remote machine can draw the cursor itself. A server can then
take advantage of this by not sending updates every time the cursor
moves. I haven't found much advantage in using this yet, and I
don't really handle it properly since I choose not to draw the
cursor at all - which is probably appropriate for a touch screen
device).

9) Added resize encoding so that the remote device can handle screen
size changes properly.

10) Some attempts at optimisation - though currently I've probably
added more overhead than I've saved.

11) Added the SHARPROM #define so that it can be built more easily for
standard Qtopia devices.

Problems
========

1) Occasional floating point exception at connection.

I'm not sure if that is something I've added or not. If you get this persistently from a particular server try checking the "Request 8-bit session" box.

2) I can't currently build for opie based machines.

Even the original code freshly checked out of the CVS segfaults for me
when I build it for an Opie target so I have only tested this on a
Sharp ROM based Zaurus.

3) I'm not sure that I can get much of a sample to estimate bandwidth
in hextile encoding...

...so you may get stuck in hextile encoding when using auto mode.

4) I haven't tested auto mode in a wide enough set of networks, yet.

Which is why I'm making this release.

[TimW]

I found the problem. Funny how you can spend days looking for a bug and then find it the day after you release something. Anyway, it looks like it has been in keypebble right from the start so this fixed version may work better for you even if keypebble didn't work before. You can get the updated version here.

If you are interested, the bug was in the initial negotiation of screen depth. If a server suggested a depth of more than 16 keypebble was supposed to request that it be limited to 16 but the structure was only getting filled in if the "Request 8-bit session" check box was activated. This meant that any server trying to serve up a 24 bit (or more) screen would fail (the negotiation, not the server). Tight VNC would just kick the client off, OSXVnc and RealVNC would just hang during the negotiation meaning that the first refresh would never arrive

[xamindar]

Cool, I tried the first version last night but was unable to get it to connect while the original keypebble connected just fine. That was probably the cause. I could never get keypebble to even get an 8-bit session even with the box checked.

[TimW]

Cool, I tried the first version last night but was unable to get it to connect while the original keypebble connected just fine.  That was probably the cause.  I could never get keypebble to even get an 8-bit session even with the box checked.

So the second version is working okay? If so I'd like to hear how the different encodings work out for you and especially if the auto setting chooses appropriate settings. It works okay on the four networks I've tried it on but four isn't a big sample 8^).

I get the best results on my SL5000 with a tightvnc server using zlib encoding - but zrle on a realvnc server isn't far behind and may even catch up once I've had a chance to optimise a bit more.

[xamindar]

It seems to be working now, the request 8 bit button works too

I am using auto and connecting to my gnome desktop's vnc. I do not know which encoding it is using, is there a way I can find out? Console output?

I'll do more testing with realvnc in windows when I get home. But for now it does seem a little faster and I love having the cursor there. Now I can at least see where the mouse should be.

[TimW]

It seems to be working now, the request 8 bit button works too

I am using auto and connecting to my gnome desktop's vnc.  I do not know which encoding it is using, is there a way I can find out?  Console output?

I'll do more testing with realvnc in windows when I get home.  But for now it does seem a little faster and I love having the cursor there.  Now I can at least see where the mouse should be.

It puts a brief status message up on the taskbar whenever it changes. Usually the first opportunity to change is as the first screen finishes drawing. At this point it should say something like:

Using raw

or

Using hextile

or

Using zlib.

It will also say this at the console but running it from the console is very slooooow unless you turn nearly all the debug off (which I think I have but I can't remember if the encodings are still printed out).

If you can see the mouse cursor then it is being drawn by the VNC server. Ironically, the option I added turns the cursor *off* rather than on 8^). Unfortunately so much depends on the precise pairing of client and server (and which OS the server is on) that it is really hard to guess beforehand whether the cursor will be drawn by the server or not. If it is, then checking the local cursor encoding does nothing, if it isn't then currently the cursor won't be drawn - though that will change once I understand a bit more about how qt/embedded handles cursors.

Using auto encoding is unlikely to give you the fastest setting as it tries to balance server load against bandwidth usage. I try and make it so that a full screen redraw will be done in less than two seconds and use the least processor intensive encoding to achieve that. Off course, all these calculations are approximate and don't take into account CPU at the client.

If you want speed, then the best settings for me are usually with setting auto to off and setting zlib and zrle to on. Tight servers generally have zlib and real servers generally have zrle. I've just found a server which only does raw and hextile (of the non-deprecated encodings) so I may have to modify auto a bit to cope with that.

[undrwater]

I'm unable to connect.

When I start up I get:

CODE

SlSharedManager: can't get proc entry
Display size = 480x640
Connecting...

QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
...
...etc...

It first comlained about a libsl.qmid, but I was able to resolve that.

This is on a SL-6000, stock Sharp ROM, installed to SD.

[eviLjazz]

This looks nice. I would love to test your program but somehow I can't download from your site. Always getting 404s.
If you could make the software available again, that would be mighty cool. Thanks in advance.

[speculatrix]

what do people think is the best vnc server (I use it on mp mp3 jukebox at home, which is a headless win2k box running winamp)... I tried ultravnc but it put quite a load on the win2k box (which is a low-powered duron!), and found that tightvnc seems to be a good compromise on compresion efficiency vs overhead.

As I understand it, rdp/remote desktop is more efficient than vnc when running (oops, nearly put "ruining"!) on windows... but that'd mean upgrading the box to XP and I'm doing my best to escape the clutches of MS.

[chyang]

cannot access. Would you like to add it with the attach function? Thanks.

[TimW]

cannot access. Would you like to add it with the attach function? Thanks.

I tried adding the code to draw the cursor locally. It works under qvfb using the sdk but I don't think it is working on the Zaurus yet. Otherwise this is the same as 0.2 except attached here.

Attached File(s)

 teakettle_0.3_arm.ipk ( 53.33K ) Number of downloads: 66

 

[TimW]

I'm unable to connect.

When I start up I get:

CODE

SlSharedManager: can't get proc entry
Display size = 480x640
Connecting...

QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
...
...etc...

It first comlained about a libsl.qmid, but I was able to resolve that.

This is on a SL-6000, stock Sharp ROM, installed to SD.

These don't look much like errors which this can produce. There is no direct linking to libsl and I'm not directly using QGDict. I'd say the installation went wrong but I don't have an SL-6000 so maybe it does something very different to my SL-5000.

Try uninstalling it and reinstalling it. I can't come up with anything more constructive than that, I'm afraid.

[TimW]

what do people think is the best vnc server (I use it on mp mp3 jukebox at home, which is a headless win2k box running winamp)... I tried ultravnc but it put quite a load on the win2k box (which is a low-powered duron!), and found that tightvnc seems to be a good compromise on compresion efficiency vs overhead.

As I understand it, rdp/remote desktop is more efficient than vnc when running (oops, nearly put "ruining"!)  on windows... but that'd mean upgrading the box to XP and I'm doing my best to escape the clutches of MS.

Tightvnc is pretty good. If you can use the mirror driver (dfmirage from the devel downloads) on win2k then that should help a lot. If you using my version of keypebble then using zlib encoding and make the "check for screen updates" value large. The recommended value IIRC is 40 but I prefer to run at 1000 (no two updates will arive within a second of one another). I think you can do things on tightvnc itself to reduce the polling load which will also help.

I have used tightvnc without any of these optimisations under windows ME on a ~600MHz crusoe without too much trouble but I wasn't doing anything else which put any load on it.

BTW, if you do upgrade the box to XP you'll need the pro version, I think - and rdp is much more efficient than VNC.

[TimW]

I've added some more trace to help track down problems with unusual server pixel formats, and added some extra code to cope with them - I may even have caught them all, this time 8^).

I've also done a little bit more optimisation by forcing the pixel format to little endian which reduces the amount of byte shuffling and is more likely to match the server (unless you have a PowerPC Mac).

Here is the latest.

Attached File(s)

 teakettle_0.4_arm.ipk ( 52.9K ) Number of downloads: 75

 

[ken]

Here is the latest.

This wouldn't by any chance act as a terminal services client would it?