[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.
Some newer BIOS versions of the TrekStor SurfTab wintron 7.0 tablet use
different (better) DMI strings, update the existing 60-sensors.hwdb
entry for this tablet to also work with the newer BIOS.
#Add "Early 2008 Core 2 Duo/Penryn" Macbook4,1 match string to the existing touchpad range definition
##Symptoms
* Jerky/Jumpy cursor motion using touchpad
* "Axis value outside expected range" message in Xorg.0.log
##Fix
I followed the instructions described here :https://wayland.freedesktop.org/libinput/doc/latest/absolute_coordinate_ranges.html and came up with the following :
evdev:input:b0003v05ACp022A*
EVDEV_ABS_00=256:1469:12
EVDEV_ABS_01=256:829:12
The ranges and resolutions are the same as stated in the existing definition (+/- 2) so only add the match string.
Full dmi/id/modalias:
dmi:bvnLENOVO:bvrB4CN29WW:bd12/04/2015:svnLENOVO:pn80HV:pvrLenovoMIIX3-1030:rvnLENOVO:rnMartini:rvrSDK0G98662WIN:cvnLENOVO:ct11:cvrLenovoMIIX3-1030:
Tested on Lenovo MIIX3 with Debian 9
Confirmed via `udevadm test /sys/class/input/eventX` that
POINTINGSTICK_* properties were not being set for my T430s trackpoint.
After adding a local entry file (as advised in this file), the same
`udevadm test` command showed properties.
More importantly, the movement of mouse using trackpoint felt much
better. Hard to describe its previous state, but following come to mind:
slippery, hard to control, awkward. Now it feels more consistent and predictable.
A little on the sensitive side with the defaults, but didn't think it warranted
dedicated properties just for this series though as the X230 is same generation
and uses the defaults.
Before local change:
$ udevadm info /dev/input/event5
P: /devices/platform/i8042/serio1/serio2/input/input6/event5
N: input/event5
E: DEVNAME=/dev/input/event5
E: DEVPATH=/devices/platform/i8042/serio1/serio2/input/input6/event5
E: ID_BUS=i8042
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_POINTINGSTICK=1
E: LIBINPUT_DEVICE_GROUP=11/2/a:synaptics-pt/serio0
E: MAJOR=13
E: MINOR=69
E: SUBSYSTEM=input
E: USEC_INITIALIZED=38609915
After change:
$ udevadm info /dev/input/event5
P: /devices/platform/i8042/serio1/serio2/input/input6/event5
N: input/event5
E: DEVNAME=/dev/input/event5
E: DEVPATH=/devices/platform/i8042/serio1/serio2/input/input6/event5
E: ID_BUS=i8042
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_POINTINGSTICK=1
E: LIBINPUT_DEVICE_GROUP=11/2/a:synaptics-pt/serio0
E: MAJOR=13
E: MINOR=69
E: POINTINGSTICK_CONST_ACCEL=1.0
E: POINTINGSTICK_SENSITIVITY=200
E: SUBSYSTEM=input
E: USEC_INITIALIZED=38609915
The changes in pci.ids, usb.ids, and the .hwdb files are almost always
additions. 20-OUI.hwdb drops a few names and replaces them by
"IEEE Registration Authority". I'm not sure what to do about this.
Many other removals do not seem to be removals of real entries, but
rather placeholder or generic names.
So far I avoided adding license headers to meson files, but they are pretty
big and important and should carry license headers like everything else.
I added my own copyright, even though other people modified those files too.
But this is mostly symbolic, so I hope that's OK.
The GP-electronic T701 has its LCD panel mounted upside-down, initially
my plan was to fix this by transparently rotating the image in the i915
driver (my "drm/i915: Deal with upside-down mounted LCD" patch), but
that approach has been rejected instead the kernel will now export
a "panel orientation" property on the drm-connector for the panel and
let userspace deal with it.
Since the upside-down-ness of the panel is now no longer transparently
hidden from userspace, the current accel mount quirk for the T701 needs
to be updated to take the upside-down-ness into account.
The input_id builtin assigns the various ID_INPUT based on the exported evdev
bits. In some cases, the device may not have the properties required to label
a device as one specific type but the physical form factor is clear.
e.g. in the case of #7197 it's a tablet pad that does not have x/y axes which
the kernel exports for pads for historical reasons.
A custom override is needed, best to be solved with a hwdb entry.
Related #7197
On some devices the display (LCD panel) is mounted non upright
in the device's casing, e.g. mounted upside-down or 90 degree rotated.
Document the expected ACCEL_MOUNT_MATRIX settings for such devices.
