While the DBus API is still in flux, things can break at any time.
Keeping piper and libratbag in version-step works terribly, doubly so where
piper is flatpaked but ratbagd comes from some repo somewhere. We can't check
at build-time, we can't run ratbagd --version at runtime.
so let's add a version field for now and drop it if we ever get to stable.
Meanwhile, ratbagd.py will throw an exception if the expected version doesn't
match exactly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Force the tests to load a test device with JSON that matches their
expectations instead of having a magic device pre-setup where the tests have
to know what the values are.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't rely on some other tool to install the policy file, let's just do this
in ratbagd.devel directly so it's immediately executable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Which is the same env that ratbagd uses as well. And we don't have variable
values in RATBAGCTL_DEVEL anymore, so no point in having two different
variables here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it possible to run the script against a manually started
ratbagd.devel - with a lot less effort.
And since we're don't need to be root to do this, let's move that check too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it a lot easier to start ratbagd.devel in gdb, then run
ratbagctl.devel against it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have a separate name for the devel bus anyway, the git sha doesn't
give us a huge amount of benefits but makes manual debugging a major PITA.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When there's a bug that's triggered by the test suite it's hard to figure out
what exactly crashes. So allow starting ratbagd.devel manually and run the
test suite against that process so we can gdb it.
The steps required for this are a bit insane, so the instructions are listed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For two dicts x and y the merged dict can be created as {**x, **y}. We use
that to take the enum names and covert them to lowercase with hyphens instead
of underscores.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of multiple entry points for different values, make the button mapping
a single entry point that takes the mapping type and a variant for the value.
The ratbagd.py bindings are basically left as-is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GObject silently catches exceptions and logs it to stderr without ever passing
on the exceptions. Avoid oversight by checking stderr in the tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't have mice that can do report rates per resolutions, so let's not
commit to that.
This is a DBus API break but also a break in ratbagd, piper will need to
update to fetch the rate/rates from the profile object now.
It's a ratbagctl break as well, ratbagctl info changes slightly and the
resolution is not argument anymore for the rate.
Fixes#645
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since 2607114709 we returned the second parser
to handle everything after the device argument. That parser didn't have the
various options we handled in the original one, causing --keepalive to stop
working. Restore this by passing the existing namespace down to the parser.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a fixed (uu) with an extra capability flag, let's just make this a
variant defined to be a u or a (uu), depending on whether we have a single or
a separate resolution.
In the ratbagd.py bindings we return a tuple for both, but a simple len()
check will tell us which one it is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the specific name isn't the list (e.g. howling-woodrat) do a basic string
search on all the device names. For the normal case where users have only one
or maybe two devices and they have unique model names, they can do
ratbagctl "Logitech G303" info
Which is something we can easily support forever as sensible API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This seems like a convenience thing, possibly dating back to when we thought
ratbagctl will be the primary libratbag interaction. Either way, for the
limited number of commands we have here it's better to be very strict in what
we accept to avoid accidental typos making it into the API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ratbagd uses GObjects and properties so we also make use of notify() a
fair bit. Make sure we don't crash out in ratbagc for that, just add an empty
noop function named notify()
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Take the first 4 bytes of the device id (a sha), parse them as two 2-byte hex
values and mod them by the length of a pre-determined array of rodents and
their vocalisation methods. This gives us an index and a device name
assignement like this:
wailing-squirrel: Logitech G500s Laser Gaming Mouse
warbling-groundhog: Logitech MX Anywhere 2S
humming-hutia: Logitech Gaming Mouse G303
This relies on the sha's first 4 bytes to be unique enough that they don't add
up to the same 2 values. Which is probably safe enough.
This does not affect ratbag-command which still uses the hidraw nodes
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Device is an object on DBus, there is no need for another opaque ID, we
can just emulate this in the client. In our case by using the object
path and generating a sha1 from it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having the device node last makes it easy for us to test the same line
on various devices. That is not the most common use-case - normally we'd
expect our users to have one mouse and run several commands on it
(that's the case during debugging as well).
So let's change the device node to be the first argument, it makes for
easier typing/copy-paste, etc.
Plus it makes it a lot more obvious which one the full command is
(`dpi set 800` in this example)
```
$ ratbagctl hidraw4 dpi set 800
```
Fixes: #635
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
