Score:1

Using x11vnc when the screen is off

in flag

I have a small server hooked up to a projector and recently upgraded from Ubuntu 18 to Ubuntu 22. There were some issues at first with screensharing via x11vnc but after some tinkering and disabling wayland I was able to get it working.

The issue I'm having is that when the projector is turned off, the screen sharing no longer works. I seem to connect and I can see application windows, but the desktop background flashes between an image and a black screen and none of my input works. There is no lock screen configured and I have an active logged-in user session with a graphical desktop. On the old system this worked and I could still control the screen whether or not the projector/monitor was turned on. I suspect it might have something to do with changing from lightdm to gdm.

The command and options I'm running specifically are:

x11vnc -xkb -noxrecord -noxdamage -avahi -allinput -rfbauth /etc/x11vnc.pass -forever -rfbport 5900 -display :0

I don't see any error in the journal logs Example::

Dec 22 19:02:24 hm80 x11vnc[4969]: 22/12/2022 19:02:24 Got connection from client 192.168.0.17
Dec 22 19:02:24 hm80 x11vnc[4969]: 22/12/2022 19:02:24   0 other clients
Dec 22 19:02:25 hm80 x11vnc[4969]: 22/12/2022 19:02:25 Normal socket connection
Dec 22 19:02:25 hm80 x11vnc[4969]: 22/12/2022 19:02:25 Disabled X server key autorepeat.
Dec 22 19:02:25 hm80 x11vnc[4969]: 22/12/2022 19:02:25   to force back on run: 'xset r on' (3 times)
Dec 22 19:02:25 hm80 x11vnc[4969]: 22/12/2022 19:02:25 incr accepted_client=9 for 192.168.0.17:58992  sock=8
Dec 22 19:02:25 hm80 x11vnc[4969]: 22/12/2022 19:02:25 Client Protocol Version 3.3
Dec 22 19:02:25 hm80 x11vnc[4969]: 22/12/2022 19:02:25 Protocol version sent 3.3, using 3.3
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27 Got connection from client 192.168.0.17
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27   1 other clients
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27 Normal socket connection
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27 incr accepted_client=10 for 192.168.0.17:58993  sock=10
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27 client_count: 1
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27 Client 192.168.0.17 gone
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27 Statistics             events    Transmit/ RawEquiv ( saved)
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27  TOTALS              :      0 |         0/        0 (  0.0%)
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27 Statistics             events    Received/ RawEquiv ( saved)
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27  TOTALS              :      0 |         0/        0 (  0.0%)
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27 Client Protocol Version 3.3
Dec 22 19:02:27 hm80 x11vnc[4969]: 22/12/2022 19:02:27 Protocol version sent 3.3, using 3.3
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 Enabling full-color cursor updates for client 192.168.0.17
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000450)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000044C)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 Enabling NewFBSize protocol extension for client 192.168.0.17
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000044D)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000451)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000044E)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 Using zlib encoding for client 192.168.0.17
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 Pixel format for client 192.168.0.17:
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28   32 bpp, depth 32, little endian
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 Enabling full-color cursor updates for client 192.168.0.17
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000450)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000044C)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 Enabling NewFBSize protocol extension for client 192.168.0.17
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000044D)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000451)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000044E)
Dec 22 19:02:28 hm80 x11vnc[4969]: 22/12/2022 19:02:28 Switching from zlib to zlib Encoding for client 192.168.0.17
Dec 22 19:02:29 hm80 x11vnc[4969]: 22/12/2022 19:02:29 client_set_net: 192.168.0.17  0.0031
Dec 22 19:02:34 hm80 x11vnc[4969]: 22/12/2022 19:02:34 client 10 network rate 112.6 KB/sec (6333.6 eff KB/sec)
Dec 22 19:02:34 hm80 x11vnc[4969]: 22/12/2022 19:02:34 client 10 latency:  1136.2 ms
Dec 22 19:02:34 hm80 x11vnc[4969]: 22/12/2022 19:02:34 dt1: 1.3067, dt2: 0.0046 dt3: 1.1362 bytes: 147693
Dec 22 19:02:34 hm80 x11vnc[4969]: 22/12/2022 19:02:34 link_rate: LR_DIALUP - 1136 ms, 112 KB/s

What I can do to get this working again?

NovHak avatar
cn flag
I doubt the display manager could interfere, and I know it’s not very helpful, but you could check by installing `lightdm` again. You could try other display managers too… `apt-cache showpkg x-display-manager` shows the `x-display-manager` virtual package is provided by : `xdm`, `wdm`, `slim`, `sddm`, `nodm`, `lxdm`, `lightdm`, `gdm3`.
NovHak avatar
cn flag
`nodm` is a special case, it’s not really a display manager since it’s just a means of automatically opening an X session at boot. No authentication whatsoever… Also, are you running an X session or a Wayland session ? If Wayland, that could explain things…
Eaten by a Grue avatar
in flag
@NovHak - it's an X session. Wayland is disabled. I'll try installing lightdm sometime this week and let you know how it goes.
ar flag
What software is your client? I use KRDC and linux or Chicken of the VNC on mac. Also I see the super high latency of 1 second: `client 10 latency: 1136.2 ms` and suggest the server is removing your desktop background picture causing the flicker. Swap HDMI ports, disable screen saver and standy. Swap projector for a monitor.
Eaten by a Grue avatar
in flag
@Tomachi - I was using OS X native screensharing. I tried Chicken just now and it almost-kind-of worked. Same background flashing. I was able to move a window just a bit and then it crashed and said "Error 255". I realize now that OS X screensharing is actually controlling the screen as well but *very* high latency - 2 or 3 seconds and most of my input is lost. It's just odd that none of this happens when the projector is on. I tried swapping HDMI ports and screen save is already off.
Eaten by a Grue avatar
in flag
@NovHak - I tried installing lightdm and nothing changed (other than the headache of reconfiguring things). I then tried swapping projector for a monitor and the problem went away. Screensharing still works with the projector on, but when it's off there is an incredible latency, flashing background and assorted graphical artifacts. The fact that it's "kind-of" working in a broken state leads me to believe that there must be a setting somewhere to get this functioning again.
Eaten by a Grue avatar
in flag
@Tomachi - see comment above
NovHak avatar
cn flag
I don’t have a projector myself and don’t have a precise enough idea of how it interfaces with the system, but what comes to my mind is that when it’s off it’s possible that some driver related to it remains loaded and unresponsive (or responding slowly). Maybe unloading the driver manually, ideally _before_ powering off, would do the trick ?
Eaten by a Grue avatar
in flag
@NovHak - Have no idea. But please bear in mind this worked totally find with Ubuntu 18 on a different box which is what I was running prior with the same projector. As far as I can tell, It's basically just a monitor to the OS. What's odd to me is that it somewhat works but not well enough to be useable. Normally I expect things to either work or fail. Having it continue to work with an odd performance degradation makes me really confused. Probably has somethinng to do with the desktop backround flashing on and off and sending that event over the VNC. hmmm...
BaTycoon avatar
mm flag
Shouldn't you use display :1 and not :0 since latest changes to xinit 1.4.1 (U22.04) from xinit 1.3.4 (U18.04).
Eaten by a Grue avatar
in flag
@BaTycoon - no `:0` works, `:1` fails.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.