-
-
Notifications
You must be signed in to change notification settings - Fork 63
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
Cannot connect to wayvnc when running on labwc with no local display connected #286
Comments
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: :: |
Did you maybe run it in detached mode ( |
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 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:
|
OK, here's the journalctl output: Jan 15 10:29:49 raspberrypi systemd[1]: Starting wayvnc.service - VNC Server... |
If you run it with |
Labwc doesn't use any fallback headless output when there are no outputs left. Edit: |
Thanks, Consolatis. We can extend |
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. |
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.
Need it. |
@Consolatis, do you know if it's possible to execute the |
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 In the meantime one can hack around the issue by injecting a keyboard shortcut via the virtual keyboard protocol (e.g. via
Labwc purposefully does not support any kind of IPC other than via the wayland / wlroots protocols (and |
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 labwc/labwc#1586 which allows enabling a fallback output by setting an env var to something like |
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 |
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.
The text was updated successfully, but these errors were encountered: