how to completely disable laptop lid detection? [SOLVED]

GNUser · 2018-04-28 01:19:07

I have a T400 with Libreboot and Devuan ASCII with MATE and lightdm. Everything works great except that closing and opening the laptop lid triggers a horrible graphics bug*.

I think the simplest fix would be to completely disable the laptop lid detection. Here is what I already did:

1. HandleLidSwitch=ignore in /etc/elogind/logind.conf
2. IgnoreLid=true in /etc/UPower/UPower.conf
3. deleted /etc/acpi/events/lid-acpi-support

However, even with the three changes above, something still detects the laptop lid because closing/reopening the lid continues to trigger the bug 100% of the time.

Please, how do I completely disable the laptop lid switch? I'd do it with a piece of tape if there were a physical switch, but I can't find a switch (I think there are some magnets and magnet sensors hiding somewhere).

* The bug is a horizontal line across the screen below which I can see nothing. The line follows the cursor around when I move the mouse up and down. Blacklisting the i915 kernel module and using vesa graphics driver makes this bug go away, so I know this is a software issue and not a hardware issue.

Last edited by GNUser (2018-04-29 19:00:40)

ralph.ronnquist · 2018-04-28 06:18:58

Maybe you have xserver-xorg-input-evdev installed, and it grabs the lid switch as input device for X?
Check /var/log/Xorg.0.log where it says Lid Switch.

GNUser · 2018-04-28 11:09:24

Thank you, ralph.ronnquist. X is indeed grabbing the lid switch as a device, because this line is in /var/log/Xorg.0.log:

[     7.945] (II) config/udev: Adding input device Lid Switch (/dev/input/event1)
[     7.945] (II) No input driver specified, ignoring this device.
[     7.945] (II) This device may have been added with another device file.

However, xserver-xorg-input-evdev is not installed. Only these xserver-xorg-input-* packages are installed on my system:

xserver-xorg-input-all 1:7.7+19
xserver-xorg-input-libinput 0.23.0-2
xserver-xorg-input-synaptics 1.9.0-1+b1
xserver-xorg-input-wacom 0.34.0-1

Any ideas?

Last edited by GNUser (2018-04-28 12:37:19)

ralph.ronnquist · 2018-04-28 12:36:05

Well, I'm no expert on this, but I think it's the lines following that log line that should tell whether the input is actually added or ignored. On the other hand, it's apparently eudev that presents the lid switch to X in the first place, presumably during its traversal of /sys. Perhaps it traces back to /lib/udev/rules.d/80-libinput-device-groups.rules or 90-libinput-model-quirks.rules, or some other rule(s), and perhaps there's a suitable knuckle-rap to make eudev ignore the lid switch instead.

Thus I'm thinking that whatever it is that results in the /dev/input/eventX device node should be patched to not do that for the lid switch, and then it won't be presented to X. I tried this by removing /dev/input/eventX manually, and restarting X (not rebooting), which resulted in a log without a "Lid Switch" discovery line. Maybe you could try that as an experiment to see if it makes any difference for your graphics problem. Otherwise it's probably no use in digging deeper.

GNUser · 2018-04-28 12:40:09

ralph.ronnquist, I updated my post above with the subsequent lines from the log. It does seem that something else is presenting the lid switch to X.

I will do the experiment and will report back in a minute.

mlsmith · 2018-04-28 12:47:06

I can only speak for my laptop, but do you see LID or LID0 in /proc/acpi/wakeup? Perhaps that is what it triggering the lid.

GNUser · 2018-04-28 12:55:14

@ralph.ronnquist. I have very strange results to report:

1. My lid switch is /dev/input/event1, so manually deleted /dev/input/event1. I also deleted /var/log/Xorg.0.log
2. I then kill X (Control + Alt + Backspace) and log back in
3. /var/log/Xorg.0.log shows the same Lid Switch lines (it is added as /dev/input/event1) even though /dev/input/event1 does not exist
4. Closing and opening the lid triggers the crazy graphics bug

@mlsmith:

bruno@thinkpad:~$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
HDEF	  S4	*disabled  pci:0000:00:1b.0
USB1	  S4	*enabled   pci:0000:00:1d.0
USB2	  S4	*enabled   pci:0000:00:1d.1
USB3	  S4	*enabled   pci:0000:00:1d.2
EHC1	  S4	*enabled   pci:0000:00:1d.7
USB4	  S4	*enabled   pci:0000:00:1a.0
USB5	  S4	*enabled   pci:0000:00:1a.1
USB6	  S4	*enabled   pci:0000:00:1a.2
EHC2	  S4	*enabled   pci:0000:00:1a.7
SLT1	  S4	*disabled  pci:0000:05:00.0
SLT2	  S4	*disabled
SLT3	  S4	*disabled
SLT6	  S4	*disabled
LANC	  S3	*disabled
LANR	  S3	*disabled
SLPB	  S3	*enabled   platform:PNP0C0E:00
LID	  S3	*enabled   platform:PNP0C0D:00

