[SOLVED] Lid switch settings ignored

Bidski · 2023-10-22 22:31:16

I am trying to setup my laptop so that if I am docked or on external power, closing the lid will be ignored, but if I am not on external power and not docked then closing the lid will suspend my laptop. However, these settings seem to be ignored as every time I close my lid when on external power and I have a DisplayLink USB dock plugged in my laptop always gets suspended. Sometimes, if I send a HUP to systemd-logind this will allow my settings to be honoured, but this is not always the case.

In journcalctl I see the following output when I close my laptop lid

Oct 23 09:10:25 systemd-logind[751]: Lid closed.
Oct 23 09:10:25 kernel: evdi: [I] (card3) Notifying display power state: off
Oct 23 09:10:26 /usr/lib/gdm-x-session[1979]: (II) modeset(0): Allocate new frame buffer 3840x1200 stride
Oct 23 09:10:26 kernel: evdi: [I] (card3) Notifying display power state: off
Oct 23 09:10:30 systemd[1]: systemd-timedated.service: Deactivated successfully.
    Subject: Unit succeeded
    Defined-By: systemd
    Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
 
    The unit systemd-timedated.service has successfully entered the 'dead' state.
Oct 23 09:10:34 systemd-logind[751]: Lid opened.

In /etc/systemd/logind.conf I have

HandleLidSwitch=suspend
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
LidSwitchIgnoreInhibited=yes

systemd-inhibit --list --mode=block shows

abiddulph 1000 abiddulph 2364 gsd-power      handle-lid-switch                                        External monitor attached or configuration changed recently block
abiddulph 1000 abiddulph 2359 gsd-media-keys handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses                                   block

I used to have "ignore lid switch" (or whatever the setting was called) set in Gnome tweak tools, but this setting no longer appears to exist. Looking in DConf editor I can't find any similar settings.

I saw someone mention that removing the "ignore-lid-switch-tweak" program from gnome-session-properties might help, but this appears to have had no affect.

How can I achieve the behaviour that I am looking for?

Last edited by Bidski (2024-01-16 21:38:50)

seth · 2023-10-23 06:12:57

In journcalctl I see the following output when I close my laptop lid

That does *not* suggest the system suspended?

Oct 23 09:10:25 kernel: evdi: [I] (card3) Notifying display power state: off

But you're using display link and that turns off?

Bidski · 2023-10-23 06:50:41

seth wrote:

But you're using display link and that turns off?

I am using DisplayLink and it is getting turned off (or at least the monitors go into power saving mode).

