backend/kms: Use mst PATH for output naming
#1335
Conversation
|
Can't wait until the day that I wake my laptop up or when I connect it to my dock, for the screens to show up how I set them up last! I can test anything you want on my setup. It happens multiple times a day for me. |
Yeah I think this is a good idea. I am not sure how consistent these are, but if we want user-readable output for e.g. Though I would still prefer to use EDID-hashes (+ this as a fallback) for storing state. |
| } | ||
| write!(&mut interface, "{}", port).unwrap(); | ||
| first = false; | ||
| } |
There was a problem hiding this comment.
Can we make this into another helper function, please?
Yeah. Like #1325, we want to use edid, then fallback to connector name, so both should be stored somehow. Regardless of how we use As for hashing, I see Kwin's implementation just takes an md5 hash of the whole edid blob. Not sure if it makes any difference if the whole blob is compared vs just the product/vendor information. Though a hash like that would be convenient enough if we have it multiple place in configuration files, want to use it as a key for a map, etc. Though the fact we also need to store connector names makes that a little more complicated. The only downside of hashing of course would be that we can't display information about the output a workspace was assigned to, etc. when it's not connected. Or check the file to see that information manually. Probably not an issue. I don't think we currently have an md5 implementation in the dependency tree, so maybe |
This may provide more consistent connector names, though that could use more testing.
On my system, I get
eDP-1,DP-2-1,DP-2-2. I don't know how to test situations where child connector uses multiple mst "ports" (probably with a monitor I don't have).This doesn't seem to match other compositors. But there's no expectation that it does.
If we prefer to expose the existing output names to the user, this could be stored separately and used internally for output matching. (Though with #1325, etc, that would only be needed for outputs with the same edid). I'm not sure what naming is most intuitive. The arbitrary dynamic connector numbering MST outputs already have may be confusing.