Implements feature to disable resolutions from a static resolution list.
Updates DBus API and tests accordingly.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
When a boolean property is optional, the default None value and the False
value both represent a boolean false. So let's rename the property so that the
boolean values cannot be confused, because None and (Disabled == false) have
the same meaning (profile is enabled).
This is an API break.
Fixes#756
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the API version mismatches we want to fail early before performing
any more complex initialisation. We do however have to check for
devices first so that we can distinguish cases where we cannot access
the daemon from those where it is too old to provide an API version.
If access failed, e.g. due to insufficient permissions, don't confuse
the user by reporting an API mismatch.
This is a minimal improvement to target issue #802. As, if access is
restricted to a group, that group is known in Meson, it would even be
possible to report that group in the error message. But, that would
require converting ratbagd.py to a template or finding some other way to
inject that information at build time.
Bumped copyright to 2019.
Fixed typo in profile.capabilities description.
only ratbagd.py: Removed vim helper line since the file has a proper file extension.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
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>
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>
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>
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>
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>
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>
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>
When the SVGs need to be maintained elsewhere, we need something reliable to
match devices with SVGs. The easiest is to provide a unique model string,
usually composed from the usb/bluetooth information.
A string format was chosen to make it more flexible for the glorious future
where we have something other than usb or bluetooth devices. Meanwhile, the
format is the well-known "usb:1234:56ef:0" string (bus, vid, pid, version).
The version in this string is a future-proof safeguard for libratbag. It will
be used where libratbag supports two devices with the same VID/PID and where
this is not otherwise differentiable. We don't have any such devices yet, so
libratbag just returns a hardcoded 0.
The format is currently defined for usb and bluetooth, in the future we may
have other strings.
The base guarantee is that this is a reliable identifier for the model that
will never change for that model. IOW this is what piper can use to map
devices to their SVGs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The led type was the physical led type to describe where the LED sits.
This property is basically unused and of questionable use anyway. GUI
applications would need to rely on drawings of the mouse anyway. Scripts don't
really care because ratbagctl uses the led index anyway. The only time this
matters is when we're looking at (human) device discovery. But even then just
trying to set the LED is enough to figure out which one is which.
So let's drop this API on the assumption that it's not really needed and
maintaining and extending that enum forever is not necessary.
This is not a full purge, merely the DBus API that gets dropped.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The button type was the physical button type, not the logically assigned
button number.
This property is basically unused and of questionable use anyway. GUI
applications would need to rely on drawings of the mouse anyway. Scripts don't
really care because ratbagctl uses the button index anyway. The only time this
matters is when we're looking at (human) device discovery. But often clicking
around is enough to figure out the index.
So let's drop this API on the assumption that it's not really needed and
maintaining and extending that enum forever is not necessary.
This is not a full purge, merely the DBus API that gets dropped.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
