wlroots
wlroots copied to clipboard
swaywm
Don't expose make/model via wl_output
Similar to https://github.com/swaywm/wlroots/issues/1610, but for wl_output.{make,model}.
- These two are legacy
wl_outputproperties -
xdg-output.{name,description}are much better - It's not clear what make/model/serial is for a virtual output
- Clients shouldn't rely on it
wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1623
These properties are somewhat benign compared to the layout position. But I don't really feel strongly either way.
Well some people are thinking about using those with the wlr-output-management protocol to get the make/model. I'd prefer to make it clear output management shouldn't use wl_output (and the other way around).
But yeah it's less important than the position ofc.
In order to superseed these we should use a format in xdg-output.description that allow to extract that information.
Why would this be needed?
The current description (e.g. Dell Inc. DELL U2717D J0XYN71G742L (HDMI-A-1)) is a bit too verbose to present to the user so being able to spit out the parts like vendor & model is nice (and gradually displaying more information in case of identical vendor & model so the user can tell them apart. The current wl_output properties allow for that.`
xdg-output.description will be used by other clients displaying information about outputs (e.g. screen sharing apps, screen shooters, etc). So instead of having workarounds to re-format the title in the shell, I think it would be better to have wlroots or the compositor produce higher quality xdg-output.description.
wl_output hat distinct fields to extract information, xdg-output.descripton is free form text. In some situations you would have the above look like:
Dell Inc. DELL U2717D
while in others you might want the user to see
Dell Inc. DELL U2717D on HDMI-A-1
but I don't see how the compositor could tell what is needed so end users be able to make sense of the format. Since xdg-output is unlikely to grow structured data about the output I see these alternatives:
1.) make wlr-output-management provide that information
2.) keep the information in wl_output
3.) Cram everything into xdg-output.description in a paresable form
4.) As a band aid parse xdg-output.description client side as is
1.) would likely be best and it would even match the protocol's intent. We could Does this make sense?
wl_output hat distinct fields to extract information
These are legacy. wl_output shouldn't have had those fields.
In some situations
What are the situations you'd want to have the first and what are the situations in which you'd want to have the second form?
I'd rather not implement any of the 4 solutions. xdg-output.description exists because make/model have issues.
Your example doesn't show any use for a distinction between make/model. It shows you want a description that does not contain the name. I'm not sure why you'd want that, if you now have two identical monitors, then you aren't able to differentiate them without looking at the name property as well.
Your example doesn't show any use for a distinction between make/model
But I can only do that since I know what the vendor and the the model are.
I'm not sure why you'd want that, if you now have two identical monitors, then you aren't able to differentiate them without looking at the name property as well.
See what I wrote above. You only want to display the serial to the user if needed (in that special case you mention) otherwise vendor + model are sufficient and are things the user is more likely to know. That's why structured data is nicer.
What are the situations you'd want to have the first and what are the situations in which you'd want to have the second form?
The first form is almost always sufficient except when you have monitors of identical vendor/model. Then you want to provide additional information to the user like either serial or connector.
If the fields need to go (and I see no reason for that) clients will need to poke at the drm properties to get that information.
The first form is almost always sufficient except when you have monitors of identical vendor/model. Then you want to provide additional information to the user like either serial or connector.
Then the compositor can set the output description accordingly, and that will benefit all clients. It's not hard for the compositor to do it.
If the fields need to go (and I see no reason for that) clients will need to poke at the drm properties to get that information.
This is the worst possible solution. Clients should use output descriptions, that's what they're made for.
Then the compositor can set the output description accordingly, and that will benefit all clients. It's not hard for the compositor to do it.
That means the description of an already connected output may change when hotplugging a second one.
It's perfectly valid for the compositor to send the wl_output properties a second time to update them.
It's perfectly valid for the compositor to send the wl_output properties a second time to update them.
Both xdg_output and wlr_output_management define the description as immutable.
Maybe a new property could be used in addition to name, description like device to describe the connected device independent of the output.
https://lists.freedesktop.org/archives/wayland-devel/2019-April/040506.html
With the wayland-protocols 1.18 release, description is now mutable. We'll be able to add something like wlr_output_set_description to let compositors update the description.