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.)
Are you using GNOME in Wayland mode (default) or in X11/Xorg 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?
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?
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.
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.
smcv
