Support output IDs

[wille]

I need to support targeting the output with the output identifier (Dell Inc. DELL U3223QE GB6Y9P3) rather than just the output name (eg. DP-6) because the output name might change every time I replug my monitors and I want my internal OLED display to have no image while my external monitors should have a nice image.

Example:
swaylock -f -c 000000 --image "Dell Inc. DELL U3223QE GB6Y9P3":~/Pictures/1.jpg -d

The wl_output_description returns the full model, make and output name so I am trimming the output name from the output description to match kanshi and sway output id matching.

[emersion]

Unfortunately, this adds assumptions about the format of the output description which are unreliable and non-portable across compositors. I'd rather not do that.

[wille]

You're definitively right, I was wondering if you can point me in the right direction to reliably get this ID just as in Kanshi or sway output

[emersion]

Sadly there is no way to get this information. I'm not sure just adding an event to pass it to clients is a good way forward, an opaque tag might be better, see the discussions in https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/109#note_970789

[wille]

Sorry I don't follow, both sway and kanshi supports targeting the output by the identifier which I want to do here as well.

I just pushed a new commit to simply check if the output description contains the output name provided to --image, so --image "Dell Inc. DELL U3223QE GB6Y9P3":~/Pictures/1.jpg would match the output_descripton Dell Inc. DELL U3223QE GB6Y9P3 (DP-X)

[trinitronx]

From the perspective of user-friendly per-display configuration, the use-case behind this PR is a great idea. It would unify the configuration matching behavior of output specifiers for swaylock with sway, swaybar, waybar, kanshi and similar wlroots-based projects. Additionally, wlroots-based compositors including sway, and components like swaybar already support using the EDID-based identifier (e.g. make + ' ' + model + ' ' serial) as in swaywm/sway@50d36ef23, kanshi, wlroots DRM backend, wlroots wlr_output struct, and of course the wlr-output-management-unstable protocol since version 2 supports make, model and serial.

The nice thing these days is that EDID is well supported by the vast majority of output displays, thanks to the standardization efforts of VESA, and CTA (formerly CEA) we have CTA-861. For the edge cases where devices deviate from the standards or misbehave, the EDID data can be overridden by placing files in /lib/firmware with the Linux Kernel's CONFIG_DRM_LOAD_EDID_FIRMWARE option, or in the case of supported v4l2 devices, the v4l2-ctl utility can be used to set it via VIDIOC_S_EDID. One notable example of the latter option v4l2-ctl is used by PiKVM to set the EDID from a file managed by the kvmd-edidconf utility.

Another nice thing is that EDID is also supported by the vast majority of DRM drivers. Might be worth considering using at least the make, model, and serial for the user-friendly UX benefits of identifying a display in configuration files. It's generally unique enough for most cases to identify a display output in a port-agnostic way¹. In those cases where it doesn't, the user can override the EDID data using aforementioned methods, or simply fallback to the old name matching and use the port identifiers (e.g. HDMI-A-N, DP-N) and plug in the displays accordingly. However, the benefits of EDID-based data are great for identifying a particular display especially for devices with hot-pluggable displays (e.g. laptops) and users who often plug into the same displays frequently. Examples might be plugging into a particular make & model of projector in meeting rooms, plugging in an HDMI output for temporary extended displays, etc... Being able to have a "public-facing" swaylock background image for the external displays would be a great benefit.

Footnotes

1. In most cases, the user doesn't need a 100% absolutely universally unique identifier (e.g. UUID or hash)... they just need some human-readable display name to match and configure what they want. While the port-numbered names can be useful, they often fail to provide a display-centric approach to configuration when the user doesn't plug things in the same port every time, or the kernel brings up devices in a different order for some reason. ↩