Raspian has a built-in VNC server, and I wish to use it under RISC OS to do those dificult things web-wise like banking – well, just banking for now – in a VNC window under RISC OS! I’ve previously done this with a NetBook running Ubuntu, but which has now died!

Using Avalanche 0.22 I can connect easily with RISC OS machines (RPis), but not with Raspian, which claims from error reports to be using VNC 3.3 (which should be OK!).

Have tried both RPi3 and RPi2 (ARMv7) without success.

From the Raspian notes it appears that port 5800 is used by the inbuilt-server rather than 5900, but Avalanche just signals “Connecting to …” and eventually gives up.

Just as a follow-up, if anyone would like to take-on using, say, I²C as an interface instead of the network to connect, say, a Pi Zero as a Linux 2nd processor to work in a window, that’d be great for many RISC OS users – but I suspect that’s just a flying porcine dream!

Just downloaded and tested Avalanche on pi2 connecting to Raspbian on a pi3. And it works fine… but does need a couple of changes. Assuming you are using the RealVNC server, in Options, Security, change Unix password to VNC password. And Encryption to prefer off. Then in Users and Permissions set a password for Standard User.
Also, you say you’ve got port 5800 not 5900, that sounds like maybe you have ‘serve VNC viewer for java’ rather than ‘allow VNC connections over tcp’ under Connections.

I’m sure other set ups work, but for me that proved it could be done at least. HTH

if anyone would like to take-on using, say, I²C as an interface instead of the network to connect, say, a Pi Zero as a Linux 2nd processor to work in a window,

Uh…no. Not unless you like watching the window be drawn.

Seriously, now:

Default RISC OS runs the IIC port at 100kHz. My hack bumps that up to 400kHz ‘cos it’s the twenty first century now. Eight data bits are followed by an Ack bit. I’ll let you work out the effective data rate, suffice to say, not a lot.

RISC OS assumes it is the only host on the system so it takes control of SCL (clock), and it probably doesn’t understand clock stretching by slower devices (and isn’t the Pi’s IIC hardware bugged when it comes to this?).

RISC OS on the Pi disables interrupts when doing IIC transfers. Annoying, as pushing ~10K to an OLED can cause music playback to abort. Imagine what’ll happen if trying to transfer huge amounts of data. IIC wasn’t designed for that!

I was running an older version of Raspian on a Pi 3. Chrome worked fine, and VNC seemed to, connected, but failed to authenticate.

Eventually I noticed that the VNC version on the Linux m/c said it was ARMv6!

Replacing the Raspian distro with the latest fixed the problem, and now I can, after finding the screensize setting in Preferences>Raspberry Pi Configuration > Resolution > Set Resolution (requiring a reboot to take effect!) to get my VNC screen to 720×400 and setting Chrome to 80%, now have a working system to update my spreadsheets (Fireworkz) from a window under Chrome via VNC showing my internet banking account windows.

Thanks Will for showing me it could be done and spurring me on not to give-up!

I’m using Avalanche 0.22 (28-Dec-2009) on a BBxM to work a headless RPi. However, various of the control keys don’t work as expected – for a very basic example, backspace doesn’t work in a writable icon, but Ctrl-H does! Even the Return key doesn’t, though Control-M does.

v0.16 contained various control key fixes – snippet of ReadMe:
Added support for many more VNC key codes (e.g. Home, End, and the keypad)
Fixed builtin Ctrl-modification of keypresses ignoring the right Ctrl key
Improved Ctrl-modification of most keys to send them through KeyV instead of
inserting bytes into the keyboard buffer; this fixes e.g. Shift-Ctrl-C / Shift-
Ctrl-V in StrongED being detected as Ctrl-C / Ctrl-V

and v0.17:
0.17 2017-02-04 [jeffrey]
Fixed handling of character codes >= 128 when inserting into keyboard buffer
All keyboard input received from the client will now be translated to the
current RISC OS alphabet (requires Service_International 8 / RISC OS 5). This
enables the full range of UTF-8 characters to be used if using a Unicode-
capable client and ‘UTF8’ alphabet on the server.
Improved clipboard text handling to also perform translation to and from the
current RISC OS alphabet.

I’m running Avalanche 0.22 on my armx6 and identical copies of VNCServer 0.18 on my iyonix, beagleboard, pandaboard and pi (I copy a master folder to each device so each is identically configured). Each connection to each computer is also configured identically in Avalanche.

The pi, pandaboard and iyonix only allow the following control chars ctrl-E, ctrl-G, ctrlH, ctrl-J, ctrl-U, ctrl-W and also Return. So keyboard shortcuts for cut copy and paste don’t work.

The beagleboard works as you would expect all control chars are passed through so ctrl-X, ctrl-C, ctrl-V control the clipboard.

Colin: Just to be clear – is it the server or the client which is showing problems for you?

You’ll be able to get some debug output from VNCServer if you have SysLog running and *set vncserv_debug 1 before starting the server. That should show you what keypress events are being sent to the OS. If you want to see the raw VNC keypress data as it comes from the client, you’ll have to edit io_keypress in server.c to enable the first dprintf call, and then rebuild the module. That might help if it looks like the client is behaving oddly.

I’d guess it is the server. I’m only using avalanche on my armx6 all the other machines are running the server. As the avalanche (armx6) to server (beagleboard) works absolutely correctly – control keys work – avalanche must be working ok. Also F12 (either key press or via the avalanche menu) doesn’t work on the other machines but does when connected to the beagleboard.

F12 (and maybe the Ctrl keys as well) sounds like it could be the kernel KeyV debounce issue, which should have been fixed by the introduction of the vncserv_stretch_keys option in version 0.16. But that setting should be enabled by default. Although I don’t think I was ever able to reproduce the issue when running the server on RISC OS 5, so maybe there’s a second problem which needs to be dealt with.

Do all the machines have keyboards connected? Maybe there’s some odd behaviour if a machine is running headless or via a KVM switch.

Also double-check that you are running 0.18 on all machines, and that there aren’t any unexpected differences in the configuration/startup files.

Do all the machines have keyboards connected? Maybe there’s some odd behaviour if a machine is running headless or via a KVM switch.

I was just about to post that query!

Using either Avalanche on the Titanium or VNC Viewer on the Mac with a headless, and keyboard less, RPi3, the missing key presses return if if the RPi has seen a keyboard.

P.S. I should say I discovered this entirely by accident having messed something up requiring a keyboard to be attached to correct the mess and noticing the issue had “gone away”. In my case nothing to do with expertise.

OK, that makes sense. There are a few bits of the OS’s keyboard handling which are dependent on the type/layout of the connected keyboard, so if the machine hasn’t seen a keyboard yet then those bits won’t work very well. I think I can ask the OS if a keyboard is present, and if not have VNCServer register a fake one to kick the keyboard handling into life (one of the drawbacks of the OS’s keyboard handling is that you can’t have multiple keyboards connected of different types, so the server is designed to piggyback on the existing keyboard as much as possible)

I can confirm that, once a real keyboard has been plugged in, keyboard handling in VNC server (even 0.15) appears to work correctly. All I need to do is plug in a keyboard for long enough for it to be recognised, then unplug it (and re-plug it back where it belongs!). That’s it.

Not a good enough solution for real life, but it’s clearly been a good diagnostic. Thanks to everyone who has chimed in.

If you need a work around, until Jeffrey has time, running this program on the server machine seems to work ok for me. It just checks if there is a keyboard id present and if not announces a pc keyboard is present at the KeyV.