romangg
commented
4 years ago marked this issue as related to kwinft#66
Closed romangg closed 8 months ago
romangg
commented
4 years ago marked this issue as related to kwinft#66
romangg
commented
4 years ago Added a conclusion section. Result of a discussion with Simon in #sway-devel about this topic. Protocol:
[18:12] <romangg> wlr-output-management has a description event that is some free text to describe the output similar to xdg-output. How can a translation system in the client translate such information since it's not structured?
[18:13] <romangg> For exampel the example
[18:13] <romangg> 'Virtual X11
[18:13] <romangg> output via :1'
[18:13] <romangg> sorry for formatting...
[18:14] <emersion> i'd say the translation would need to happen in the compositor if you want to translate anything…
[18:16] <romangg> ok, that's what I feared. Would you be up for adding some events so clients can add translations: events for manufacturer (code) and model name.
[18:16] <romangg> I'm currently brainstorming the problem a bit: https://gitlab.com/kwinft/disman/-/issues/20
[18:20] <emersion> why do you need the client to do the translation?
[18:20] <romangg> Presenting it in a UI.
[18:21] <emersion> yeah?
[18:21] <emersion> why can't the compositor do it?
[18:21] <emersion> this doesn't address the issue in xdg-output
[18:22] <romangg> I'm unsure compositors in general want to include a translation system. But yes, then it could be done this way. Where is xdg-output description event actually be used?
[18:25] <emersion> the xdg-output event will be presented to the user when they need to select an output
[18:25] <emersion> i mostly use CLI tools so i don't really know
[18:25] <romangg> :)
[18:26] <romangg> for example in a game I guess
[18:26] <emersion> i know phosh uses it
[18:26] <romangg> where to show the game fullscreen window.
[18:26] <emersion> yeah, that would be a use-case indeed
[18:26] <romangg> interestingm thanks.
[18:26] <romangg> Ok, then it definitely makes sense to have the translation in the compositor
[18:26] <romangg> so the xdg-output description is translated too
[18:26] <emersion> i wonder if other parts of wayland need translations…
[18:27] <emersion> i agree it's annoying, but i don't see a better way
[18:27] <romangg> Well the idea I had was sending make and model name which are normally not translated and then let the client create a string.
[18:27] <emersion> a unified description is better than each client inventing its own hand-made description imho
[18:27] <romangg> But since we have already the desciption event in xdg-output I'm reluctant to change this up again.
[18:28] <romangg> also true
[18:28] <emersion> wlroots uses a trick to not have to translate anything
[18:29] <emersion> it just sets description to "<vendor> <model> <serial> (<name>)"
[18:29] <emersion> it's not optimal
[18:29] <romangg> Your example for nested displays in the protocol xml is of different nature though. ;)
[18:30] <romangg> Another question is about identifying outputs. wlr_output_management_unstable_v1 provides the name event but that is about a connector. it should also provide some identifying information about the display hardware itself. but one could misuse the description for that if wlroots set it as you described.
[18:30] <emersion> what do you mean by "display hardware"? do you have an example?
[18:31] <emersion> > 1920x1080@60+;800x600@120
[18:31] <emersion> hm, i don't really get it
[18:31] <romangg> I have here a 4K monitor and a 1200p monitor. Both can be connected to DP-1. But only one of them supports setting a 4K resolution.
[18:32] <emersion> i see
[18:32] <emersion> GNOME displays something like "13" screen"
[18:32] <emersion> or "Samsung 13" screen"
[18:33] <romangg> I have worked on KDisplay in the last two weeks. And it loads a stored previous configuration on display hot-plug if available. For that it needs to know what displays are connected on hot-plug (so it can load the correct one).
[18:33] <emersion> less techy users probably care more about "VGA" than "VGA-1" (they know the connector type, not the connector name)
[18:33] <romangg> It could do this in its wlroots backend with the description event as you described.
[18:34] <emersion> also, this may be relevant https://lists.freedesktop.org/archives/dri-devel/2020-April/261419.html
[18:34] <emersion> (some laptops have a DP port on the GPU, which actually is an HDMI port on the side of the laptop)
[18:35] <emersion> while i'm at it, this may be relevant too https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html
[18:37] <romangg> yes, but that are two different issues. I was not talking anymore about what is shown to the user but how a client can identify a connected display and distinguish it from other ones (that might have been connected to the same port in the past).
[18:37] <romangg> Normally the EDID data is used for that.
[18:37] <emersion> ah, and something i've thought about too: if two connectors have the same description ("Samsung 13" screen") then the compositor could update the description with helpful hints: "Samsung 13" screen on the left" or "Samsung <model> 13" screen"
[18:37] <emersion> ah, okay
[18:38] <emersion> so, for this, i agree output-management is lacking
[18:38] <emersion> description isn't great, and name isn't enough
[18:38] <romangg> As said the description event could be (mis)used for this at the moment as you set it to: "<vendor> <model> <serial> (<name>)"
[18:38] <romangg> (like you noted above)
[18:38] <emersion> yeah, it could be abused like this, but exposing something else would be better
[18:39] <emersion> damn, github is down
[18:39] <emersion> i had an issue about this in wlr-protocols
[18:40] <romangg> For DRM one could just send the whole EDID info.
[18:40] <romangg> ddevault talked about this in https://drewdevault.com/2019/08/09/DRM-leasing-and-VR-for-Wayland.html
[18:40] <romangg> He said there that it needs a file descriptor because of Wayland message size limit.
[18:41] <emersion> the whole EDID is perhaps a bit much
[18:41] <romangg> What I don't understand because I thought the message size limit is 4096byte but the EDID is only 128 byte.
[18:41] <emersion> i think mutter/gnome uses make/model/serial
[18:41] <emersion> romangg: EDIDs can have extension blocks
[18:42] <emersion> they usually have some
[18:42] <emersion> so it's easy for an EDID block to be 512 bytes or more
[18:42] <emersion> and then say you have 4 screens…
[18:42] <emersion> it's getting dangerous
[18:42] <romangg> yea, but you would send one event per screen
[18:43] <emersion> the 4K limit isn't per-event
[18:43] <romangg> but ok, I get it. if there are extensions block one can't be sure it never breaks the 4K limit.
[18:43] <romangg> wat?
[18:43] <emersion> it's per dispatch cycle
[18:43] <romangg> oh
[18:44] <emersion> sending events will fill the 4K buffer, and it'll only get emptied when the event loop runs
[18:44] <romangg> pls can this information be written down somewher. I not even found the 4K limit anymore when I tried to look it up yesterday.
[18:44] <emersion> libwayland docs would be a good place, i think
[18:44] <romangg> only in some text-input protocol it said something like "can't be more than 4000 chars because of limit"
[18:44] <emersion> ahah
[18:45] <romangg> https://gitlab.gnome.org/GNOME/mutter/blob/master/src/wayland/protocol/gtk-text-input.xml#L125
[18:45] <romangg> That's the only reference to an actual number I found when looking it up yesterday.
[18:47] <emersion> gotta go, see you later!
[18:47] <romangg> This sounds like a deficiency in the protocol itself. There should be a warning or an automatism to let the compositor know that the buffer gets full and it needs to dispatch.
[18:47] <romangg> alright, cu
[18:48] <emersion> romangg: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159mentioned in commit 589c48ee297b9a02ccf27c9e77f2ea10c8c72f2a
Overview
There are typically the following data fields provided by the windowing system to describe an output:
DP-1,DP-2.Identification
DRM
We can have several meanings of "identification" here. For real hardware this can mean:
For us in Disman the last meaning is essential since we need to guarantee to apply a compatible configuration with the current state.
Nested
The name of an output can be set to something like "nested-1" or "wayland-1", "x11-1" (there is also the Virtual connector type in Drm but it is about something different).
In regards to identifying outputs nested sessions are problematic since there are limitless combinations of output properties. In order to make sure that stored configurations are compatible all relevant properties for that (the mode list) must be encoded into the identifier. Example for such an identifier:
1920x1080@60+;800x600@120Neither name, make or model should be misused for that. We could see it as kind of a serial number for a nested output. If we use this we should either also in above DRM case identify specific properties by the serial number. Or detect if it's a nested case and only then use the serial number for that, but here we could also just make sure the stored mode is in the actual mode list.
Another option is to have a common identifier event where the mode list or the EDID is MD5-hashed on the windowing side and then this hash value sent over. This would require MD5 hashing in the compositor what might need additional dependencies. In this event sending the raw EDID data or the nested mode-list identifier over might also be possible.
On the other side as said above Disman could just detect if it's a nested session and in this case make sure by the actual mode list that the stored output data is compatible. If not then the stored output data is overridden. The mode list of nested outputs normally does not change too often to make the user experience unpleasant.
Make and model can be either omitted or set to something like "KWinFT" for the make and "X11" for the model.
Designation
In UI we normally want to either show the description or something like make and model. The problem with the description is translation. For UI therefore we should use manufacturer and model if available what shall remain untranslated and the frontend can decide how to prettify this data with additional text.
Conclusion
Designation
Since the description is used in xdg-output protocol too and clients might show it to the user (for example games which monitor to display on the fullscreen game window) it makes sense to have the translation in the compositor and use only that event in our output configuration.
Identification
DRM
For identifying an output we need EISA/PNP ID, model and serial.
Nested
In the nested case we can use what's available from this data or if none available (and compositors should do that) fall back to the name of the output and check manually if the stored mode information is compatible with the output.
This way the discussed identifier by mode list is not necessary.
No configuration in nested sessions
Another question is if compositors should at all allow configuration for nested sessions. It might make no sense to modify and/or save any output data for these.
In this case a fallback to xdg-output would be good to receive current state of the outputs and introduce a
Wrtiableflag for supported features that is not set in this case.