Last edited by GNUser (2018-04-28 12:58:31)

mlsmith · 2018-04-28 13:22:28

Just a shot in the dark here but what happens if you run

echo " LID" > /proc/acpi/wakeup

as root to disable LID? Note that there is a space before the L in LID since the device must be 4 characters. As I understand it, this doesn't persist between boots so you have to disable the lid in /etc/rc.local.

GNUser · 2018-04-28 14:24:05

Thank you for that, mlsmith. I tried it and closing/reopening the lid still triggers the bug.

I think my best chance is to disable the lid switch at the lowest possible level. dmesg shows this:

bruno@thinkpad:~$ dmesg | grep Lid
[    0.797043] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00/input/input1
[    0.797058] ACPI: Lid Switch [LID]

Is eudev related to the first line above?

I will try ralph.ronnquist's idea to explore eudev meanwhile.

Last edited by GNUser (2018-04-28 14:29:56)

mlsmith · 2018-04-28 14:29:02

I hope you figure it out! Please be sure to follow up with the solution once you find it as it might help others.

GNUser · 2018-04-28 15:14:24

Here is the output of udevadm info -a -n /dev/input/event1:

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00/input/input1/event1':
    KERNEL=="event1"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00/input/input1':
    KERNELS=="input1"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{uniq}==""
    ATTRS{properties}=="0"
    ATTRS{phys}=="PNP0C0D/button/input0"
    ATTRS{name}=="Lid Switch"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00':
    KERNELS=="PNP0C0D:00"
    SUBSYSTEMS=="acpi"
    DRIVERS=="button"
    ATTRS{hid}=="PNP0C0D"
    ATTRS{path}=="\_SB_.PCI0.LPCB.EC__.LID_"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00':
    KERNELS=="PNP0C09:00"
    SUBSYSTEMS=="acpi"
    DRIVERS=="ec"
    ATTRS{uid}=="0"
    ATTRS{hid}=="PNP0C09"
    ATTRS{path}=="\_SB_.PCI0.LPCB.EC__"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a':
    KERNELS=="device:2a"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{adr}=="0x001f0000"
    ATTRS{path}=="\_SB_.PCI0.LPCB"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00':
    KERNELS=="PNP0A08:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{adr}=="0x00000000"
    ATTRS{hid}=="PNP0A08"
    ATTRS{path}=="\_SB_.PCI0"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00':
    KERNELS=="LNXSYBUS:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{hid}=="LNXSYBUS"
    ATTRS{path}=="\_SB_"

  looking at parent device '/devices/LNXSYSTM:00':
    KERNELS=="LNXSYSTM:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{hid}=="LNXSYSTM"
    ATTRS{path}=="\"

The lid switch has the convenient "Lid Switch" name attribute. Can someone help me write a udev rule that will disable the lid switch?

I know very little about udev rules, but tried creating /etc/udev/rules.d/90-disable-lid-switch with this in it:

ACTION=="add", ATTRS{name}=="Lid Switch", RUN="/bin/sh -c 'echo 0 >/sys/\$devpath/authorized'"

Not surprisingly, my feeble attempt at a udev rule had no effect--lid switch is still functional and able to trigger the video bug.

Last edited by GNUser (2018-04-28 17:31:07)

GNUser · 2018-04-28 15:43:20

From looking at the output of the udevadm command in post #11, another option might be to somehow blacklist the button driver. Alas, button does not seem to be a kernel module (I don't see button in the output of lsmod), so I have no idea how to blacklist it.

ralph.ronnquist · 2018-04-28 23:53:20

Right, the kernel uses the ec and button drivers for dealing with the lid switch. In my lsmod I have a button module, used by nouveau and i915. I don't have an ec module, so that's probably built-in, and maybe so is the button module for you(?)
(my kernel is linux-image-4.9.0-5-amd64 version 4.9.65-3+deb9u2 from ascii-security)

If button is built-in, blacklisting is not an option, and according to modinfo button there are only the two parameters lid_report_interval and lid_init_state, which don't appear to be useful here.

But, maybe you have a thinkpad_acpi module, or some other module, that registers as button driver? A quick glance at
modinfo $(lsmod | sed 's/\s.*//') might lead to something...

The other end of the chain is at X, and perhaps installing that xserver-xorg-input-evdev would lead to something...

