Re: [systemd-devel] DisplayPort display non-persistent device naming

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2120 bytes --]

On Thu, 29 Oct 2020 21:53:34 +0100
Marcin Kocur <marcin2006@gmail.com> wrote:

> Hello,
> 
> this is the output of turning off and on my display (using power button):

...

> The monitor was visible in xrandr as DP-2, after power off and on it's 
> visible as DP-3 (DP-2 is still there "disconnected").
> 
> It's troublesome for:
> 
> - GUI display configurators
> 
> - scripting
> 
> - for Xorg configuration which stops to work:
> 
> Section "Monitor"
>      Identifier  "DP-2"
>      Option      "Primary" "true"
> EndSection
> 
> Is this a bug or a feature?

Hi,

this is how the kernel DRM sub-system works. The connector names are
not persistent in general, just like you can't expect that the same gfx
card appears always at the same /dev/dri/cardN node if you have
several. By default, cardN nodes are assigned in the order of which
driver instance happens to initialize first and it can be random.

Usually hard-wired (in hardware) connectors just happen to always be
discovered in the same order, and if you only have a single gfx card in
your machine, the connector naming is practically persistent. This is
an accident. It is not guaranteed if you have multiple cards or you
have MST connectors.

MST connectors can appear and disappear dynamically. There is a KMS
property that attempts to reflect something about the MST topology so
that you might have some hope to match a "connector", but this is not
in the connector name. The concept of a persistent connector is
problematic if the connector is in a MST monitor for daisy-chaining
more monitors - you can always unplug the first monitor making the
connector disappear (not just become disconnected).

If you want reliable monitor matching, monitor serial number (if
present) would be a more reliable method. I'm not sure Xorg config has
matching rules for that though, but I suppose RandR based configuration
utilities could do it.

If you want to discuss this further, dri-devel mailing list is the
place - Cc'd. Nothing to do with systemd here, nor even with udev.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel