Simply abort if the macro value is bad, that's a libratbag bug and should
never happen.
Found in #312
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Checks for the three layers we need and that any buttons in the files are
consecutive and have the right layers
Fixes#196
Co-authored-by: Jente Hidskes <hjdskes@gmail.com>
We keep the hardcoded fallback.svg for the test device, otherwise we get an
error every time we start ratbagd.devel
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This SVG is generic enough to cover 7-button mice with up to 3 LEDs that are
supported but don't have an SVG. The SVG style is intentionally NOT a generic
mouse to make it obvious that something isn't right here. If we use a generic
mouse, people may not put the effort into a proper SVG style because the
generic mouse is good enough.
The fallback is currently only used for test devices
Some devices can have a custom name, so let's export that capability.
In ratbagd, libratbag/ratbag_profile_set_name() returns an error, we
put it under silence, the client has to check for the capabilities
before asking ratbagd to change the profile name.
Fixes: #266
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
We have autodetection for Logitech, but let's always specify the driver for
devices we have in the hwdb.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we couldn't find the name on the bus or the ratbagd process already
terminated, return None and fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I originally intended to have a dynamic use of argparse to generate
the commands, but it turned out to be a nightmare.
Just go down the tree of arguments and format the help properly.
Fixes#288
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We shouldn't try to access input_string[0] if len(input_string) is null.
Meaning a condition in the break in the while loop could be checked
earlier (or later).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
ns is never reset, so once it has a subparser, it'll keep it, so the try
catch is just too much
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Calling "ratbagctl profile -t" resulted in an infinite loop because it
tried again and again to parse "-t" in the profile
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Too easy to trigger ("ratbagctl.devel profile" is just enough), so we
probably better have a proper usage call here.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
.parse did not consumed the input_string, it only appends the given
parsing to the parent. Rename the function and kill the debug output
in nested calls as this was misleading while re-reading the code.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The help option (or verbose FWIW) were not global which makes some random
behavior when using -h at different places for the input string.
Retrieve those options once and remove them from the list of things to
process.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
"sudo ./build/ratbagctl.devel profile 2 4" returns an exception with cmd
being unknown.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Keeps the ratbagd daemon running until a signal is received. This is helpful
for using an external client (like piper) to run against the ratbagd.devel
instance. And to make that even easier, print the RATBAGCTL_DEVEL environment
variable for use with ratbagd.py. In the future, this should probably be a
more generic name.
The integration is a bit odd because we need to add --keepalive to the actual
parser, but we recreate that on every parse() call. So we set a flag on the
parent object and check for that during parser creation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't automatically handle the help output - call print_help() on the parser
manually.
It's unclear why this doesn't just get called correctly, but at least this
fixes the immediate issue. The subcommand help is still pretty terrible
though.
https://github.com/libratbag/libratbag/issues/288
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
