IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Note that the MS receivers likely work like the Logitech ones, i.e. all
devices connected show up with the same vid/pid/name. Full evidence remains to
be gathered.
This way entries from the same brand with the same dpi and frequency
can be coalesced. It is also visually easier to find the right DPI
than order hexadecimal identifiers.
Pointer acceleration for relative input devices (mice, trackballs, etc.)
applies to the deltas of the device. Alas, those deltas have no physical
reference point - a delta of 10 may be caused by a large movement of a
low-dpi mouse or by a minute movement of a high-dpi mouse.
Which makes pointer acceleration a bit useless and high-dpi devices
essentially unusable.
In an ideal world, we could read the DPI from the device directly and work
with that. In the world we actually live in, we need to compile this list
manually. This patch introduces the database, with the usual match formats
and a single property to be set on a device: MOUSE_DPI
That is either a single value for most mice, or a list of values for mice
that can change resolution at runtime. The exact format is detailed in the
hwdb file.
Note that we're explicitly overshooting the requirements we have for
libinput atm. Frequency could be detected in software and we don't
actually use the list of multiple resolutions (because we can't detect
when they change anyway). However, we might as well collect those values
from the get-go, adding/modifying what will eventually amount to hundreds
of entries is a bit cumbersome.
Note: we rely on the input_id builtin to tag us as mouse first, ordering
of the rules is important.
(David: fixed up typos and moved hwdb file into ./hwdb/)
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>
