Keyboard not working

Bug #1894017 reported by Nicholas Demosthenous
84
This bug affects 16 people
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-5.4.0-45-lowlatency 5.4.0-45.49
ProcVersionSignature: Ubuntu 5.4.0-45.49-lowlatency 5.4.55
Uname: Linux 5.4.0-45-lowlatency x86_64
ApportVersion: 2.20.11-0ubuntu27.8
Architecture: amd64
CasperMD5CheckResult: skip
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=/boot/vmlinuz-5.4.0-45-lowlatency root=UUID=6035c42c-766d-44fd-b45c-6cdf9c74e0b5 ro quiet splash vt.handoff=1
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-45-lowlatency N/A
 linux-backports-modules-5.4.0-45-lowlatency N/A
 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.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 2209
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 57.57
dmi.chassis.asset.tag: Chassis Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnInsyde:bvrF.30:bd03/13/2018:svnHewlett-Packard:pnHPPavilion11x360PC:pvr0977100000405F00010420180:rvnHewlett-Packard:rn2209:rvr57.57:cvnHewlett-Packard:ct10:cvrChassisVersion:
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.version: 0977100000405F00010420180
dmi.sys.vendor: Hewlett-Packard

Revision history for this message
Nicholas Demosthenous (demosnk) wrote :
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Robert Lambourne (robertlambourne) wrote :

Having the same problem Bug #1894125

Revision history for this message
g.maverick (giannamelo) wrote :

+1

Revision history for this message
Sam N (colorful-shirts8573) wrote :

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.

Revision history for this message
Sam N (colorful-shirts8573) wrote :

After testing out various kernels, I've found that the keyboard and trackpad gain functionality in kernel 5.4.18-050418-generic.

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.

Revision history for this message
Carlos (fridugiso) wrote :

I can confirm both the bug and it being fixed in 5.4.18. Thanks!

Revision history for this message
Carlos (fridugiso) wrote :

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://bugzilla.kernel.org/show_bug.cgi?id=208525#c9
[2]: https://bugzilla.kernel.org/show_bug.cgi?id=208945
[3]: https://bugzilla.kernel.org/show_bug.cgi?id=208853
[4]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894012
[5]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894125

Revision history for this message
Igor (prigoryan) wrote :

I have exactly same bug on Acer Aspire E5-511G

Revision history for this message
Hans de Goede (j-w-r-degoede) wrote :

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

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:

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=fixes&id=1797d588af15174d4a4e7159dac8c800538e4f8c

This one will hopefully be merged by Linus real soon (I have send out a pull-req for it to Linus).

Revision history for this message
Hans de Goede (j-w-r-degoede) wrote :

For everyone who is seeing this issue with the intel-vbtn driver,
if you do:

cat /sys/class/dmi/id/chassis_type

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.

Revision history for this message
Igor (prigoryan) wrote :

Confirmed:
cat /sys/class/dmi/id/chassis_type returns 10 on Acer Aspire E5-511G (Intel Celeron N2940)

Revision history for this message
Peter Horn (handyboy) wrote :

I can confirm that cat /sys/class/dmi/id/chassis_type returns 10 on Hewlett-Packard HP Pavilion 11 x360 PC.
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://askubuntu.com/questions/1272818/built-in-laptop-keyboard-not-working-today-on-hp-convertible-x360-with-ubuntu-18.

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 ?

Revision history for this message
Hans de Goede (j-w-r-degoede) wrote :

@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.

Revision history for this message
Hans de Goede (j-w-r-degoede) wrote :

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.

Revision history for this message
Peter Horn (handyboy) wrote :

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 ! ).

Revision history for this message
Peter Horn (handyboy) wrote :

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 ?

Revision history for this message
piotrek (piotrek359) wrote :

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?

Revision history for this message
Hans de Goede (j-w-r-degoede) wrote :

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.

Revision history for this message
Peter Horn (handyboy) wrote :

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!).

Revision history for this message
piotrek (piotrek359) wrote :

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.

Revision history for this message
Carlos (fridugiso) wrote :

Have you tried blacklisting the kernel module "intel_vbtn" as a workaround?

By the way, on Chuwi Minibook m3-8100Y, "cat /sys/class/dmi/id/chassis_type" returns "3", so all good in that regard.

Thanks, Hans!

Revision history for this message
John Pitt (burritojohn) wrote :

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/dmi/id/chassis_type" returns 10.

Thanks for reading me !