The behavior to me is indistinguishable from suspension. When I open my the laptop lid again there is a period where the laptop screen is black and I have to wait for it to wake up, whether it is waking up from suspension, or whether the waking up of the DisplayLink just causes the laptop screen to remain black for 15+ seconds (I haven't actually timed it) I don't know

seth · 2023-10-23 07:16:36

Please post the complete system journal for a boot you suspect to have suspended.

Bidski · 2023-10-23 22:35:57

Here is a link to journalctl -b-1 -x

seth · 2023-10-23 23:12:27

Oct 23 09:10:23 4TELLT129 sudo[4550]: abiddulph : TTY=pts/0 ; PWD=/home/abiddulph ; USER=root ; COMMAND=/usr/bin/systemctl kill -s HUP systemd-logind.service
Oct 23 09:10:23 4TELLT129 sudo[4550]: pam_unix(sudo:session): session opened for user root(uid=0) by abiddulph(uid=1000)
Oct 23 09:10:23 4TELLT129 systemd[1]: systemd-logind.service: Sent signal SIGHUP to main process 751 (systemd-logind) on client request.
Oct 23 09:10:23 4TELLT129 systemd-logind[751]: Config file reloaded.
Oct 23 09:10:23 4TELLT129 sudo[4550]: pam_unix(sudo:session): session closed for user root
Oct 23 09:10:25 4TELLT129 systemd-logind[751]: Lid closed.
Oct 23 09:10:25 4TELLT129 kernel: evdi: [I] (card3) Notifying display power state: off
Oct 23 09:10:26 4TELLT129 /usr/lib/gdm-x-session[1979]: (II) modeset(0): Allocate new frame buffer 3840x1200 stride
Oct 23 09:10:26 4TELLT129 kernel: evdi: [I] (card3) Notifying display power state: off
Oct 23 09:10:30 4TELLT129 systemd[1]: systemd-timedated.service: Deactivated successfully.
Oct 23 09:10:34 4TELLT129 systemd-logind[751]: Lid opened.
Oct 23 09:10:36 4TELLT129 kernel: evdi: [I] (card2) Notifying display power state: off
Oct 23 09:10:36 4TELLT129 kernel: evdi evdi.0: [drm] *ERROR* flip_done timed out
Oct 23 09:10:36 4TELLT129 kernel: evdi evdi.0: [drm] *ERROR* [CRTC:35:crtc-0] commit wait timed out
Oct 23 09:10:46 4TELLT129 kernel: evdi evdi.0: [drm] *ERROR* flip_done timed out
Oct 23 09:10:46 4TELLT129 kernel: evdi evdi.0: [drm] *ERROR* [PLANE:31:plane-0] commit wait timed out
Oct 23 09:10:46 4TELLT129 kernel: evdi: [I] (card2) Notifying display power state: on
Oct 23 09:10:46 4TELLT129 kernel: evdi: [I] (card2) Notifying mode changed: 1920x1200@60; bpp 32; pixel format XR24 little-endian (0x34325258)

At no point does the system sleep, DisplayLink needs ~10s to get its act together after opening the lid.
Does this also happen when you cut out gnome entirely and startx into eg. an openbox session?

Bidski · 2023-10-23 23:25:54

seth wrote:

Does this also happen when you cut out gnome entirely and startx into eg. an openbox session?

I have never tried. How would I go about doing this?

This doesn't even happen every time with the current setup. I have yet to find any rhyme or reason as to why it works sometimes but not other times. Here is a link to todays logs where everything worked as expected (closing the lid left the external monitors on).

seth · 2023-10-24 06:53:48

Install xinit, xterm and and twm (the default xinit WM, so you don't have to configure it), disable GDM or boot only the multi-user.target (2nd link below), log into a console and run startx.
You should™ see a GUI w/ three xterms. Then close your lid and see what happens.

My suspicion is that gnome wants to respond to the lid close by reconfiguring the outputs and ends up turning off all of them.

Bidski · 2023-10-25 23:34:01

seth wrote:

Install xinit, xterm and and twm (the default xinit WM, so you don't have to configure it), disable GDM or boot only the multi-user.target (2nd link below), log into a console and run startx.
You should™ see a GUI w/ three xterms. Then close your lid and see what happens.
My suspicion is that gnome wants to respond to the lid close by reconfiguring the outputs and ends up turning off all of them.

I am struggling to get displaylink to start after running startx so I cant even get the external monitors to turn on. I am assuming there is more to starting displaylink than just modprobing evdi and running DisplayLinkManager?

seth · 2023-10-26 07:41:44

Not much but I infer it's not automatically activated, https://wiki.archlinux.org/title/Displa … g_X_Server

Bidski · 2023-10-26 22:06:19

Ok, managed to get DisplayLink/Xorg to turn on the external monitors. Closing the lid doesn't cause the the external monitors to turn off, but it also doesn't turn off the laptop screen, I am 99% sure I can still move my mouse on to the laptop screen after the lid is closed. I obviously can't see the mouse pointer on the laptop screen, but if I move the mouse a lot to the left I have I have to move it a lot to the right to get the mouse pointer back on to one of the external monitors so I am pretty sure it isnt just hiding at the edge of the screen.

seth · 2023-10-27 06:48:07

What happens when you, w/ the closed lid, run

xrandr --output eDP1 --off; sleep 30; xrandr --output eDP1 --auto

The --auto is a failsafe to get yourself the output back after 30s and please look up the correct name for the internal display (placeholder "eDP1") from "xrandr -q"

Bidski · 2023-10-29 23:20:55

seth wrote:

What happens when you, w/ the closed lid, run
xrandr --output eDP1 --off; sleep 30; xrandr --output eDP1 --auto
The --auto is a failsafe to get yourself the output back after 30s and please look up the correct name for the internal display (placeholder "eDP1") from "xrandr -q"

That appears to work. I am unable to navigate to the laptop screen after running that command. After opening the laptop lid (and after running that command) the laptop screen is still on and it appears that the laptop screen is mirroring the external monitors.

I'm not sure this has actually proven anything though as my normal setup has always been sporadic and I could never quite pinpoint the conditions under which it would work or not. Having said that, things appear to be working well in my normal setup, for almost a week I think. I did recently upgrade evdi from 1.13 to 1.14 and DisplayLink from 5.7 to 5.8, so it is entirely possible that this upgrade has fixed things.

seth · 2023-10-30 07:26:42

my normal setup has always been sporadic and I could never quite pinpoint the conditions under which it would work or not. Having said that, things appear to be working well in my normal setup, for almost a week I think. I did recently upgrade evdi from 1.13 to 1.14 and DisplayLink from 5.7 to 5.8, so it is entirely possible that this upgrade has fixed things.

Under the assumption that the above results are meaningful and the problem remained:
----------------------------------------------------------------------------------------------------------------------

The critical aspect, b/c of the findings in #11 would have been the impact on the external output.
If there was none, it's just gnome trying to be extra smart and ending up usually dumb.

Afaiu there's no way to disable that any longer, but you would be able to "xrandr --output evdi --auto" (lookup the proper output name again) to restore the external output after it got turned off.

Bidski · 2023-10-30 21:52:32

Just to add something new and interesting to the mix. Booted my laptop this morning, laptop screen is on as well as the 2 external monitors. Closed the laptop lid and only 1 of the external monitors remained on and the other one turned off. Restarting the displaylink.service with the laptop lid closed resulted in both external monitors being turned on. Here is journalctl -x -b0 for today. Laptop lid is closed at 8:40:04 and displaylink service is restarted at 8:45:41

seth · 2023-10-31 13:31:12

Fyi

sudo journalctl -b | curl -F 'file=@-' 0x0.st

Never use "-x" w/ the journal, it's just spam.

Oct 31 08:40:04 4TELLT129 systemd-logind[767]: Lid closed.
Oct 31 08:40:04 4TELLT129 kernel: evdi: [I] (card3) Notifying display power state: off
Oct 31 08:40:04 4TELLT129 kernel: evdi: [I] (card3) Notifying display power state: off

There's no such entry for card2.

Oct 31 08:40:04 4TELLT129 kernel: evdi: [I] (card3) Notifying display power state: off
Oct 31 08:40:04 4TELLT129 kernel: evdi: [I] (card3) Notifying display power state: off
Oct 31 08:40:05 4TELLT129 kernel: evdi: [I] (card3) Disconnected from Task 992 (DesktopManagerE) of process 973 (DisplayLinkMana)
Oct 31 08:40:05 4TELLT129 kernel: evdi: [I] (card3) Removing i2c adapter bus number 21
Oct 31 08:40:05 4TELLT129 kernel: evdi: [I] (card3) Closed by Task 992 (DesktopManagerE) of process 973 (DisplayLinkMana)
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card3) Opened by Task 992 (DesktopManagerE) of process 973 (DisplayLinkMana)
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card3) Added i2c adapter bus number 20
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card3) Connected with Task 992 (DesktopManagerE) of process 973 (DisplayLinkMana)
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card3) Connector state: connected
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card3) Connector state: connected
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card3) Edid property set
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card3) Connector state: connected
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card3) Edid property set
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card3) Connector state: connected
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card3) Edid property set
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card3) Connector state: connected
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card3) Edid property set
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card3) Notifying display power state: on
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card3) Notifying mode changed: 1920x1200@60; bpp 32; pixel format XR24 little-endian (0x34325258)
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card3) Notifying display power state: on
Oct 31 08:40:08 4TELLT129 kernel: evdi: [W] evdi_painter_connect:886 (card3) Double connect - replacing 00000000a7b02e58 with 00000000a7b02e58
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card3) Connected with Task 992 (DesktopManagerE) of process 973 (DisplayLinkMana)
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card3) Connector state: connected
Oct 31 08:40:09 4TELLT129 kernel: evdi: [I] (card3) Connector state: connected
Oct 31 08:40:09 4TELLT129 kernel: evdi: [I] (card3) Edid property set
Oct 31 08:40:09 4TELLT129 kernel: evdi: [I] (card3) Notifying mode changed: 1920x1200@60; bpp 32; pixel format XR24 little-endian (0x34325258)

