Bug 419494

For X this is not fixable, for wayland we may have an option

Still an issue on neon unstable.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.25.80
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.4
Graphics Platform: Wayland

*** Bug 454486 has been marked as a duplicate of this bug. ***

>for wayland we may have an option

This landed in 5.26

*** Bug 461199 has been marked as a duplicate of this bug. ***

(In reply to David Edmundson from comment #1)
> For X this is not fixable, for wayland we may have an option

Would it be possible to simply append numbers onto the names of monitors in the order they are gathered from the OS for X?
I don't know where you're getting the information from for the monitor names, but I assume there's some kind of query being made, and an array of strings is being returned or objects with string properties, maybe just append the array index value onto the string? With a +1 so it starts at 1 instead of 0.

Also, just another idea, another option would be to append the name of the port the monitors are connected to. onto the name of the monitor being displayed. That's what Linux Mint seems to do with it's display settings. So when there are multiple monitors, they also show the port names, 'HDMI-0', 'HDMI-1', 'HDMI-2', etc. That would resolve the issue.

(In reply to Grady from comment #6)
> (In reply to David Edmundson from comment #1)
> > For X this is not fixable, for wayland we may have an option
> 
> Would it be possible to simply append numbers onto the names of monitors in
> the order they are gathered from the OS for X?
> I don't know where you're getting the information from for the monitor
> names, but I assume there's some kind of query being made, and an array of
> strings is being returned or objects with string properties, maybe just
> append the array index value onto the string? With a +1 so it starts at 1
> instead of 0.

IIRC The problem with X11 is the ordering is not deterministic accross reboots, we simply can't use it.

> Also, just another idea, another option would be to append the name of the port the monitors are connected to

What if you have two HDMI ports ?
Then X11 is not deterministic.

Ports and ordering are useless here, you always need a better source of truth.
For linux that's libdrm and the serialnumber https://gitlab.freedesktop.org/mesa/drm.

But Even then we have trouble because screens by some manufacturers can share the exact same serialnumber...
Hence https://bugs.kde.org/show_bug.cgi?id=450344

(In reply to Méven from comment #8)
> 
> IIRC The problem with X11 is the ordering is not deterministic accross
> reboots, we simply can't use it.

Thanks for the feedback.

Just a suggestion but is it strictly necessary for the ordering to be deterministic across reboots?

I'm thinking from the perspective of the numbers only being added to the GUI at runtime, not stored or saved with the configuration itself, so the numbers would have no impact on the actual display configuration. 

So another words it's a purely GUI thing, definitely not stored with the monitor configuration at all so it would have no impact on the order of the monitors for configuration.

From the user's perspective, all the "Identify" button needs to achieve is helping us identify which monitors physically in front of us correspond to the monitors in the dropdown list or laid out in the 2D representation of the screen configuration.

So even if the numbers change between reboots, as long as they remain consistent while we're looking at them, that's perfectly fine from my perspective as a user and definitely an improvement.

If the choice is between 'no means of telling which monitor is which' and 'having numbers that are not consistent between reboots', I'd say having numbers that are not consistent between reboots would be preferred.

(In reply to Grady from comment #9)
> (In reply to Méven from comment #8)
> > 
> > IIRC The problem with X11 is the ordering is not deterministic accross
> > reboots, we simply can't use it.
> 
> Thanks for the feedback.
> 
> Just a suggestion but is it strictly necessary for the ordering to be
> deterministic across reboots?

It is mandatory, if not for the UI, it is for the screen settings and plasma (widgets).

(In reply to Méven from comment #10)
> (In reply to Grady from comment #9)
> > (In reply to Méven from comment #8)
> > > 
> > > IIRC The problem with X11 is the ordering is not deterministic accross
> > > reboots, we simply can't use it.
> > 
> > Thanks for the feedback.
> > 
> > Just a suggestion but is it strictly necessary for the ordering to be
> > deterministic across reboots?
> 
> It is mandatory, if not for the UI, it is for the screen settings and plasma
> (widgets).

Right that's what I mean, this wouldn't be for the screen settings or impact the plasma widgets.

I mean just using the numbers purely 100% as just a minor visual adjustment of the GUI of the display settings, just literally adding a number to the names of the monitors in the dropdown UI component and using that name for the displayed monitor name on screen.

So that would have no impact on screen settings, shouldn't that be possible?

Created attachment 153537 [details]
Mockup of change

Mockup of proposed change

I attached a mockup of what I'm referring to, this would be a purely GUI thing, would have zero impact on system settings or the actual stored names of the monitors, just an additional text label in the GUI next to each monitor's name, with a number. If you like for visual pleasantness, could make the numbers based on the monitor positions sorted from left to right and top to bottom.

This might be something to take another look at now given there's been a recent change in how KDE handles multiple monitors that may impact what has been discussed here:

Information about the changes here:
https://notmart.org/blog/2022/12/multi-screen/

And here:
https://pointieststick.com/2022/12/16/this-week-in-kde-wayland-fractional-scaling-oh-and-we-also-fixed-multi-screen/

Quoting pointiestick.com blog post:
> Fixing Multi-Screen
> 
> Multi-screen is a complicated beast because it touches so many parts of the software stack. Ultimately most of our problems arose from the use of connector IDs to identify screens and map Plasma desktops and panels (“containments”) to screens. This worked poorly, because connector IDs can and do change under various circumstances. As a result, things often became a scrambled mess, with the behavior either being random, or consistently wrong.
> 
> That’s all changed. You can read the details here. In a nutshell, we now use an index-based system, with index numbers bound very tightly to Plasma containments, but index numbers themselves being able to move between screens based on how many screens there are. So for example, when screen 1 with your Plasma desktop and panel becomes unavailable, a new screen becomes screen 1, and the Plasma desktop and panel bound move over to it.
> 
> This new system should result in vastly greater stability, reliability, and predictability with respect to how screens are enabled and disabled, positioned, and what Plasma desktops and panels they show. It fixes notorious bugs like Plasma containments being randomly moved around or lost and desktops sometimes losing their wallpapers, widgets, and icon settings. It also makes arrangements of screen layouts and Plasma containments stable across the Plasma X11 and Wayland sessions. Big stuff.

And quoting the notmart.org blog post:

> We have a new Wayland protocol for screen ordering (as well an X11 counterpart) for KScreen and KWin to agree to which one is the real logical ordering of the screens, so Plasmashell will now follow this without attempting to identify monitors by itself, removing a very big failure point.

This sounds like it would fix the issue which was described by Meven of not having a consistent method of identifying which monitor is which.