YaLTeR / niri

A scrollable-tiling Wayland compositor.
https://matrix.to/#/#niri:matrix.org
GNU General Public License v3.0
4.14k stars 123 forks source link

Handle matching monitor model + make + serial #734

Open YaLTeR opened 1 month ago

YaLTeR commented 1 month ago

They can match, in fact the entire EDID can match between multiple monitors. Currently this can cause crashes related to workspaces moving to their original output, and probably other weirdness.

I've heard that KDE handles this by resorting to connector names when there are matching EDIDs. We need something similar I guess.

kchibisov commented 1 month ago

Isn't connector name is the most robust thing here from the compositor internal stuff point of view, so your internal caches should be generally based on the connector_id(could be name)? You just have to map them to whatever you want used by user configuration when dealing with the requests from the user/reading out the config.

YaLTeR commented 1 month ago

I decided to change the workspace original output to model + make + serial so that it also works as expected when e.g. unplugging and replugging a display into a thunderbolt dock that bumps the connector name every time a monitor is replugged. It also makes open-on-output for named workspaces work by simply setting the original output to that value (if it's a connector name, then it's resolved into model + make + serial as soon as the monitor is first connected).

kchibisov commented 1 month ago

I think it doesn't really matter since it's just a hash, so whatever the value is is irrelevant, it's just uniquely identifies it. To compare you still would go through the EDID+serial+make+whatever.

I'm not saying to rely on connector_id, I'm saying to use it for internal operations where it doesn't matter and what matters is uniqueness of the value. For all the settings stuff you'd still use the EDID+make+serial pretty much, though via reverse mappings.

YaLTeR commented 1 month ago

In this case it does conflict though:

So in case where there are multiple monitors with exactly matching EDID + make + model + serial, these matching monitors should switch to connector names, as a workaround.

kchibisov commented 1 month ago

I'm not sure what you're talking about in a thunderbolt dock case, the name of the connector is irrelevant and user configuration is based on the edid/etc where you reverse map it to connector_id.

Like the issue with dock creating a new name doesn't matter, since you use u64 from id, since it's a unique value for the given monitor, for user config you have e.g. Vec<(u64, EDID)> where you search stuff to apply.

The only issue would be that you apply the same configuration twice if monitors exactly match, but probably could have more random data pulled.

YaLTeR commented 2 weeks ago

Added a workaround debug flag until there's a proper fix:

debug {
    disable-monitor-names
}