Once the seat is acquired, gnome-settings-daemon (GSD) takes full
control of rfkill by sending RFKILL_IOCTL_NOINPUT ioctl to disable
rfkill control in kernel.
Since GSD expects wlan keycode when the hotkey gets pressed, we should
change the "unknown" to "wlan" accordingly.
Tested under both GNOME and KDE.
I read the addition of the purism laptop keyboard and noticed
that the 60-keyboard.hwdb file could/should have an alphabetical ordering.
I scratched that itch with this commit.
Similar to 16bed3afa1, this model also doesn't have the
LED.
```
cat /sys/class/dmi/id/modalias
dmi:bvnLENOVO:bvrN1KET16W(1.03):bd01/20/2016:svnLENOVO:pn20FH001AMX:pvrThinkPadT560:rvnLENOVO:rn20FH001AMX:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone:
```
[I'm just submitting the solution originally suggested by @barzog.
Nevertheless, this looks pretty straightforward, we don't want to define
any keys on a universal receiver.
Note that this definition was added back in
aedc2eddd1, when we didn't yet have
support for figuring out what hardware is connected behind a logitech
receiver.]
In 60-keyboard.hwdb there is a definition of # Cordless Wave Pro
evdev:input:b0003v046DpC52[9B]*
which in fact not a cordless keyboard but an USB receiver to which different
types of keyboard can be connected. The solution is to completely clean
definition evdev:input:b0003v046DpC52B* from there.
I: Bus=0003 Vendor=046d Product=c52b Version=0111
N: Name="Logitech USB Receiver"
P: Phys=usb-0000:00:1d.0-1.8/input1
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.8/4-1.8:1.1/0003:046D:C52B.0005/input/input20
U: Uniq=
H: Handlers=kbd mouse0 event8
B: PROP=0
B: EV=1f
B: KEY=3007f 0 0 83ffff17aff32d bf54444600000000 ffff0001 130f978b17c000 6773fad941dfed 9ed68000004400 10000002
B: REL=1c3
B: ABS=100000000
B: MSC=10
Fixed#8095.
The touchpad toggle key (Fn + Esc) on the T-bao Tbook air sends CTRL +
META + scancode 0x76 without this quirk. With this quirk it sends CTRL +
META + F21, with F21 mapping to XF86TouchpadToggle, which is what we want.
Note that the CTRL + META modifiers being send together with the F21 are
still somewhat unusual, userspace will need to be thought to deal with
this as there is nothing we can do about this at the hwdb level. Note at
least one other laptop also sends CTRL + META + F21 instead of just F21.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The touchpad toggle key (Fn + F6) on the VIOS LTH17 sends CTRL + META + F24
without this quirk. With this quirk it sends CTRL + META + F21, with F21
mapping to XF86TouchpadToggle, which is what we want.
Note that the CTRL + META modifiers being send together with the F21 are
still somewhat unusual, userspace will need to be thought to deal with
this as there is nothing we can do about this at the hwdb level. Note at
least one other laptop also sends CTRL + META + F21 instead of just F21.
The intent of the hwdb entry for the Cube iWork8 air tablet buttons is
to fix them being swapped. The kernel is using left-meta for the
home key (it is being treated as the windows key on keyboards, as it has
a windows logo on most x86 tablets).
Fix the hwdb entry to only swap the buttons and not change the keycode
emitted by the home key.
At each time pressing the WiFi Fn key on Dell Latitude E7270 laptop, the system
reports the following error/warning messages:
atkbd serio0: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0).
atkbd serio0: Use 'setkeycodes e008 ' to make it known.
This is due to commit 0e33634 which was added to fix
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1441849.
However on Dell Latitude E7* models, we need to restore the old generic
behavior which consists in ignoring the key event since it's already done by
the HW.
Indeed the hardware has a specific driver (dell_wmi) to handle rfkill in the
hardware level. So, as long as the hardware handles, the best is to leave as
is.
This patch was originally written by Takashi Iwai.
Fixes#5047
The power key keycode e076 is emitted on several different Acer laptop
models, and it is expected that it will also be used on upcoming models.
Verified on the following models:
Aspire ES1-421
Aspire ES1-432
Aspire A515-51
Aspire A515-51G
Aspire A517-51
Aspire A517-51G
Nitro AN515-31
According to the key code v2.02 from Acer, scancode E0 86 will be
generated for airplane mode hotkey. Verified on Aspire, TravelMate,
Easynote and Predator.
It is useful for desktop environments to be able to show Caps-Lock or
Num-Lock status changes as an on-screen display when using a keyboard
that doesn't have LEDs for this.
Closes: #5559
The home and power buttons on the Cube iwork8 air tablet are swapped,
add a hwdb entry fixing this up.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Sometimes a system may have 2 input event nodes with the same name where
we only want to apply keyboard hwdb rules to 1 of the 2 devices.
This problem happens e.g. on devices where the soc_button_array driver is
used (e.g. intel atom based tablets) which registers 2 event nodes with
the name "gpio-keys".
This commit adds a new extended match rule which extends the match to also
check $attr{phys} and $attr{capabilities/ev}, allowing to differentiate
between devices with an identical name.
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Yubikeys and other pseudo keyboards require that they are in the US layout,
otherwise the data they send is invalid. Add two new keys to signal this to
processes that handles (XKB) layouts.
Add MSI VR420 (model MS-1422) to the list of MSI models which need to
ignore brightness hotkey presses, as these are already reported through
the acpi-video interface.
Bug-link: https://bugzilla.redhat.com/show_bug.cgi?id=1270124
Reported-by: David Dreggors <dadreggors@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Like the Inspiron 1520, the Dell Latitude 2110 emits brightness-control
key events both through atkbd and acpi-video. This suppresses them on
the atkbd side.
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>
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.
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>
