It's hard to say which one of the two mappings should stay. But the later
one would win (when both very present), and nobody complained, so let's
assume that that's the one.
This way it's clear that the property block does not end at the comment.
The python checker will complain if this is not the case.
We had a few bugs before where two match blocks were merged by mistake,
and this change should help avoid that.
Apparently the vendor string for newer models now uses "svnHP" instead of
"svnHewlett-Packard", so add this alternative match to the global HP map.
Generalize matches for micmute key on ProBook 4xx.
Silence two hardwired keys on the ProBook 440 G3 that should not produce evdev
events. Thanks to Hermann Kraus for those! (See PR #2679)
This Lenovo machine use codec Line2 to implement a microphone mute
button, it depends on the unsolicited interrupt to generate key event,
the scan code for this button is assigned to 0x00 in the linux kernel
driver, and the keycode is KEY_MICMUTE(248), we need to remap this
keycode to KEY_F20 to make this hotkey work in X11.
BugLink: https://bugs.launchpad.net/bugs/1531362
Signed-off-by: Hui Wang <hui.wang@canonical.com>
The Yoga's firmware sends key events whenever it's being folded or unfolded.
These are thus *not* a button for requesting a screen orientation change, just
an indication that this already happened. Thus they should not be assigned to
"direction", but be ignored. Assigning them to "reserved" does not silence the
"unknown key pressed" kernel warning, so there's no point in maintaining a
mapping here.
Fixes#1440
This breaks the same vendor/product ID with the German keyboard layout. As this
is a hack around some weird keyboard driver bug, let's revert until this is
understood better.
See https://github.com/systemd/systemd/issues/1243
This reverts commit a2aa71a954.
Unplugging and plugging in the cable will create various scancodes
on the keyboard controller.
Userspace within X should be able to interact with these to show
interesting messages. Assign them to generic prog1/prog2.
(David: add comment to hwdb explaining that these keycodes are reserved)
Parse properties in the form
EVDEV_ABS_00="<min>:<max>:<res>:<fuzz>:<flat>"
and apply them to the kernel device. Future processes that open that device
will see the updated EV_ABS range.
This is particularly useful for touchpads that don't provide a resolution in
the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974).
All values in the property are optional, e.g. a string of "::45" is valid to
set the resolution to 45.
The order intentionally orders resolution before fuzz and flat despite it
being the last element in the absinfo struct. The use-case for setting
fuzz/flat is almost non-existent, resolution is probably the most common case
we'll need.
To avoid multiple hwdb invocations for the same device, replace the
hwdb "keyboard:" prefix with "evdev:" and drop the separate 60-keyboard.rules
file. The new 60-evdev.rules is called for all event nodes
anyway, we don't need a separate rules file and second callout to the hwdb
builtin.
This reverts commit ba76ee29bc. As it turns
out, we need to match on driver=atkbd to not load the fixups on any
plugged USB devices.
That is, whenever you use "name:<name>:dmi:<dmi>" style matches, you
better provide a name or you're screwing things up.
Currently, we always run
hwdb 'keyboard:name:$attr{name}:$attr{[dmi/id]modalias}'
as last step to match keyboards. Therefore, if nothing else matched so
far, we still try the device-name+dmi combination.
However, we have a special atkbd rule which is only run for atkbd as:
hwdb 'keyboard:$attr{[dmi/id]modalias}'
This is redundant, as we already pass the same information to hwdb in the
last fallback step.
This patch converts the hwdb "keyboard:dmi:*" matches to
"keyboard:name:*:dmi:*" matches and drops the redundant rule.
There is no reason to match on usb-modaliases, if we can use the
input-modalias to achieve the same. This commit changes the
keyboard-lookups to not be restricted to USB, but pass all modaliases to
the hwdb. Furthermore, we convert all usb:* matches to input:* matches,
thus getting rid of any ambiguity if multiple usb devices are chained (or
a bluetooth device / etc. is on top).
Note that legacy keyboard:usb:* matches are still supported, but
deprecated. If possible, please use keyboard:input:* matches instead.
This is a required step to make other input devices work with
60-keyboard.hwdb. Other bus-types are often chained on usb and we want to
avoid any ambiguity here if we incorrectly match on a USB hub.
ThinkPad tablet firmware has DMI product name and version reversed:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 7762AS1
Version: ThinkPad X61 Tablet
Serial Number: LKZCDH2
UUID: 6ADBC681-4FC9-11CB-844F-B47CB9210BE2
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: ThinkPad X61 Tablet
On these several HP laptops, the microphone mute hotkey is "Fn+F8" and
the scancode for this hotkey is 0x81, but this scancode was mapped to
fn_esc in the HP generic keymap section. To fix this problem, we add
a machine specific keymap section to add the correct keymap rule.
BugLink: https://bugs.launchpad.net/bugs/1409721
BugLink: https://bugs.launchpad.net/bugs/1334968
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Some time ago 95-keymap.rules was replaced by
60-keyboard.hwdb. Original comments for MSI laptops (that were in
95-keymap.rules) were removed, but I think they are important for
understanding what's going on.
https://bugs.freedesktop.org/show_bug.cgi?id=88412
On the Dell Inspiron 1520 both the atkbd and acpi-video input devices report
an event for pressing the brightness up / down key-combos, resulting in user
space seeing double events and increasing / decreasing the brightness 2 steps
for each keypress.
This hwdb snippet suppresses the atkbd events, making the Inspiron 1520 work
like most modern laptops which emit brightness up / down events through
acpi-video only.
Reported by Pavel Malyshev <p.malishev@gmail.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1141525
The compaq ku 0133 keyboard has 8 special keys at the top:
http://lackof.org/taggart/hacking/keyboard/cpqwireless.jpg
3 of these use standard HID usage codes from the consumer page, the 5
others use part of the reserved 0x07 - 0x1f range.
This commit adds mapping for this keyboard for these reserved codes, making
the other 5 keys work.
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
