Bug#927275: gnome-shell - Intel GPU - monitors.xml is ignored and settings are not applied after suspend/reboot

[-]

Am Donnerstag, den 18.04.2019, 19:44 +0100 schrieb Simon McVittie:
> Control: severity -1 normal
> Control: reassign -1 libmutter-3-0 3.30.2-6
> Control: tags -1 + moreinfo
> Control: affects -1 gnome-shell
> 
> On Wed, 17 Apr 2019 at 10:32:25 +0200, - wrote:
> > Severity: serious
> 
> This is an annoying bug, but is not so serious that removing GNOME
> from
> Debian would be better than releasing buster with this bug unfixed,
> so
> I'm downgrading it to normal.
> 
> > Debian Version: Buster with latest updates
> 
> I've assumed that this means libmutter-3-0 3.30.2-6, among other
> packages.
> If possible please report Debian bugs with the reportbug tool, which
> provides useful information that helps developers to solve the bugs
> you report.
> 
> > It seems gnome-shell is not reading in the monitors.xml where the
> > correct settings are applied and stored for each side after a
> > suspend
> > or even a reboot.
> > 
> > Any idea what is causing this issue and what could be a workaround
> > for
> > now to trigger a manual reading of the monitors.xml so that it can
> > be
> > applied manually as a temporary fix?
> 
> monitors.xml handling is part of libmutter, which GNOME Shell uses
> for
> window management and compositing. I don't know what is causing this
> or how to solve it, but if you can provide more information, that
> might
> help someone else to find a solution:
> 
> The monitors.xml you attached has two configurations. Do these
> accurately
> represent what you configured at your office and your home?
> 
> * Configuration A:
>     * 1920x1080 SyncMaster, serial number H9XSA30201, on DisplayPort
>       connector DP-1-3, on the left
>     * 1920x1080 SyncMaster, serial number H9XSA30209. on DisplayPort
>       connector DP-1-2, on the right
>     * Laptop's internal display panel disabled
> * Configuration B:
>     * 2560x1440 FUS P27-8 TE Pro, serial number YVBH702276, on
> DisplayPort
>       connector DP-5
>     * Laptop's internal display panel disabled
> 
> (I'm surprised they're using such different DisplayPort connector IDs
> when you said you're using the same docking station at each site -
> I'd expect the labelling to be the same.)

Yes it does, I double checked it, because for me it was also weird that
the same docks use different DisplayPort connector IDs at each site. I
assume it is because on one site just one monitor (DP -> DP) and on the
other side two (DP -> DVI) are connected and therefore maybe a MST-Hub
or so kicks in if the two DVI monitors are connected. And if just one
DP Monitor is connected, the DP signal is just forwarded through the
dock without.
And the L390 is not a Thunderbolt device, it just has usb-c alternate
mode displayport, which also might be a difference to connecting a
thunderbolt device to the thunderbolt dock. In the specs of the dock it
is listed that usb-c DP devices are supported, just with a lower
resolution than thunderbolt 3 devices 
https://support.lenovo.com/de/en/solutions/pd029622 .

I switched back to my T470 (which has a thunderbolt port) because of
another bug where the device crashed while going to suspend, so I can
test if the monitor.xml will change in the same setup while connecting
to the docks with a thunderbolt 3 enabled thinkpad.

> 
> Are you using GNOME in Wayland mode (default) or in X11/Xorg mode?

I am using the default Wayland mode.

> 
> If you reconfigure monitors in gnome-control-center, does that
> temporarily get you back to the desired configuration until the next
> undock/suspend/resume/dock cycle?

Yes it does. But while staying at the same site even a
undock/suspend/resume/dock cycle does not brake the config.

> 
> If you undock, suspend, resume and connect to *the same* dock, do you
> get the desired result, or do you get the same problem as if you had
> connected to the other dock?

A undock, suspend, resume and connect at the same site keeps the
configuration. Just coming back from the other side brakes it.

> 
> Does the contents of monitors.xml change during the
> undock/suspend/resume/dock cycle? For example, please try this:
> 
> * have the configuration you wanted (or any distinctive
> configuration,
>   really)
> * copy monitors.xml to monitors.xml.start
> * undock
> * copy monitors.xml to monitors.xml.undocked
> * suspend
> * resume
> * copy monitors.xml to monitors.xml.resumed
> * dock
> * copy monitors.xml to monitors.xml.docked
> * log out and back in (or reboot)
> * copy monitors.xml to monitors.xml.restarted
> 
> and compare the various monitors.xml.* files to see whether the
> contents
> changed at any point.

As far as I have seen they have not changed. The monitor.xml normally
just changed after applying new settings in the gnome-control-center.
The "broken" configs where not visible there. But as mentioned above, I
switched back to a T470 so I can not test that anymore with the L390,
but I will if the problem consists with the T470.

> 
> Is anything interesting or possibly-relevant-looking logged at
> each step? If you are using Debian's default systemd init system,
> everything should be logged to the systemd Journal, accessible by
> running the journalctl command. If you are not using systemd, the
> logs
> are more scattered: try ~/.xsession-errors, /var/log/Xorg.*.log and
> /var/log/syslog.
> 
> You can leave markers in the systemd Journal or in /var/log/syslog
> with a command like:
> 
>     logger -t debug-monitor-detection "About to undock..."
> 
> which might be a useful way to see which messages happened before or
> after which action you took.
> 
> It would probably also be useful to install the read-edid package,
> and record the output of these commands at each step:
> 
>     head /sys/class/drm/card*/modes
>     for x in /sys/class/drm/card*/edid; do echo "$x:"; parse-edid <
> "$x"; done
> 
> If none of the above has provided useful information, another thing
> that
> might help to find what the problem is or how to fix it would be to
> edit
> /usr/share/wayland-sessions/gnome.desktop and modify the line
> 
>     Exec=/usr/bin/gnome-session
> 
> to be
> 
>     Exec=/usr/bin/env MUTTER_VERBOSE=1 MUTTER_DEBUG=1 /usr/bin/gnome-
> session
> 
> which should result in libmutter logging a lot more messages to
> whatever
> log you found other gnome-shell messages in.

I will do that with the T470 after beeing back at work on
tuesday/wednesday if the problem will persist, so that I can get useful
logs.

Thanks for all your hints and tips on how to debug further the issue.

best regards