VNC Server

Having tried several VNC Servers to connect a Pi to my Windows machine, I just cannot get anything to function in anything other than 256 greys and a ridiculously low resolution.

Now we have newer, better hardware, and faster ethernet, doesn’t someone fancy the challenge of writing a half decent VNC Server? I can’t code for toffee, so I’m at someone else’s mercy here!

Or has anyone managed to get one to function reasonably well?

Anyone feel like writing or porting a functioning VNC Server that will work relatively stably with the Raspberry Pi, and, as a bonus, the BeagleBoard and PandaBoard? One with an easy, user configurable front-end would be ideal. And one that can cope with more than 256 colours and keep working for considerably more than five minutes without crashing.

In a bizarre twist, I am prepared to pay a small amount (and I don’t mean a tenner, I mean in the hundreds) for the right, open sourced one, if someone wants to take up the challenge.

Anyone interested?

I have had reasonable success with VNCServ and VNC Viewer at full resolution and colours on a windows machine. It’s just a little slow at updating the window. This is server on the Pi and viewer on the windows MC.
VNCServ has no front end, I just placed it in my Predesk folder so it loads on boot.

It should be noted that the current version of vnc_serv isn’t ARMv7 compatible. A while ago I did have a look at recompiling it with GCC 4, but that was before OSLib was readily available for GCC 4. Now that that situation has changed it should be a bit easier to recompile it.

I’ve also considered updating it so that vnc_serv runs as a GraphicsV driver (in place of the default driver). So instead of the OS drawing to the screen and vnc_serv reading back the pixels, the OS would draw directly into a buffer managed by vnc_serv (and you’d get nothing on screen, which may or may not appeal to you). This would allow for faster operation on things like the Iyonix where reading from screen memory is deathly slow, and it was also going to be a useful way for me to test multiple display driver support in the OS. But so far I haven’t done this.

It should be noted that the current version of vnc_serv isn’t ARMv7 compatible.

There’s a recompiled with GCC4 ARMv7 safe version of vnc_serv here.

There’s a recompiled with GCC4 ARMv7 safe version of vnc_serv here.

I’m using this on Raspberry Pi RISCOS (5.19) and finding that the two vnc viewers I use both make a good VNC connection and allow the RISCOS cursor to be moved etc., but give blank screens on the viewer. (In contrast to Tank’s experience.) I’ve tried preferring a few different encodings (raw and hextile) at the viewer end and reducing the colour depth and resolution at the RISCOS end.

Is this a feature of 5.19 or of Raspberry Pi RISCOS, or something I’ve missed?

Is this a feature of 5.19 or of Raspberry Pi RISCOS, or something I’ve missed?

In my experience, it happens when you try with 16m colours, on all new hardware. If you drop to 256 colours on the Pi, it will work fine and you’ll be able to see the screen too. On a Panda or Beagleboard, it will work at 32k colours too.

After much playing about, I’m not sure if it’s just in my head, but it seems to improve its responsiveness if I reduce the refresh rate. YMMV. I try to use a 24Hz one if I can, but I don’t think it’s available on the Pi (it is on the Panda and Beagle).

I have managed to get vncserver working ok on a pandaboard.
Using the version from Chris Gransden’s website.
It works ok at 32k (even at high res)
The only issue I have found is realvnc is the only client that I could get to work.
That was on windows 7 FYI.

I’ve only used RISC OS VNC clients in the last few years. Nowadays I use Avalanche on the Iyonix to control my Ubuntu box.

Does Avalanche work for you?

I’ve not tried vnc clients on RISC OS, I’m looking the otherway round so I can do webcasts etc.
But I’ll take a look, be nice to connect to my linux partition that way

Does anybody have a Raspberry Pi image of RISC OS with a working VNC Server enabled?

I have a Pi, but don’t have the equipment to run it any other way, other than headless. So to be able to run RISC OS on it I need VNC Server already installed and working.

My VNC client would be tightvncviewer on ubuntu.

Sorry can’t help re VNC. Presumably your equipment problem is not having any screen with an HDMI or DVI intput? If so don’t you have anything with composite video in? It is present on almost all TVs or displays with SCART socket.
If space for a display is the problem, we(CJE/4D) do a suitable 3.5"
LCD! http://www.cjemicros.co.uk/micros/individual/newprodpages/prodinfo.php?prodcode=RPI-35LCD

You can even have one running off 5V and share a PSU with a Pi.
http://www.cjemicros.co.uk/micros/individual/newprodpages/prodinfo.php?prodcode=RPI-35LCD-5V

Have two TV’s with HDMI but they are not very accessible, No HDMI cable, No USB keyboard, No USB mouse. My computer uses a KVM switch and all equipment only supports VGA and non USB keyboard & mouse. Pi runs headless with SSH and VNC using Raspbian. I have RISC OS via Rpcemu under Ubuntu so its not essential to get it working on the Pi. But if there was a RISC OS image with vncserver already setup I would.

Not that it would solve your problems Keith I do think that one of the 3rd RISC OS utilities that allows the keyboard to act as a mouse should be implemented in all ROM builds. Say with *keymouse on having immediate effect.

