# how to find/disable tablet lid switch

## psycho

i just want to stop the os responding to the lid switch event.

my HP TX2613au (a local variant of the common TX2500 tablet) has never caused problems before in "tablet" mode (with the screen swiveled around and clicked down over the keyboard). the buttons on the sides of the tablet, and on the IR remote control, have still worked normally. now, for some reason, with xorg-server 1.8 and kernel 2.6.33-gentoo-r1 (amd64), putting the tablet physically into this position immediately disables all of these input events: with the mouse cursor over the little xev window, all button presses do nothing at all. lifting the screen up about two inches, they all come to life again.

this is definitely not a hardware issue (older xorg and older kernel allow buttons to work even with lid closed), so i'm guessing something linked to the lid switch event is happening, and telling xorg to ignore other events (except for the stylus/touchscreen, which still work). unfortunately inotifywait can't see the change if it's in /sys...and in any case, it happens even after rebuilding the kernel without hp-wmi (so that /sys/platform/devices/hp-wmi/tablet no longer exists). before disabling hp-wmi, i could see the "tablet" file (under /sys...) toggling from 1 to 0 as the lid was closed and opened...but for some reason itnotifywait ignored this change (unless i relayed it via cat > some_other_file).

is it something in udev? i can't see any relevant rules to edit.

ideally i would like to return to the proper behavior of the earlier kernel/xorg (where i had screen rotation triggered by the lid switch event), but at this stage i would be happy just to disable the lid switch entirely. if nobody can think of a way to do it via software changes, i'll probably take the tablet to bits and disable it physically.

----------

## Rexilion

Did you check the xorg.conf(.d)?

----------

## psycho

according to man evdev there's a "GrabDevice" option for the evdev driver, which sounds vaguely like it could be the cause of the problem (i.e. the lid switch is some kind of evdev device that grabs and hogs the whole evdev layer, blocking the keyboard etc.)...but it's not explicitly defined anywhere, and when i tried a catch-all "MatchIsTablet" conf with "/dev/input/event*" and set the GrabDevice option to "off", it made no difference. nor does setting GrabDevice on or off make any difference in the keyboard driver section.

i'll have another look through the logs to see if i can figure out if the server is aware of the lid switch at all (the fact that it doesn't do anything in xev suggests to me that it isn't). i might have a go with different keyboard models too. hmmm. actually...maybe if i install the old xf86-input-keyboard driver and use that, the problem would go away...

i will try that and come back...

----------

## psycho

no...and setting "AutoAddDevices" to "false" makes no difference either.

if i hadn't seen it working perfectly well with a slightly older kernel/xorg, i'd assume it was a hardware thing. but something, somewhere in the filesystem is making it behave this way...

*shrugs*

----------

## psycho

ok, finally some progress today: i've narrowed it down to acpi, because booting with "acpi=off" fixes the problem. obviously in a laptop i do want acpi however, so any suggestions as to how i can tweak acpi to ignore the lid switch are most welcome. i've already rebuilt the kernel without the "button" acpi module that's supposed to deal with lid switches, but this had no effect: disabling acpi completely is the only thing that has worked so far.

if nobody has any better ideas, i guess i'll just go through every possible acpi option (in the kernel, plus boot options like "acpi=strict"), enabling them one at a time and in various combinations until i (hopefully) find the specific cause.

----------

## Rexilion

Do you have acpid installed and running?

----------

## psycho

i did have, but don't at present (nor the "acpi" package). it didn't seem to make any difference to anything: acpid running or not, the /proc/acpi/button/lid/LID/state file says "open" all the time, presumably because it monitors whether the screen is closed face-down (as on a typical laptop) rather than twisted around and closed face-up (which is what i'm concerned with: it's possible to operate the tablet with the stylus and no buttons, but it was a heck of a lot better when the twenty-something keys around the edge of the screen and on the IR remote control were programmable and active).

do you think it would it be possible to use acpid to disable the behavior rather than disabling it in the kernel? i suppose that would be a better solution.

for now i am just going to continue working through the various kernel and boot parameter options.

 :Smile: 

----------

## psycho

ok, i can be more specific about the problem now...but still haven't found a solution.

the problem appears to be caused by acpi itself: the only kernel config change that fixes it is total omission of acpi. even if i build acpi with no modules (battery, fan, processor, etc.) selected underneath it, the keyboard is killed. what's more, none of the many acpi-related kernel parameters fix it except for "acpi=off" and "acpi=ht" (hyperthreading only, which is much the same as no acpi at all, in terms of fans running at full speed, no lcd brightness control, etc.).

i've also noticed that it has nothing to do with x11, because even at the console without X running, i can hold down a key and it stops repeating once the screen is tilted low enough to activate the switch. this is not hard-wired behavior because (a) the buttons work perfectly well with the screen in tablet position when the kernel's booted acpi=off, and (b) in slackware64 13.0 / vanilla linux 2.6.31 they worked perfectly well WITH acpi. so maybe it's a kernel bug because it seems that acpi is now doing something silly like interpreting the lid switch as a key press, and so locking out all other key press events until the lid is raised out of tablet position.

time to downgrade the kernel?

 :Sad: 

----------

## Rexilion

Yeah downgrade for now. You could report a bug to the kernel bugzilla and see if you can help bisecting it.

----------

## psycho

downgraded: no effect. installed known working 2.6.31 vanilla linux kernel, configured exactly as it was in slackware64 (in which acpi and the lid switch worked properly): still no effect.

so it's not a kernel bug either! either it's a weird hardware glitch that coincidentally developed at exactly the same time i installed gentoo...or something in gentoo's userspace (something very early) is causing the problem.

tomorrow i will try wiping out gentoo's udev rules and replacing them with slackware's...i don't know whether this will help (or even if different distros have substantially different rules) but it's all i can think of now. i've already tried disabling various boot scripts (ones like keymaps that seemed to have some possibility of being relevant) but nothing made any difference. it definitely worked in slackware64, and yet in gentoo even with the exact same kernel (+initrd) on the exact same hardware, acpi kills all buttons in tablet mode.

crazy.

----------

## Rexilion

Compare versions of the relevant pieces of software like Hal, xorg and friends. DON'T delete udev rules, use that only as a last resort since it can trash ur system.

----------

## psycho

i don't mean to wipe them out irreversibly: i'm just going to rename the directories and put the slackware versions in their place. if it trashes the system i can boot from usb and fix it. if it works, i can start narrowing it down to which part of udev fixed it, and eventually revert to gentoo's udev with just that one change.

i've already determined that hald's running or not running makes no difference; ditto for xorg (the problem kicks in somewhere between grub's loading the kernel and my logging in to the console). after several days i am pretty much at the point of "last resort" anyway: if this doesn't fix it i might break the switch...although having learned that it could be a gentoo-specific problem, i will probably try installing another distro before that.

----------

