This allows clients to respond to changes in the default resolution. It's
not the cleanest approach, but it works. To clean it up, we could cache
the changed resolutions and make sure to only emit the signal on those,
just as the FIXME already notes.
References https://github.com/libratbag/piper/pull/36.
This allows clients to respond to changes in the active resolution. It's
not the cleanest approach, but it works. To clean it up, we could cache
the changed resolutions and make sure to only emit the signal on those,
just as the FIXME already notes.
References https://github.com/libratbag/piper/pull/132.
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>
This also drops the separate x/y properties and instead just returns a tuple
for "Resolution".
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is superfluous, it's trivial enough to get the Resolutions property and then
work with that. We're not talking about a huge amount of data anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is superfluous, it's trivial enough to get the Profiles property and then
work with that. We're not talking about a huge amount of data anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a GetActiveProfile in the device, make this a property of the
profile. The SetActive method stays around, it's less prone to mis-use than
the property since we cannot allow a caller to go "profile.is_active = False"
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>
Was using 'b0' as enumerator, copy-paste error from the button code. Switch to
'l0' to make it easier to differentiate in d-feet or other dbus viewers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because if we can't strdup a device name or dbus path, we have problems we
can't recover from anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of copying them into our own struct, just query libratbag when we need
them. This brings the resolution code in line with the button and LED code
which don't do caching either.
Eventually we may want to cache them again to detect changes behind your
back (if libratbag value != our cached value) but for now this reduces the
work ratbagd does.
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>
* ratbagd: drop the ActiveResolutionChanged signal generation
Leave the signal in the DBus API for now so we can hook it up later, but
stop the signal being generated. Changing the dpi does not change the active
resolution.
https://github.com/libratbag/libratbag/issues/205
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* ratbagd: fix signal dbus interface name
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
