This fixes the following warning:
```
parse_hwdb.py:120: UserWarning: warn_ungrouped_named_tokens_in_collection: setting results name 'SETTINGS*' on And expression collides with 'HZ' on contained expression
dpi_setting = (Optional('*')('DEFAULT') + INTEGER('DPI') + Suppress('@') + INTEGER('HZ'))('SETTINGS*')
```
Not sure about for the mount_matrix, but LGTM.com warns in that line,
and, adding Group() does not change the parse result.
The properties are not unquoted by udev, so the quotes effectively became part
of the value.
Even though those properties were added quite a while ago
(086c001e29,
d7d31692bf), they never started being used
(because of issues with having multiple layouts), see
https://gitlab.gnome.org/GNOME/mutter/-/issues/906,
https://bugzilla.gnome.org/show_bug.cgi?id=775681.
Let's remove the quotes while we still can.
From https://bugzilla.gnome.org/show_bug.cgi?id=775681#c7:
> Note to self: the values for XKB_FIXED_LAYOUT and XKB_FIXED_VARIANT are
> quoted, meaning that we need to remove the quotes before passing the values
> from udev_device_get_property_value() to xkb_keymap_new_from_names()
> otherwise the compilation of the keymap fails (please don't ask how I found
> out...)
This is all confusing as hell, becuase in some places lowercase hexadecimal
digits are used, and in other places uppercase. This adds a check for the
most common case that we and others got wrong.
I tried to extend the general grammar in hwdb_grammar() to include this check,
but it quickly became very complicated and didn't seem to work properly. Doing
initial parsing with more general rules is easier and also seems to give better
error messages:
/home/zbyszek/src/systemd-work/build/../hwdb.d/60-autosuspend.hwdb: 3 match groups, 5 matches, 3 properties
Pattern 'v058fp9540*' is invalid: Expected W:(0123...), found 'f' (at char 4), (line:1, col:5)
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
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.
Björn Daase