I would also like to see a VNC server that works reliably on a Pi. I plan to have a Pi in an inconvenient location – the airing cupboard, which is the centre of all the wiring of the heating system. Rather than carry a keyboard, mouse and monitor to the airing cupboard – and still have no convenient work surface available – I’d prefer to control it remotely via VNC.

Or RDP, come to that.

Whichever it is, I’d want the server to be reliable.

This is by no means a solution, but there is the TServer module which would allow you to telnet to a command line on the RPi. If you can arrange things to work at the CLI level, that could work quite nicely. If you need desktop, you’ve got more of a problem… although you could always *screensave from TServer and then view the screendump from ShareFS and click on stuff with MouseCmd. ;)

I spent a frustrating evening yesterday trying and failing to get the VNC server module from Chris Gransden’s site to work on either the Raspberry Pi or the Iyonix.

Between the RPi and Iyonix, using Avalanche at the other end claimed a connection immediately but left Avalanche’s window black and didn’t move the mouse cursor at the far end. The symptoms were identical in both directions. I did try different colour depths but nothing appeared to make any difference.

Using the VNC server module on the Iyonix or RPi and using vinagre or another VNC client on Ubuntu 13.10, the clients appeared to try indefinitely to get a connection without success. Again no difference whether the RPi or Iyonix were server.

Presumably someone somewhere has managed to get the server to work; but with what client, with what settings, and was anything else necessary? (I only have RISC OS and Ubuntu 13.10 available to me.)

I just tried to get RealVNC’s VNC Viewer (client) on Android to connect to VNCserver on Iyonix and it just sits there with an endless “connecting” message, so at least it must be seeing 192.168.1.6:5900 specified as the Iyo’s port.

I found two versions of the vncserver module, both claiming to be 0.10 (28-Aug-2006): one 36,204 bytes, the other 34,908 bytes (Chris Gransden’s 25-Apr-2012 recompilation).

I, too, would be pleased if it were possible to demonstrate vncserver on Iyo working with ANOther client, but meanwhile wonder whether there is some setup detail that I need to correct.

I just tried to get RealVNC’s VNC Viewer (client) on Android to connect to VNCserver on Iyonix and it just sits there with an endless “connecting” message, so at least it must be seeing 192.168.1.6:5900 specified as the Iyo’s port.

Not necessarily. I regularly get this message when I try to connect to my PandaBoard (with Chris’s VNC module and the VNC server front end) from my Android phone when I forget to turn on Wifi on the phone. So it can’t see the Panda over 3G/HSDPA, but just endlessly tries to connect.

I set picture quality to Automatic on the VNC Viewer and use a password at both ends. Here are the settings on the Panda:

I set picture quality to Automatic on the VNC Viewer and use a password at both ends.

I’m only aware of one password, set at the server and quoted in the client. Here it works for both Android client and Avalanche to Windows 7 server (UltraVNC). The Android moves swiftly through ‘Connecting’ to ‘Authenticating’ to the screen display. My VNCSvr Choices are similar to yours.

On accessing the Iyo, the Android client still sticks on ‘Connecting’, so doesn’t even get as far as asking for the password.

FYI there’s now a new version of vncserver on my website, featuring a bunch of fixes and improvements: http://www.phlamethrower.co.uk/riscos/vnc_serv.php

In terms of usability, I think the main areas that need improving are:

• Performance optimisation. I haven’t bothered to optimise the pixel translation code, so this new version will be a bit slower than the old one if it has to translate between different pixel formats. But as with the DisplayLink driver, the main performance bottleneck is that the code has to manually scan the screen for changes. If we can switch to using an abort handler to track screen writes then that should be a big help.
• Adding a wimp frontend for configuration, seeing server status, etc.
• Adding clipboard support
• Memory optimisation. The transmit buffer is typically several MB in size, which is rather foolish when you consider how slow the server is (or how fast your network should be).

Many thanks for the updated VNC server Jeffrey. Just to let you know, it works fine on my Pandaboard ES, RO 5.21.

The updated VNC Server works on the Raspberry Pi, OS5.21 (18-Nov-14), and can be seen by the Mac’s Screen Sharing app on Yosemite.

Many thanks.

Great news! I’m going to have fun playing with that tonight.

Does it work on the Pi in a mode higher than 256 colours? I get that 16m will push the network to the limit, but it’s perhaps better than blocky 256 screenmodes.

Does it still work with the VNCSvr front-end, pictured above?

Does it work on the Pi in a mode higher than 256 colours? I get that 16m will push the network to the limit, but it’s perhaps better than blocky 256 screenmodes.

I haven’t actually tested it on a Pi (only Iyonix + BB), but it should work fine in all true colour modes (although performance will generally be slower, especially in 16M colour modes).

Note that operation in 256 colour modes (or when connected to 256 colour clients) has been improved as well – the server will now explicitly set the palette that the client uses, whereas before it used a generic RGB 332 palette that didn’t match the RISC OS palette very well at all.

Does it still work with the VNCSvr front-end, pictured above?

It should do – there are a couple of new *commands to cover the new features, but the old commands have remained the same.