Oct 31 08:40:04 4TELLT129 kernel: evdi: [I] (card2) Edid property set
Oct 31 08:40:04 4TELLT129 kernel: evdi: [I] (card2) Disconnected from Task 992 (DesktopManagerE) of process 973 (DisplayLinkMana)
Oct 31 08:40:04 4TELLT129 kernel: evdi: [I] (card2) Removing i2c adapter bus number 20
Oct 31 08:40:04 4TELLT129 kernel: evdi: [I] (card2) Closed by Task 992 (DesktopManagerE) of process 973 (DisplayLinkMana)
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card2) Opened by Task 992 (DesktopManagerE) of process 973 (DisplayLinkMana)
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card2) Added i2c adapter bus number 21
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card2) Connected with Task 992 (DesktopManagerE) of process 973 (DisplayLinkMana)
Oct 31 08:40:07 4TELLT129 kernel: evdi: [I] (card2) Connector state: connected
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card2) Connector state: connected
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card2) Edid property set
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card2) Connector state: connected
Oct 31 08:40:08 4TELLT129 kernel: evdi: [I] (card2) Edid property set
Oct 31 08:40:09 4TELLT129 kernel: evdi: [I] (card2) Connector state: connected
Oct 31 08:40:09 4TELLT129 kernel: evdi: [I] (card2) Edid property set

