On the ThinkBook 14 G7 ARP (21MV), ideapad-laptop is bound to both the ACPI
device (VPC2004:00) and the WMI device
(8FC0DE0C-B4E4-43FD-B0F3-8871711C1294) at the same time, and both report the
mic mute key into the same input device ("Ideapad extra buttons") a few
milliseconds apart, with different scan codes: 0x8 from the ACPI path and
0x13e from the WMI path.
Userspace applies the toggle twice, so the microphone returns to its previous
state and the key appears not to work at all. Unmapping the WMI scan code
leaves a single event per keypress, and the key then toggles the microphone
reliably, mic mute LED included.
Note this differs from the ThinkBook 16p G5 IRX entry above, where the
duplicate comes from the AT keyboard; here both events originate from
"Ideapad extra buttons" itself.
This was discussed on platform-driver-x86, where the hwdb approach was
suggested in preference to unbinding the WMI driver.
The calculator key (Fn + numpad =) emits a press event but never a
release, leaving KEY_CALC permanently held down. Desktop environments
then repeatedly spawn the calculator.
Before:
MSC_SCAN a1 / KEY_CALC value 1
(no release for the remaining 24s of the capture)
After:
MSC_SCAN a1 / KEY_CALC value 1
MSC_SCAN a1 / KEY_CALC value 0 (14us later)
Scancode 0xd7 (Fn+F4) is an atkbd echo of the mic mute key that
ideapad-laptop already reports as KEY_MICMUTE with a proper
press/release pair. Mapping it to unknown silences the repeated
"Unknown key pressed" kernel messages without affecting the working
key.
Tested on Fedora 44, kernel 7.1.10, BIOS P5CN31WW.
The NitroSense button on the Acer Nitro V 15 (ANV15-52) emits atkbd
scancode 0xf5, the same as its sibling ANV15-51 (#38415). Map it to
prog1 so it is usable out of the box.
Verified on hardware:
dmi:bvnINSYDECorp.:bvrV1.31:bd06/27/2025:br1.31:efr1.7:svnAcer:pnNitroANV15-52:pvrV1.31:rvnRPL:rnSportage_RTH
evdev capture on "AT Translated Set 2 keyboard":
EV_MSC MSC_SCAN f5
EV_KEY KEY_PRESENTATION 425 (via the generic Acer f5 rule)
The embedded controller on the HP ENVY x360 Convertible 13 emits atkbd
scancode e057 on every lid open. The generic HP block maps e057 to
KEY_WLAN, which desktop environments bind to the airplane-mode action, so
opening the lid switches off every radio. There is no physical key on this
machine that emits e057, it only ever arrives from the lid.
This is the same firmware behavior already quirked for the HP Spectre
x360 Convertible ("Prevents random airplane mode activation") and the HP
Pavilion Gaming 15-dk1 ("lid keys").
Add the property to the existing ENVY x360 13 record rather than to the
Spectre d7 block. The match line for this model already appears further
down the file, so duplicating it there is rejected by parse-hwdb.
e058 is emitted on lid close but carries no keycode in the generic HP
block, so it is already inert and is left alone here.
Replaces #43495.
Closes#43494.
Co-authored-by: Robin Richard Rajan <robinrichardrajan@gmail.com>
I'm not sure if these leading zeros matter or not, but the description
at the top of the file clearly says that the numbers are 4-digit. The
author of this entry also mentions evdev:input:b0003v1020p0501* in the
PR that added it.
Follow-up-for: 4ae4470ad9
Add a hwdb entry for the HP EliteBook 845 G7 laptop.
The Fn+F11 airplane mode key is reported as KEY_F8 by the atkbd
driver. Map it to !wlan to expose the correct wireless radio switch
event to userspace.
The physical key between right Shift and right Ctrl (Brazilian ABNT2 ["/
? deg"]) emits scancode 0x4e (KEY_KPPLUS) at boot.
Remap the observed 0x4e keycode to KEY_RO so it produces the expected
characters with the Brazilian ABNT2 XKB layout.
The mic-mute key on the Logitech K950 keyboard (046D:B388, Bluetooth)
emits BTN_0 (scancode 0x100e1) instead of a usable key, so it does
nothing under GNOME/KDE. Map it to KEY_MICMUTE, its intended function.
Scancode determined with evtest on the device.
Previously the key was unknown so add the correct mapping as it does not follow the general
case for MSI Laptops.
[ 192.562000] atkbd serio0: Unknown key released (translated set 2, code 0xd7 on isa0060/serio0).
[ 192.562011] atkbd serio0: Use 'setkeycodes e057 <keycode>' to make it known.
Add it currently as a definition specific for this model but can be generalized to other MSI
Laptops if this issue is present also elsewhere.
On Lenovo ThinkPad T14 Gen 1 AMD model 20UES5TQ00 with the Brazilian
keyboard, the physical slash/question key reports as KEY_RIGHTCTRL.
This keyboard layout has no physical Right Ctrl key in that position. The
key after Space is AltGr, then PrtSc, then the slash/question key. Map the
AT keyboard scancode 0x9d to KEY_RO, matching the ABNT slash/question key
used by Brazilian keyboard layouts.
Verified with evtest:
Event: type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 1
After applying the hwdb mapping, the key reports as KEY_RO.
DMI: svnLENOVO:pn20UES5TQ00:pvrThinkPadT14Gen1
AT keyboard scancode: 0x9d
The Acer Nitro AN515-58 has a dedicated NitroSense button (scan code
0xf5) with no entry in its device-specific block. It currently falls
through to the generic Acer rule:
KEYBOARD_KEY_f5=presentation
This is semantically wrong — the button has no relation to
presentation mode. Other Nitro models (AN515-47, AN517-54, ANV15-51)
already map it to prog1 (XF86Launch1), making it a user-programmable
button that desktop environments (KDE, GNOME, etc.) can bind to any
action.
Add the same mapping for AN515-58 for consistency:
KEYBOARD_KEY_f5=prog1 # NitroSense button
Tested on Acer Nitro AN515-58 with Linux 7.0.12 and KDE Plasma 6.7
This no longer matched with any MSI Claw device after c65efd4145
("(hwdb) Update MSI Claw Entries") because of the modalias structure:
dmi:bvnAmericanMegatrendsInternational,LLC.:bvrE1T52IMS.112:bd12/04/2025:br1.18:svnMicro-StarInternationalCo.,Ltd.:pnClaw8AI+A2VM:pvrREV1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMS-1T52:rvrREV1.0:cvnMicro-StarInternationalCo.,Ltd.:ct30:cvrN/A:sku1T52.1:
Fix this by matching against board vendor field rather than system
vendor.
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
- Add support for MSI Claw A8 BZ2EM.
- Switch to using rn vice pn as MSI uses a unique pn for variants of the
same model. This prevents needing to update this file when a low volume
variant is released (I.E. Polar White AI 8+).
Map the Power Boost key (top-right corner, scancode 0x64) to KEY_PROG1.
Map the Touchpad Toggle key (Fn+F8, scancode 0x76) to KEY_F21.
Verified working via evtest:
Event: type 4 (EV_MSC), code 4 (MSC_SCAN), value 64
Event: type 1 (EV_KEY), code 148 (KEY_PROG1), value 1
Event: type 4 (EV_MSC), code 4 (MSC_SCAN), value 76
Event: type 1 (EV_KEY), code 206 (KEY_F21), value 1
DMI: svnInfinix:*pnY3Max:*
AT keyboard scancodes: 0x64, 0x76 (set 2)
I got infos from product_name:
$ cat /sys/class/dmi/id/product_name
X+ Piccolo
Turns out the modalias has a little difference:
$ cat /sys/class/dmi/id/modalias
dmi:bvnAmericanMegatrendsInternational,LLC.:bvr5.27:bd09/10/2025:br5.27:svnX-Plus.tech:pnX+Piccolo:pvrDefaultstring:rvnX-Plus:rnXPLUS-SERIES81x-DEV:rvrDefaultstring:cvnDefaultstring:ct10:cvrDefaultstring:skuSeries81x:pfaPiccoloSeries:
So let's remove the extra space. Crossing fingers... 🤞
Fixes: 033be1a41b
Addition to PR https://github.com/systemd/systemd/pull/41181
Plasma-workspace OSD notifications about turning the touchpad on
and off are guided by f21. When this match is specified,
KDE notifies on this laptop that the on/off switch of the atchpad
state is pressed.
Fix dmesg:
atkbd serio0: Unknown key pressed (translated set 2, code 0xc1 on isa0060/serio0).
The ITE keyboard controller firmware (version 0xAB83) is shared
between the Clevo PA70ES and the X+ piccolo series.
The piccolo's hwdb rule matches by input device ID
(evdev:input:b0011v0001p0001eAB83*) and remaps scan code 0x9c
(KP_Enter) to Enter, since the piccolo has no numpad and its
main Enter key sends the wrong scan code.
The Clevo PA70ES has a real numpad. The piccolo rule matches it
because both laptops use the same ITE controller firmware, which
breaks KP_Enter on the PA70ES.
Add a DMI-specific override that restores KEY_KPENTER for 0x9c
on the PA70ES.
The piccolo rule should ideally be narrowed to use DMI matching
instead of input device ID to avoid catching other laptops with
the same ITE controller firmware.
This fixes an incomplete mapping introduced in PR #39769 for the Acer
Nitro 5 AN515-58.
The previous PR mapped the physical keyboard backlight keys (scancodes
`0xef` and `0xf0`) to `kbdillumup` and `kbdillumdown` to prevent them
from dropping screen brightness.
However, the embedded controller on this Acer model only emits "make"
(press) scancodes and fails to emit "break" (release) scancodes for
these specific keys. Without a release event, the input subsystem
registers the keys as continously held down (auto-repeat). In desktop
environments like KDE Plasma, pressing the key once causes the
brightness UI slider to get stuck in an infinite adjustment loop.
This issue is previously unnoticed as this model did not expose any
keyboard backlight control.
The fix is done by prepending the `!` (force-release) flag to the
keycodes. This instructs `evdev` to synthesize a key
release event.
The fix is verified locally on an Acer Nitro AN515-58. `evtest` now
correctly reports `value 1` immediately followed by `value` 0, and KDE
Plasma brightness OSD no longer gets stuck.
Signed-off-by: Dirga Yuza <dirgayuza123@gmail.com>
The match in "AYA NEO" will never happen as dmi modalias will wipe blank
spaces. Even more the intended match was covered before by "AYANEO".
Actually there are contributions that rely on someone giving some data
to other someone with no test at all.
Should be consider to enforce the full udevadm info --export-db as
mandatory requirement fot this kind of contributions.
After kernel commit 907bc9268a ("Input: atkbd - map F23 key to support default copilot shortcut")
Fn+F5 combination (switch touchpad on/off) stopped working correctly.
Fn produces F23, it is probably a bug in BIOS, ther eis no "Copilot" key.
It was ignored before that commit, but now we have to remap it here in hwdb.
This workaround is similar to systemd commit d2502f5
("hwdb/keyboard: Map FN key on TUXEDO InfinityFlex 14 Gen1")
Hardware probe of this notebook: https://linux-hardware.org/?probe=2d5266f5c6
The Xiaomi Mi Notebook Pro keyboard has a "star" key that
generates AT keyboard scancode 0x72 but is not mapped in
the default hwdb.
Map it to KEY_MACRO so it appears as a usable input key.
Verified using evtest.
Signed-off-by: Arjun <arjunchoozhi1234@gmail.com>
After kernel commit 907bc9268a ("Input: atkbd - map F23 key to support default copilot shortcut")
Fn+F5 combination (switch touchpad on/off) stopped working correctly.
Fn produces F23, it is probably a bug in BIOS, ther eis no "Copilot" key.
It was ignored before that commit, but now we have to remap it here in hwdb.
This workaround is similar to systemd commit d2502f55a2
("hwdb/keyboard: Map FN key on TUXEDO InfinityFlex 14 Gen1")
Hardware probe of this notebook: https://linux-hardware.org/?probe=7aca7ed668
See also: https://bugzilla.rosa.ru/show_bug.cgi?id=19950
Prior to this commit, the behaviour looked like this:
| Keypress | Result |
| -------- | ------------ |
| Up | KEY_PAGEUP |
| Down | KEY_PAGEDOWN |
| Left | KEY_LEFT |
| Right | KEY_RIGHT |
| Fn+Up | KEY_UP |
| Fn+Down | KEY_DOWN |
| Fn+Left | KEY_HOME |
| Fn+Right | KEY_END |
This commit would fix it so that PGUP/PGDN would also require the Fn
key so that the arrow keys behave identically depending on whether Fn
was pressed.
Presumably after a BIOS update, HP seems to have fixed the order. This
now means this commit is now behaving exactly as the table above.
Revert the commit to restore the intended behaviour:
| Keypress | Result |
| -------- | ------------ |
| Up | KEY_UP |
| Down | KEY_DOWN |
| Left | KEY_LEFT |
| Right | KEY_RIGHT |
| Fn+Up | KEY_PAGEUP |
| Fn+Down | KEY_PAGEDOWN |
| Fn+Left | KEY_HOME |
| Fn+Right | KEY_END |
This reverts commit 4fd7c712dc.
Signed-off-by: Han Sol Jin <hansol@hansol.ca>
change matches to generic input devices one as name can't be used
because these keyboards have multiple names and also they are used in
multiple devices. This way will be possible to define more detachable
keyboards in an easy way for multiple devices.
Known USB ids for D330 series are: 17EF:60C3, 17EF:60C6 and 17EF:60C8.
Also mark that the tablet part keys and the keyboard doesn't have any
LED to let interfaces decide to expose on-screen indicators.
- Different BIOS versions of the Legion Go 2 can init the keyboard
device as set 1 (appears as raw set 2) or as set 2 (appears as
translated set 2). Add the Legion Go 2 to the Translated list.
- While at it, specify the models in a more verbose manner for
posterity.
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Adds missing scancodes for Lenovo Legion Go, Go S, and Go 2. When long
pressing the power button the device should issue a LEFTMETA + F16
combo. The LEFTMETA code fires properly, but the F16 is not mapped.
Go and Go S devices detect as AT Translated Set 2 Keyboard, while Go 2
detects as AT Raw Set 2 Keyboard, hence the multiple entries.
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Change unknown key mappings to reserved.
A KEY_RESERVED button is marked as reserved and passed to the kernel. This will stop the kernel from passing this keystroke event to user space.
If unknown, the key is set to KEY_UNKNOWN and the event is passed to user space, which we want to avoid.
Pressing Fn+F10 on Acer Nitro 5 AN515-58 incorrectly triggers display
brightness down (scancode 0xef) instead of keyboard backlight control,
causing the screen to go completely dark. Similarly, Fn+F9 (scancode
0xf0) has no function explictily stated in hwdb causing unknown keycode
debug messages.
Both keys should control the keyboard backlight as labeled on the
keyboard. Map scancodes 0xef and 0xf0 to kbdillumup and kbdillumdown
respectively to enable proper keyboard backlight control.
On the Dell Inspiron 3505 both the atkbd and acpi-video input devices report
an event for pressing the brightness up / down keys, resulting in user
space seeing double events and increasing / decreasing the brightness 2 steps
for each keypress.
Fix this by adding the device to the already existing list of Dell
devices that suffer from the same problem.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Fn + F1 which is the shortcut for toggling the touchpad on/off sends
atkbd scancodes f7 (first press) + f8 (second press) just like on various
other Clevo models. Add the V64x_V65xAU model to the list of models where
these scancodes are mapped to touchpad-toggle.
Kevin Charpentier
Lucas Adriano Salles
Alperen Kılıç
Renan Pagani
Srijan KeshriandRobin Richard Rajan
David Tardon
rodin-ia
Rafael Passos
Alexandre Saou
Matthew Schwartz
Matthias P. Walther
dirhamtriyadi
Fede2782
LucasTavaresA
Pranay Pawar
Derek J. Clark
sykikxo
Christian Hesse
RiskoZS
Artem Proskurnev
Matheus Afonso Martins Moreira
Dirga Yuza
Nita Vesa
kakolla
Tobias Heider
David Santamaría Rogado
Mikhail Novosyolov
Andrii Zora
The-An0nym
Arjun-C-S
Han Sol Jin
Dirk Su
QuickSwift315490
Armin Wolf
Hans de Goede