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

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.

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! 🙏

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:

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).

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

Astounding! Well done!

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

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!

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).

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.

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.

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...

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.