Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VNC server's "virtual desktop" mode broken in Raspberry Pi OS Bullseye #318

Open
ghost opened this issue Jan 26, 2023 · 5 comments
Open

Comments

@ghost
Copy link

ghost commented Jan 26, 2023

The built-in VNC server can run in "virtual desktop" mode, i.e. not backed by a real display, but instead running the desktop in memory, and allowing clients to connect via VNC in the otherwise normal way. See official documentation here: https://www.raspberrypi.com/documentation/computers/remote-access.html#creating-a-virtual-desktop. In this case, the VNC server starts up on VNC display number 1, i.e. port 5901.

This works fine on Raspberry Pi OS Buster (legacy), but on Bullseye I see two different breakages.

Breakage 1: On my Pi 4 with 4GB of RAM, the mutter window manager is used by default, and it won't run on the virtual desktop.
Here's a Pi 4 with 4GB RAM after VNCing in and starting a terminal from the menu:
pi4mutter
Notice no window manager, terminal starts top left, panel menu no longer accessible.

This is a known problem, which for the console graphical desktop is fixed by forcing the use of openbox when the VNC server is enabled. Which leads me to breakage number 2.

Breakage 2: With the openbox window manager, the panel appears to start up and crash a few times, then vanish, when started from the virtual desktop. The final position looks like this on a Pi 4B 4GB:
pi4openbox

Notice no panel, so the desktop is unusable.
(The few white pixels in the middle of the top of the window client area is the VNC toolbar drawn by the VNC viewer, which drops down when you mouseover it).

@ghost
Copy link
Author

ghost commented Jan 26, 2023

I've done some more testing to see if I could get it working with openbox by disabling some of the panel applets. It seems the applets entitled Volume Control (PulseAudio) and Microphone Control (PulseAudio) are the ones that cause the panel to crash when run on the virtual desktop. Removing both of those from the panel, using the console's graphical desktop, then restarting the VNC virtual desktop allows the panel to start up OK and stay running, making the VNC session usable again.

I originally observed this on a Pi 2 (two), but switched to a Pi 4 to speed up testing, and to check it wasn't specific to Pi 2. It's not. On a Pi 2 the failure with openbox is the same, but I don't get the policykit error message on the screen.

@ghost
Copy link
Author

ghost commented Jan 26, 2023

Just for completeness, here's a screenshot of it working correctly on a Pi 4 with 4GB RAM with openbox, after disabling the two aforementioned panel applets:
workingpi4

@ghost
Copy link
Author

ghost commented Jan 26, 2023

And here's what it looks like connecting to the VNC "virtual desktop" mode on a Pi 2 running Raspberry Pi OS Buster:
pi2buster
Note the volume control applet works and doesn't crash the panel. (Although since the VNC server doesn't support sending audio, it doesn't do anything useful).

@XECDesign
Copy link
Member

@spl237

@spl237
Copy link

spl237 commented Jan 26, 2023

At a guess, the fact that audio isn't supported means those plugins are looking for some sort of virtual audio device which they cannot connect to.

Given the likelihood is that this area will be changing significantly in future, investigating problems with the current remote desktop configuration are a low priority - if I get time I'll have a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants