Quick version:
Blacklisting the "Intel Virtual Button driver" in udev, per a post in
the Arch user forum that David linked to, made it work again. I created
/etc/udev/rules.d/99-acer-libinput.rules with the single line
ACTION=="add|change", KERNEL=="event[0-9]*", ATTRS{name}=="Intel Virtual Button driver",
ENV{LIBINPUT_IGNORE_DEVICE}="1"
, ran update-initramfs (which I may not have needed to do), and rebooted;
the keyboard and mouse then worked again in X.
Long version: see below.
On Wed, 21 Oct 2020, David wrote:
2) Take a look at this and surrounding posts for troubleshooting ideas:
https://bbs.archlinux.org/viewtopic.php?pid=1925437#p1925437
That discussion relates to kernel 5.* versions but maybe Debian has
applied some patches earlier.
This particular post ended up being the key to fix it; see below.
3) That discussion suggests that X, udev and libinput might be
possible suspects that you might bug report against their Debian
packages to get troubleshooting ideas from their maintainers. Check
if those packages changed on your system recently.
In my original post, I mentioned that when the problem first showed up,
I had changed from linux-image-4.19.0-9-amd64 to
linux-image-4.19.0-10-amd64 , but I *also* changed from libinput10 and
libinput-bin 1.12.6-2 to 1.12.6-2+deb10u1 at the same time. When I
downgraded those two packages back to 1.12.6-1 using
snapshots.debian.org , I still had the problem with the 4.19.0-10
kernel image.
I also looked at the log files from when I first started troubleshooting
this, and they were dated 26 August. I remember Googling at that time
and not finding anything online about this problem. I wrote the first
draft of my email around that time as well, but I didn't have much time
to spend on troubleshooting, so I didn't send it.
That Arch BBS post is from 9 September, and the Debian bug is from 8
October.
Conclusion: I should have Googled again before sending my
nearly-2-month-old email. :D
(From David's second email:)
5) Try this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971839
(if that's your model laptop)
That is very close to my model. That bug cites an "E5-511". Both the
sticker on the bottom of my laptop, and some of the fields in the
dmidecode output, give the model I have as "ES1-511". A Web search
shows that both should be valid Acer models; the E5-511 has a faster
CPU and bigger disk than the ES1-511, but the rest of the specs are
similar.
I tried the suggestion in that bug and got a little improvement: the
built-in keyboard worked in X, but the touchpad did not. Strangely, I
could log into X with the keyboard, and say "cat /dev/input/mice" as
root, and get characters on the screen when I moved my finger on the
touchpad, but X still refused to recognize it for some reason.
In that condition (keyboard worked, touchpad didn't), looking in
/var/log/Xorg.0.log showed that libinput didn't understand that quirks
entry:
---
(EE) Unknown key ModelTabletModeSwitchUnreliable in [Acer E5-511]
(50-system-acer.quirks)
(EE) Failed to load the device quirks from /usr/share/libinput and
/etc/libinput/local-overrides.quirks. This will negatively affect device
behavior. See
https://wayland.freedesktop.org/libinput/doc/1.12.6/device-quirks.html for
details.
---
A little digging around on freedesktop.org shows that the
ModelTabletModeSwitchUnreliable keyword is not mentioned in the libinput
1.12.6 documentation. The first version where that option shows up in
the docs is 1.13.0 .
I put the 50-system-acer.quirks file back to its default condition,
without the extra entry suggested in the Debian bug.
I thought I would try disabling that device at the udev level. As
suggested in the Arch BBS post, I created a new file
/etc/udev/rules.d/99-acer-libinput.rules
with the single line
ACTION=="add|change", KERNEL=="event[0-9]*", ATTRS{name}=="Intel Virtual Button driver",
ENV{LIBINPUT_IGNORE_DEVICE}="1"
.
I don't know if I *needed* to do this, but I then ran update-initramfs,
for the 4.19.0-11 kernel.
Then, I powered the laptop completely off with the power button, turned
it back on with the power button, and booted into the 4.19.0-11 kernel.
Success! Both the keyboard and touchpad work in X again.
They work when I first boot up the laptop into X, and they still work
after I close the lid, let the laptop suspend, open the lid, and let it
come out of suspend.
I'm still not sure why changing which *kernel* I booted made this bug
appear. Perhaps the old kernel initialized (or didn't initialize) that
input device in a different way than the later ones.
Thanks for your help!
Matt Roberds
