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>
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>
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>
Make this implict - if the profile has a name, it's writable. Otherwise it's
not and you'll have to rely on the index or make up your own naming.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the have all moved or been removed, there is no need to keep this
API.
This is a DBus API break, the Capabilities property disappears.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is arguably a profile-specific thing since the device itself is static
(we still know button numbers, etc.), we just don't know the content of each
profile.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have a profiles/resolution/button/led, we can write to it. That is the
default assumption and where we don't have write-access to those, we should
simply not expose them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have more than one profile, we can switch between them. Because
otherwise having more than one profile is just showing off and we don't like
that type of behaviour, no no.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This capability is superfluous. If we have more than one resolution, we can
switch between them because ... well, why have more than one then?
Signed-off-by:Peter Hutterer <peter.hutterer@who-t.net>
This is a profile-specific capability, not a device-specific one so let's move
it there.
Arguably, the DBus API should not expose SetEnabled() where not available, but
that's a separate issue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Theoretical case is where some profiles cannot be set to be the default, but
realistically: this is a profile-specific attribute so let's move the flag
there.
Arguably, the DBus API should not expose SetDefault() where not available, but
that's a separate issue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We started with event nodes for some reason lost in the distant past (probably
because that's what a lot of other tools use). But since we exclusively deal
with hidraw devices here and event nodes only serve to look up the hidraw
node, let's get rid of that indirection layer and work with hidraw directly.
Note that changes how ratbagctl works, it used the event nodes before. So
anyone who hardcoded the event node in one way or another is going to see
breakage. Then again, the "eventX" string was the device ID as advertised by
ratbagd, so it's supposed to be treated as an opaque string anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Strings on DBus need to be valid UTF8, some of the default profile names on
the G700 include the degree character (" Profile n° 1"), the whole string ends
up being invalid UTF8.
This results in two issues:
- ratbagd gets quietly kicked off the bus when it sends that string
- ratbag-command throws an exception because Python is unhappy about the
non-UTF8 string:
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcb0' in position 3: surrogates not allowed
The quick workaround here is to strip anything that's not ASCII from the
profile name. The same may be necessary for some device names too, but let's
wait until we see that.
For ratbag-command we convert the string to bytes and back using the 'ignore'
argument, this way we should see the original profile string without the
printf errors.
This is an incomplete fix, we'll have the same issue if a user tries to set a
non-ASCII name. The long-term fix is to convert whatever we have (probably ISO
8859-1, but can we detect that?) into UTF8 before passing it around. That
would also mean converting it back before writing to the device.
Fixes#617
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ratbagd now implements commit as normal always-successful call with a
potential Resync signal later if something failed on the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ratbag-command has an 'except RatbagdDBusUnavailable' line despite that class
never being defined. That's ok because we'll never throw it in this case but
it's still confusing (to flake8). So let's change the class name to something
more generic and define it in ratbagc.py
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we're sandboxing the client we don't have access to the SVG files directly.
So pass a read-only file descriptor to the client over DBus and let them deal
with the SVG that way.
In ratbagd.py we pull the fd off but we convert the quirky dbus error into a
normal FileNotFoundError(), much easier to catch in the caller.
On the ratbagctl side we now have to search the SVG for it's name - stored in
the 'sodipodi:docname' attribute by Inkspace. This isn't guaranteed to exist
or be always correct, but meh, it's close enough. We could continue to use the
GetSvg() call here but I want to deprecate that and remove it in the near
future.
Fixes#521
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
$> flake8-3 tools/ratbagctl.devel.in tools/ratbagctl.in tools/ratbagctl.test.in .
tools/ratbagctl.in:166:1: E302 expected 2 blank lines, found 1
tools/ratbagctl.in:173:25: E201 whitespace after '['
tools/ratbagctl.in:173:68: E202 whitespace before ']'
tools/ratbagctl.in:314:1: E302 expected 2 blank lines, found 1
tools/ratbagctl.in:318:1: E302 expected 2 blank lines, found 1
tools/ratbagctl.test.in:281:43: E261 at least two spaces before inline comment
tools/ratbagctl.test.in:302:31: E261 at least two spaces before inline comment
tools/ratbagctl.test.in:306:43: E261 at least two spaces before inline comment
tools/ratbagctl.test.in:337:43: E261 at least two spaces before inline comment
tools/ratbagctl.test.in:576:1: E302 expected 2 blank lines, found 1
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We do not need to parse all the devices, but only the one given in the
command line. Make ratbagc.py handle this case properly.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
To be able to query which modes are available.
Exposed via ratbagctl as
./build/ratbagctl.devel led 0 capabilities event4
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tools/ratbagctl.in:146:92: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:147:92: E126 continuation line over-indented for hanging indent
tools/ratbagctl.in:154:91: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:155:91: E126 continuation line over-indented for hanging indent
tools/ratbagctl.in:161:118: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:162:118: E126 continuation line over-indented for hanging indent
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
A driver is supposed to know what type an LED is, unknown doesn't help anyone
here. So replace this with a private #define and abort when a driver doesn't
set the type. This also adds a requirement that any driver initializing a LED
must have the read_led() function, otherwise we can't fill it in correctly.
And bump the enum up by one, the first valid value should start at 1 (or some
other non-boolean value).
Related #365Fixes#364
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
1-bit RGB is needed for the Logitech G300, let's rename the main RGB to
indicate how many bits we actually have.
See #335
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The initial value of 400 in the enum is chosen so it looks weird when someone
tries to interpret the value as integer. Values of 1, 2, 4, etc. could be
confused with something realistic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the other commands try to access a node, there will be an other error
("Unable to find device X"). So there is no points in having this as a
global check.
For the .devel and .test versions, we are guaranteed to have the
test_device at least, so no worries on this side too.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Plan is to remove the key mapping altogether and make it transparent from the
Macro mappings (in libratbag/the drivers). Meanwhile, remove the DBus API so
nothing can actually start using it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
