Keyboard not working
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
The laptop keyboard doesn't work at login or in the de. If I ctrl+alt+F3 from an external usb keyboard to a terminal the laptop keyboard works. An external usb keyboard works everywhere. The laptop's keyboard does work everywhere with the previous kernel 5.4.0.42.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-
ProcVersionSign
Uname: Linux 5.4.0-45-lowlatency x86_64
ApportVersion: 2.20.11-0ubuntu27.8
Architecture: amd64
CasperMD5CheckR
CurrentDesktop: KDE
Date: Thu Sep 3 03:09:49 2020
InstallationDate: Installed on 2019-08-07 (392 days ago)
InstallationMedia: Kubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
MachineType: Hewlett-Packard HP Pavilion 11 x360 PC
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=
RelatedPackageV
linux-
linux-
linux-firmware 1.187.3
SourcePackage: linux
UpgradeStatus: Upgraded to focal on 2020-04-06 (149 days ago)
dmi.bios.date: 03/13/2018
dmi.bios.vendor: Insyde
dmi.bios.version: F.30
dmi.board.
dmi.board.name: 2209
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 57.57
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.
dmi.modalias: dmi:bvnInsyde:
dmi.product.family: 103C_5335KV G=N L=CON B=HP S=PAV X=MIN
dmi.product.name: HP Pavilion 11 x360 PC
dmi.product.sku: M0B61EA#ACQ
dmi.product.
dmi.sys.vendor: Hewlett-Packard
Nicholas Demosthenous (demosnk) wrote : | #1 |
- AlsaInfo.txt Edit (30.8 KiB, text/plain; charset="utf-8")
- AudioDevicesInUse.txt Edit (290 bytes, text/plain; charset="utf-8")
- CRDA.txt Edit (252 bytes, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (67.4 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (2.5 KiB, text/plain; charset="utf-8")
- IwConfig.txt Edit (579 bytes, text/plain; charset="utf-8")
- Lspci.txt Edit (10.9 KiB, text/plain; charset="utf-8")
- Lspci-vt.txt Edit (1.0 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (495 bytes, text/plain; charset="utf-8")
- Lsusb-t.txt Edit (687 bytes, text/plain; charset="utf-8")
- Lsusb-v.txt Edit (44.5 KiB, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (4.1 KiB, text/plain; charset="utf-8")
- ProcCpuinfoMinimal.txt Edit (1.0 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (331 bytes, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (3.1 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (9.3 KiB, text/plain; charset="utf-8")
- PulseList.txt Edit (11.2 KiB, text/plain; charset="utf-8")
- RfKill.txt Edit (112 bytes, text/plain; charset="utf-8")
- UdevDb.txt Edit (203.9 KiB, text/plain; charset="utf-8")
- WifiSyslog.txt Edit (98.2 KiB, text/plain; charset="utf-8")
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed | #2 |
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
Robert Lambourne (robertlambourne) wrote : | #3 |
Having the same problem Bug #1894125
g.maverick (giannamelo) wrote : | #4 |
+1
Sam N (colorful-shirts8573) wrote : | #5 |
Same here.
Same computer as original bug report (Hewlett-Packard HP Pavilion 11 x360 PC)
But different distro release (Xubuntu 20.04)
Laptop keyboard and trackpad totally nonfunctional on any kernel higher than 5.4.0.42. Starting with 5.4.0-45 and all further kernels to today (2020-09-22) the problem persists. External (USB) mice and keyboards work fine.
Sam N (colorful-shirts8573) wrote : | #6 |
After testing out various kernels, I've found that the keyboard and trackpad gain functionality in kernel 5.4.18-
No luck in the latest (5.8~) yet, but as 5.4 is a LTS kernel for now I'll just stick with booting to 5.4.18 as that's only a few point releases behind current stable anyway. Hope this info helps others.
Carlos (fridugiso) wrote : | #7 |
I can confirm both the bug and it being fixed in 5.4.18. Thanks!
Carlos (fridugiso) wrote : | #8 |
Following a tip from [1] (the user there suspects their laptop is erroneously entering tablet mode) I blacklisted the kernel module intel_vbtn and it seems to do the trick, my laptop keyboard works again on kernel 5.4.0-48.
I found a few other bug reports which may be related or duplicates. One ([2]) suggests some kernel parameters as a partial fix, the others ([3], [4], [5]) have no solution
[1]: https:/
[2]: https:/
[3]: https:/
[4]: https:/
[5]: https:/
Igor (prigoryan) wrote : | #9 |
I have exactly same bug on Acer Aspire E5-511G
Hans de Goede (j-w-r-degoede) wrote : | #10 |
This should be fixed by this upstream commit, which landed in Linus' tree a couple of hours ago:
Note for the Ubuntu kernel devs: a similar bug was introduced in 5.8 in the asus-nb-wmi code, so when fixing this you really should also pick-up this fix:
This one will hopefully be merged by Linus real soon (I have send out a pull-req for it to Linus).
Hans de Goede (j-w-r-degoede) wrote : | #11 |
For everyone who is seeing this issue with the intel-vbtn driver,
if you do:
cat /sys/class/
On your laptop, and the output is NOT "31" or "32" then the
fix, which I linked above, 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.
Igor (prigoryan) wrote : | #12 |
Confirmed:
cat /sys/class/
Peter Horn (handyboy) wrote : | #13 |
I can confirm that cat /sys/class/
I had the same issue using Ubuntu 18.04 and got around it by using kernel 5.4.0-42. When I upgraded to Ubuntu 20.04 I found the same issue and get around it using kernel 5.4.0-42 again.
see my original Question on AskUbuntu here: https:/
Does anyone know if the fixes described by Hans De Goede above have resolved this issue or should I wait to see what Linus comes up with ?
Hans de Goede (j-w-r-degoede) wrote : | #14 |
@handyboy, my fix for this has been merged by Linus for inclusion into 5.9. If one of the Ubuntu devs can add the 2 mentioned fixes to the next 20.04 kernel build then this issue should be resolved/fixed.
Hans de Goede (j-w-r-degoede) wrote : | #15 |
I just got an email from gkh that both patches have also been added to the various stable kernel series, including 5.4.x and 5.8.y, so they should show up in the next stable series release for those kernels.
Thus if the Ubuntu kernel follows the stable series then this will get fixed through that.
Peter Horn (handyboy) wrote : | #16 |
Thank you for this Hans - it is really appreciated by me.
I will wait and see if the stable series release fixes this (hopefully soon ! ).
Peter Horn (handyboy) wrote : | #17 |
I received kernel 5.4.0-51 yesterday (2020.10.15) but it still hass the same issue. I have reverted to using 5.4.0-42 to get my Ubuntu 20.4 going. Does any one know when the next stable series release will happen ?
piotrek (piotrek359) wrote : | #18 |
I'm experiencing identical problem with HP Pavilion 11 x360. For me, still only solution is to use kernel version -42. Installing 5.4.0-51 didn't solve the issue. Anyone know is solution is planed by Ubuntu team?
Hans de Goede (j-w-r-degoede) wrote : | #19 |
This has been fixed in the upstream 5.4.71 stable series release, so as soon as the Ubuntu kernels pick up the fixes from that release then this should be resolved.
Peter Horn (handyboy) wrote : | #20 |
I have since received kernel 5.4.0-52 but this still has the same issue (Keyboard AND Mouse not working).
I will continue to use 5.4.0-42 until this can be fixed - my only other option is to revert to Windows (ugh!).
piotrek (piotrek359) wrote : | #21 |
5.4.71!? Realy? And how long can it take when 5.4.0-55 is available? Years? OMG That's very bad news for me.
Carlos (fridugiso) wrote : | #22 |
Have you tried blacklisting the kernel module "intel_vbtn" as a workaround?
By the way, on Chuwi Minibook m3-8100Y, "cat /sys/class/
Thanks, Hans!
John Pitt (burritojohn) wrote : | #23 |
Affected too, with an asus x751BP laptop on groovy.
Blacklisting intel_vbtn doesn't change anything (not active with lsmod after the blacklist bug the bug's still there). Still there with the latest kernel from the update manager (5.8.0-26-generic) received today. The integrated keyboard/mouse work fine with 5.4.0-52-generic, and "cat /sys/class/
Thanks for reading me !
Hans de Goede (j-w-r-degoede) wrote : | #24 |
@burritojohn, if you are seeing this on an Asus device then you are hit by a different variant of what is in essence the same bug.
The Asus case is fixed by this upstream commit:
Which has also been cherry-picked into the 5.8.y stable series (it is there since the v5.8.15 release).
So to fix this for you (and many many other Asus users!) the Ubuntu kernels should pickup the upstream fix for this.
Kevin Tang (dacto) wrote : | #25 |
System: HP Convertible x360 11-ab0XX
$ cat /sys/class/
31
Keyboard was working in 5.4.0-42.
Broken with update to 5.4.0-54.
Still broken in 5.9.10.
Working in 5.4.75.
Is 5.9.10 missing the fix that was included in 5.4.75 for chassis_type 31?
Hans de Goede (j-w-r-degoede) wrote : | #26 |
chassis_type 31 is "Convertible", so we expect the intel-vbtn SW_TABLET_MODE reporting to work there.
There was one other HP model which had a bit of a weird issue, this was fixed by:
But that workaround got dropped when we switched to ignoring SW_TABLET_MODE on all devices where the chassis_type is not 31 or 32, since the model which needed that fix ("HP Pavilion 11 x360") uses a chassis_type of 10, so that workaround was no longer needed.
So now it seems that we should not have dropped the workaround as possibly more HP models need it. If you can build your own 5.9.10 kernel with the linked workaround applied, and test it that would be great.
There should be docs somewhere on how to build an ubuntu kernel with patches applied yourself. If you do not feel up to doing this yourself, then please say so, then one of the Ubuntu devs should be able to provide a test kernel with the patch added for you.
piotrek (piotrek359) wrote : | #27 |
System: HP Convertible x360 11-ab0XX
$ cat /sys/class/
Ubuntu 20.04 LTS.
Last available for download 5.4.0-54. No new karnel updates are detected. I'm confused because of what "Kevin Tang (dacto) wrote on 2020-11-25: #25" wrote. Not only because of new kernels available (that my computer doesn't see?)but of the fact that something works, stop's working, than is fixed and stops working again...
For me to use keyboard and touch-pad 5.4.0-42. is only solution available. :( I wanted to ask how to get those new kernels mentioned in previous posts, bout now seems no point in doing it?
Kai-Heng Feng (kaihengfeng) wrote : | #28 |
The fix pointed by Hans is included in Ubuntu kernel 5.4.0-55.61 and onward.
Hans de Goede (j-w-r-degoede) wrote : | #29 |
@kaihengfeng, can you perhaps build a 5.9.xx kernel with:
https:/
His device gets intel-vbtn SW_TABLET_MODE support enabled based on the chassis-type, yet it seems to always report SW_TABLET_MODE=1, I want to know if the mentioned commit fixes this. This commit was a workaround introduced before we switched to an allow list (which includes certain chassis-types). This workaround was reverted after switching to the allow list, but since @dacto is still seeing this with 5.9.10 it looks like we may need the workaround even with the new allow-list approach.
@dacto, 2 questions:
1. What happens with 5.9.10 if you fold the 2-in-1 into tablet mode and then back into laptop/clamshell mode again, does that fix the kbd and touchpad not working ?
2. Can you provide an acpidump of your device? Run:
sudo acpidump -o acpidump.
And then attach the generated acpidump.
###
So looking closer at the difference between 5.4.75 and 5.9.10, 5.9.10 has:
https:/
Which 5.4.75 does not have, so this strongly suggests that despite switching to the allow list we still need the workaround for some HP models and it should be re-added (undoing the revert / undoing the dropping of the workaround).
I can take care of getting this re-added but first I would like to see some confirmation that this is indeed the problem.
Ideally you (@dacto) would test a 5.9.10 (or .11 or .12) kernel with the patch added, but I can also confirm that this patch needs to be re-added by looking at an acpidump.
Kai-Heng Feng (kaihengfeng) wrote : | #30 |
5.9.12 + commit d823346876a9705
https:/
mark (pleasework12345) wrote : | #31 |
I am seeing a similar reproduction, but earlier at the FDE passphrase screen. My system apparently (at least under liveusb) reports /sys/class/
Seems related, but i've posted a new bug due to the chassis type being "correct" (?) https:/
Carlos (fridugiso) wrote : | #32 |
This bug is fixed for me in kernel 5.4.0-58-
Ashwin Ram kumar (ashrk) wrote : | #33 |
I just received an patch yesterday on Live patch for Ubuntu 20.04.1, the kernel version in my Laptop is 5.8.0-38-generic, but still I am having this same bug from Ubuntu. Did try blacklisting intel_vbtn "sudoedit /etc/modprobe.
This "cat /sys/class/
Is there anyother fix? and any potential dates the patch for the same is released
Ashwin Ram kumar (ashrk) wrote : | #34 |
And somehow my windows is behaving in the same way as well. Oh, and another thing, there is stream of b's (bbbbbbbbbbbbbb
Sasa J. (sipankh) wrote : | #35 |
I have the exact same problem; the keyboard type 10 and blacklistng intel_vbtn kernel module in /etc/modprobe.
Launchpad Janitor (janitor) wrote : | #36 |
This bug was fixed in the package linux - 5.10.0-14.15
---------------
linux (5.10.0-14.15) hirsute; urgency=medium
* hirsute/linux: 5.10.0-14.15 -proposed tracker (LP: #1913724)
* Restore palm ejection on multi-input devices (LP: #1913520)
- HID: multitouch: Apply MT_QUIRK_CONFIDENCE quirk for multi-input devices
* intel-hid is not loaded on new Intel platform (LP: #1907160)
- platform/x86: intel-hid: add Rocket Lake ACPI device ID
* Hirsute update: v5.10.11 upstream stable release (LP: #1913430)
- scsi: target: tcmu: Fix use-after-free of se_cmd->priv
- mtd: rawnand: gpmi: fix dst bit offset when extracting raw payload
- mtd: rawnand: nandsim: Fix the logic when selecting Hamming soft ECC engine
- i2c: tegra: Wait for config load atomically while in ISR
- i2c: bpmp-tegra: Ignore unknown I2C_M flags
- platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634
- ALSA: seq: oss: Fix missing error check in snd_seq_
- ALSA: hda/realtek - Limit int mic boost on Acer Aspire E5-575T
- ALSA: hda/via: Add minimum mute flag
- crypto: xor - Fix divide error in do_xor_speed()
- dm crypt: fix copy and paste bug in crypt_alloc_
- ACPI: scan: Make acpi_bus_
- btrfs: don't get an EINTR during drop_snapshot for reloc
- btrfs: do not double free backref nodes on error
- btrfs: fix lockdep splat in btrfs_recover_
- btrfs: don't clear ret in btrfs_start_
- btrfs: send: fix invalid clone operations when cloning from the same file
and root
- fs: fix lazytime expiration handling in __writeback_
- pinctrl: ingenic: Fix JZ4760 support
- mmc: core: don't initialize block size from ext_csd if not present
- mmc: sdhci-of-dwcmshc: fix rpmb access
- mmc: sdhci-xenon: fix 1.8v regulator stabilization
- mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend
- dm: avoid filesystem lookup in dm_get_dev_t()
- dm integrity: fix a crash if "recalculate" used without "internal_hash"
- dm integrity: conditionally disable "recalculate" feature
- drm/atomic: put state on error path
- drm/syncobj: Fix use-after-free
- drm/amdgpu: remove gpu info firmware of green sardine
- drm/amd/display: DCN2X Find Secondary Pipe properly in MPO + ODM Case
- drm/i915/gt: Prevent use of engine->wa_ctx after error
- drm/i915: Check for rq->hwsp validity after acquiring RCU lock
- ASoC: Intel: haswell: Add missing pm_ops
- ASoC: rt711: mutex between calibration and power state changes
- SUNRPC: Handle TCP socket sends with kernel_sendpage() again
- HID: sony: select CONFIG_CRC32
- dm integrity: select CRYPTO_SKCIPHER
- x86/hyperv: Fix kexec panic/hang issues
- scsi: ufs: Relax the condition of UFSHCI_
- scsi: ufs: Correct the LUN used in eh_device_
- scsi: qedi: Correct max length of CHAP secret
- scsi: scsi_debug: Fix memleak in scsi_debug_init()
- scsi: sd: Suppress spurious errors when WRITE SAME is being disabled
- riscv: ...
Changed in linux (Ubuntu): | |
status: | Confirmed → Fix Released |
Nemo Fang (fyj123121) wrote : | #37 |
I still experience the problem on ubuntu 20.04 with Lenovo Slim 9 14ITL5. The kennel is: 5.11.0-25-generic, and "cat /sys/class/
Hans de Goede (j-w-r-degoede) wrote : | #38 |
I just typed a long email in reply to someone asking about the keyboard not working by email. The contents of that email are likely useful for other people who are still experiencing the keyboard not working too, so I've copy and pasted my entire reply below.
If you still need help with this please follow the provided debug instructions and provide the requested info.
###
First of all lets see if we can find the root cause. Bug 1894017
is about the keyboard events being discarded in userspace, because
userspace thinks the device is folded in tablet mode with the
keyboard behind the display (and any key-presses are thus done
accidentally).
Please install evemu and then run:
sudo evemu-record
This will give you a list of available input devices. The problems
reported in bug #1894017 are caused by a false-positive
reporting of SW_TABLET_MODE with a value of 1. By one of the
following input-devices:
"Intel HID events"
"Intel HID switches"
"Intel Virtual Buttons"
"Intel Virtual Switches"
Or something like this, you can select a device by typing the
number of its /dev/input/event# node.
After selecting a device evemu-record will print which events the
device can report. If it can report SW_TABLET_MODE then the
output will also contain the current value of SW_TABLET_MODE,
if this is 1 then that is the cause.
(press CTRL+c to exit evemu-record)
But you write "seems to stop responding at random" where as with
the SW_TABLET_MODE problem I would expect it to simply not work
at all (with certain kernel versions).
So you may very well have a different problem then the one described
in launchpad issue 1894017.
What you can also try is running "sudo evemu-record" and then selecting
the "AT Translated Set 2 keyboard" keyboard. After this if you type some
keys on the keyboard they should show up in evemu-record as key-presses.
If this works, then try doing it again (over e.g. ssh, or with an
external usb kbd) when the keyboard has stopped responding. I suspect
that you will find that at this point evemu-record will also no longer
report keys, which means that the problem is happening at a lower
level.
I suspect that you will find that the problem indeed is happening at
a lower-level and that you need something like this:
https:/
https:/
In order to determine what is necessary to fix things I need
a number of things:
1. output of: "grep . /sys/class/dmi/id/* 2> /dev/null" run from a terminal
2. Install acpica-tools and then run: "sudo acpidump -o acpidump.txt" and then
attach the generated acpidump.txt file to your next email
3. It would help a lot if we can go from
"seems to stop responding at random" to "stops responding when I do a,
followed by b..." some ideas here are:
3.1 perhaps it stops responding after folding the display past 180 degrees
(so a little beyond it lyinf fully flat on the table) and then back again?
3.2 perhaps it stops responding after folding the display all the way back
so that the device ...
cipibad (cipibad) wrote : | #39 |
In my case it was the same behavior, but the cause was a kernel boot parameter(
Added details on how I found it here: https:/
Enrico Lumetti (doppioandante) wrote (last edit ): | #40 |
Hello, this also happens on my laptop, Lenovo l390 Yoga. My "cat /sys/class/
I have verified that everything is broken on
1) Xorg, gnome or KDE
2) sddm
but it works on
1) gdm3
2) wayland
What doesn't work: my keyboard doesn't work, the fn lock led is permanently on, my caps lock led doesn't turn on when I press caps lock, the physical touchpad buttons don't work.
My touchpad tap and tracking work, and also my touchscreen.
I can login into wayland by carefully using the on screen Qt keyboard of SDDM. If by chance I press any keyboard key, asin comment #34, I get a stream of characters inside whatever prompt is focused that makes it impossible to login (same thing happens on focused prompts if I log into X11).
I tried using evemu inside wayland as suggested in #38, and I found the switch for tablet mode, which looks correct to me. I wonder what would happen inside X11, but I don't have an external keyboard to test this atm.
I tried the intel_vbtn blacklist thing, but it didn't make a difference.
How is it possible that when logging into Wayland the problem disappears?
This change was made by a bot.