Repository navigation
keventd: fix hwdb lookups that never match - #517
Merged
Merged
Conversation
troglobit
approved these changes
Nov 12, 2026
troglobit
left a comment
Collaborator
There was a problem hiding this comment.
Another great PR, for a slow maintainer, sorry again for taking so long!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When setting up bluetooth on my custom distro, I noticed that the device name was never properly resolved. Poking around new keventd implementation, and
hwdbparsing feature in particular, revealed several issues that caused this incorrect behavior. Namely:Issue 1. Properties after comments were dropped
A comment line ended the record being read. Comments are now skipped; only an empty line ends a record.
Issue 2. Lookup key as an argument was not processed and buffer was too small
Many hwdb invocations in the stock rules pass the key as an argument, e.g.
hwdb 'evdev:name:$attr{name}:$attr{[dmi/id]modalias}'. The argument was ignored, so those rules (mouse, touchpad, joystick, sensor, name-based evdev, camera, ieee1394) looked up a synthesised key or nothing. The first non-option argument is now the key.Additionally, the key buffer was 256 bytes and silently cut longer keys off. With typical DMI strings the name-based evdev key is 250 to 265 bytes, and 280 to 300 for the name+phys+ev form, so 256 is marginal. The buffer is now 1024 bytes and a key that still does not fit is skipped with a warning. The prefix is inserted in place, so there is no second buffer.
Issue 3. Uninitialised input ids were getting parsed
hwdb_input_key()parsed vendor, product and version from uninitialised buffers when anid/file was missing.Issue 4. Input keys were not built the way rules expect
The stock rules use
and the entries are
evdev:input:b0003v...andid-input:modalias:input:b0003v..., i.e. the prefix followed by theinput modalias. keventd built
evdev:input:b...and then added the prefix, givingevdev:evdev:input:..., which never matches. The key is nowinput:b.... Themodaliasattribute of the input device is used when present, because two of the sevenid-inputentries match on the capability list that theid/files do not have.Results with the real hwdb entries and the stock invocations:
evdev:prefix, device with modaliasEVDEV_ABS_00,EVDEV_ABS_01evdev:prefix,id/files onlyid-input:modalias:, needs capability listID_INPUT_POINTINGSTICK=1