VNC Server

Is there a way to start the VNC server automatically when the RPi boots, like in Raspbian?

All I do is place VNCSvrFE in Apps, and then run it from !Boot. The easiest way to do this is double-click !Boot and when the Configuration window appears, click once on Boot. In the Boot Sequence window, click once on Run. The drag the VNCSvrFE app from Apps into the window that appears. This will enable it to run at startup. Click Set and it’s good to go. If you’re using the Front End, double click it in the Apps window so that it appears on the iconbar. Middle-click over the VNCServer icon, click on Choices and tick the Start Automatically option. That should do it!

Andy, by ‘VNCSvrFE’ do you mean the ‘vncserver’ Module? It’s the first time I do something like this, so I’m a little lost.
I imagine to configurate the port and password I need to change the ‘start’ file. How I know this port in the RPi and what client can I use from a Windows machine?

Thank you very much.

I imagine to configurate the port and password I need to change the ‘start’ file.

I didn’t have a 32 bit version of VNCSvrFE and took the easy route:

I created a handy directory and put VNCSvr module in it along with the start and stop obey files.
The start obey file gets run by the Run of the boot configuration as described above.
The start file is edited to match my requirements. The port can remain as the default, or for more security bu obscurity you can specify a port with a different number. Change the “bob” entry to something different for the password.

Using the RealVNC Viewer select the advanced options and expert tab, scroll down to “PointerEventInterval” and change from the default 0 to 10 (this value seems to be OK for stability and doesn’t particularly impact on performance.)

Yes, I set it up the same way last night on the RPi that is about to become my new central heating controller.

Hi! after using the VNC server in the RPi for two weeks, today I’ve noticed that my ‘Control and Enter key’ don’t work. I’ve reestablished RISC OS’s keyboard but no result :( Does anyone have the same problem?

Does anyone have the same problem?

Not here. Used it solidly for a couple or three of weeks. Very stable and only ever goes wrong when the system crashes.

FYI I’ve just released an updated version of the VNC server. Bug fixes, performance improvements, and clipboard support.

http://www.phlamethrower.co.uk/riscos/vnc_serv.php

I’ve got some more ideas for improving performance (e.g. using the filter manager to listen out for window redraw and rectangle copy messages), so there’s a chance I’ll be looking at that over the next few weeks.

Top work Jeffery, that’s already much more responsive, really appreciated!

Great stuff, Jeffrey, there’s a very noticeable improvement there. Thanks a lot!

As everyone seems to be saying, great work Jeffrey. Not only more responsive but less likely to crash when the keyboard / mouse update is set at a small interval. Not yet tried the VNC viewer default value of “0” but then that’s probably a bad idea anyway.

As everyone seems to be saying, great work Jeffrey.

Thanks!

Not yet tried the VNC viewer default value of “0” but then that’s probably a bad idea anyway.

I haven’t made a conscious effort to fix the mouse/keyboard update rate handling yet, so yeah that would probably be a bad idea.

Instead I’ve been messing around with adding support for the zlib & ZRLE encodings. ZRLE has some interesting tile encoding options that I think are quicker to compute than hextile (and produce smaller results), but the high overhead of zlib compression (even at level 1) means that I think it will always end up using more CPU time than just hextile would. I might toy with allowing the user to set the zlib compression level to 0, but in general I think the only time you’d see a useful benefit to zlib/ZRLE would be when you are actually using VNC over a slow network (i.e. internet) rather than over a high-speed LAN. Not that that’s a bad thing, but it is a bit annoying that the user would have to configure things differently depending on the use case (another option I can think of would be to have the server only use zlib/ZRLE if it detects that the client isn’t on the local subnet)

Once I’ve finished playing with that I’ll probably be looking at optimising the update logic as a whole – at the moment the server only keeps track of one rectangle which needs sending to the client, so if something in the top left of the screen changes (click on an icon) and something in the bottom right (!Alarm updates its iconbar icon) you’ll end up with a massive rectangle which covers almost the entire screen being sent to the client. Once the server is capable of tracking and buffering multiple update rectangles it should then be a lot easier to start playing around with things like the filter manager events, or with restricting the send buffer size to a sensible level.

And then maybe I’ll fix the mouse/keyboard update rate handling ;-)

That would be very nice. To my mind one of the biggest advantages of VNC is the ability to use Win2VNC – One keyboard and mouse with 3 screens – Windoze in the middle with Linux one side and RISCOS on the other.

The RISCOS mouse would benefit from a bit some update response improvements.

But stiil a great product! Thank you.

I’d like to (rather belatedly) add my thanks, too. Great stuff!

To my mind one of the biggest advantages of VNC is the ability to use Win2VNC – One keyboard and mouse with 3 screens – Windoze in the middle with Linux one side and RISCOS on the other.

Now that sounds very interesting. You don’t fancy porting that to RISC OS, do you, Jeffrey?! ;-)

I think I’m getting close to having a new version of the VNC server ready for release. I’ve done a big refactor of the framebuffer update handling which has allowed the transmit buffer size to be reduced (the encoders now operate on small chunks of data at a time, allowing large rectangles to be broken down into small chunks and processed asynchronously), and the server is able to track multiple rectangles which need updating.

