Help - Search - Members - Calendar
Full Version: Updated Vnc Viewer For Sharp Roms
OESF Forums > General Forums > General Support and Discussion > Software
Pages: 1, 2
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
QUOTE(xamindar @ Mar 9 2006, 06:13 PM)
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 smile.gif

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
QUOTE(xamindar @ Mar 10 2006, 05:43 PM)
It seems to be working now, the request 8 bit button works too smile.gif

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
QUOTE(chyang @ Mar 11 2006, 03:34 PM)
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.
TimW
QUOTE(undrwater @ Mar 11 2006, 04:48 AM)
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
QUOTE(speculatrix @ Mar 11 2006, 02:42 PM)
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.
ken
QUOTE(TimW @ Mar 11 2006, 02:36 PM)
Here is the latest.


This wouldn't by any chance act as a terminal services client would it?
TimW
QUOTE(ken @ Mar 12 2006, 12:38 AM)
QUOTE(TimW @ Mar 11 2006, 02:36 PM)
Here is the latest.


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


No - there is a terminal services client for the zaurus, though. Search for rdesktop. The ELSI entry is on this page and the ZSI one is on this page. I'm not sure which you need for your ROM but I'm pretty sure I'm using the ZSI one on my Sharp ROM.
ken
QUOTE(TimW @ Mar 11 2006, 02:46 PM)
No - there is a terminal services client for the zaurus, though. Search for rdesktop.


Thanks, had hoped to do 2 birds with one stone. I installed that one before, but was never really successful with it. I guess I can take a second crack at it again.
chyang
Ivhave posted the english one sometime before, the qtrdesktop is cey good.
undrwater
QUOTE(TimW @ Mar 11 2006, 04:36 PM)
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.
*


Got your PM, thanks! I'm getting the same error as stated above. I don't think the problem is on the server side as I get the same error regardless of the IP.

Opie-keypebble 1.0.0 connects (without error) but won't accept the correct password.

Has anyone else tried this on a 6000?

Thanks for your work Tim!
TimW
QUOTE(undrwater @ Mar 13 2006, 07:21 AM)
Got your PM, thanks! I'm getting the same error as stated above.  I don't think the problem is on the server side as I get the same error regardless of the IP.

Opie-keypebble 1.0.0 connects (without error) but won't accept the correct password.

Has anyone else tried this on a 6000?

Thanks for your work Tim!
*

The problem is that none of that trace is generated by my code so I don't know how far you're getting. Is it possible to do

teakettle 2>errs.txt

from a terminal and then send me the errs.txt file?
undrwater
QUOTE(TimW @ Mar 13 2006, 02:05 AM)
QUOTE(undrwater @ Mar 13 2006, 07:21 AM)
Got your PM, thanks! I'm getting the same error as stated above.  I don't think the problem is on the server side as I get the same error regardless of the IP.

Opie-keypebble 1.0.0 connects (without error) but won't accept the correct password.

Has anyone else tried this on a 6000?

Thanks for your work Tim!
*

The problem is that none of that trace is generated by my code so I don't know how far you're getting. Is it possible to do

teakettle 2>errs.txt

from a terminal and then send me the errs.txt file?
*



I'm still not getting the trace. All I see is:
CODE
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key

even when doing teakettle 2>errs.txt

I should add that I installed using ipkg install, and no errors were thrown.

Curious! blink.gif
TimW
QUOTE(undrwater @ Mar 13 2006, 04:47 PM)
I'm still not getting the trace.  All I see is:
CODE
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key
QGDict::hashStringKey: Invalid null key

even when doing teakettle 2>errs.txt

I should add that I installed using ipkg install, and no errors were thrown.

Curious!  blink.gif
*

I didn't realise that was the entire trace! I am completely stumped.

The whole app is in a single executable file which I run directly from the command line when testing - I don't even install it usually - so installation location shouldn't matter. I'll try putting up just the executable when I've got it to hand, if you want to try. I generally just do:

/mnt/cf/teakettle

or, if I'm testing for speed

