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.
Note, this change does not require the kernel running on the host is
equal or newer than 6.17. But systemd-udevd needs to be built with the
kernel headers with KEY_PERFORMANCE, and the relevant kernel header is
already updated by the previous commit.
By default, pressing Fn+F8 maps the scancode to KEY_BLUETOOTH (in evtest,
MSC_SCAN 7e -> KEY_BLUETOOTH). Windows/the manufacturer may intercept the
same scancode to execute "Launch Emoji keyboard."
On Linux, we get the "raw" KEY_BLUETOOTH code, which is unacceptable.
prog1 is already reserved by default for launching MyAsus (a Windows
application) with the Fn+F12 combination, so we will use prog2.
Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
This reverts commit 6428c0f480.
The rule seems to match not only keyboard itself but other devices.
Let's revert the change, and consider better way later.
Fixes#38502.
Asus ROG keyboards seems to send power off key code when keyboard wake
up. Reserve the key codes could suppress this problem.
Devices added: ROG Falchion & ROG Scope
Based on the work by Jon Nettleton:
https://gist.github.com/jnettlet/afb20a048b8720f3b4eb8506d8b05643
This fixes Acer Nitro ANV15-51 Nitro sense toggle
Event: time 1753852156.475850, -------------- SYN_REPORT ------------
Event: time 1753852156.565054, type 4 (EV_MSC), code 4 (MSC_SCAN), value f5
Event: time 1753852156.565054, type 1 (EV_KEY), code 148 (KEY_PROG1), value 0
Map the FN key of TUXEDO InfinityFlex 14 Gen1 that wrongly produces the F23
scancode by default.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Map the FN key of TUXEDO NB02 devices that produces a scancode unrecognized by
the Linux kernel.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
PR #34685 moved the handling of keys 66/65 from specific models to
generic HP laptops.
Key 66 has been linked to the `pickup_phone` function; however, this
action key is not available on all HP laptop models, particularly older
versions. On my HP Pavilion laptop, key 66 is mapped to the `backspace`
function, which caused the backspace key to stop working after the
change.
The following PR fixes the issue on my **HP Pavilion Laptop 15-eg0xxx**.
I have placed the modifications under the Pavilion section, but I cannot
guarantee that this solution will apply to all Pavilion models.
Additionally, I have included a line that checks for "HP" instead of
solely searching for "Hewlett-Packard," as my model is simply labeled as
HP.
HP Elitebook 2170p's keyboard scancodes under coreboot is different
with those under oem firmware. The scan code of backspace key of HP
Elitebook 2170p under coreboot is 0x66, but 93b078c has
KEYBOARD_KEY_66=pickup_phone for general HP laptops, making the
backspace key of the HP Elitebook 2170p running coreboot unusable.
The committed scancodes map KEYBOARD_KEY_66 back to backspace, and
provide all Fn-keys of HP Elitebook 2170p under coreboot.
Their evdev string matches the default SMBIOS tables of coreboot
for Elitebook 2170p, to avoid conflict with HP Elitebook 2170p running
oem firmware.
Fixes#35469 and https://ticket.coreboot.org/issues/571
adding `KEYBOARD_KEY_76` in generic section is causing a regression
in MSI GF63. Moving this down fixes.
This commit also adds a probable KEY Code for MSI GF63 touchpad toggling
This takes the idea from #18595 and implements it based on our current
hwdb: the original PR suggested the keys 66/65 are a generic HP thing,
and not limited to specific laptops. The current specific laptop entries
do not contradict that claim.
Hence, let's move them from the specific sections matching some HP
laptops to the generic section matching all.
This uses the correct key names, which have long been fixed (which used
to be a problem our CI was tripped off by).
This is not tested, but I think fairly risk-less, and should allow us to
get rid of a really old PR.
Replaces: #18595