I’ve also had a play around with using the filter manager to track screen updates – despite the filter manager not really being designed for this use case, it mostly works OK. At the moment the main problems are that the standard Wimp text caret isn’t tracked (no filter manager events are generated for caret rendering), and there needs to be some code to make it fall back to scanning for screen updates manually if you leave the desktop. There’s also the possibility of improving the code to make proper use of the rectangle copy events (there’s a “rectangle copy” message in the VNC protocol), but it’s a bit of a headache to work out how to pipeline the rectangle copies with the other framebuffer updates, so I suspect I won’t be tackling that for the upcoming release.

However I will probably have a go at tackling the mouse update rate, because I’ve noticed that if you tell RealVNC to rate-limit its updates it can make things feel slower than they actually are (e.g. menu item highlighting lagging significantly behind the pointer movement on the client, because the server only receives pointer updates at about 5-10 per second)

Hi! after using the VNC server in the RPi for two weeks, today I’ve noticed that my ‘Control and Enter key’ don’t work. I’ve reestablished RISC OS’s keyboard but no result :( Does anyone have the same problem?

Contrary to what I said in January, I do now! I’ve checked it with different clients (both RISC OS and Windows), and like Adrian, my Enter/Return key doesn’t work! Nor does Ctrl (or F12, although that might be deliberate?). It becomes a bit problematic when typing!

The above “control, function, enter” issues seems to be intermittent on mine. Sometimes it just works, sometimes it just doesn’t and I can’t decipher any kind of reason.

Another issue I seem to have is that I can’t get it to work properly at any resolution above 1024×768 on a RiscPC. I’ve tried it with a Viewfinder and using the VIDC. When I try to connect from a different machine using Avalanche, it says Connected in the status bar at bottom left, but it doesn’t ask for a password, and I’m left with a black window that just sits there permanently. If I run VNCServer on an ARMX6, I can connect to it from any machine using Avalanche at 3440×1440!

Anyone have similar experiences?

I only get this “control, F12, enter” problem when I connect a Pi2 or Pi3 directly to a laptop or another RISC-OS machine. I’ve tried quiet a few clients but all have the same problem. If I connect into my network then it works flawlessly. Not having an Enter key is a bit of a problem!

Another issue I seem to have is that I can’t get it to work properly at any resolution above 1024×768 on a RiscPC.

The current version of the server is very memory hungry – it tries to allocate 8*width*height bytes of memory for its send buffer, plus it allocates another buffer for storing a copy of the screen. For old machines this can easily total to an amount that’s larger than can fit in the module area, or maybe even more memory than you have in the machine!

The new version of the server I mentioned a few posts above should fix this, but I’ve still got a few nasty bits to tackle before it’s safe for release.

I only get this “control, F12, enter” problem when I connect a Pi2 or Pi3 directly to a laptop or another RISC-OS machine. I’ve tried quiet a few clients but all have the same problem. If I connect into my network then it works flawlessly. Not having an Enter key is a bit of a problem!

I’ve been able to reproduce this now, when checking for the screen size/memory issue reported above – if I run the server on my RiscPC then the control/enter/function keys don’t work. But if I run it on a Pi, BeagleBoard, iMX6, Iyonix, etc. it seems to be fine (either that or I never used the keyboard enough to notice – most of the time I’m testing the screen responsiveness).

Anyway – now that I have a reliable way of reproducing it I can hopefully come up with a fix.

The new version of the server I mentioned a few posts above should fix this, but I’ve still got a few nasty bits to tackle before it’s safe for release.

Anyway – now that I have a reliable way of reproducing it I can hopefully come up with a fix.

That’s great news, Jeffrey! Very much appreciated!

New version is now available. Mouse update rate, control/F12/enter, excessive memory usage, and many other problems should be fixed.

http://www.phlamethrower.co.uk/riscos/vnc_serv.php

For the curious – the control/F12/enter issue was that the server was running on a machine where kernel debouncing of KeyV was enabled (RiscPC with PS/2 keyboard), and the client (!Avalanche) was sending rapid down-up events for the keys (presumably because it’s stuck using Wimp key events instead of being able to track the up/down transitions directly). So now there’s an option (enabled by default) to ‘stretch’ the key down events so that they’re long enough for the kernel to register them as a valid key press. Although I am left wondering why people were seeing the issue on newer machines (anything with a USB keyboard should have the kernel key debouncing disabled).

I have been using ‘TightVNC’ with the VNC server on the Iyonix.

All seems to be working – but have been trying to use the right key ‘Menu’ – with keymapper – the key between alt and ctrl.

Ctrl works as a RO menu button – but not the Menu key.
Is this down to TightVNC or the RO server?
Thanks

Its only now that I discover that there is a new version of the vncserver module! Thanks for the update, it works fine on Pi 2 in 256 colours.

16M colours – with the Iyonix here >> TightVNC or !Avalanche on a RO emulator.

‘!Avalanche’ is RO’s other end.

The module works well… but not the keyboard handling.

With a French keyboard, azerty is in the right place, but à is not printed, nor shift+à (should be 0), nor alt-gr+à (should be @). Etc.

Speed is OK, and stability is here. So it’s almost perfect, and a good way to use old software on new hardware (just connect to a Pi1 connected on the local network with Avalanche).

Only limit, I’m not sure Avalanche will very stable on Pi2 / Pi3.
(it was not very stable on my Pandaboard)