VNC Server

I’m using Avalanche on the ArmX6 to view a number of rPi’s running RO5.23. I can’t find a way to send ctrl-shift-F12 to the pi’s. Am I missing something? I’ve accidentally shut down the ArmX6 several times trying to do this. It would also be useful to be able to send alt-break and control-break.

I can’t find a way to send ctrl-shift-F12

Have you tried the Switcher menu option on the remote machine?

I have a number of Pi RO 5.24 systems all with the keyboard fix which Colin produced on 11-May-2018. They all run with no known issues ….

I am using Avalanche 0.22 as the client. That connects to all the other VNCservers OK.

Any ideas?

Identical CPU speeds and mouse delay times in !configure?

Identical CPU speeds and mouse delay times in !configure?

Probably not. I will investigate and report back. Will probably take a while.

Probably not. I will investigate and report back

Hmmmm. Interesting. I connected to the server in question and started to open the configure window and it just started working. I will see if that is repeatable whilst I check the the points you suggested.

Identical CPU speeds and mouse delay times in !configure?

OK. I have set the arm_freq in Config.txt to 900 in all cases and it all seems to work now.

But the Pi boards are a mixture:- Pi 2 Version 1 (Cortex A7), Pi 2 Version 2 (Cortex A53), and Pi 3B+. Do I need to leave them all running at the slower CPU speed?

The mouse speeds were all the same. (slowest possible)

Do I need to leave them all running at the slower CPU speed?

Unsure, but I was guessing at a timing issue. If setting the CPU speed higher causes intermittent failures then I would report the details to Jeffrey, so he can investigate.

I seem to remember having intermittent mouse control issues when testing a version a while back(few years), this may be something similar but needing an edge case of higher CPU rate to trigger it.

Many thanks for your help.

I will try to make time to experiment with various CPU speeds, but for now it all looks good.

I will try to make time to experiment with various CPU speeds …

Life is not as simple as that. (Is it ever?)

I have tried with the client (Avalanche) CPU running slower than the server and also with the client CPU speed running faster than the server and it made no difference. I could always drag the windows (location and re-size) with all the different CPU speeds tried.

In fact, I can no longer reproduce the original error!

That’s what happens when you look closely.
It’s the Observer effect

VNCServer appears to have a behaviour where it continues to use a lot of CPU time after the client disconnects from it. I don’t know at this point whether it’s doing something like polling or blindly broadcasting.

I noticed the behaviour a while ago when an RPi I connected to became sluggish and had the CPU stuck at the high MHz on CPUClock. In the Linux port I can see the RISC_OS process continue to use 100% of a core after disconnecting from VNC.

I don’t know what to do. Maybe for now I could just make a restart obey file to kick myself off and resume waiting for a connection or something?

I have some old redundant raspberry pi’s I thought I’d put to good use running the distributed.net client headless under riscos. VNC works great for this when the pi is booted while plugged into a monitor using HDMI, however when I boot the PI with no monitor connected I just get a blank screen when I connect remotely. Unfortunately my monitor is my TV and it’s not convenient to have them located there. I’ve tried adding hdmi_force_hotplug=1 to config.txt to force it to think that it’s connected to a screen using HDMI but still get a blank screen when I connect remotely. I’m using VNC viewer for google chrome on a chromebook, any ideas please?

You need to explicity state the resolution in config.

Thanks Chris, that may have pointed me in the right direction. Looking at various sources online I can’t find anything specifically about setting resolution for VNCServer in config but if I want a default screen resolution of 1366 × 768 I can add hdmi_group=2 and hdmi_mode=39 so I’ll try this tonight and see what happens.

Yeah – just using the config.txt hdmi_group and hdmi_mode settings (or similar) is what Chris was referring to, I believe.

Thanks for your suggestions, I added the two lines above, both with and without hdmi_force_hotplug=1 but got exactly the same result, I get the connection password when I connect to the VNC server but then just get black screen. Any other suggestions as I’m not sure what to try from here?

*vncserv_enable_filter 1

