How can I get stable video output names?

I ran into similar issues, and thought it would be useful to add some information to this post in case anyone else experiences problems relating to the changing of port IDs between X.org and /sys/class/drm.

On the https://bbs.archlinux.org/viewtopic.php?id=244118 Arch Linux thread, one key was noted:

It's less xrandr and more amdgpu.

To correct this further, it's not xrandr, xrandr is simply what exposes the Xorg port IDs to the user, as you could see in the /var/log/Xorg.0.log samples.

Also, the 'solution' to downgrade kernels to avoid this behavior (to 4.18) at that point obviously isn't, and never was, a solution in any real sense.

There's a few things to notice here:

• Each Xorg driver behaves in different ways, for example, when we hit this issue, someone dug up the relevant amdgpu code where DP-1 for example was changed to DisplayPort-0 by amdgpu. It would take more data than I have access to determine the behavior of each Xorg driver when it comes to how it handles Port IDs internally.

• The /sys/class/drm ports I believe require kernel modesetting capable drivers, with modesetting enabled. There's a reasonably good summary of drm / kms here: http://trac.gateworks.com/wiki/linux/display To quote:

DRM [Direct Rendering Manager] is the driver subsystem in the kernel that is able to communicate with video drivers, such as the Freescale I.MX6 processors. Through ioctl() calls, multiple userspace programs can draw to a display at any given time as DRM will manage these requests. DRM is also able to interface with the graphics processor (GPU) in order to hardware accelerate these requests.

DRM drivers deal with DMA, AGP memory management, resource locking, and secure hardware access. In order to support multiple, simultaneous 3D applications the 3D graphics hardware must be treated as a shared resource. Locking is required to provide mutual exclusion. DMA transfers and the AGP interface are used to send buffers of graphics commands to the hardware. Finally, there must be security to prevent clients from escalating privilege using the graphics hardware.

Kernel Mode Setting (KMS) is a method for setting display resolution, pixel depth, and screen refresh in the kernel space rather than user space. In the past this was done in user-space by the X-Server. Modern video drivers like the etnaviv driver for the IMX6 GPU support KMS. The Linux kernel's implementation of KMS enables native resolution in the framebuffer and allows for instant console (tty) switching. KMS also enables newer technologies such as DRI2 which help reduce artifacts and increase 3D performance.

This level of the graphics stack is hard to wrap your head around, but from what I can see, the Ports in /sys/class/drm are similar to the devices in for example /dev/sdX, which can and do shuffle at every boot, depending on the detection sequence, not on what the device actually is.

I've looked, so far in vain, for some way to directly connect the Xorg port IDs with the /sys/class/drm IDs, but so far have not been able to find such a way. It does appear that the Xorg display drivers have some way to create 'sticky' port IDs, but unfortunately, they also apply fairly random transformations to those IDs, which makes directly connecting them to the relevant drm port ID far more difficult than it should be.

These transformations can be quite random, for instance, on one card, you might have drm ID eDP-1 and Xorg ID eDP, or drm HDMI-A-1 and Xorg HDMI-0, it depends I believe on the specific display driver, though I don't know how that works internally in Xorg.

It also appears that Wayland, which requires KMS capable drivers, will always show the same IDs, with the caveat that if you use Xwayland and xrandr, xrandr will show XWAYLAND0 ... type port IDs, probably because the IDs are actually totally abstracted from the hardware in Xwayland is my guess.

It's quite difficult to find conclusive clear documentation of these changes, particularly since it appears that each group that maintains an Xorg driver is essentially free to change the IDs in whatever way they feel like. It would take many more samples from different drivers, kernels, and hardware setups to really determine the full possible range of these variations. VGA-1 for example is usually preserved as VGA-1, but could also be VGA0, it's quite random.

The best solution would be to have some way to determine the physical port ID in /sys, the actual path that is, then to determine the physical port path in Xorg, and then just ignore the IDs that Xorg and the kernel generate, but I have been unable as of yet to determine this.

I am probably off on some of these points/assumptions, if so, any correction is appreciated since I'm also trying to understand how this actually works under the covers.

Matters are made more complicated also because the nvidia non free driver has had some long standing bugs that make systemd believe connected and enabled monitors are disabled, which then can lead to undesired suspend actions. There's been a few other nvidia driver bugs related to the drm data simply not appearing.

Examples of such nvidia non-free driver bugs: https://forums.developer.nvidia.com/t/no-sys-class-drm-card0-entries-on-kernel-4-15/57855 https://forums.developer.nvidia.com/t/sys-class-drm-enabled-reports-disabled-for-enabled-monitors/51187

If your monitors are all different, you can deduce which monitor Xorg is giving a specific ID to based on its EDID vendor and product id (prod id) and Serial No: (not all monitors have the serial number data though). But I cannot find any way to link that Xorg data from port ID and monitor info to pci bus or /sys/class/drm info in a completely reliable and non-ambiguous way. If I do find such a way, which will probably be non-trivial to do, I'll update this post.

[update] Thanks to comment from mic_e which shows that as of about 2009 (xrandr 1.2 and later, released around 2007, but shipped in frozen pool around 2009) xrandr --prop / --property adds the CONNECTOR_ID to output, which can be matched against /sys/class/drm/*/connector_id to get a positive match. This will only work with DRM drivers/hardware, but that's most graphics now.

Note that --prop also shows the EDID data, though you can get that directly from /sys anyway so that doesn't really matter, and xrandr is just another dependency on top of that anyway, but you do need it if you need to match drm and xorg port ids.

If you wanted full coverage, and don't mind the overhead of reading a lot of output, --verbose always worked, and triggered --prop when it was introduced.