GNOME Bugzilla – Bug 788915
External monitor shuts off when laptop lid closes under wayland.
Last modified: 2018-02-09 07:31:31 UTC
As the title suggests, the external monitor shuts off when laptop lid closes. I believe the laptop goes into suspend mode. The correct behaviour would be to disable the suspend function when an external monitor is connected. I further observed that the correct behaviour happens on a fresh login and this persists after login. However, if I unplug the external monitor and close the laptop lid, then reopen the lid and replug the monitor, the problem starts. The external monitor shuts off when laptop lid is closed. The problem is fixed when I log out and re-login. However, if I do the above, the problem starts again. Very frustrating indeed! This problem only seems to exist in wayland session and not Xorg session. I am using gnome 3.26.1 Linux LTS 4.9.51 & Linux 4.13.5 I've posted the same bug report here under gnome-shell by mistake: https://bugzilla.gnome.org/show_bug.cgi?id=788864
Just an update, It seems that I did not thoroughy check the xorg session. Even Xorg appears to have the same bug. The problem thus seems to lie with gnome 3.26. I did not experience this behaviour in gnome 3.24.
I saw the same issue using ubuntu 17.10 with gnome 3.16.1: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716160 They say that this was fixed though, on my machine with all the updates, it does not seem to work.
This is happening to me as well. I can get one monitor to work but every time I dock, I have to set the secondary monitor to Primary Display. It was working fine before the update to gnome 3.26.1. I am running Solus.
there issue is probably a gnome-shell one, gnome-control-center is a graphical interface to edit the configuration, it has no role in applying changes and has no service which is active when the interface is closed
I am seeing similar behaviour. However it persists even when I tell GNOME not to go to sleep on monitor close when power is connected (shouldn't that be the default?) Off-topic, but that setting is usually but not always respected, and I have not yet found the pattern. The way I solve this is to open the display settings with the laptop screen open and make the external monitor the default. This setting is remembered across undocking and re-docking my laptop, but not always respected: I often have to disable and re-enable it to make it take effect again. GNOME Shell 3.26.1 Ubuntu 17.10/Linux 4.13.0-16-generic
*** Bug 788864 has been marked as a duplicate of this bug. ***
I now think understand the problem with the laptop going to sleep with an external monitor connected a bit better. By default this seems to be controlled by systemd-logind, not by gnome-shell. And it is configured by default to go to sleep if the lid is closed when the laptop is not docked, which it defines as no external monitor is connected. However, when I close the lid the whole screen set-up is reconfigured, I presume by the Intel driver, and for about half a second the external monitor is reported as disabled (as determined from the value of /sys/class/drm/card0-DP-<n>/enabled). I assume that if systemd-logind happens to check the external monitor in that half second (not unlikely) it will decide that the lid was closed while the laptop was not docked, and will go to sleep.
Inhibiting suspend whether an external monitor is active or not is dealt with in gnome-settings-daemon. Configuring the monitors, however, is dealt with by mutter. You should be able to monitor what happens with the suspend inhibitation using 'dbus-monitor --system'. It should also be able to see what types of configuration calls happens by using 'dbus-monitor --session'.
Thanks to all for the response. I'm not quite sure what I need to do. Is there any specific information that anyone further needs? Since this issue does not seem to be specific to my laptop, do I still need to provide more information from my side? Or do the developers know what's going on?
Here is a workaround that seems to work: Edit /etc/UPower/UPower.conf Change the setting IgnoreLid=false to IgnoreLid=true This seems to disable any and all lid actions and helps solve the issue until it gets fixed properly. Just be sure to use Single display setting in the display settings or disable the laptop one as closing the lid now does not trigger a display settigs change. For me this workaround works when I take my laptop and connect it to a dock with the lid closed and external display connected. Previously I had to have the laptop lid open to have the external monitor show anything at all.
Created attachment 362878 [details] [review] monitor-config-manager: Don't include closed laptop panel in config key When deriving the list of disabled monitors when creating new monitors configs, don't include the laptop panel if the lid is currently closed, as we consider the laptop panel nonexistent when the laptop lid is closed when it comes to configuration. The laptop panel connector(s) will either way be appropriately disabled anyway, as the field listing disabled monitors in the configuration do not affect actual CRTC/connector assignments.
Created attachment 362879 [details] [review] monitor-manager: Compare keys when checking whether a config is complete We only counted configured monitors and whether the config was applicable (could be assigned), howeverwe didn't include disabled monitors when comparing. This could caused incorrect configurations to be applied when trying to use the previous configuration. One scenario where this happened was one a system with one laptop screen and one external monitor that was hot plugged some point after start up. When the laptop lid was closed, the 'previous configuration' being the configuration where only the laptop panel was enabled, passed 'is-complete' check as the number of configured monitors were correct, and the configuration was applicable. Avoid this issue by simply comparing the configuration key of the previous configuration and the configuration key of the current state. This correctly identifies a laptop panel with the lid closed as inaccessible, thus doesn't incorrectly revert to the previous configuration.
Created attachment 362880 [details] [review] monitor-unit-tests: Add test for lid closed after hot plug Add a test case that checks that we don't try to revert to a laptop-panel-only configuration after closing the lid after an external monitor is connected.
Thanks very much for working on this Jonas! Are those patches that you attached? How can we test this?
(In reply to harish.hyma from comment #14) > Thanks very much for working on this Jonas! Are those patches that you > attached? How can we test this? The best way to test is to apply the patches, build and install mutter yourself.
Which bug are these patches supposed to fix? 1.) External monitor shuts off when laptop lid is closed, or 2.) External monitor settings are fogotten Thanks
(In reply to harish.hyma from comment #16) > Which bug are these patches supposed to fix? > > 1.) External monitor shuts off when laptop lid is closed, They should fix this issue. > or > 2.) External monitor settings are fogotten > What issue do you mean by this? The issue this bug describes is the external monitor is incorrectly disabled when closing the lid. Are you referring to some other issue?
The three patches worked for me on Mutter 3.26.2 under Wayland on Arch Linux. Hopping to see them on upstream soon.
The patch does not seem to have helped me unless (I do not think so but those things do happen) I made some mistake applying the patch. I was able to trigger the problem using the following sequence of events. 1) I used my laptop at work, closed, docked and with an external monitor. 2) I used my laptop travelling. 3) I docked my laptop at home (identical set-up but different monitor serial number) and started it without opening it, with the monitor already switched on, by pressing the power button on the dock. The laptop started and went back to sleep without enabling the monitor. 4) I opened the laptop. Both the internal and the monitor were enabled. I closed the laptop again and it went back to sleep. 5) (Skipped a couple of opens and closes.) I opened the laptop, changed the display settings and cancelled when asked to confirm. I then closed the laptop and the monitor stayed on. As requested, I took logs of "dbus-monitor --session" and "dbus-monitor --system", starting before step 3) and stopping after step 4). I fear they may contain a little unrelated information as well judging from the size of them, and just hope the bugtracker will let me upload them.
Created attachment 363172 [details] DBus logs
After further testing I have to say that it looks that the patches cause some problems: my gnome-shell crashes if: - attach an external monitor; - detach it; - close the lid letting the laptop to standby and lock the desktop; - reopen the lid - gnome-shell crashes! ``` Process 30465 (gnome-shell) of user 1000 dumped core. Stack trace of thread 30465: #0 0x00007f4e9e18c226 meta_monitors_config_key_equal (libmutter-1.so.0) #1 0x00007f4e9e194675 meta_monitor_manager_ensure_configured (libmutter-1.so.0) #2 0x00007f4e9ffac6f5 g_closure_invoke (libgobject-2.0.so.0) #3 0x00007f4e9ffc00b0 n/a (libgobject-2.0.so.0) #4 0x00007f4e9ffc4696 g_signal_emit_valist (libgobject-2.0.so.0) #5 0x00007f4e9ffc5920 g_signal_emit (libgobject-2.0.so.0) #6 0x00007f4e9ffb2bf6 n/a (libgobject-2.0.so.0) #7 0x00007f4e9ffae52a g_object_notify (libgobject-2.0.so.0) #8 0x00007f4e9ffac6f5 g_closure_invoke (libgobject-2.0.so.0) #9 0x00007f4e9ffc00b0 n/a (libgobject-2.0.so.0) #10 0x00007f4e9ffc4696 g_signal_emit_valist (libgobject-2.0.so.0) #11 0x00007f4e9ffc5920 g_signal_emit (libgobject-2.0.so.0) #12 0x00007f4e9ffb2bf6 n/a (libgobject-2.0.so.0) #13 0x00007f4e9ffae52a g_object_notify (libgobject-2.0.so.0) #14 0x00007f4e9606443e n/a (libupower-glib.so.3) #15 0x00007f4e9a3f71c8 ffi_call_unix64 (libffi.so.6) #16 0x00007f4e9a3f6c2a ffi_call (libffi.so.6) #17 0x00007f4e9ffb584b g_cclosure_marshal_generic (libgobject-2.0.so.0) #18 0x00007f4e9ffac6f5 g_closure_invoke (libgobject-2.0.so.0) #19 0x00007f4e9ffbfae2 n/a (libgobject-2.0.so.0) #20 0x00007f4e9ffc4696 g_signal_emit_valist (libgobject-2.0.so.0) #21 0x00007f4e9ffc5920 g_signal_emit (libgobject-2.0.so.0) #22 0x00007f4ea024ddac n/a (libgio-2.0.so.0) #23 0x00007f4ea02c2ea9 n/a (libgio-2.0.so.0) #24 0x00007f4e9fcdc0be g_main_context_dispatch (libglib-2.0.so.0) #25 0x00007f4e9fcddf69 n/a (libglib-2.0.so.0) #26 0x00007f4e9fcdef42 g_main_loop_run (libglib-2.0.so.0) #27 0x00007f4e9e1c91bc meta_run (libmutter-1.so.0) #28 0x000055c1e041c011 n/a (gnome-shell) #29 0x00007f4ea09fcf6a __libc_start_main (libc.so.6) #30 0x000055c1e041c16a n/a (gnome-shell) ..... ```
@Mario You might want to read this: https://lists.x.org/archives/xorg-devel/2017-October/055025.html
@Michael: I think this is not my problem: I just reverted on the mutter package of my Arch Linux and I'm not able to make my gnome shell crash using the reported steps (on my patched mutter build the crash was systematic...). In the past weeks I had other, sporadic, gnome shell crashes that could be related to what you report. Thanks for it.
(In reply to Michael Thayer from comment #19) > The patch does not seem to have helped me unless (I do not think so but > those things do happen) I made some mistake applying the patch. I was able > to trigger the problem using the following sequence of events. > > 1) I used my laptop at work, closed, docked and with an external monitor. > 2) I used my laptop travelling. > 3) I docked my laptop at home (identical set-up but different monitor serial > number) and started it without opening it, with the monitor already switched > on, by pressing the power button on the dock. The laptop started and went > back to sleep without enabling the monitor. > 4) I opened the laptop. Both the internal and the monitor were enabled. I > closed the laptop again and it went back to sleep. > 5) (Skipped a couple of opens and closes.) I opened the laptop, changed the > display settings and cancelled when asked to confirm. I then closed the > laptop and the monitor stayed on. > > As requested, I took logs of "dbus-monitor --session" and "dbus-monitor > --system", starting before step 3) and stopping after step 4). I fear they > may contain a little unrelated information as well judging from the size of > them, and just hope the bugtracker will let me upload them. I can't reproduce this while trying to emulate this behavior with test case. Could you attach your ~/.config/monitor.xml ? (In reply to Mario from comment #21) > After further testing I have to say that it looks that the patches cause > some problems: my gnome-shell crashes if: > - attach an external monitor; > - detach it; > - close the lid letting the laptop to standby and lock the desktop; > - reopen the lid > - gnome-shell crashes! Good catch, thanks a lot. I'll upload a new version of the patch and an updated test that also checks that sequence.
Created attachment 363274 [details] [review] monitor-manager: Compare keys when checking whether a config is complete We only counted configured monitors and whether the config was applicable (could be assigned), howeverwe didn't include disabled monitors when comparing. This could caused incorrect configurations to be applied when trying to use the previous configuration. One scenario where this happened was one a system with one laptop screen and one external monitor that was hot plugged some point after start up. When the laptop lid was closed, the 'previous configuration' being the configuration where only the laptop panel was enabled, passed 'is-complete' check as the number of configured monitors were correct, and the configuration was applicable. Avoid this issue by simply comparing the configuration key of the previous configuration and the configuration key of the current state. This correctly identifies a laptop panel with the lid closed as inaccessible, thus doesn't incorrectly revert to the previous configuration.
Created attachment 363275 [details] [review] monitor-unit-tests: Add test for lid closed after hot plug Add a test case that checks that we don't try to revert to a laptop-panel-only configuration after closing the lid after an external monitor is connected.
Created attachment 363276 [details] [review] monitor-unit-tests: Add test for lid toggle after hot unplug
Jonas, I currently do not have a monitors.xml. I deleted it previously while trying to work out what was happening and it has not yet been recreated.
Does it reproduce after the monitors.xml file was removed? Do you have a monitors.xml~ file (a backup file) that if you restore it, the issue starts to reproduce again?
I do not have the back-up, but I have applied your new patches, rebuilt, set up my screen configuration again and taken a copy of monitors.xml. I will be at work in half an hour and will try reproducing this and if so send you the old and the new XML files. Anything else I can do? I will check my mail again before docking.
I failed to reproduce this at work after applying the patches and rebooting. A sanity check suggests that the patches are in place (diff says that libmutter-1.so.0.0.0 matches the one in the build output but not the one in the original Ubuntu package). I will try to reproduce again tonight when I get home, keeping a copy of monitors.xml before and after. Still the question about whether I can get any more information.
Created attachment 363280 [details] [review] monitor-unit-tests: Always reset CRTC transform ability Changing the test monitor managers ability to rotate CRTCs in one test affected the next test. Avoid leaking such state by resetting it before each test. To continue passing, some tests needed to be updated regarding to still pass.
Created attachment 363282 [details] [review] monitor-unit-tests: Check config loading on lid switches Check that we apply the correct stored configuration when the lid is opend and closed while an external monitor is connected.
@Jonas: I'm testing the last set of patches you provided and, on first glance, it looks to fix the main goes-on-standby-on-lid-closure bug and let mutter survives to the steps reported by me. Thanks.
I am currently running with your patches up to and including comment 27. I twice failed to reproduce the problem, and I will not be in the office next week to try again. Until and unless I reproduce it again please do not consider my case as a blocker for this bug.
*** Bug 789199 has been marked as a duplicate of this bug. ***
Review of attachment 362878 [details] [review]: right, looks fine
Review of attachment 363274 [details] [review]: makes sense
Attachment 362878 [details] pushed as 62dedfb - monitor-config-manager: Don't include closed laptop panel in config key Attachment 363274 [details] pushed as b7518c8 - monitor-manager: Compare keys when checking whether a config is complete Attachment 363275 [details] pushed as ce25a01 - monitor-unit-tests: Add test for lid closed after hot plug Attachment 363276 [details] pushed as 050267f - monitor-unit-tests: Add test for lid toggle after hot unplug Attachment 363280 [details] pushed as 500c13a - monitor-unit-tests: Always reset CRTC transform ability Attachment 363282 [details] pushed as fc713ec - monitor-unit-tests: Check config loading on lid switches
Backported non-test patches to gnome-3-26.
Created attachment 368149 [details] monitors.xml I am once again seeing this issue regularly as described above. Now using Ubuntu 18.04/GNOME Shell 3.26.2-0ubuntu2. Attaching monitors.xml in case it is useful.
Seems like the mutter package in 18.04 doesn't contain those patches.
Sorry, you are right there. I thought they were in 3.26.2.