Conversation
Tools can make use of the wlr-output-management-v1 protocol to configure outputs. Let's drop the "last" special case and leave all of the output configuration up to an external tool.
|
What is the best utility that uses wlr-output-management-v1 to set the compositor to use a single screen? or just do clone mode (with or without scaling) for something like |
|
I do see Kanshi is in Debian, so I guess it can be a dependency for I am testing it now gets me EDIT: I need the number of output lines to match the number of outputs in the profile, I guess I could create like 16 different profiles with 1-16 screens, that should more than cover it... |
|
Yeah, hardcoding all of these outputs isn't super great but is a viable workaround. For a proper fix: https://gitlab.freedesktop.org/emersion/kanshi/-/issues/11 For output mirroring, see https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/101 |
I will take a look. However I am realizing that upon creating the full file, the profiles that specify more screens than there actually are, cause "duplicate output" errors, so it might not be viable at this point, unless I am doing wrong. (If I have 3 outputs, and a profile with 4 output lines, it gets treated as a duplicate, and errors out the parsing) I'm thinking maybe I can trap SIGWINCH, and use wlr-randr, to enumerate and then position the outputs with wlr-randr... |
|
Is it possible to use kanshi to reproduce the |
|
Something like this maybe: I've opened this feature request to be able to easily write any kind of output config logic with a wlr-randr script: https://gitlab.freedesktop.org/emersion/wlr-randr/-/issues/3 |
|
In the same topic, I think it would be nice if Cage does not try to configure a new output if a Wayland client is currently registered as a wlr-output-management protocol listener. |
Ref #452 |
|
@n3rdopolis For your use-case, kanshi v1.9 now supports this syntax: |
|
I do see that, and I did pounce on that already in I do think though adding this to cage is slightly more compact, I already have foot calling a script, but other users would have to call kanshi from a script that is also called by cage Although the binary is pretty small, so the size doesn't matter as much, seeing that initrds are compressed for vt-less systems that need Cage for the panic routine. Also this constrains the regions to the smallest screen instead of the largest, IMO, it's more usable for a terminal, but that's just my opinion |
Tools can make use of the wlr-output-management-v1 protocol to configure outputs. Let's drop the "last" special case and leave all of the output configuration up to an external tool.