Revision history for this message
Hans de Goede (j-w-r-degoede) wrote :

@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:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1797d588af15174d4a4e7159dac8c800538e4f8c

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.

Revision history for this message
Kevin Tang (dacto) wrote :

System: HP Convertible x360 11-ab0XX
$ cat /sys/class/dmi/id/chassis_type
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?

Revision history for this message
Hans de Goede (j-w-r-degoede) wrote :

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:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d823346876a970522ff9e4d2b323c9b734dcc4de

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.

Revision history for this message
piotrek (piotrek359) wrote :

System: HP Convertible x360 11-ab0XX
$ cat /sys/class/dmi/id/chassis_type 10
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?

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

The fix pointed by Hans is included in Ubuntu kernel 5.4.0-55.61 and onward.

Revision history for this message
Hans de Goede (j-w-r-degoede) wrote :

@kaihengfeng, can you perhaps build a 5.9.xx kernel with:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d823346876a970522ff9e4d2b323c9b734dcc4de added for @dacto from comment 25 to test ?

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.HP-Convertible-x360-11-ab0XX

And then attach the generated acpidump.HP-Convertible-x360-11-ab0XX file here, or send it directly to me: <email address hidden> .

###

So looking closer at the difference between 5.4.75 and 5.9.10, 5.9.10 has:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=21d64817c72470ed69483f59279ce557c0658826

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

5.9.12 + commit d823346876a970522ff9e4d2b323c9b734dcc4de:
https://people.canonical.com/~khfeng/lp1894017/

Revision history for this message
mark (pleasework12345) wrote :

I am seeing a similar reproduction, but earlier at the FDE passphrase screen. My system apparently (at least under liveusb) reports /sys/class/dmi/id/chassis_type==31

Seems related, but i've posted a new bug due to the chassis type being "correct" (?) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1909056

Revision history for this message
Carlos (fridugiso) wrote :

This bug is fixed for me in kernel 5.4.0-58-lowlatency, Chuwi Minibook m3-8100Y. (The new bugs referred to above don't affect me, so far.)

Revision history for this message
Ashwin Ram kumar (ashrk) wrote :

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.d/blacklist-intel_vbtn.conf" but the bug continues on my Dell Inspiron 15 5558.

This "cat /sys/class/dmi/id/chassis_type" give me a number: 9.

Is there anyother fix? and any potential dates the patch for the same is released

Revision history for this message
Ashwin Ram kumar (ashrk) wrote :

And somehow my windows is behaving in the same way as well. Oh, and another thing, there is stream of b's (bbbbbbbbbbbbbbbbbbb) being generated on both OS on my Latop. Any help, would be great

Revision history for this message
Sasa J. (sipankh) wrote :

I have the exact same problem; the keyboard type 10 and blacklistng intel_vbtn kernel module in /etc/modprobe.d/blacklist.conf and reboot didn't fix it. Tech info re hardware and OS: Distributor ID: Ubuntu Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 (had the same issue with 20.10 version and few other kernel versions)) Codename: hirsute Kernel running is 5.11.0-051100-generic Laptop is Lenovo W550s.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (20.7 KiB)

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_oss_synth_make_info()
    - 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_req_aead
    - ACPI: scan: Make acpi_bus_get_device() clear return pointer on error
    - 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_relocation
    - btrfs: don't clear ret in btrfs_start_dirty_block_groups
    - btrfs: send: fix invalid clone operations when cloning from the same file
      and root
    - fs: fix lazytime expiration handling in __writeback_single_inode()
    - 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_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
    - scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback
    - 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
Revision history for this message
Nemo Fang (fyj123121) wrote :

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/dmi/id/chassis_type" give me a number: 10. blacklisting intel_vbtn doesn't fix the problem for me.

Revision history for this message
Hans de Goede (j-w-r-degoede) wrote :
Download full text (3.3 KiB)

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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=addab6febc42ed94e4eee1abbe486150e4f8b9e9
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5b1032a656e9aa4c7a4df77cb9156a2a651a5f9

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 ...

Read more...

Revision history for this message
cipibad (cipibad) wrote :

In my case it was the same behavior, but the cause was a kernel boot parameter(acpi=noirq).

Added details on how I found it here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894012/comments/9

Revision history for this message
Enrico Lumetti (doppioandante) wrote (last edit ):

Hello, this also happens on my laptop, Lenovo l390 Yoga. My "cat /sys/class/dmi/id/chassis_type" is 31, my laptop is indeed convertible.
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?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.