11

My Kubuntu updated from kernel 5.4.0-42 to kernel 5.4.0-47 and my laptop's keyboard stops working (except brightness keys). Booting back to 5.4.0-42 solved the problem.

Keyboard also works perfectly on Windows 10 (I have dual boot).

Keyboard also works in GRUB (2.04). But it does not in kernels 5.4.0-47 and above.

Updating to Kubuntu 20.10 (beta) does not help either (kernel 5.8.0-20 same problem).

My problem is similar to this one: Keyboard on HP notebook stops working under kernel 5.4.0-45-generic

And yes, I've seen this on launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894017

So what's the problem and why is it not fixed in whole range of kernels 5.4.0-47 - 5.8.0-20?

9
  • 1
    Refer askubuntu.com/help/on-topic where you'll notice only supported releases of Ubuntu and flavors are on-topic for this site. For groovy gorilla [20.10] questions you'll need to use a development support site such as IRC (#ubuntu+1) or Ubuntu Forums, or wait until after release for this site (expected release date for Ubuntu 20.10 is 22 October (discourse.ubuntu.com/t/groovy-gorilla-release-schedule/15531) when your question will be on-topic here).
    – guiverc
    Oct 5, 2020 at 12:29
  • 1
    Think to answer the question you posed, the problem seems to limited to some HP and Acer laptops so far. For me it started on 0-44 on an Acer. Most of questions(less than a dozen) on here seem to be limited to those two makes. Imagine the kernel writers and Intel would have to get together to find the bug on those models affected.
    – crip659
    Oct 5, 2020 at 12:50
  • 1
    @guiverc this issue is valid for 20.04. I said about 20.10 just for reference that this issue is not fixed even in future release. The main problem seems to be in linux kernel module "intel_vbtn". After blacklising it everything works great
    – IGR94
    Oct 5, 2020 at 12:50
  • 2
    Ubuntu and Linux also had a kernel bug with Intel's baytrail CPUs. Do not think they have completely fixed that yet, except for the work around with C-State.
    – crip659
    Oct 5, 2020 at 13:01
  • 2
    The baytrail bug causes random hard freezes of the computer. Do not know if they have fixed it yet. You not knowing about it and having baytrail also, maybe is fixed. I have the c state work around in grub(I think it is still there), so have not notice if fixed. askubuntu.com/questions/883430/…
    – crip659
    Oct 5, 2020 at 14:35

2 Answers 2

9

The solution was found here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894017

I just blacklisted intel_vbtn kernel module in /etc/modprobe.d/blacklist.conf and rebooted. Author mentioned that somehow intel_vbtn thinks my laptop is in tablet mode (WHAT?!) and disabled keyboard/touchpad.

How to blacklist

To implement this, you can either create a new file in /etc/modprobe.d with the suffix .conf or use the main blacklist.conf file. The former may be preferable, since you can then just delete the file when it is no longer required (i.e. when the bug is fixed):

sudoedit /etc/modprobe.d/blacklist-intel_vbtn.conf

Add a line to the file, optionally with a comment explaining why you are doing this

# bug in module breaks keyboard, so don't load it
blacklist intel_vbtn

Save the file, exit and reboot.

P.S. After mailing with Mr. Hans de Goede from RedHat I got following answer:

This should be fixed by this upstream commit, which landed in Linus' tree a couple of hours ago: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86?id=8169bd3e6e193497cab781acddcff8fde5d0c416

Igor, if you do:

cat /sys/class/dmi/id/chassis_type

On your laptop, and the output is NOT "31" or "32" then this fix should work for you.

If the output actually is "31" or "32 (which I do not expect), then please let me know, because then we need a different fix.

P.P.S. On my system (Intel Celeron N2940) chassis_type returns 10

10
  • Same issue here on Dell XPS 15 9500. Notebook is being detected with type 10. Your solution didn't work for me. Do you have any other workaround?
    – leoheck
    Mar 29, 2021 at 13:14
  • Which kernel version do you have?
    – IGR94
    Mar 29, 2021 at 13:37
  • Right now it is 5.8.0-48. I tested reverting to an old kernel (5.8.0-45). Same results. The strange thing that sometime after booting, I started to work with it using the trackpad and built-in keyboard then I tried the mouse by an impulse and it was working. My chassis type is being reported as 10 and I didn't revert the file that blacklists the intel_vbtn
    – leoheck
    Mar 29, 2021 at 23:14
  • 1
    This does not work for me. Laptop: Lenovo. I can't believe this nonsense... like wtf for real Apr 25, 2021 at 22:37
  • 1
    @IGR94 true that worked for me!
    – curious
    Feb 7, 2022 at 14:01
2

This seems to be libinput that receives a SW_TABLET_MODE event from one of the laptops input devices. I don't know why they disable the keyboard and touchpad when receiving that event, but I would guess it was to avoid button presses on laptops you can flip the screen all the way around so the keyboard/touchpad is underneath the touch screen.

However, some laptop models emit this event even when the keyboard is not flipped around. Dell Precision 5760 has an "Intel HID switches" input device which triggers this event when the laptop is moved. So every time I triggered the accelerometer the internal keyboard and touchpad stopped working for some time. Before it went back to laptop mode. This bug seems to have been [fixed a few weeks ago][1], so hopefully it gets rolled out in a stable release soon.

Others have suggested blacklisting intel_vbtn, but that didn't work for me. Probably because of a different driver in use. But I found a different workaround, which is a solution in libinput for this exact problem; register a quirk for the input device triggering tablet mode: ModelTabletModeSwitchUnreliable.

First you need to figure out which input device is triggering the SW_TABLET_MODE event. Install libinput-tools to help you debug the problem:

$ sudo atp install libinput-tools

Now we need to record all input events with sudo libinput debug-events. Start it, and try to trigger the SW_TABLET_MODE event. It should look something like this:

-event27  SW_TABLET_MODE  .....

That means it is /dev/input/event27 which is triggering the tablet mode. It is probably a different number for others. Let's list the input devices to find out it's name:

$ sudo libinput list-devices

Look for the event number you got earlier and note down the device name:

Device:           Intel HID switches
Kernel:           /dev/input/event27

Now we need some identifiers for your computers modalias:

$ cat /sys/class/dmi/id/modalias
dmi:bvnDellInc.:bvr1.4.1:bd09/08/2021:br1.4:svnDellInc.:pnPrecision5760:pvr:sku0A5E:rvnDellInc.:rn0FW9DW:rvrA00:cvnDellInc.:ct10:cvr:

It doesn't really matter what part of it you pick, but I chose svnDellInc.:pnPrecision5760: since it includes the manufacturer and model of my computer.

As root, create a file /etc/libinput/local-overrides.quirks

[QUIRKS DESCRIPTION]
MatchName=*DEVICE NAME*
MatchDMIModalias=dmi:*PART OF MODALIAS*
ModelTabletModeSwitchUnreliable=1

For my Dell Precision 5760 it looks like this:

[Precision 5760 Disable Tablet Mode]
MatchName=*Intel HID switches*
MatchDMIModalias=dmi:*svnDellInc.:pnPrecision5760:*
ModelTabletModeSwitchUnreliable=1

Save the file. To verify the quirk matches the device, try:

$ libinput quirks list /dev/input/event27

It should output the ModelTabletModeSwitchUnreliable quirk.

Reboot your computer, and the SW_TABLET_MODE events should be ignored.

2
  • 1
    that worked for me even without being able to install libinput from recovery mode as networking was not available. I found the representative string from $ cat /sys/class/dmi/id/modalias and created the file /etc/libinput/local-overrides.quirks. Couldn't check anything with libinput as i couldn't install it but after rebooting from normal mode all works!
    – curious
    Feb 7, 2022 at 14:01
  • 1
    I do have the same difficulty with a Laptop and 22.04 Ubuntu Jammy Jellyfish (development branch): blacklisting intel_vbtn most times works (YEAH!!) as long as I use the gdm3 diaplay manager. Using sddm leads to a completely disabled keyboard including on/off power switch (brand new Fujitsu E5511) but touchpad works. The challenge will be to resolve this (Kernel is 5.15.0-22-generic). Mar 10, 2022 at 20:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.