| Age | Commit message (Collapse) | Author |
|---|
|
DPI information was taken from the device's setup guide.
Additional (shortened) information from udevadm info:
P: .../usb2/2-1/2-1:1.0/0003:046D:C07E.0002/input/input6/event2
N: input/event2
S: input/by-id/usb-Logitech_Gaming_Mouse_G402_6D93117D5049-event-mouse
S: input/by-path/pci-0000:00:12.0-usb-0:1:1.0-event-mouse
...
E: ID_BUS=usb
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_MODEL=Gaming_Mouse_G402
E: ID_MODEL_ENC=Gaming\x20Mouse\x20G402
E: ID_MODEL_ID=c07e
E: ID_PATH=pci-0000:00:12.0-usb-0:1:1.0
E: ID_PATH_TAG=pci-0000_00_12_0-usb-0_1_1_0
E: ID_REVISION=9002
E: ID_SERIAL=Logitech_Gaming_Mouse_G402_6D93117D5049
E: ID_SERIAL_SHORT=6D93117D5049
E: ID_TYPE=hid
E: ID_USB_DRIVER=usbhid
E: ID_USB_INTERFACES=:030102:030000:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Logitech
E: ID_VENDOR_ENC=Logitech
E: ID_VENDOR_ID=046d
E: LIBINPUT_DEVICE_GROUP=3/46d/c07e/111:usb-0000:00:12.0-1
E: MAJOR=13
E: MINOR=66
E: SUBSYSTEM=input
...
|
|
Update the location of the bug tracker and mention that pull requests
are preferred.
|
|
Macbook2,1, late 2006 model.
https://bugzilla.redhat.com/show_bug.cgi?id=1246651
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=91364
|
|
|
|
|
|
|
|
|
|
The main purpose of this hwdb was to tag touchpads that have the physical
trackstick buttons wired to the touchpad (Lenovo Carbon X1 3rd, Lenovo *50
series). This hwdb is not required on kernels 4.0 and above, the kernel now
re-routes button presses through the trackstick's device node. Userspace does
not need to do anything.
See kernel commit cdd9dc195916ef5644cfac079094c3c1d1616e4c.
This reverts commit 001a247324b44c0e0b8fdba41a6fc66e7465b8b6.
|
|
|
|
|
|
|
|
|
|
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)
|
|
typo
keymap: Add Samsung NP350V and NP670Z
|
|
Since 3.19, the devices have the proper vid/pid and the model number in the
name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
DPI is guesswork, no specs found on the web and calculating DPIs on a
trackball is tedious.
|
|
|
|
|
|
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=90540
|
|
http://www.logitech.com/en-us/product/wireless-trackball-m570#specs
https://bugzilla.redhat.com/show_bug.cgi?id=1217881
|
|
This model needs the trackpoint sensitivity to be boosted to not be too slow
to be usable, see: https://bugzilla.redhat.com/show_bug.cgi?id=1200717
|
|
Multiple models in the same hardware series are likely to have similar
specs. We should use organization similar to hwdb/60-evdev.
|
|
Like the T440s these need the sensitity to be set significantly higher
then the default of 128 for the trackpoint to be usable. Like with the
T440s 200 seems to be a good value to get a reasonable but not too high
sensitivity.
|
|
|
|
Device name is PixArt, but it's sold as a HP brand.
https://bugs.freedesktop.org/show_bug.cgi?id=90142
|
|
The atmel driver sets a default resolution of 20 for each touchpads it
creates. On this model, 10 is more appropriate.
The resolution is not set for the touchscreen by the kernel, so match
the name to both touchpad and touchscreen.
|
|
The Lenovo X230 advertize a vertical resolution of 136, which gives a true
size of 31 mm. The actual physical size of the touchpad is 40 mm, so
override the resolution to 100.
|
|
The pointingstick of the Dell Latitude E6400 is somewhat slow by default,
whereas the pointingstick of the Dell Latitude D620 is much too fast by
default, set POINTINGSTICK_CONST_ACCEL for both of them to adjust for this.
|
|
Lenovo has changed the sensitivity of the trackpoint on the x240 / T440s / T540
generation of Thinkpads, making them somewhat insensitive by default, add a
hwdb entry to tweak the sensitivity setting.
The ThinkPad X200s is way way too slow by default and unless you push the
trackpoint quite hard only sends delta events in the 1-2 range, tweak the
sensitivity to make it send a wider range of deltas and apply a const accel
factor to make it have a more reasonable speed by default.
|
|
IBM / Lenovo trackpoints allow specifying a sensitivity setting through a
ps/2 command, which changes the range of the deltas sent when using the
trackpoint.
On some models with normal usage only deltas of 1 or 2 are send, resulting in
there only being 2 mouse cursor movement speeds, rather than the expected fluid
scale. Changing the sensitivity to a higher level than the bootup default fixes
this.
This commit adds support for setting a POINTINGSTICK_SENSITIVITY value
in hwdb to allow changing the sensitivity on boot through udev / hwdb.
|
|
There is quite a wide spread in the delta events generated by pointingsticks,
some generate deltas of 1-2 under normal use, while others generate deltas
from 1-20.
This commit adds a hwdb file which allows specifying a per model
POINTINGSTICK_CONST_ACCEL value which can be used by the userspace input stack
to normalize the deltas so that all pointingsticks get the same feeling ootb.
The hwdb matching re-uses the existing 60-evdev.rules.
|
|
It does not generate a release event.
https://launchpad.net/bugs/1441849
|
|
This adds support for the keyboard illumination keys and fixes
Fn+F1.
|
|
Verified for the 5,1 Macbook, the others are guesses based on the list of
supported devices of the moshi trackpad protector.
http://www.moshi.com/trackpad-protector-trackguard-macbook-pro#silver
Resolution calculated based on the min/max settings set in the kernel driver,
divided by the physical size. This is probably slightly off, but still better
than no resolution at all.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
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.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=89743
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=89684
|
|
|
|
This reverts commit ba76ee29bc02879fb42c048132af8889b00220d5. 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.
|
|
|
|
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=84437
|
