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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
HP spec mandates the hp-wireless driver as canonical source of rfkill
event, so mask the rfkill event from intel-hid to avoid double rfkill
events fired from a single hotkey press.
This fixes the broken rotation on the Acer Spin 1 I recently bought (exact model is SP111-34N-P4BZ).
It is possible that all of the SP111 models would use the same matrix, but to be on the safe side, I added a new entry.
This has now been deprecated in libinput, the only known user of this
property. It was never set for any device and weston and mutter, maybe
other compositors, never added the code required to parse it.
The benefit we could get in the UI from handling tilt differently to
wheel is tiny and the lack of support shows that it isn't of interest to
anyone. Let's remove this.
See also
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/444
Commit 3d864658ea ("hwdb: assume all Medion Akoya E-models have the
same matrix"), unified the entries for most Medion Akoya E* modes,
including the entry for the Medion Akoya E2215T MD60198.
But the accelerometer on the E2215T has an ACPI-id of KIOX000A, rather
then KIOX010A as the other models have, so that commit broke the
ACCEL_MOUNT_MATRIX for the E2215T.
Add a separate match for the E2215T so that it gets the correct
ACCEL_MOUNT_MATRIX again.
The original source of these dimensions had swapped the x y dimension
arguments to touchpad-edge-detector. The correct dimensions are
x = 100 mm, y = 68 mm
With the default config repeated press of fn+VolumeUp or fn+VolumeDown lead to
repeated presses even after release, which leads to volume going to 100% or 0%.
Unlike newer Medion Akoya E* models for which we have a generic
wildcard match, this model uses a somewhat older KIOX0009 accelerometer.
Not only does our generic catch all not match, we also need a different
matrix for this model, so add a model-specific entry for it.
the modalias reported by udev is acpi:BOSC0200:BOSC0200: but the rules
only matched acpi:BOSC0200:BOSC0200 (without the trailing colon)
change to acpi:BOSC0200* as in other models
This was added in ffac30349e in 2017 but didn't
get added to the meson.build thus never actually installing it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add the resolution and range information for Lenovo Ideapad 310S-14ISK Alps touchpad. It provides information for the test case of libinput for Alps devices.
The Synaptics Touchpad that comes with the T490 doesn't explicitly set
its resolution, so these lines are needed to provide that, in order to
help the libinput code detect overly large jumps. Since this device
contains buttons under the lower section of the touchpad, large jumps
are common, so having the resolution helps libinput greatly reduce
the number of occurances of pointer jump.
This comes from
https://gitlab.freedesktop.org/libinput/libinput/issues/402.
The kernel now has proper evdev codes for the menu buttons below the
small LCD-s builtin to some keyboards.
Add mappings for these buttons on the Logitech MX5000 and MX5500 keyboards.
This commit fix the accelerometer orientation on the Jumper EZpad
Go tablet.
The tablet does not have its product name filled in dmi table, make
the match string a bit generic. Here we assume that the use of a
KIOX000A + bios-vendor + chassis-type combo is unique enough to
match the currently available product in Jumper's x86 tablet series.
For future reference, as in 2019, the tablet has a dmialias of:
dmi:bvnAmericanMegatrendsInc.:bvrZB-BI-11.6-SF133AR200-059-J \
:bd05/21/2019:svnjumper:pnEZpad:pvrTobefilledbyO.E.M.:rvnTob \
efilledbyO.E.M.:rnTobefilledbyO.E.M.:rvrTobefilledbyO.E.M.:c \
vnTobefilledbyO.E.M.:ct31:cvrTobefilledbyO.E.M.:
There is no change in the file right now, but the download seems to work
OK.
It's funny that the biggest company in the world cannot provide a
download link in plain text.
Chromebook keyboards have a top row which generates f1-f10 key codes but
the keys have media symbols printed on them. A simple scan code to key
code mapping to the correct media keys makes the f1-f10 inaccessible. To
properly use the keyboard a custom key code to symbol mapping in xbk is
required (a variant of the chromebook xkb model is already upstream).
Other devices have similar problems.
This commit makes it possible to specify which xkb model should be used
for a specific device by setting XKB_FIXED_MODEL.
pyparsing 2.3.1/2.4.0 had some changes to grouping of And matches, and as a
result we'd report 0 properties and 0 matches, and not really do any checks.
With this change we get identical behaviour for pyparsing 2.3.1, 2.4.0, 2.4.2:
$ hwdb/parse_hwdb.py
hwdb/60-evdev.hwdb: 72 match groups, 94 matches, 262 properties
hwdb/60-input-id.hwdb: 3 match groups, 3 matches, 4 properties
hwdb/60-keyboard.hwdb: 173 match groups, 256 matches, 872 properties
Keycode KBD_LCD_MENU1 unknown
Keycode KBD_LCD_MENU4 unknown
Keycode KBD_LCD_MENU2 unknown
Keycode KBD_LCD_MENU3 unknown
hwdb/60-sensor.hwdb: 101 match groups, 120 matches, 105 properties
hwdb/70-joystick.hwdb: 2 match groups, 3 matches, 2 properties
hwdb/70-mouse.hwdb: 104 match groups, 119 matches, 123 properties
hwdb/70-pointingstick.hwdb: 8 match groups, 30 matches, 11 properties
hwdb/70-touchpad.hwdb: 6 match groups, 9 matches, 6 properties
pyparsing sometimes changes behaviour and stops giving matches. This should
allow us to detect such scenario. With this change, parse_hwdb fails with
pyparsing 2.4 on F31.
