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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
