mako
mako copied to clipboard
emersion
Added support for specifying output by identifier for wlroots.
This allows for the following setting:
output=Acer Technologies XF270HU SERIAL
Which would make it so that if your output adapter changes, it would still show up on the same monitor. Unfortunately for me, my monitor outputs change frequently.
I've made a similar PR for Waybar https://github.com/Alexays/Waybar/pull/956
The code for getting the identifier from the description is almost a direct copy paste from the swaybar implementation: https://github.com/swaywm/sway/pull/3415/files#diff-f1816f4a24dbbcf1a1dc419a0daeee3ac8bfcb410a44bd9d9e75900d1210bbbcR264-R279
@vilhalmer I think both of those proposals would be definite improvements. As discussed briefly on IRC, I would hope that this suffices for now. In the future wlr-output-management could be used instead and a more granular configuration would be possible alongside a regex. Though maybe that is also overkill for the application's simplicity.
swaybar does this because it's designed to run on Sway. mako isn't designed to run just on Sway, it can run on any compositor supporting layer-shell.
The xdg_output.description is a mutable, human-readable string. It's not designed to be used for automated output selection, it's not unique and has no format.
wlr-output-management is for output management, and mako doesn't manage your outputs, so can't use the protocol.
@emersion this should work for wlroots, if there are many other users other than sway. Though regardless do you have any other suggestions for implementing this behaviour? There is a definite problem with output names as they are not unique or consistent.
this should work for wlroots, if there are many other users other than sway
wlroots compositors just have the default set to <make> <model> <serial> (<connector>) for the DRM backend. Other backends have different defaults, and compositors can customize output descriptions via wlr_output_set_description to provide more human-friendly names.
There is a definite problem with output names as they are not unique or consistent.
Output names are unique, as opposed to output descriptions.
do you have any other suggestions for implementing this behaviour?
No, the protocols don't allow to implement this.
wlroots compositors just have the default set to
( ) for the DRM backend. Other backends have different defaults, and compositors can customize output descriptions via wlr_output_set_description to provide more human-friendly names.
I understand that this is not the best way of implementing this, but you say yourself that the protocols don't implement this and thus it isn't possible otherwise. Whether the descriptions were meant to be "human-friendly" or not, they are the only way of retrieving this information. I would be up to see if this can be implemented another way as I said before, but alas there does not seem to be another way that is immediately available. Not unless we propose a new protocol, though the likelihood of that coming to fruition anytime soon is zero.
Output names are unique, as opposed to output descriptions.
Unfortunately this is not always the case. My display output names are changing on boot, on resume, and when monitors are hotplugged. I am not saying descriptions are unique, but the identifier part of the wlroots descriptions definitely are unique. Sway and swaybar acknowledge this problem and provided a workaround for it, it would be nice if other software could compromise on a solution for the users who are experiencing this problem. Additionally it makes it independent of the display interface used, and does differentiation based on the actual monitor.
No, the protocols don't allow to implement this.
Would that stop us from implementing this? Wlroots is giving a temporary solution that could at least be used for wlroots users. Worst case is that this would only work for wlroots for now.
I understand that this is not the best way of implementing this, but you say yourself that the protocols don't implement this and thus it isn't possible otherwise.
Which is why I'd prefer not implementing it.
Unfortunately this is not always the case. My display output names are changing on boot, on resume, and when monitors are hotplugged.
Unique means that at a given time two outputs don't have the same. This is true for output names, not for output descriptions. For instance some monitors have the same make/model and don't specify the serial number.
Would that stop us from implementing this? Wlroots is giving a temporary solution that could at least be used for wlroots users. Worst case is that this would only work for wlroots for now.
Sway and swaybar rely on sway-specific behaviour. This may not hold true for other wlroots compositors as noted in previous comments.
I don't want to try to put a square peg in a non-existing round hole.
Is there anything you would have me do that would improve my situation then? I understand this sentiment but this is often the trade-off being made in the Linux community. The actual user experience taking a hit because the code isn't right. Believe me I want to get this properly fixed, but if Sway didn't have this workaround it would basically be impossible for me to use.
Unique means that at a given time two outputs don't have the same. This is true for output names, not for output descriptions. For instance some monitors have the same make/model and don't specify the serial number.
This is only a solution for those where the output names are not consistent. To allow for us to at least use the software. There is no alternative.
Sway and swaybar rely on sway-specific behaviour. This may not hold true for other wlroots compositors as noted in previous comments.
Yes, but in the future this description parsing can be replaced by a better solution. A solution that currently does not exist at all.
Please consider making a compromise so I could use mako. The Wayland adoption is already so meek, I hate for this to be the norm for the sake of code quality. Again, I am asking if there is anything I can do myself to improve it.
wlr-output-management is for output management, and mako doesn't manage your outputs, so can't use the protocol.
Indeed, I missed the warning in the description. "This protocol is not designed to be a generic output property advertisement protocol for regular clients."
Sorry, but I won't merge something because a user really needs it or because they won't use my software otherwise. I have no incentive to get more users. I build software for my own needs, and make it available for others if they find it useful. If they don't, they can use something else.
That said, we should investigate to see what a solution could look like. I'm not sure right now how that would be possible, maybe by using a checksum of the EDID for xdg_output.name, but some monitors have the same EDID or no EDID. Maybe we should start with a new issue on wayland-protocols.
Another way would be to use https://github.com/emersion/mako/issues/138 to dynamically change the output.
Ref for a proper solution: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/109#note_970789
@emersion Do you think there is a way to implement this in the present? This being a way to configure mako to use an identifier unique to the monitor so configuration can be shared across multiple machines (for example a work and personal machine) and so it's irrelevant what connector is used.
My understanding is that if using the now available wl_output protocol, you would accept this PR?
@emersion I understand your reasoning for wanting to do things the proper way. You have a better understanding of what is going on with wlroots, sway, and Wayland protocols. Is there anything you see that would allow for this functionality in the future and do you have any guess on when?
It's a bit disappointing to see that functionality like this hasn't come to fruition in the last 2 years and user experience is not considered important enough to "commit a small tragedy" in the "Linux desktop world" (referring to year of the Linux desktop never coming). I am willing to help out (and definitely do more than this puny PR) if there is something tangible that can be done.
I don't think any functionality is worth pushing for hacks. If the feature is important, then it's a good reason to push for a proper solution.
I think to fix this properly we need:
- To resolve the discussions and merge https://gitlab.freedesktop.org/emersion/libdisplay-info/-/merge_requests/115
- To submit a patch to the Wayland protocol to add the sink tag to
wl_output(or a separate protocol), as suggested in the MR linked above
Closing because I do not have the time to follow up on getting something added to the Wayland protocols spec and I do not see us making a compromise here. While it's understandable to want to do things the right way, I think a more pragmatic approach is beneficial when the right way is not within easy reach.