I have tried this setting and it quite transformative, vnc is much nicer in use, after I had got used to icon drags not working. Unfortunately on both the Titanium and RPi3B+ the processors never reduced to their idle speeds and ran somewhat hot as a consequence.

No different I’m afraid David, back to the drawing board. I also tried a different client on a windows PC in case it was a client issue but no luck there either.

Edit: I have just tried disabling the auto start for the distributed.net client just in case, still no joy. Next step is a clean install of riscos and try that. Edit 2 – Which didn’t work.

This is so frustrating in the fact that it works for every-one else except me :-(

I think the VNC server is excellent in use, but I did have one or two challenges setting it up the first time, but I think they were related to using 5.23.

I am using vncserver version 0.19 (19 Jan 2018) on three Raspberry Pi boards:-
– A Ras Pi 2 Cortex A7 with a monitor via an HDMI to VGA Adapter at 1024×768 resolution
– A Ras Pi 2 Cortex A53 with an HDMI (DVI) monitor at 1920×1080 resolution
– A Ras Pi 2 Cortex A53 – headless at 1024×768 resolution

I use !Avalanche (version 0.22 28th December 2009) and a Windows XP client.

None have anything special in the config.txt file or elsewhere except that vncserver is auto started at boot time, together with a few other apps.

CPUclock shows that they all revert to slow speed after the client disconnects.

All are using 5.24 (with Colin’s keyboard fix from 11th May 2018.

One issue I still have is that the order in which other tasks start up can affect whether window drag is going to work or not. Currently it is OK on all three systems.

CPUclock shows that they all revert to slow speed after the client disconnects.

Thanks, I had not noticed that.

I have some old redundant raspberry pi’s I thought I’d put to good use running the distributed.net client headless under riscos. VNC works great for this when the pi is booted while plugged into a monitor using HDMI, however when I boot the PI with no monitor connected I just get a blank screen when I connect remotely

I used to have this problem with a headless ARMX6. It was an EDID issue on there, I seem to remember, so depending on which version of RISC OS you’re using on the Raspberry Pi, it may be the same thing. On the ARMX6, I just stopped loading the EDID stuff, which I think can be achieved on later versions of RISC OS on the Pi by creating a file called cmdline/txt in !Boot.Loader with the single line of

disable_mode_changes


It might work, so I guess it’s worth a try?

Thanks for your suggestions, to summarise the current situation

RPi1 model B with clean install of riscos v.5.24 and vncserver V0.19 (19/1/2018) configured to start on boot, vnc works fine if the pi is booted connected to a TV with an HDMI cable but if booted without the cable I get a black screen after putting in the vnc password. I have specified a screen resolution of 1024 × 768 by adding the lines hdmi_group=2 and hdmi_mode=16 to CONFIG/TXT and added a text file called cmdline/txt to !Boot.Loader with the line disable_mode_changes to prevent EDID loading, however I still get a black screen using vnc if booted without being connected to a screen.

CPUclock shows that they all revert to slow speed after the client disconnects.

In all circumstances, or just when a clean disconnect occurs?
i.e. Under certain connection failure circumstances it has been noted that only a stop and start of the server process will allow the client to reconnect, this is presumably a circumstance where the server still sees an open socket connection.
This spinning process could keep the processor at a high rate – not unknown on Unix and Linux either.

A keep-alive in the server – client setup could cover this, failure of keep-alive should drop the “active” connection at the server end.

added a text file called cmdline/txt to !Boot.Loader with the line disable_mode_changes to prevent EDID loading, however I still get a black screen using vnc if booted without being connected to a screen.

I have had a fiddle around here and been completely unable to get a black screen over vnc from a headless Pi. My best offer was a small screen over vnc when headless, when with the monitor connected it was 1920 × 1200. The card is a vanilla-ish OS5.24 as originally downloaded from ROOL. The RISC OS Screen Configuration defaults to EDID which is undefined if the monitor is not found. The work around is to save the EDID generated MDF with the monitor connected and use that. Just guessing really, a small screen is not a black screen.

There are two components to this, how the Pi gpu sets itself up with the monitor and what RISC OS passes to the gpu. vncserver reads the output from RISC OS not the gpu.

The screen information utility from here shows what is going on.