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)
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
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.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
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.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
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
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
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>
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
One would expect pressing the button to go to an overview / show
applications mode, we thus map it to leftmeta, the Windows key.
See https://bugzilla.gnome.org/show_bug.cgi?id=658602#c17
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
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
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
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
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
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>
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Reportedly also applies to NP900X4B, so relax the match to apply to all models
of this series.
https://launchpad.net/bugs/902332
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Add a comment to all assignments to f20 that this actually should be "micmute"
in a future when we aren't limited by X.org's key code limiations any more.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
On the Dell Latitude, the mic mute key event is generated by wmi
driver, the keycode assigned to this hotkey from kernel is
KEY_MICMUTE (248), this keycode is too big for xorg to handle,
in the xorg, the XF86AudioMicMute is assigned to F20.
Please refer to 4e648ea0 of xkeyboard-config.
BugLink: https://bugs.launchpad.net/bugs/1326684
BugLink: https://bugs.launchpad.net/bugs/1339998
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Originally is KEY_TOUCHPAD_TOGGLE, but X.org can't handle the big key events,
so use the F21 convention.
https://bugs.freedesktop.org/show_bug.cgi?id=72807
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
This is upstream commits
f89b42ec0fd51feab5566d6bdbacee101023c037
15f392394e75ffb7f318920008fd1bbe4e82b488
by Marcel Holtmann <marcel@holtmann.org> and Scott Thrasher <scott.thrasher@gmail.com>
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Keymaps for Samsung 900X3E and 900X3F should be the same as for other
models in the series.
I have also moved the comment for '# Series 9' to the right place
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
This squashes upstream commits from the following authors:
AppleBloom
Dmitry Pisklov
Jimmie Tauriainen
Jose Ignacio Naranjo
Kay Sievers
Marcel Holtmann
Martin Pitt
Raudi
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Without this, the hwdb trie gets mis-sorted to match the more specific rules
first, as ":pvr" is lexicographically after ":pn". So ensure that all our
matches have some ":pn" match to avoid this trap.
Spaces are dropped from vendor and product names in DMI modaliases, so a match
like "svnDell Inc.:" will never happen. Also, some machines use "Dell", some
"Dell Inc", some "Dell Inc.", so just match on "Dell*" to avoid all these
traps.
https://launchpad.net/bugs/1218433
Don't use "KEYBOARD_KEY_xx=!" assignments (i. e. only enabling force-release)
if more general matches already explicitly set a key code before, to not
override the previously set value.
https://launchpad.net/bugs/1218433
