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

Automatic headless outputs #6

Merged
merged 6 commits into from
Feb 12, 2024
Merged

Conversation

any1
Copy link
Contributor

@any1 any1 commented Jan 27, 2024

This automatically creates a headless output instead of relying on NOOP-1.

Headless outputs can be resized, so this will allow VNC clients to set arbitrary modes on the output.

The auto-headless plugin will need to be added to the relevant configuration files and the wayfire-pi script needs to be modified to enable the headless outputs. Mine looks like this:

#!/bin/sh

. /usr/bin/setup_env

export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export DESKTOP_SESSION=LXDE-pi-wayfire
export WLR_XWAYLAND=/usr/bin/xwayland-xauth
export XAUTHORITY=~/.Xauthority
export WLR_BACKENDS="drm,headless"
export WLR_HEADLESS_OUTPUTS=0

if [ -f "$HOME/.config/gtk-3.0/gtk.css" ] ; then
  rm "$HOME/.config/gtk-3.0/gtk.css"
  sync
fi

if raspi-config nonint gpu_has_mmu ; then
  exec /usr/bin/wayfire $@
else
  exec /usr/bin/wayfire -p $@
fi

@spl237
Copy link
Contributor

spl237 commented Jan 30, 2024

Just tried merging this. It all built fine, but even without the changes to wayfire.ini and wayfire-pi, I am still getting a valid output when headless. My understanding based on the above is that that should not happen?

@any1
Copy link
Contributor Author

any1 commented Jan 30, 2024

I am not sure what you mean by "valid output".

Before these changes, you should see "NOOP-1" when there is no output connected. After the change, you should see "HEADLESS-N" where N is a positive integer. When there is an output connected you should not see either of "NOOP-1" or "HEADLESS-N".

There are two separate protocols for enumerating outputs. One is the core object registry and the other is wlr-output-management-v1. The former will always show you all physical and virtual outputs including the noop, but the latter excludes the noop.

For enumerating wl_output from the registry, one can call: wayland-info -i wl_output

For enumerating output-management outputs, one can call wlr-randr

@spl237
Copy link
Contributor

spl237 commented Jan 30, 2024

I was expecting that the new changes would mean that I would only get an output when headless if I made the corresponding changes to the config to enable the new behaviour. But from what you say above, I assume that I am getting the NOOP output when I haven’t made the changes, and will get the new HEADLESS output if I do make the config changes?

@any1
Copy link
Contributor Author

any1 commented Jan 30, 2024

But from what you say above, I assume that I am getting the NOOP output when I haven’t made the changes, and will get the new HEADLESS output if I do make the config changes?

Yes, that appears to be the most likely outcome, but this can be tested by calling wlr-randr in the two different scenarios.

@spl237
Copy link
Contributor

spl237 commented Jan 31, 2024

This doesn't seem to be working all that well for me.

Without the auto-headless plugin and those environment variables, I get the same behaviour as before.

With those changes, I can indeed see a display labelled as HEADLESS-2 in wlr-randr. But a lot of other things seem to be broken:

  • Booting with no HDMI display connected boots to greeter rather than desktop. If I then log in at the greeter, the desktop starts briefly; then enlarges to a larger screen size, before clearing to a grey window rather than the desktop, and then dropping back to the greeter again. I can't actually get to a usable desktop.
  • Booting with an HDMI display connected gives a desktop on the local display, but the mouse and keyboard are unresponsive. Logging in via VNC while in this state gives a workable mouse and keyboard in the VNC session, but not on the local seat. If I disconnect the HDMI display at this point, this is when I can see the HEADLESS-2 display in wlr-randr, but I cannot use the local seat at all - if I reconnect the HDMI, the display works, but local mouse and keyboard do not.

@any1
Copy link
Contributor Author

any1 commented Jan 31, 2024

Looks like this needs more work.

@any1
Copy link
Contributor Author

any1 commented Feb 4, 2024

I'm taking a different approach to this now being that things are somewhat fragile w.r.t. outputs coming and going. Now the NOOP output is just resizeable. I also fixed a potential crash due to uninitialised pointer.

Edit: I should also mention that config changes and changes to the script are no longer required, nor will they do any good.

@spl237
Copy link
Contributor

spl237 commented Feb 5, 2024

OK, this now means that I can see the HEADLESS-2 output in wlr-randr, which is good. You say it is resizeable, but the only mode offered by wlr-randr is 1920x1080, and if I try to force it to another size, I get told that the size requested is an "unknown mode". I can set the orientation to inverted, and that seems to work, so the output is responding to wlr-randr - it just cannot be resized with it.

Edit - which may, of course, be a wlr-randr problem?

Edit2 - ah, need to use the "custom-mode" option in wlr-randr, not "mode"! That works fine.

@any1
Copy link
Contributor Author

any1 commented Feb 5, 2024

You shouldn't be seeing HEADLESS-2. This is a completely different approach where instead of creating headless outputs, the NOOP-1 output is now resizeable.

I force pushed the changes. Did you pull fail?

@spl237
Copy link
Contributor

spl237 commented Feb 5, 2024

Hmm. OK, I am now seeing the NOOP-1 output, and it is resizeable. Not sure why I was still seeing the HEADLESS-2 output when I tried earlier - I might have forgotten to reboot. But it all seems to work fine for me now.

@spl237 spl237 merged commit 91ffd31 into raspberrypi-ui:master Feb 12, 2024
@spl237
Copy link
Contributor

spl237 commented Feb 12, 2024

Looks fine - many thanks!

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

Successfully merging this pull request may close these issues.

3 participants