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>
Clients e.g. ratbagctl ask for all properties, so this getter gets
called often even if the button is not a special action.
We do not want to send the value for an invalid special action as
that is negative 1. Converting to unknown is good enough here so
let's just remove the error logging and convert in silence.
Before we send something as "u" down DBus, check that it's not -1, a commonly
used error code in libratbag. If so, return a dbus error instead and log where
this occured so we can fix it.
This should at least help spot these errors quickly while at the same time
hopefully not crashing piper anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allows systems that provide libelogind (which provides a portion of
libsystemd that libratbag uses) to also compile without having to patch
out the rest of the build to remove the full systemd dependency.
This commit:
- Adds a systemd swith on meson_options.txt, a boolean set to true as
default to keep expected behaivour
- Adds a check on meson.build for the systemd switch and adds
dep_systemd
- Guards sections meant to generate systemd service units under the
systemd switch
Some devices like the logitech G9 have a button in its profile
data which is not a real physical button. This breaks the direct
mapping from button number to profile number.
This patch reduces this case from an error to a warning
After some "user testing" (having a friend try it), I've put the side
view back in. This has the benefit of keeping all buttons visible
without overlap, which would be necessary for
https://github.com/libratbag/piper/issues/71.
A driver for the logitech G600. The behavior is similar to the
G300 but with enough differences that it seemed cleaner to implement
as a separate driver.
../src/liblur.c:46:3: warning: 'd' may be used uninitialized in this function [-Wmaybe-uninitialized]
hidpp10_device_destroy(*hidpp10_device);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/liblur.c:198:59: note: 'd' was declared here
_cleanup_hidpp10_device_destroy_ struct hidpp10_device *d;
And similar messages
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was nasty. We correctly set the number of buttons but rely later
on the field set in drv_data.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Given that there is a sanity check on the available resolution, we
need to provide default values. There might be a way to fetch the
actual values from the hardware but at least provide some sort of
default that re-enables the hardwares.
Fixes bacdab2596
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
