Too easy to trigger ("ratbagctl.devel profile" is just enough), so we
probably better have a proper usage call here.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
.parse did not consumed the input_string, it only appends the given
parsing to the parent. Rename the function and kill the debug output
in nested calls as this was misleading while re-reading the code.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The help option (or verbose FWIW) were not global which makes some random
behavior when using -h at different places for the input string.
Retrieve those options once and remove them from the list of things to
process.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
"sudo ./build/ratbagctl.devel profile 2 4" returns an exception with cmd
being unknown.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Keeps the ratbagd daemon running until a signal is received. This is helpful
for using an external client (like piper) to run against the ratbagd.devel
instance. And to make that even easier, print the RATBAGCTL_DEVEL environment
variable for use with ratbagd.py. In the future, this should probably be a
more generic name.
The integration is a bit odd because we need to add --keepalive to the actual
parser, but we recreate that on every parse() call. So we set a flag on the
parent object and check for that during parser creation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't automatically handle the help output - call print_help() on the parser
manually.
It's unclear why this doesn't just get called correctly, but at least this
fixes the immediate issue. The subcommand help is still pretty terrible
though.
https://github.com/libratbag/libratbag/issues/288
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We do not really care using the actual ratbagctl command, we just want
to run it. So we can simply call out the python functions directly
and live happily ever after.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We want to share as much as possible between ratbagctl.devel and
ratbagctl.test, so better have a separate file that knows how to
properly spawn the dbus daemon and terminate it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
On CircleCI, the builds fail one over four times because we are launching
the testsuite while ratbagd.devel is still not ready.
Do a basic polling after we launch the daemon so that we are aware when
the ratbagd daemon is ready.
A proper solution would be to use "new" for querying the proxy, not
"new_sync". However, this would require us to have a GTK mainloop
running, so it's a PITA.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
is it a hack or the correct way?
triggered by: sudo ./build/ratbagctl.devel led 0 set color ffffff
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
No need to have two copies here, simply have the dict and then flip it so it
works with the strings as keys too.
The slightly odd list comprehension is because we can't add to a dictionary
while iterating through it, so we need to get everything out first.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
few minor issues which were unseen because driver-test was missing to set
the special key mappings
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Assigning an action on a button has some side effects, and this is why we
do not have writable properties on those.
Mark the _set_dbus_property() as read only so we do not get a bunch of
PropertyReadOnly exceptions.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
ratbag-command uses parentheses, not chevrons, and it also reports
which profile is currently active.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We need to read the directory and the profiles only once.
Nothing tells us how many profiles are supported, so use the specifications
from Logitech website, and add a hwdb entry for those.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The usage help is wrong, it's not how it works.
It'll be too much pain to fix it the other way around, and I prefer
using "ratbag* profile N enable" than "ratbag* profile enable N".
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Now that we've moved all properties to read-write where required, unleash the
exception again - any UnknownProperty error is now a bug.
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>
set_cached_property merely updates the proxy's own copy, it doesn't do
anything to the remote. Manually call the DBus.Properties.Set interface
to do that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
