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>
We don't want anyone to rely on a specific content of the ID, e.g. by
hardcoding hidraw/event node numbers. So let's make this an opaque list with
no meaning other than "this is a rodent".
This is solely for the benefit of ratbagctl which uses these IDs as access
identifier.
This doesn't affect ratbag-command which still uses device paths. It also does
not affect the object path. And piper shows the device name anyway.
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>
Schedule the actual operation as a callback to handle at the end of the event
loop and return success. The Resync signal will handle the rest.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ratbagd is not something that needs stay around forever just because we
configured a mouse once. We have DBus activation and we don't store anything
anyway, so we might as well exit after a period of inactivity (20 min).
There's a slight race condition where if something comes in at exactly the
20min mark, we may shut down anyway and the messages get lost. This is too
narrow to worry about.
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>
Make sure we log an error if any of these fail, because most really never
should, they're scaffolding we rely on to send the data. Some of these calls
(the *_read() ones) could fail if a client sends wrong data, but we might as
well log that.
This patch only wraps calls that reply on the bus, normal sd_bus_* calls that
we catch the error ourselves are handled as before.
Likewise, any errors from libratbag are left as-is. We somewhat rely on
libratbag to log something and such errors are not a failure of the actual
scaffolding.
This should make errors like https://github.com/libratbag/piper/issues/237
easier to debug.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It always bothered me that it was in the middle of the normal ratbagd, which
made fiding it more effort than neccessary. Split it out into a separate file
so it's easily identifiable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This SVG is generic enough to cover 7-button mice with up to 3 LEDs that are
supported but don't have an SVG. The SVG style is intentionally NOT a generic
mouse to make it obvious that something isn't right here. If we use a generic
mouse, people may not put the effort into a proper SVG style because the
generic mouse is good enough.
The fallback is currently only used for test devices
Some devices can have a custom name, so let's export that capability.
In ratbagd, libratbag/ratbag_profile_set_name() returns an error, we
put it under silence, the client has to check for the capabilities
before asking ratbagd to change the profile name.
Fixes: #266
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This code isn't actually hit because we don't handle signals correctly, but
once we do, ratbagd_free() will assert because the devices never get removed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our device list is so small that having separate signals is a bit pointless,
updating the property should be sufficient.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have DeviceAdded and DeviceRemoved signals but given the expected number
of devices (less than 2 in most cases) it's easier to just update the Devices
property. The DeviceAdded/Removed signals stick around for now, they will be
removed later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure we keep the defaults as such by duplicating them in
driver-test.c (and mark the input data as const).
Add a dbus method to reset the test device from the caller.
This is much useful when running tests given we have no guarantees on the
ordering.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
In case the udev property is not present, we might want to query
the driver for the SVG name.
This is useful for driver-test as there is no udev device attached to
it, and for hidpp20 as we have auto-detection. We should then be able
to implement this in hidpp20 also so that the name gets automatically
created.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Two new DBus interfaces:
org.freedesktop.ratbagd1.Manager.Themes -> string array
org.freedesktop.ratbagd1.Device.GetSvg('theme') -> string
The Themes property is a static list of available themes. These are currently
hardcoded in ratbagd, but the theme 'default' is guaranteed to exist.
The GetSvg() method takes a theme name and returns the full file path to the
themed SVG.
Longer-term this will deprecate the Svg and SvgPath properties in the Device
but for now we leave them there.
https://github.com/libratbag/libratbag/issues/204
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When developing with ratbagd, we need to test against master, not
the system-wide installed daemon.
Allow to name space ratbagd with the creation of a new (not installed)
rabtagd.devel daemon, that is tagged with the git sha of the ratbagd
folder.
Handle this namespace in ratbagctl by looking at an environment variable
RATBAGCTL_DEVEL.
Then provide a python script that launches both rabtagd.devel and
ratbagctl with the correct environment variable set so that they can
talk to each other.
Note that we blindly overwrite the dbus .conf file as nobody else than
developers should have one.
Note: the tagging of ratbagd.devel (like the meson bit) won't run unless
a rebuild is triggered. So we don't necessarily always get the right git
tag. However, touching ratbagctl.in triggers a rebuild, so we should be
OK-ish.
Fixes#206
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
