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>
This isn't used by anything in the tree and Piper doesn't use it either.
(`ratbagctl` queries it from the sodipodi name in the SVG).
Plus, assuming we run sandboxed the filename is useless anyway, `GetSvgFd()`
takes care of this bit though.
So let's drop this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
toolbox.py:86: DeprecationWarning: time.clock has been deprecated in Python
3.3 and will be removed from Python 3.8: use time.perf_counter or
time.process_time instead
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* tools: canonicalize path first in udev_device_from_path
This fixes a problem in which running ratbag-command with the path to a
device node symlink (e.g. /dev/logi-g502 -> /dev/input/event4), such as
one created by a udev rule, would not work correctly, due to the code
failing to resolve the symlink prior to checking for the presence of the
"/dev/input/event" prefix.
This resulted in nonsensical error messages (shown below) and the
curious inability to run ratbag-command successfully with anything but
the actual raw path to the device node itself (e.g. /dev/input/event4
would work fine, but /dev/logi-g502 would not, despite both being valid
ways of getting to the same device node).
Error: Can't open '/dev/logi-g502': Success
Error: Device '/dev/logi-g502' is not supported
Note that this same problem also prevented the usage of autogenerated
symlinks by udev, i.e. '/dev/input/by-id/' and '/dev/input/by-path/'.
* Update tools/shared.c
Co-Authored-By: jgottula <justin@jgottula.com>
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>
ratbagctl requires 'eventX' as argument, but ratbag-command requires
/dev/input/eventX. That's not smart, let's do better.
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>
Without --verbose ratbagd just starts up with no message whatsoever. It's hard
to tell if any devices are supported or if the server just hangs. Let's log
the devices detected by default, at least that way we get some feedback.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In some cases we get Piper trying to use None as a list, see
https://github.com/libratbag/piper/issues/237
This can be reproduced by returning an error (e.g. -ENOMEM) from
ratbagd_get_devices(). That error isn't handled anywhere on the client side,
the effective result is that the property is None when calling
proxy.get_cached_property().
The error is visible on the bus:
method call time=1535084121.223284 sender=:1.1311 -> destination=:1.1310
serial=7 path=/org/freedesktop/ratbag1;
interface=org.freedesktop.DBus.Properties; member=GetAll
string "org.freedesktop.ratbag1.Manager"
error time=1535084121.223433 sender=:1.1310 -> destination=:1.1311
error_name=org.freedesktop.DBus.Error.NoMemory reply_serial=7
string "Cannot allocate memory"
Make ratbagd.py more robust here and always return an empty list for those
properties where we expect an array. This papers over the real bug which is
that a) we need better logging in ratbagd on errors and b) something on the
other side needs to handle this error.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
https://bugs.llvm.org/show_bug.cgi?id=3888
clang analyzer doesn't know how to handle __attribute__(cleanup()).
There are only 2 warnings raised because the analyzer only look at the
current compilation unit for checking the malloc call. So only those
2 are detected by clang and then marked as memory leak.
This also means our current continuous integration doesn't check for
memory leaks.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
$> 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>
This one gets a little bit meesy given that the libratbag expects a
C array. Provide some wrapping aound it and hope we won't have to
do it again and again.
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>
