GNOME Bugzilla – Bug 774135
Doesn't remember my rotated monitor setup across Wayland and X sessions
Last modified: 2021-07-05 13:51:28 UTC
I installed GNOME 3.22 (ie. Fedora 25) and configured my external monitor (it is rotated 90 degrees anti-clockwise) in the Wayland session. It worked great. Yay! However, when I logged into the X session, I had to set it up again because it lost my previous configuration. Would be nice if the setup worked across the Wayland and X sessions.
Could you provide the ~/.config/monitors.xml file resulting after you apply the configuration on both sessions? I wonder if there is some mismatch that makes the configuration not applied to your external monitor. AFAICS, both reading config from that file and rewriting it after the user confirmed display config changes happen in quite generic code, and it at least worked to me here (I just tried with the builtin display though). Also, was the monitor hotplugged on any of both sessions or was it plugged before starting the session on both situations?
This is most likely due to differences in how the ddx drivers vs. mutter's native backend names outputs (i.e. drm connectors) since there's no "standard". That said, mutter can be more lenient when matching saved configurations. I think it's reasonable that a monitor should be "remembered" if I connect it through VGA today and DVI tomorrow. I'll look into this.
Created attachment 339408 [details] [review] meta-monitor-config: Initialize MetaConfiguration's properly We weren't initializing the ref count which means we could either be leaking or end up using free'd memory.
Created attachment 339409 [details] [review] meta-monitor-config: Don't use connector names to match outputs Connector names aren't standardized between DDX's or our own native backend which means we couldn't match saved configurations on one driver when running on another. It also means we wouldn't match the same set of monitors if they switched connectors. -- I can't think of any bad side-effects of doing this, but I'm not sure I evaluated all cases.
Created attachment 339410 [details] [review] meta-monitor-config: Avoid a potential crash If we can't find an output we would crash dereferencing a NULL pointer.
*** Bug 772709 has been marked as a duplicate of this bug. ***
Review of attachment 339408 [details] [review]: Oops, nice catch :)
Comment on attachment 339410 [details] [review] meta-monitor-config: Avoid a potential crash LGTM, perhaps worth a warning. It's funny that find_output_by_key() says "this is fatal" in the return NULL condition, but nothing seems to make it actually fatal...
Comment on attachment 339409 [details] [review] meta-monitor-config: Don't use connector names to match outputs In theory it makes perfect sense, in practice, do you think we might get duplicate keys on the right conditions? eg. having two monitors of the same brand and model, whose edid happens to misreport serial as 00000000?
I was thinking of that too; can the connector still be used to break ties if there are multiple matches?
Created attachment 339537 [details] [review] meta-monitor-config: Collect MetaOutputInfo's as they're assigned This avoids us having to match MetaOutput's with MetaOutputKey's twice which will be required for the next patch.
Created attachment 339538 [details] [review] meta-monitor-config: Avoid assigning the same output more than once Since we don't match on the connector name anymore we need to be careful to not assign the same output more than once in case several outputs have the same vendor, model, serial. -- (In reply to Carlos Garnacho from comment #9) > In theory it makes perfect sense, in practice, do you think we might get > duplicate keys on the right conditions? eg. having two monitors of the same > brand and model, whose edid happens to misreport serial as 00000000? I don't think duplicate keys are a big problem, you just won't be able to save multiple configurations with that same set of monitors. A more serious issue is what this patch (and the previous) fixes.
Comment on attachment 339408 [details] [review] meta-monitor-config: Initialize MetaConfiguration's properly Attachment 339408 [details] pushed as 76b6cc0 - meta-monitor-config: Initialize MetaConfiguration's properly
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.