Generally the lid closing seems to be at the very same time when GDM hands the session over - what if you don't close the lid immediately after the login?

Bidski · 2023-11-06 04:08:32

seth wrote:

Generally the lid closing seems to be at the very same time when GDM hands the session over - what if you don't close the lid immediately after the login?

I generally wait for some applications to start before I close the lid. These applications include some auto-starting applications (Slack and Microsoft Teams) as well as others that I start manually (gnome-terminal, Thunderbird, and Google Chrome). I haven't found much of a correlation between how much time passes after logging in and before closing the laptop lid. I am assuming that if Gnome is launching applications that the GDM session handover should be completed? Or is there some other condition that would signify the completion of the handover?

seth · 2023-11-06 08:56:47

afaiu GDM waits for the session to register what in the last journal took 17s after your login and ended up exactly overlapping w/ the lid close event.
Just get a cup of coffee first or so or wait 2 minutes while staring at a clock (I'd opt for the coffee) - the dbus timeout is 25s, systemd 90s

Bidski · 2023-11-14 21:40:30

So it doesn't seem to be related to session handover. I can wait 5+ minutes after logging in. After I have finished doing a system package update, checking my emails, and opening up chrome. Then I close my laptop lid and DisplayLink still ends up turning off both external monitors. Todays logs.

seth · 2023-11-14 22:58:15

Same pattern, there was https://github.com/DisplayLink/evdi/issues/192 but that resulted in the service crashing.

Since there're multiple evdi packages in the AUR, which one do you use?
https://wiki.archlinux.org/title/Displa … xx_Devices

Bidski · 2023-11-14 23:04:15

That issue also mentions using Wayland, which I'm not using.

Im using this evdi package.

seth · 2023-11-14 23:23:32

The bug is on the kernel module, the display server should be irrelevant.
You could try the performance of https://aur.archlinux.org/packages/evdi-git
Right now this looks like either a bug in the kernel module or userspace daemon.

You could possibly leverage https://wiki.archlinux.org/title/Acpid for an automatic workaround to restart the service.

Bidski · 2024-01-16 21:37:59

seth wrote:

You could possibly leverage https://wiki.archlinux.org/title/Acpid for an automatic workaround to restart the service.

Going to mark this as solved. Using acpid to restart the displaylink service on lid close seems to be an adequate workaround for now. Maybe one day I will have the time to investigate this properly.

Thank you for your help seth.

Arch Linux

#1 2023-10-22 22:31:16

[SOLVED] Lid switch settings ignored

#2 2023-10-23 06:12:57

Re: [SOLVED] Lid switch settings ignored

#3 2023-10-23 06:50:41

Re: [SOLVED] Lid switch settings ignored

#4 2023-10-23 07:16:36

Re: [SOLVED] Lid switch settings ignored

#5 2023-10-23 22:35:57

Re: [SOLVED] Lid switch settings ignored

#6 2023-10-23 23:12:27

Re: [SOLVED] Lid switch settings ignored

#7 2023-10-23 23:25:54

Re: [SOLVED] Lid switch settings ignored

#8 2023-10-24 06:53:48

Re: [SOLVED] Lid switch settings ignored

#9 2023-10-25 23:34:01

Re: [SOLVED] Lid switch settings ignored

#10 2023-10-26 07:41:44

Re: [SOLVED] Lid switch settings ignored

#11 2023-10-26 22:06:19

Re: [SOLVED] Lid switch settings ignored

#12 2023-10-27 06:48:07

Re: [SOLVED] Lid switch settings ignored

#13 2023-10-29 23:20:55

Re: [SOLVED] Lid switch settings ignored

#14 2023-10-30 07:26:42

Re: [SOLVED] Lid switch settings ignored

#15 2023-10-30 21:52:32

Re: [SOLVED] Lid switch settings ignored

#16 2023-10-31 13:31:12

Re: [SOLVED] Lid switch settings ignored

#17 2023-11-06 04:08:32

Re: [SOLVED] Lid switch settings ignored

#18 2023-11-06 08:56:47

Re: [SOLVED] Lid switch settings ignored

#19 2023-11-14 21:40:30

Re: [SOLVED] Lid switch settings ignored

#20 2023-11-14 22:58:15

Re: [SOLVED] Lid switch settings ignored

#21 2023-11-14 23:04:15

Re: [SOLVED] Lid switch settings ignored

#22 2023-11-14 23:23:32

Re: [SOLVED] Lid switch settings ignored

#23 2024-01-16 21:37:59

Re: [SOLVED] Lid switch settings ignored

Board footer