any1
Cannot connect to wayvnc when running on labwc with no local display connected
-
Version: v0.8-rc0-6975b25 (pios)
-
Describe how to reproduce the problem When running wayfire with no local HDMI display connected, it is still possible to connect to WayVNC, and some default framebuffer is used. But when running labwc instead of wayfire, while connecting to WayVNC works fine if there is a local HDMI display, if there is no local HDMI display, the connection appears briefly with a window which is all black, and a second or so later the connection is dropped with the error message "An unexpected error occurred when communicating with the server: Invalid PixelBuffer of 21845 pixels requested"
This is using the TigerVNC client.
What happens if stop the wayvnc service and run it from terminal instead, attaching directly to the headless session? A trace log might be useful.
Not sure this will be much help...
I managed to run wayvnc from the terminal under labwc. With the monitor still connected, this time I got a grey screen in the client, but the connection didn't drop, and the same happened with the monitor disconnected. This is the output of -Ltrace:
DEBUG: ../src/server.c: 1813: Trying address: :: DEBUG: ../src/server.c: 1833: Successfully bound to address Info: Listening for connections on :::5900 DEBUG: ../src/ctl-server.c: 785: Initializing wayvncctl socket: /tmp/wayvnc/wayvncctl.sock DEBUG: ../src/ctl-server.c: 693: New connection Info: New control socket client connected: 0x55560e432570 DEBUG: ../src/ctl-server.c: 305: << {"method":"version","params":{},"id":1} Info: Dispatching control client command 'version' Info: Enqueueing response: OK (0) DEBUG: ../src/ctl-server.c: 543: Response data: {"wayvnc": "v0.8-rc0-6975b25 (pios)", "neatvnc": "0.7.1", "aml": "0.3.0"} DEBUG: ../src/ctl-server.c: 580: >> {"code":0,"id":1,"data":{"wayvnc":"v0.8-rc0-6975b25 (pios)","neatvnc":"0.7.1","aml":"0.3.0"}} Info: Control socket client disconnected: 0x55560e432570 Info: New client connection from ::ffff:10.3.31.23: 0x55560e433700 (ref 1) DEBUG: ../src/server.c: 789: Client chose security type: 19 Info: User "spl" authenticated DEBUG: ../src/main.c: 1332: Client connected, new client count: 1 DEBUG: ../src/ctl-server.c: 913: Enqueueing client-connected event: {"id":"1","hostname":"::ffff:10.3.31.23","username":"spl","seat":null,"connection_count":1} DEBUG: ../src/ctl-server.c: 940: Enqueued client-connected event for 0 clients Info: Choosing tight encoding for client 0x55560e433700
Did you maybe run it in detached mode (-D or --detached)? That would give you a grey screen until it's attached using the wayvncctl attach command.
Yes, I just ran wayvnc-run.sh from /usr/sbin; that has --detached in it.
Running wayvncctl attach (which I obviously have to do via SSH, because I have no local monitor) reports "Failed to find socket path "/run/user/1000/wayvncctl": No such file or directory"
Running wayvnc-run.sh with the --detached option removed (which requires sudo to access the crypto credentials) reports that it failed to connect to WAYLAND_DISPLAY="wayland-0", but again, I am really not sure that I am doing something sensible here.
Can you please give me step-by-step instructions as to exactly what I should do to run from the terminal rather than the service and capture the relevant trace? I originally tried just adding the -Ltrace option and the pipe through tee to wayvnc-run.sh, but that didn't produce any output file.
If you run journalctl --unit=wayvnc, you'll see the output from the wayvnc service.
If you have one wayland instance running, it should be located at "wayland-1". It might also be "wayland-2". It's probably best to run it without any authentication enabled from within an ssh session:
touch /tmp/dummy.cfg
WAYLAND_DISPLAY=wayland-1 wayvnc -C/tmp/dummy.cfg -Ltrace :: 5901
OK, here's the journalctl output:
Jan 15 10:29:49 raspberrypi systemd[1]: Starting wayvnc.service - VNC Server... Jan 15 10:29:49 raspberrypi sh[911]: tee: /home/spl/wayvnc.log: Permission denied Jan 15 10:29:51 raspberrypi sh[911]: DEBUG: ../src/server.c: 1813: Trying address: :: Jan 15 10:29:51 raspberrypi sh[911]: DEBUG: ../src/server.c: 1833: Successfully bound to address Jan 15 10:29:51 raspberrypi sh[911]: Info: Listening for connections on :::5900 Jan 15 10:29:51 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 785: Initializing wayvncctl socket: /tmp/wayvnc/wayvncctl.sock Jan 15 10:29:51 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 693: New connection Jan 15 10:29:51 raspberrypi sh[911]: Info: New control socket client connected: 0x55559d6c2570 Jan 15 10:29:51 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 305: << {"method":"version","params":{},"id":1} Jan 15 10:29:51 raspberrypi sh[911]: Info: Dispatching control client command 'version' Jan 15 10:29:51 raspberrypi sh[911]: Info: Enqueueing response: OK (0) Jan 15 10:29:51 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 543: Response data: {"wayvnc": "v0.8-rc0-6975b25 (pios)", "neatvnc": "0.7.1", "aml": "0.3.0"} Jan 15 10:29:51 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 580: >> {"code":0,"id":1,"data":{"wayvnc":"v0.8-rc0-6975b25 (pios)","neatvnc":"0.7.1","aml":"0.3.0"}} Jan 15 10:29:51 raspberrypi sh[911]: Info: Control socket client disconnected: 0x55559d6c2570 Jan 15 10:29:51 raspberrypi systemd[1]: Started wayvnc.service - VNC Server. Jan 15 10:29:52 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 693: New connection Jan 15 10:29:52 raspberrypi sh[911]: Info: New control socket client connected: 0x55559d6c6d30 Jan 15 10:29:54 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 305: << {"method": "attach", "id": 0, "params": {"display": "/run/user/1000/wayland-0"}} Jan 15 10:29:54 raspberrypi sh[911]: Info: Dispatching control client command 'attach' Jan 15 10:29:54 raspberrypi sh[911]: DEBUG: ../src/main.c: 1580: Attaching to /run/user/1000/wayland-0 Jan 15 10:29:54 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 913: Enqueueing capture-changed event: {"output":""} Jan 15 10:29:54 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 940: Enqueued capture-changed event for 0 clients Jan 15 10:29:54 raspberrypi sh[911]: Info: Capturing output Jan 15 10:29:54 raspberrypi sh[911]: Info: Attached to /run/user/1000/wayland-0 Jan 15 10:29:54 raspberrypi sh[911]: Info: Enqueueing response: OK (0) Jan 15 10:29:54 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 543: Response data: (null) Jan 15 10:29:54 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 580: >> {"code":0,"id":0} Jan 15 10:29:54 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 305: << {"method": "event-receive", "id": 1} Jan 15 10:29:54 raspberrypi sh[911]: Info: Dispatching control client command 'event-receive' Jan 15 10:29:54 raspberrypi sh[911]: Info: Enqueueing response: OK (0) Jan 15 10:29:54 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 543: Response data: (null) Jan 15 10:29:54 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 580: >> {"code":0,"id":1} Jan 15 10:30:18 raspberrypi sh[911]: Info: New client connection from ::ffff:10.3.31.23: 0x55559d6cdae0 (ref 1) Jan 15 10:30:18 raspberrypi sh[911]: DEBUG: ../src/server.c: 789: Client chose security type: 19 Jan 15 10:30:25 raspberrypi sh[911]: Info: User "spl" authenticated Jan 15 10:30:25 raspberrypi sh[911]: Info: Starting screen capture Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/main.c: 1332: Client connected, new client count: 1 Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 913: Enqueueing client-connected event: {"id":"1","hostname":"::ffff:10.3.31.23","username":"spl","seat":"seat0","connection_count":1} Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 940: Enqueued client-connected event for 1 clients Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 580: >> {"method":"client-connected","params":{"id":"1","hostname":"::ffff:10.3.31.23","username":"spl","seat":"seat0","connection_count":1}} Jan 15 10:30:25 raspberrypi sh[910]: wl_display@1: error 1: invalid arguments for [email protected]_virtual_pointer_with_output Jan 15 10:30:25 raspberrypi sh[910]: ERROR: ../src/main.c: 503: Failed to dispatch pending Jan 15 10:30:25 raspberrypi sh[910]: *** BUG *** Jan 15 10:30:25 raspberrypi sh[910]: In pixman_region_init_rect: Invalid rectangle passed Jan 15 10:30:25 raspberrypi sh[910]: Set a breakpoint on '_pixman_log_error' to debug Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 913: Enqueueing detached event: {} Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 940: Enqueued detached event for 1 clients Jan 15 10:30:25 raspberrypi sh[910]: *** BUG *** Jan 15 10:30:25 raspberrypi sh[910]: In pixman_region_union_rect: Invalid rectangle passed Jan 15 10:30:25 raspberrypi sh[910]: Set a breakpoint on '_pixman_log_error' to debug Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 580: >> {"method":"detached","params":{}} Jan 15 10:30:25 raspberrypi sh[911]: Info: Client 0x55559d6cdae0 (1) hung up Jan 15 10:30:25 raspberrypi sh[911]: Info: Closing client connection 0x55559d6cdae0: ref 0 Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/main.c: 1275: Client disconnected, new client count: 0 Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 913: Enqueueing client-disconnected event: {"id":"1","hostname":"::ffff:10.3.31.23","username":"spl","seat":null,"connection_count":0} Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 940: Enqueued client-disconnected event for 1 clients Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 580: >> {"method":"client-disconnected","params":{"id":"1","hostname":"::ffff:10.3.31.23","username":"spl","seat":null,"connection_count":0}} Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 305: << {"method": "attach", "id": 2, "params": {"display": "/run/user/1000/wayland-0"}} Jan 15 10:30:25 raspberrypi sh[911]: Info: Dispatching control client command 'attach' Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/main.c: 1580: Attaching to /run/user/1000/wayland-0 Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 913: Enqueueing capture-changed event: {"output":""} Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 940: Enqueued capture-changed event for 1 clients Jan 15 10:30:25 raspberrypi sh[911]: Info: Capturing output Jan 15 10:30:25 raspberrypi sh[911]: Info: Attached to /run/user/1000/wayland-0 Jan 15 10:30:25 raspberrypi sh[911]: Info: Enqueueing response: OK (0) Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 543: Response data: (null) Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 580: >> {"method":"capture-changed","params":{"output":""}} Jan 15 10:30:25 raspberrypi sh[911]: DEBUG: ../src/ctl-server.c: 580: >> {"code":0,"id":2}
- When running wayfire with no local HDMI display connected, it is still possible to connect to WayVNC, and some default framebuffer is used. But when running labwc instead of wayfire, while connecting to WayVNC works fine if there is a local HDMI display, if there is no local HDMI display, the connection appears briefly with a window which is all black, and a second or so later the connection is dropped with the error message "An unexpected error occurred when communicating with the server: Invalid PixelBuffer of 21845 pixels requested"
Labwc doesn't use any fallback headless output when there are no outputs left.
You could either start labwc in headless mode (WLR_BACKENDS=headless, but couldn't add local outputs anymore) or you could add a virtual output to the usual session via VirtualOutputAdd.
Edit: There is another generic restriction in regards to the screen capture implementation in wlroots: AFAIR it is driven by the frame callbacks from the outputs themselves. This may for example cause issues when you run a nested labwc session (e.g. using the wayland backend of wlroots), attach wayvnc to it and then minimize / cover up the window. That would then prevent the frame callbacks to come in and thus wayvnc wouldn't see any updates until the nested window is visible again. This might be the same when having a local output connected but suspended / powered off.
Thanks, Consolatis.
We can extend wayvnc-control.py in the pios branch to add and remove the virtual output depending on whether there is a physical one available or not.
or you could add a virtual output to the usual session via VirtualOutputAdd.
Could labwc automatically create a virtual output if there are no real outputs detected? Is there any reason not to do that? (I am assuming this is what wayfire does anyway?)
As far as I understand, wayfire has a dummy headless output for the purpose of always having an output available in case some client depends on there always being an output available. labwc doesn't care about that (or need it?).
I've been looking at this and the way things are implemented in wayfire, it seems that capturing of the NOOP output just works by accident. I don't think that it was meant to be used for this purpose. However, I did manage to hack it so that you can control the NOOP output via output-manager and I'll send you the patches for that soon.
or you could add a virtual output to the usual session via VirtualOutputAdd.
Could labwc automatically create a virtual output if there are no real outputs detected? Is there any reason not to do that?
Technically we could, yes. However we decided against that to not accidentally cover up potential crashes or other bugs that may arise when there is no output left.
As far as I understand, wayfire has a dummy headless output for the purpose of always having an output available in case some client depends on there always being an output available. labwc doesn't care about that (or need it?).
Need it.
@Consolatis, do you know if it's possible to execute the VirtualOutputAdd action on startup or if you can send it via unix socket?
if it's possible to execute the
VirtualOutputAddaction on startup
Currently that is not possible in a clean way. We thought about having a generic autostart config section for actions (rather than random applications) but so far we only see a use-case for the VirtualOutputAdd command which points to a generic autostart section not being the right move forwards. We are currently not sure how to proceed with a solution. Another option could be to add a config option that creates a virtual output by default in a disabled state so applications like wayvnc could enable it via the output management protocol or wlr-randr before connecting and disable it again when disconnecting. CC @johanmalm
In the meantime one can hack around the issue by injecting a keyboard shortcut via the virtual keyboard protocol (e.g. via wtype or wlrctl in the generic ~/.config/labwc/autostart or before connecting via wayvnc) but that obviously requires user configuration of the keybind and is in general pretty hacky.
or if you can send it via unix socket?
Labwc purposefully does not support any kind of IPC other than via the wayland / wlroots protocols (and SIGHUP to reload the config if you want to call that IPC).
In the meantime one can hack around the issue by injecting a keyboard shortcut via the virtual keyboard protocol (e.g. via wtype or wlrctl in the generic ~/.config/labwc/autostart or before connecting via wayvnc) but that obviously requires user configuration of the keybind and is in general pretty hacky.
That is very hacky indeed and probably not even much less of an effort than just implementing the "enable fallback virtual output" config option.
Agreed - automatically creating a virtual output when no real outputs are present would be by far the tidiest way of doing this.
If that behaviour is not always desirable for the purpose of debugging etc - which is fine - then let's have it as a command-line option or similar with it disabled by default. But hacks involving injecting keyboard strokes are really not the way we should be doing this!
Labwc just merged https://github.com/labwc/labwc/pull/1586 which allows enabling a fallback output by setting an env var to something like LABWC_FALLBACK_OUTPUT=NOOP-fallback. That should then also allow wayvnc to detect it as a headless output.
I've been fiddling witht this some more, and there seems to be an occasional bug whereby connecting an HDMI output after booting with no output crashes the outputs completely. Sometimes it works fine, but on other occasions you just end up with a grey screen in the VNC client and no output on the HDMI.
I think this is an effect of the recent changes - the older versions before the code was refactored didn't do it, and rolling back to one of them seems to fix the problem. I'll try and work out which change is causing the problem.
A condensed labwc -d log would be useful. Suggest moving this discussion to the PR.