GNUser · 2018-04-29 02:55:51

These are all excellent ideas, which makes me all the more flabbergasted that I don't have a hot lead yet:

1. My kernel is linux-libre 4.16.2, which causes me the fewest problems (only the bug described in post #1). The button driver is definitely not a kernel module for this particular kernel, so I guess it must be a built-in driver.

2. Indeed, I found the thinkpad_acpi module loaded. Surprisingly, blacklisting it has no discernible effect.

3. modinfo $(lsmod | sed 's/\s.*//') is a great idea. Alas, I cannot find the string "button" in the output. I did find the panel_ignore_lid parameter for the i915 kernel module and I tried all of the values, no joy.

4. I installed xserver-xorg-input-evdev. Interestingly, there is basically no change in /var/log/Xorg.0.log:

[     7.869] (II) config/udev: Adding input device Lid Switch (/dev/input/event1)
[     7.869] (II) No input driver specified, ignoring this device.
[     7.869] (II) This device may have been added with another device file.

5. I'd like to try disabling the Lid Switch input method in X with a custom config file in /usr/share/X11/xorg.conf.d similar to this (without the MatchIsTouchscreen, of course), but it's looking bleak given that $ xinput --list does not output anything that looks like a lid switch.

It seems that I underestimated the complexity involved in completely disabling the lid switch. One would think it would be simple.

Last edited by GNUser (2018-04-29 03:00:10)

GNUser · 2018-04-29 19:00:08

I found a low-tech solution: I taped a tiny magnet at the right spot*. Now the switch is still detected as an input device, but closing and opening the lid has absolutely no effect.

P.S. To find the right spot, I just moved a magnet around until it triggered the lid switch. For my T400, the spot was below the display and just above the bluetooth LED.

Last edited by GNUser (2018-04-29 19:06:28)

golinux · 2018-04-29 19:21:29

LOL! Sometimes low-tech is the only solution.

GNUser · 2018-04-29 23:32:55

Haha, indeed!

Parenthetically, this whole thread was just a workaround/bandaid for my issue. The real question is "which system component is changing display settings in response to the laptop lid?" Before I close the laptop lid my display settings are fine, but after closing and reopening the laptop lid the display settings are severely messed up (see post #1).

Last edited by GNUser (2018-04-30 14:10:35)

GNUser · 2018-04-30 14:11:14

To attempt to answer my own question:

When I try miscellaneous other kernels, the lid-related graphics bug I describe in post #1 goes away. (Unfortunately these other kernels affect my system in other less tolerable ways, so using them is out of the question.) Therefore, although I can't prove it, I think the 4.16.2 kernel itself (or its i915 module) is the bad guy that messes up my display when I close and open the lid.

At any rate, with the lid switch disabled I can finally just sit back and enjoy my Devuan Ascii installation

Devuan rules!

Last edited by GNUser (2018-04-30 14:11:51)

GNUser · 2019-02-18 16:50:15

At long last, I figured out how to disable the lid switch at kernel level.

bruno@thinkpad:~378$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
HDEF	  S4	*disabled  pci:0000:00:1b.0
...
SLPB	  S3	*enabled   platform:PNP0C0E:00
LID	  S3	*enabled   platform:PNP0C0D:00

Note that the node for LID is PNP0C0D:00

Running this command at boot will disable the lid switch at the kernel level:

echo 'PNP0C0D:00' | sudo tee /sys/bus/acpi/drivers/button/unbind

Now lid switch is totally disabled--closing and opening the lid has no effect whatsoever and I can no longer trigger the graphics bug I described in my first post

Last edited by GNUser (2019-02-18 16:56:08)

PedroReina · 2019-02-18 20:12:06

GNUser wrote:

I figured out how to disable the lid switch at kernel level.

Astounding! Well done!

hotproton · 2022-07-24 07:28:49

How the hell did you work that out!!? I struggled with this for a few hours before finding your simple fix. Thank you GNUser for coming back to a thread 10 months later and posting a solution - impressive persistence award unlocked. :-)

Head_on_a_Stick · 2022-07-24 12:00:36

GNUser wrote:

Running this command at boot will disable the lid switch at the kernel level:
echo 'PNP0C0D:00' | sudo tee /sys/bus/acpi/drivers/button/unbind

The sysfsutils package provides /etc/sysfs.conf, which can be used to set values in /sys/.

However:

GNUser wrote:

after closing and reopening the laptop lid the display settings are severely messed up

Did you try removing the xserver-xorg-video-intel package? It is said to be more buggy than the modesetting DDX driver which is used as a fallback in the absence of that package. The DDX driver draws the screen for most desktops so it's more likely to be the culprit than the i915 kernel driver (which is responsible for the direct hardware interface).

Last edited by Head_on_a_Stick (2022-07-24 12:02:20)

Danielsan · 2023-05-09 23:10:35

Hi, I ended up here because I am trying to fix an issue with LID that I temporaraly resolved with this trick but some recent changes made it ineffective:

xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -n -t bool -s true

When I open the lid the system got frozen but the mouse, therefore disabling it looks like a better solution, however I don't have the same output as GNU User:

find /proc/acpi -iname lid
/proc/acpi/button/lid
/proc/acpi/button/lid/LID

I am missing lid in the section he used to disable it:

cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
HDAS	  S3	*disabled  pci:0000:00:0e.0
XHC	  S3	*enabled   pci:0000:00:15.0
XDCI	  S4	*disabled
RP01	  S4	*enabled   pci:0000:00:14.0
PXSX	  S4	*disabled  pci:0000:02:00.0
CNVW	  S4	*disabled

Any suggestion? Thanks! 🙏

Altoid · 2023-05-10 16:15:39

Hello:

Danielsan wrote:

... missing lid in the section he used to disable it:

cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
HDAS	  S3	*disabled  pci:0000:00:0e.0
XHC	  S3	*enabled   pci:0000:00:15.0
XDCI	  S4	*disabled
RP01	  S4	*enabled   pci:0000:00:14.0
PXSX	  S4	*disabled  pci:0000:02:00.0
CNVW	  S4	*disabled

Maybe one of the enabled ones is causing problems.
ie: some conflict.

Danielsan wrote:

Any suggestion?

As I understand it, you have only two options with an actual address and enabled :

XHC	  S3	*enabled   pci:0000:00:15.0
RP01	  S4	*enabled   pci:0000:00:14.0

I think XHC is related to something USB and that RP01 is related to something PCIE.

Your mouse is probably on the USB bus (?).

Try disabling one at a time or both at the same time, reboot and see what happens.
ie: if the lid works properly and the mouse does not freeze any more.

BTW: in my WS, I have all entries in /proc/acpi/wakeup set to disabled, even the ones with no address. 8^°

HTH.

Best,

A.

The officially official Devuan Forum!

#1 2018-04-28 01:19:07

how to completely disable laptop lid detection? [SOLVED]

#2 2018-04-28 06:18:58

Re: how to completely disable laptop lid detection? [SOLVED]

#3 2018-04-28 11:09:24

Re: how to completely disable laptop lid detection? [SOLVED]

#4 2018-04-28 12:36:05

Re: how to completely disable laptop lid detection? [SOLVED]

#5 2018-04-28 12:40:09

Re: how to completely disable laptop lid detection? [SOLVED]

#6 2018-04-28 12:47:06

Re: how to completely disable laptop lid detection? [SOLVED]

#7 2018-04-28 12:55:14

Re: how to completely disable laptop lid detection? [SOLVED]

#8 2018-04-28 13:22:28

Re: how to completely disable laptop lid detection? [SOLVED]

#9 2018-04-28 14:24:05

Re: how to completely disable laptop lid detection? [SOLVED]

#10 2018-04-28 14:29:02

Re: how to completely disable laptop lid detection? [SOLVED]

#11 2018-04-28 15:14:24

Re: how to completely disable laptop lid detection? [SOLVED]

#12 2018-04-28 15:43:20

Re: how to completely disable laptop lid detection? [SOLVED]

#13 2018-04-28 23:53:20

Re: how to completely disable laptop lid detection? [SOLVED]

#14 2018-04-29 02:55:51

Re: how to completely disable laptop lid detection? [SOLVED]

#15 2018-04-29 19:00:08

Re: how to completely disable laptop lid detection? [SOLVED]

#16 2018-04-29 19:21:29

Re: how to completely disable laptop lid detection? [SOLVED]

#17 2018-04-29 23:32:55

Re: how to completely disable laptop lid detection? [SOLVED]

#18 2018-04-30 14:11:14

Re: how to completely disable laptop lid detection? [SOLVED]

#19 2019-02-18 16:50:15

Re: how to completely disable laptop lid detection? [SOLVED]

#20 2019-02-18 20:12:06

Re: how to completely disable laptop lid detection? [SOLVED]

#21 2022-07-24 07:28:49

Re: how to completely disable laptop lid detection? [SOLVED]

#22 2022-07-24 12:00:36

Re: how to completely disable laptop lid detection? [SOLVED]

#23 2023-05-09 23:10:35

Re: how to completely disable laptop lid detection? [SOLVED]

#24 2023-05-10 16:15:39

Re: how to completely disable laptop lid detection? [SOLVED]

Board footer