My problem is that my laptop’s touchpad gets disabled when I close the laptop lid. Note that I have the “When laptop lid closed” setting under Power Management in the Plasma System Settings set to “Turn off screen”, but I’ve also tried setting it to “Do nothing” and that does not make a difference. I do not want it to Sleep when I close the lid.
The pointing stick continues to work. To get the touchpad working again I’ve found I can Sleep the system, and when I wake it back up the touchpad is working again.
Can anyone suggest any places to look for configuration to adjust this? I assume in some file somewhere a lid closed event is being set to disable the touchpad and the lid open event either not configured or misconfigured…
Hi and welcome to the Forum
So you want closing the lid to ‘ignore’ power management? If so you need to edit /etc/systemd/logind.conf file and change the line;
#HandleLidSwitch=suspend
to
HandleLidSwitch=ignore
Hi Malcom, and thanks for the reply. But no, I don’t want it to ignore power management. My power management setting just says turn off the screen. I don’t want it to also to just turn off the touch pad. Or rather, I just care that the touchpad works when I open it again, I’d be perfectly happy if it turned it off when I closed the lid but turned it back on when I opened it again.
I tried the setting you suggested, but it did not help, the touchpad still gets disabled when I close the lid (and not reenabled when I open it). (I see there is also HandleLidSwitchExternalPower and HandleLidSwitchDocked but I tried it on battery). The screen does still go off when I close the lid, so I think that setting does not prevent KDE Plasma’s Power Management setting from taking effect, though I don’t think that’s the problem.
I’ve watched journalctl output for a clue, but I don’t see anything that seems relevant.
I’m not sure why it shows 3 mouse devices. I’d expect 1 for the pointer stick, 1 for the touchpad. There’s no external mouse or other input device plugged in.
I’m even more confused about what is happening now. I’ve been web searching and reading and trying things. I gather that various desktop power management controls, just as the KDE Plasma Power Management (aka powerdevil) will “inhibit” the handling of various events by systemd logind. Hence why the change I made to the config for that didn’t do anything.
But I currently have that set to “Do nothing” rather than “Turn off screen”. And yet the screen clearly goes off when the lid is maybe 10-15 degrees from fully closed. This suggests to me that something else is reacting to the lid event (could it even be a UEFI thing?).
Meanwhile while swapping between browser windows, power management, and the console, in the state where the touchpad had become disabled, because I wanted to try a command that an old thread mentioned as a way to turn it back on (“toggle touchpad”) I suddenly found that the touch pad was working again. (Despite toggle being an unknown command, so not due to that). Closing and reopening the lid, it still worked. Then alt-tabbing back to the browser it stopped working again. It seems like hitting Alt can get it working again.
After a bunch of experimenting, the best way I can characterize it, is that rather than the problem being that closing the lid simply disables the touchpad, is that it puts the touchpad into some kind of weird mode. This weird mode starts out unresponsive but can be made responsive again by key actions (at least Alt, maybe others), and can also be made unresponsive again (sometimes just by alt-tabbing between windows). Sleeping and waking will put it back into “reliable” mode.
It’s hard to fully get grip on the behavior of this “fluky mode”. It sometimes behaves as if it is remembering a “disabled/enabled” state for each window independently. It will work in window X but not Y. Hitting alt in window Y will get it working there. Then it will work in X and Y but not window Z. Hitting alt with the focus in that window makes it work. This will seem consistent and repeatable but then sometimes it will revert to not working in a window in which it was working again. I can’t even imagine what part of the system could be producing this weird behavior.
Hi
The lid has a magnet (rare earth) to trigger the switch, purely electrical… check bottom left corner area (That’s where it is on my HP’s) of the screen with something metallic.
Your not the only one, I see some solutions on google with “linux+elantech touchpad+resume” but might need some more info on the modules loaded on your system. It could also be just a usb power issue with that device…
I may have gotten the problem to go away. While the touchpad was in “fluky mode”, I unchecked “Disable touchpad when typing” in the touchpad settings panel of the Plasma System Settings and saved the changes. This did not get it out of fluky mode. Then I tried a “switch user” and just logged back in as the same user (perhaps this was just equivalent to locking and unlocking), to experiment if that would have the same effect as sleep/resume. This did put it back into “reliable mode.” Now when I close and reopen the lid it seems to remain in “reliable mode.”
Going back into the touch pad settings panel I see that “Disable touchpad when typing” is checked again. It seems perhaps saving this change is broken, but perhaps simply saving the changes fixed something in the relevant config file.
I guess we’ll see if the “fix” sticks. I’d still be curious if anyone has any insight as to what could possibly been going on.
Yeah there are magnets on both bottom corners of the base and also the two matching corners of the lid. I can feel them pull together when the lid gets close to closed. This also is an HP.
FWIW, this “fix” did not in fact stick. It’s back to the old behavior. I believe it may have to do with the “disable touchpad while typing” which when I uncheck it in the Plasma input devices settings never gets saved (if I go back in it’s checked again). Maybe I’ll try posting on the KDE forums about that.
Setting DisableOnKeyboardActivity=false in ~/.config/touchpadrc produced the change desired. The KDE System Setting touchpad applet is evidently reading that, as it reflects the change, but fails to actually persist changes to it. I filed a bug in the KDE bug system.
This change also fixed my problem of closing the lid messing up the touchpad state.
