Harmonize output identification and designation
Overview
There are typically the following data fields provided by the windowing system to describe an output:
- Name of the output: That is a string describing the connector and a counter, e.g.
DP-1
,DP-2
. - EDID data:
- Make/manufacturer/vendor (EISA ID or PNP ID)
- Model name
- Serial number
- Description (same as in xdg-output v2): non-standard phrase defined by compositor describing the output (often based on EDID data in some way).
Identification
DRM
We can have several meanings of "identification" here. For real hardware this can mean:
- To find out what general properties an output has. This is identified by its manufacturer and model.
- To identify an output as a real piece of display hardware. This is defined by manufacturer, model plus serial number.
- To find out what specific properties an output has in the current display configuration. Since this can depend on the connector the output uses it is defined by name, manufacturer and model.
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@120
Neither 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 Wrtiable
flag for supported features that is not set in this case.