/mnt/cf/teakettle 2>/dev/null

since printing to the terminal is very slow.

Has anyone else succeeded on a 6000?
TimW
Another update. A few more percent speed increase and I've found the correct functions to use to set the cursor but under Qtopia there are no cursors so they still don't work....so I've just taken it out. This means that the "Local Cursor" setting cuts down on network traffic but removes the cursor (providing the server understands that encoding).
periodontist
Tim,

Just a little feedback. I installed an earlier version of TeaKettle and had no errors connecting to my WinXP box which is running the TightVNC server.

I tried a setting of Scale = 0 and it seemed to work flawlessly...although talk about a tiny display...

The only thing I noticed (and I didn't really run it through a lot of tests) was that the screen was inverted when running in landscape mode (I was not running teakettle in magnified mode if that makes any difference). Luckily, when I turned my Zaurus 180 degrees, everything looked right!

Thanks for your many efforts. Your OPIE Reader is the most used program on my Zaurus...it would be hard to live without it.

Matt
sidmoraes
Does not work with realvnc...
TimW
QUOTE(periodontist @ Mar 16 2006, 08:07 PM)
Tim,

Just a little feedback.  I installed an earlier version of TeaKettle and had no errors connecting to my WinXP box which is running the TightVNC server.

I tried a setting of Scale = 0 and it seemed to work flawlessly...although talk about a tiny display...

The only thing I noticed (and I didn't really run it through a lot of tests) was that the screen was inverted when running in landscape mode (I was not running teakettle in magnified mode if that makes any difference).  Luckily, when I turned my Zaurus 180 degrees, everything looked right!

Thanks for your many efforts.  Your OPIE Reader is the most used program on my Zaurus...it would be hard to live without it.

Matt
*

Thanks for the feedback. It is nice to know it does work for someone other than me 8^).

The scale = 0 option probably isn't much use for windows boxes where the size of the served display must be the same as the physical display - although I do use it for monitoring sometimes (control is pretty much impossible with buttons about the size of a pixel 8^)).

It works okay with my linux and Mac boxes, though - but even then for serious work I wouldn't use it - but it is "nice to have".

The rotation direction was chosen for my convenience on my SL5000 - I can easily flip it 180 degrees (I'll make it configurable). See the next release 8^).
TimW
QUOTE(sidmoraes @ Mar 17 2006, 02:27 AM)
Does not work with realvnc...
*

It does for me! RealVNC is my server of choice both on Windows and XP (mostly because it lets me try out the latest encoding I've added and is more compliant to the standards - but generally, when I'm not tweaking vncviewer code, I use tightVNC on windows, RealVNC on linux and OSXVnc on Mac).

How about a little more detail....

For example, run "teakettle 2>trace.txt" and send me trace.txt, or just teakettle on its own from the console and let me know what it prints out, or what operating system is the server on, what screen res and colour depth its using, whether it crashed or failed to connect, whether you were using 0.5 and it used to work with previous versions, etc.

Then I may be able to help 8^).
TimW
QUOTE(TimW @ Mar 17 2006, 10:24 AM)
The rotation direction was chosen for my convenience on my SL5000 - I can easily flip it 180 degrees (I'll make it configurable). See the next release 8^).
*

I've got all orientations working (0, 90, 180, 270 degrees) so if anyone is in a hurry for this functionality post here and I'll put it up. Otherwise I'll leave it until there are a few more improvements to make it worth while.

Oh, and I think I've got a version which'll work on Opie ROMs - which is good as I started doing this specifically for my Simpad running Opie! I'm just testing it out on 3.5.4 (typically I got it working on the previous version the day the new version came out).

Let me know if anyone wants to test an opie version....
loji
I'm using teakettle_0.5 and i recieve the same errors as stated:

OGDict: hashStringKey: Invalid Null Key
KRFBConnection: Socket error 1


I am running a 5600 w/ Wapaton 1.6.1 ROM, No overclocking
I have a Linksys wifi card, on a wep enabled home network.

I have TightVNC running on a winXP box that accepts local connections, so it's running. The VNC server log files don't even show a connection attempt form the Z, so i guess the socket error means it's not even getting out.

What could be the problem here? IPK installed fine - no dependancy problems.
TimW
QUOTE(loji @ Mar 20 2006, 06:40 PM)
What could be the problem here?  IPK installed fine - no dependancy problems.
*

How far have you got after starting up teakettle?

Do you even get the dialog displayed?
Have you managed open up the new bookmark?
Have you managed enter everything on the server screen?
Does it crash when you hit the connect button/the okay button/any other button?

Sorry for the tedious questions but this is really puzzling so I have *no* idea what is going on. There is a reference in the original keypebble readme to a bug in QSocket which causes a mysterious crash when connecting to a non-existent server. I can't reproduce this but maybe this is what you are hitting and it is caused by the Zaurus not being able to see your desktop?

I've used tightvnc on against a WinXP box without problems - though I was hitting the problem where tightvnc wanted a 32 bit session and the Zaurus wanted something less but wasn't filling in the whole of the response correctly - but that is all fixed in 0.5. (BTW, have you configured the XP firewall to let VNC through?).
loji
From a terminal or application icon I can start Teakettle

The dialog opens, I create a new connection
I enter my local server IP
leave display at 0 (tightVNC is configed for auto display#)
enter the password
and hit connect


At this point I can switch to the terminal to watch it run, and it jsut gives OGDict errors .. untill in the end it spits out a socket error

It doesn't ever actually crash ... it just can't connect (or seem to get far enough along to tell the CF wireless card to send packets) I haven't tried sniffing with another comp yet, but the server log doesn't show any connection attempts. . eventaully I jsut close the application normally.

I do not have the XP firewall enabled, and went as far as to totally shutdown my personal one. So there should be nothing in the way of the Z. I have a Dlink router, which doesnt' default to blocking VNC ports.


hmm .. .

----- edit ----
I wanted to add I'm using the wlan-ng drivers for the linksys :: so wlanconfig commands (assocciated with hostap drivers) don't work .. for this reason scripted applications like SLapASS fail . . but VNC shouldn't be hardscripted to call those ?
TimW
QUOTE(loji @ Mar 21 2006, 06:02 AM)
I wanted to add I'm using the wlan-ng drivers for the linksys :: so wlanconfig commands (assocciated with hostap drivers) don't work .. for this reason scripted applications like SLapASS fail . .  but VNC shouldn't be hardscripted to call those ?
*

You're right. The only things teakettle does with the lan is high level stuff - so long as IP is working, it doesn't care whether is is PPP, ethernet, wireless, USB or whatever.

I'll take a *very* close look at what happens when you press connect tonight.

In the meantime, you should also be able to connect by hitting the OK key or the OK button at the top right of the dialog. On some models this doesn't work, which is why I added the big connect button, but, just in case it is something to do with the button (unlikely, I know) it may be worth trying these alternative methods.
TimW
I think I've found the problem. You *must* give the server a bookmark name. This is the bottom-most box on the "Server" tab.

I'll put a fix in that allows "anonymous" connections in the next release but in the meantime, just give the bookmark a name.
loji
I just found the same conclusion during my show at work today. . . I do live sound for theatre, and the reason I want VNC is to remote admin a mac running the playback system. This way I can hit 'go' sequences from anyplace on my Z. but while I was sitting between cue I was trying to find what was amiss (i love my z for sitting in the dark at work! biggrin.gif)


I was able to run a session with somewhat low latency on OSXvnc over an ad-hoc connection simply by naming all fields



Thanks alot for the great app and attention
TimW
QUOTE(loji @ Mar 22 2006, 06:33 AM)
I was able to run a session with somewhat low latency on OSXvnc over an ad-hoc connection simply by naming all fields
*

I use it to administer my headless Mac Mini.

For OSXvnc, the best encodings seem to be zlib or zrle (depending on which I've worked on last). I recommend using these unless you are short of processing power on your Mac.

It's also worth remembering that I've fixed the "Check for screen updates" functionality so you can make that big if you want to minimise CPU impact, or small if you need low latency.

I tend to make it large when monitoring and smaller when controlling. Even when controlling you don't have to make it too small because it is the *minimum* time between updates. So long as that time has passed an update will be sent immediately.

Anyway, here is the fixed version. It also contains support for 0, 90, 180, 270 degree rotation and the rotation code is a little faster than it was.
oldhat
Very Nice! Running against x11vnc (a utility to export a currently running X session for those that haven't tried it) and works very well. The only glitch I've run across is if I attached to the server using a Scale of 0, then detach, change the Scale to 1, then reattach all in the same teakettle session, teakettle only uses the upper corner of the screen on my C860 during the second connection. Exiting teakettle and restarting fixed the problem. Guessing there is some state info left lying around from the Scale 0 connection that didn't get reset when the Scale was changed to 1?

All in all *very* nice! Keep it up!
oldhat
QUOTE(oldhat @ Mar 23 2006, 11:57 PM)
Very Nice!  Running against x11vnc (a utility to export a currently running X session for those that haven't tried it) and works very well.  The only glitch I've run across is if I attached to the server using a Scale of 0, then detach, change the Scale to 1, then reattach all in the same teakettle session, teakettle only uses the upper corner of the screen on my C860 during the second connection.  Exiting teakettle and restarting fixed the problem.  Guessing there is some state info left lying around from the Scale 0 connection that didn't get reset when the Scale was changed to 1?

All in all *very* nice!  Keep it up!
*


Well, I can't recreate the same situation, so maybe I messed up a setting. I've tried all combos of scale setting/resetting and different color depths, and its working like a champ!
TimW
QUOTE(oldhat @ Mar 24 2006, 04:57 AM)
Very Nice!  Running against x11vnc (a utility to export a currently running X session for those that haven't tried it) and works very well.
*

Thanks for the report.

I used to use x11vnc but the version I've got only supports a few encodings none of which were particularly efficient. IIRC in the end I settled for using CoRRE but I'm not sure. OTOH, I was using it on a lan so I could just have used raw encoding but by that stage I was testing the more advanced encodings so I needed tightvnc and realvnc to exercise them.

I just had a look at the project page for x11vnc and it looks like the more advanced encodings are now in there so guess what I'll be installing tonight 8^). I'd suggest zrle is most likely the best encoding to use if your version supports it.

I'm pretty much out of ideas for improving this ATM. I don't want to add tight encoding as it looks pretty memory intensive, looks pretty complex and it isn't that well documented - plus it doesn't improve much on zlib and zrle (unless you want fuzzy jpegs).

If I can find specs for the protocol invoking server side scaling I'll add that, too - but I can't find them anywhere.

Any one else got any features they want added?
oldhat
QUOTE(TimW @ Mar 24 2006, 05:30 AM)
QUOTE(oldhat @ Mar 24 2006, 04:57 AM)
Very Nice!  Running against x11vnc (a utility to export a currently running X session for those that haven't tried it) and works very well.
*

Thanks for the report.

I used to use x11vnc but the version I've got only supports a few encodings none of which were particularly efficient. IIRC in the end I settled for using CoRRE but I'm not sure. OTOH, I was using it on a lan so I could just have used raw encoding but by that stage I was testing the more advanced encodings so I needed tightvnc and realvnc to exercise them.

I just had a look at the project page for x11vnc and it looks like the more advanced encodings are now in there so guess what I'll be installing tonight 8^). I'd suggest zrle is most likely the best encoding to use if your version supports it.

I'm pretty much out of ideas for improving this ATM. I don't want to add tight encoding as it looks pretty memory intensive, looks pretty complex and it isn't that well documented - plus it doesn't improve much on zlib and zrle (unless you want fuzzy jpegs).

If I can find specs for the protocol invoking server side scaling I'll add that, too - but I can't find them anywhere.

Any one else got any features they want added?
*



That's one reason I like x11vnc, it allows for server side scaling (and does a pretty nice job) to cut down on the data being transfered. But I can't tell if it allows it on the fly, or if its a one time setting at program startup.
TimW
QUOTE(oldhat @ Mar 24 2006, 02:08 PM)
That's one reason I like x11vnc, it allows for server side scaling (and does a pretty nice job) to cut down on the data being transfered.  But I can't tell if it allows it on the fly, or if its a one time setting at program startup.
*

I've seen one other reference to server side scaling but I have never seen a spec. The other reference suggests that the client negotiates it during the session set up.

I've downloaded the x11vnc source and I'm going to take a look at it to see if I can work out how it works. I doubt that it'll be too difficult to implement. OTOH, this could be something different to the previous reference and you may only be able to set it at start-up - but I have "high hopes".
TimW
Mixed success. x11vnc does allow server side scaling but you can't control it from the client. OTOH, there was enough info in the source for x11vnc that I was able to implement the request for server side scaling into my version of keypebble and have had it working with osxvnc. Using server side scaling to get the size approximately right and applying client side scaling to fit the screen works really well (for some more fun you can change the Mac screen resolution on the fly...).

I've also made the client scaling options more flexible so you can scale by (e.g.) 2/3 or 3/2.

Not quite enough to warrant a release but if anyone is needing these features let me know.

Also, let me know if there are any other features needed before I wrap things up for now.
jpearn
Hi,

Does this work with Cacko OK ?? I'm just trying it on Cacko 1.23 for the 3200 and it seems to jump to a black screen with 'Please wait' followed by what looks to be the system switching to 320x240 res with all the program icons look big and out of place. It will connect OK but should it not be running at 640x480 ?? !!
I must be doing something wrong smile.gif

Thanks

Jason.
xamindar
tap and hold the stylus on the icon. a window will pop up with a couple of checkboxes. uncheck the one that says something about magnify for 640x480 screens.
jpearn
Thanks, thats worked great !!
ken
Where do you enter the port info?
TimW
QUOTE(ken @ Jun 8 2006, 10:45 AM)
Where do you enter the port info?
*

IIRC, the screen numbers correspond to different ports with screen 0 corresponding to port 5900, screen 1 -> port 5901 etc.

If this doesn't achieve what you want, let me know and I'll sort something out for you.
ldrolez
Hi !

It would be nice to post the sources on your web site so that I could list it on zaurus.palmopensource.com !

Thanks for your work,

Ludo.
ken
QUOTE(TimW @ Jun 8 2006, 10:49 PM)
QUOTE(ken @ Jun 8 2006, 10:45 AM)
Where do you enter the port info?
*

IIRC, the screen numbers correspond to different ports with screen 0 corresponding to port 5900, screen 1 -> port 5901 etc.

If this doesn't achieve what you want, let me know and I'll sort something out for you.
*



how about lower numbers? like 5400 and such?
TimW
QUOTE(ldrolez @ Jun 29 2006, 08:35 PM)
Hi !

It would be nice to post the sources on your web site so that I could list it on zaurus.palmopensource.com !

Thanks for your work,

  Ludo.
*

Theoretically the sources should go back into opie but I'm not getting any responses from the opie-devel list - maybe I'm being classified as spam - does anyone sell teakettles via spam? 8^)

I'll see if I can get a fix in for this...
QUOTE(ken @ Jun 30 2006, 12:53 AM)
QUOTE(TimW @ Jun 8 2006, 10:49 PM)
QUOTE(ken @ Jun 8 2006, 10:45 AM)
Where do you enter the port info?
*

IIRC, the screen numbers correspond to different ports with screen 0 corresponding to port 5900, screen 1 -> port 5901 etc.

If this doesn't achieve what you want, let me know and I'll sort something out for you.
*



how about lower numbers? like 5400 and such?
*


...and then I'll put the source up again - either here or on my web-site.
ken
QUOTE(TimW @ Jun 29 2006, 08:51 PM)
I'll see if I can get a fix in for this...


thanks!
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.