1
0
forked from drath/libratbag
Commit Graph

8 Commits

Author SHA1 Message Date
Luke
cdb3226ef1 meson: don't use brackets, parenthesis and braces in filenames
Renamed filenames to avoid brackets, and added a check to data-parse-test.py to
check for brackets, parentheses, and braces so they aren't shipped in filenames
in the future.
2019-11-17 00:11:42 +00:00
Filipe Laíns
edb054c6f8 hidpp20: add quirk system
Signed-off-by: Filipe Laíns <lains@archlinux.org>
2019-08-13 08:52:06 +01:00
Peter Hutterer
11db35edba Fix flake8 warnings (#678)
The only notable one here is the regex that had an escape sequence

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-03-12 06:49:54 +01:00
Peter Hutterer
734977f176 Drop the SVG handling from libratbag
The SVGs must not be part of any stable API, there is too much behavior
implied that we cannot/do not specify. So it's perfectly likely that a future
change in the SVGs or rendering libraries breaks things in some detail. But
then we cannot update the SVGs without risking breaking other clients that
rely on the current behavior.

Besides: we only have one theme, called "gnome" because a push
towards having SVGs for other themes never happened.

And that theme isn't gnome-specific, it merely looks GNOMEy. The theme is very
much piper-specific in that it requires certain elements that piper cares
about. Currently anyway, if we make this part of our API, piper cannot change
that behavior ever without breaking others.

So let's drop SVG handling completely and rely on the clients to sort it out
for themselves.

For now the SVGs are left in the tree to make it easier to copy to Piper. Once
that's done, we will remove those too.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-02-22 11:17:09 +01:00
Peter Hutterer
b93dfcfda4 data: add helper functions for checking list contents
Easier to print the lists instead of just failing

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2018-12-11 11:08:11 +10:00
Peter Hutterer
1c85d77d56 data: add LedTypes keyword argument to the device files
At least on HID++ 2.0, the LED types appear to be random and don't match the
protocol specs. Other protocols don't even have those bits, so let's make this
a generic entry.

This is pre-filled for all LEDs but drivers can override it where required.

Fixes #377

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2017-10-10 09:30:50 +10:00
Thomas Hindoe Paaboel Andersen
a19a79d33a hidpp10: add Leds entry to .device file
For the device I have I do not see a way to get
this information by querying the device.

If the value is set in the .device file it will
override anything that the hidpp10 driver itself
would have found.
2017-10-03 23:06:01 +02:00
Peter Hutterer
340e5b7d86 Switch to a .ini-file based device database
The hwdb was a quick and easy way to add entries for new devices but we need
more and more info about the various types of devices. It's better to move
this to a proper database.

Side-effect: this also gives us an easy way to point to the list of devices
supported and makes checking for e.g. missing svgs easier.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2017-08-28 17:50:20 +02:00