This code assumes that there is a python3 or python3-embed pkg-config
file on the system, which may or may not be true. On Gentoo for example,
only python-X.Y pkg-config files are available and this will fail to
build.
This makes use of the new py_installation.dependency(embed : true) if
possible, and falls back to trying to find a python that matches the
version of python found by the python3 or python module.
libratbag has a quite communication-intensive setup routine. This patch
uses short reports when possible. Using short reports will speed up the
setup process and have a lower power consumption, which is relevant for
wireless devices.
We now check the report descriptor for the supported report IDs and
adjust the report type used based on the device capabilities. Because of
that, this patch should work without any issues as the report type will
get overwritten if it not supported.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
New devices define a profile field in the button configuration. This
allows us to map a button to set the target profile as active. Even
though we don't support configuring this right now, some devices, such
as the G915/G815, come pre-configured with this action on th M-Keys.
This patch makes us able to read and write those settings, this way they
don't get lost when we write a profile to the device.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
gcc 10 complains about multiple definitions of these when linking.
/usr/bin/ld: libhidpp.a(src_hidpp-generic.c.o):/builddir/build/BUILD/libratbag-0.12/x86_64-redhat-linux-gnu/../src/libratbag-private.h:588:
multiple definition of `etekcity_driver';
libutil.a(src_libratbag-util.c.o):/builddir/build/BUILD/libratbag-0.12/x86_64-redhat-linux-gnu/../src/libratbag-private.h:588:
first defined here
Special case here is the test_driver struct, without the extern gcc seems to
think it's a new struct with all zeros, causing a segfault when we then try to
strcmp the test driver name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Removes useless setting of the dpi index when updating resolutions.
Removes weird empty line.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
Use separate variable lists for dependencies.
Uninstall check merged in upstream meson, so it can be simplified.
`libsolv` doesn't need to be updated any more with Fedora 31.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
When the API version mismatches we want to fail early before performing
any more complex initialisation. We do however have to check for
devices first so that we can distinguish cases where we cannot access
the daemon from those where it is too old to provide an API version.
If access failed, e.g. due to insufficient permissions, don't confuse
the user by reporting an API mismatch.
This is a minimal improvement to target issue #802. As, if access is
restricted to a group, that group is known in Meson, it would even be
possible to report that group in the error message. But, that would
require converting ratbagd.py to a template or finding some other way to
inject that information at build time.
- File "./build/ratbag-command", line 2289, in open_ratbagd
r = Ratbagd(1)
TypeError: __init__() takes 1 positional argument but 2 were given
- AttributeError: module 'libratbag' has no attribute
'ratbag_device_get_bus'
- File "./build/ratbag-command", line 267, in model
return "{}:{04x}:{04x}:{d}".format(bus, vid, pid, version)
KeyError: '04x'
- swig/python detected a memory leak of type 'uint32_t *', no destructor
found.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This patch moves the 0x8100 initialization routine out of
hidpp20drv_init_feature because it needs the capabilities to be
processed first.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Bumped copyright to 2019.
Fixed typo in profile.capabilities description.
only ratbagd.py: Removed vim helper line since the file has a proper file extension.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
These are two fields of a union and should have the same value. What the
code doing here is trying to free a pointer twice.
Signed-off-by: Qiu Wenbo <qiuwenbo@phytium.com.cn>
Rename fedora_latest to fedora_31 which is more representative.
Drop the Fedora Rawhide workflow which was always disabled anyway.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
We don't want any device files that use the receiver itself as a match so
let's test for that. In virtually all cases this means the user must update
the kernel and hope support for that receiver is already present in that
version.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was copied from libinput and made sense while libratbag was a library -
we want "unhandled" messages to end up somewhere and stderr is the most likely
candidate here.
Now that we always run within ratbagd and it's all effectively inseperable,
just log to stdout for anything below error.
The switch statement was reformatted for consistency, only the ERROR case has
changed code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When no device is present, starting ratbagd even with --verbose prints exactly
nothing. Let's be more verbose here to give the user an indication that
something's happening. The user wants everything, is probably willing to
accept anything but in the end all we can say is that we have nothing.
Related to #862
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Renamed filenames to avoid brackets, and added a check to data-parse-test.py to
check for brackets, parentheses, and braces so they aren't shipped in filenames
in the future.
When the windows driver puts a device in host mode it will mark all 8100
profiles as disabled. If no 8100 profile is enabled no libratbag profile
will get enabled. This patch prevents this by marking the first profile
as enabled if no profile is already enabled.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
TBH I don't know why I wrote the original code in the first place, it
clearly doesn't follow the spec.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Right now we initialize any hidpp10 device with one profile and then go and
fetch the data. But we never check for return codes, so it always succeeds
even when we can't get anything out of the device at all. Eventually we fail
the sanity checks with "invalid dpi list" which is confusing at best.
Let's avoid this by requiring at least the current profile to work. This will
break devices that have a single emulated profile, i.e. those that don't have
profiles but rely on libratbag to emulate one based on the
current-resolution/current-... calls. Not sure we actually support any of
those, so let's see.
Closes#738 though it doesn't fix it, it just bails out better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is confusing because we do have a test driver and we have an optional
test_device argument here too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than bail out completely, let's pretend the factory profile is profile
0 and keep going. This gives us a pretend-function mouse, though whether this
actually works is questionable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
CircleCI 2.0 requires a new config file location, otherwise it won't run. And
since 1.0 is sunset now, this means our CI wasn't getting executed.
The actual format of the config is the same, we were already using 2.0
features.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The G700 and G700s both use the receiver's product id, so they both end up
having the same DeviceMatch. One of those two never gets loaded but which one
is implementation-defined and may change accidentally.
Let's drop the G700s entry because the G700 is closer to a lowest comon
denominator. Once we have kernel support for the actual product id, we can
re-instante them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While the DBus API is still in flux, things can break at any time.
Keeping piper and libratbag in version-step works terribly, doubly so where
piper is flatpaked but ratbagd comes from some repo somewhere. We can't check
at build-time, we can't run ratbagd --version at runtime.
so let's add a version field for now and drop it if we ever get to stable.
Meanwhile, ratbagd.py will throw an exception if the expected version doesn't
match exactly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Force the tests to load a test device with JSON that matches their
expectations instead of having a magic device pre-setup where the tests have
to know what the values are.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
sd-bus encodes underscores as _5f which looks like memory corruption. Let's
skip them, they don't add value anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When building with --buildtype=plain, the build fails with the following
error:
cc1: error: ‘-Wformat-security’ ignored without ‘-Wformat’ [-Werror=format-security]
-Werror=format-security was recently added in 43def1b3a5 by #745
The sequence triggered by the ratbagctl.test suite is:
- DBus call Commit()
- ratbagd schedules the callback as idle func
- DBus call ResetTestDevice()
- ratbagd cleans up the test device
- callback is called on next idle
- boom! the device is already freed
To avoid this, we need to take a ref of the device while it's being scheduled
for the commit handling. But that blocks the object paths for new test devices
because the test device name is encoded in those paths (like "hidraw" for real
devices) and it doesn't change. So let's add a count to the test device name
to make sure the new device doesn't re-use the old device's paths.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Otherwise where the directory is used within meson.build, the prefix would be
missing. No real effect since we don't use it anywhere but let's be safe.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't rely on some other tool to install the policy file, let's just do this
in ratbagd.devel directly so it's immediately executable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Which is the same env that ratbagd uses as well. And we don't have variable
values in RATBAGCTL_DEVEL anymore, so no point in having two different
variables here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it possible to run the script against a manually started
ratbagd.devel - with a lot less effort.
And since we're don't need to be root to do this, let's move that check too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it a lot easier to start ratbagd.devel in gdb, then run
ratbagctl.devel against it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have a separate name for the devel bus anyway, the git sha doesn't
give us a huge amount of benefits but makes manual debugging a major PITA.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When there's a bug that's triggered by the test suite it's hard to figure out
what exactly crashes. So allow starting ratbagd.devel manually and run the
test suite against that process so we can gdb it.
The steps required for this are a bit insane, so the instructions are listed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because our profile struct can never have an NULL name, let's assume the
empty string equals NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're initializing them with incrementing indices, let's make sure the list is
initialized that way too. Makes things more obvious in the log when the first
profile to be queried from the device isn't profile 4.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No real functional changes since they just forward to the existing function.
But it reduces the cognitive load a bit when reading the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a leftover from libratbag-as-a-library and obsolete now that ratbagd
is our only product. Our buildtest now is simply: "does ratbagd build?" and we
certainly shouldn't require a C++ compiler.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Python 3.8 no longer links to libpython, resulting in undefined references to
Python API.
But it provides a python3-embed.pc now, so let's try using that first and only
fall back on the normal case if that fails.
See https://github.com/mesonbuild/meson/issues/5629
currently if any use profile is not valid we fallback to the firmware
profiles. this is quite annoying because the user might have only one
valid profile. this patch will keep valid profiles and only fallback to
firmware profiles on a profile by profile basis.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
when we read the memory from the device we already align the offset so
that it matches the end of the sector. for ex, for a 255 sector size the
offset will be set to 255-16.
when we copy the memory (using memcpy) we just copy the bytes that will
finish filling the buffer, ignoring that the offset was aligned. we need
to copy the full 16 bytes, otherwise it will fail when sector_size does
not align with 16.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
hidpp10_read_memory will return the HID++ error if the request fails.
right now, the error code from hidpp10_read_memory is transparently
passed through hidpp10_onboard_profiles_read_macro. This is problematic
because hidpp10_onboard_profiles_parse_macro only aborts on rc < 0 and
HID++ error are > 0.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
My MX Anywhere 2 has a different PID from the one supplied in the default .device file. This adds the PID to the device file to ensure mice with this PID get detected too.
We don't ship SVGs here anymore, so let's remove that README. And instead add
one to the devices directory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
_cleanup_ is deallocating the pointer returned by
ratbag_device_data_steelseries_get_dpi_{range,list}(). Deallocating
dpi_list results in a wrong step value, and a wrong step value then
results in a wrong step count when we try to set the dpi.
Fixes#436 and #702
And install dbus-daemon manually, until we figure out how to correctly start
the new dbus-broker this will at least help us pass the tests.
And disable nss-systemd so we don't suffer from timeouts as dbus-daemon waits
for that to time out, see c425780220 for details.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is installed by software-properties-common, but since we don't
start our container with systemd, it effectively points to nowhere, adding
nothing but a delay of several minutes.
That delay affects dbus-daemon on startup and on configuration reload, it
takes several minutes to do either. ratbagctl.test installs a custom dbus
config file to be able to connect to ratbagd.devel, that config file triggers
a reload in the dbus-daemon. Since that reload takes longer than any of our
timeouts, the tests eventually fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At some point meson #defined NDEBUG depending on the build type, thus
disabling asserts. libratbag relies on those, so let's error out if NDEBUG is
defined.
Related #685
There is no guarantees the current value of dpi_index will be correct.
On my G502 the profiles are read in reverse order meaning that setting the
dpi_index can be applied to a wrong value.
Look for the correct libratbag dpi index before setting it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Where a profile name is not UTF8 compatible, let's try to convert it from
latin-1. If that fails, we just escape anything that's not ascii and move on.
Fixes#617
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For two dicts x and y the merged dict can be created as {**x, **y}. We use
that to take the enum names and covert them to lowercase with hyphens instead
of underscores.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rough update but headed in the right direction
* Simplified silhouette of bag
* Reduced number of rats inside the Rat Bag to two
* Eyes are still small and potentially still not printable at small scale
* Introduced rough stylized logotype based on Google's Sedgwick Ave Display font
* Reduced total file size by a heap
Instead of multiple entry points for different values, make the button mapping
a single entry point that takes the mapping type and a variant for the value.
The ratbagd.py bindings are basically left as-is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GObject silently catches exceptions and logs it to stderr without ever passing
on the exceptions. Avoid oversight by checking stderr in the tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No longer needed now that the ReportRate is in the profile
(bf127d4c68) and the separate
x/y resolution capability is implied by the Resolution value
(8e9dd6f392)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't have mice that can do report rates per resolutions, so let's not
commit to that.
This is a DBus API break but also a break in ratbagd, piper will need to
update to fetch the rate/rates from the profile object now.
It's a ratbagctl break as well, ratbagctl info changes slightly and the
resolution is not argument anymore for the rate.
Fixes#645
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since 2607114709 we returned the second parser
to handle everything after the device argument. That parser didn't have the
various options we handled in the original one, causing --keepalive to stop
working. Restore this by passing the existing namespace down to the parser.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a fixed (uu) with an extra capability flag, let's just make this a
variant defined to be a u or a (uu), depending on whether we have a single or
a separate resolution.
In the ratbagd.py bindings we return a tuple for both, but a simple len()
check will tell us which one it is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the specific name isn't the list (e.g. howling-woodrat) do a basic string
search on all the device names. For the normal case where users have only one
or maybe two devices and they have unique model names, they can do
ratbagctl "Logitech G303" info
Which is something we can easily support forever as sensible API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This seems like a convenience thing, possibly dating back to when we thought
ratbagctl will be the primary libratbag interaction. Either way, for the
limited number of commands we have here it's better to be very strict in what
we accept to avoid accidental typos making it into the API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ratbagd uses GObjects and properties so we also make use of notify() a
fair bit. Make sure we don't crash out in ratbagc for that, just add an empty
noop function named notify()
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Take the first 4 bytes of the device id (a sha), parse them as two 2-byte hex
values and mod them by the length of a pre-determined array of rodents and
their vocalisation methods. This gives us an index and a device name
assignement like this:
wailing-squirrel: Logitech G500s Laser Gaming Mouse
warbling-groundhog: Logitech MX Anywhere 2S
humming-hutia: Logitech Gaming Mouse G303
This relies on the sha's first 4 bytes to be unique enough that they don't add
up to the same 2 values. Which is probably safe enough.
This does not affect ratbag-command which still uses the hidraw nodes
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Device is an object on DBus, there is no need for another opaque ID, we
can just emulate this in the client. In our case by using the object
path and generating a sha1 from it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having the device node last makes it easy for us to test the same line
on various devices. That is not the most common use-case - normally we'd
expect our users to have one mouse and run several commands on it
(that's the case during debugging as well).
So let's change the device node to be the first argument, it makes for
easier typing/copy-paste, etc.
Plus it makes it a lot more obvious which one the full command is
(`dpi set 800` in this example)
```
$ ratbagctl hidraw4 dpi set 800
```
Fixes: #635
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
See the earlier commit "Drop the SVG handling from libratbag" for an
explanation, this commit merely removes the actual files from git.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
When the SVGs need to be maintained elsewhere, we need something reliable to
match devices with SVGs. The easiest is to provide a unique model string,
usually composed from the usb/bluetooth information.
A string format was chosen to make it more flexible for the glorious future
where we have something other than usb or bluetooth devices. Meanwhile, the
format is the well-known "usb:1234:56ef:0" string (bus, vid, pid, version).
The version in this string is a future-proof safeguard for libratbag. It will
be used where libratbag supports two devices with the same VID/PID and where
this is not otherwise differentiable. We don't have any such devices yet, so
libratbag just returns a hardcoded 0.
The format is currently defined for usb and bluetooth, in the future we may
have other strings.
The base guarantee is that this is a reliable identifier for the model that
will never change for that model. IOW this is what piper can use to map
devices to their SVGs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The led type was the physical led type to describe where the LED sits.
This property is basically unused and of questionable use anyway. GUI
applications would need to rely on drawings of the mouse anyway. Scripts don't
really care because ratbagctl uses the led index anyway. The only time this
matters is when we're looking at (human) device discovery. But even then just
trying to set the LED is enough to figure out which one is which.
So let's drop this API on the assumption that it's not really needed and
maintaining and extending that enum forever is not necessary.
This is not a full purge, merely the DBus API that gets dropped.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The button type was the physical button type, not the logically assigned
button number.
This property is basically unused and of questionable use anyway. GUI
applications would need to rely on drawings of the mouse anyway. Scripts don't
really care because ratbagctl uses the button index anyway. The only time this
matters is when we're looking at (human) device discovery. But often clicking
around is enough to figure out the index.
So let's drop this API on the assumption that it's not really needed and
maintaining and extending that enum forever is not necessary.
This is not a full purge, merely the DBus API that gets dropped.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make this implict - if the profile has a name, it's writable. Otherwise it's
not and you'll have to rely on the index or make up your own naming.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the have all moved or been removed, there is no need to keep this
API.
This is a DBus API break, the Capabilities property disappears.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is arguably a profile-specific thing since the device itself is static
(we still know button numbers, etc.), we just don't know the content of each
profile.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have a profiles/resolution/button/led, we can write to it. That is the
default assumption and where we don't have write-access to those, we should
simply not expose them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have more than one profile, we can switch between them. Because
otherwise having more than one profile is just showing off and we don't like
that type of behaviour, no no.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This capability is superfluous. If we have more than one resolution, we can
switch between them because ... well, why have more than one then?
Signed-off-by:Peter Hutterer <peter.hutterer@who-t.net>
This is a profile-specific capability, not a device-specific one so let's move
it there.
Arguably, the DBus API should not expose SetEnabled() where not available, but
that's a separate issue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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 still need to read the data of all other profiles. This broke in f26de4bb,
the previous loop only did the is-active modification
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>
Almost the same placement, but the horizontal line that github uses to render
headers doesn't get cut off anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
First time I viewed this was on mobile, and the logo left enough space for a
lonely "li" on the left, with the "bratbag" in the line below the logo. Let's
call that a design faux pas and make it small enough to scale.
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>
We don't install the default SVGs anymore and all the effort for new mice goes
into the gnome theme.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Coverity seems to think this can use uninitialized array elements but that can
only happen when hidpp10->dpi_count is 0. In which case the callee doesn't
touch it anyway but coverity doesn't care about that bit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Noteworthy: "Description" has been renamed to "Name" ages ago in ratbagd, this
just corrects the documentation.
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>
Scan-build is at the point where it gives us too many false positives to be
reliable and they're not easily fixable other than sprinkling
"ignore_clang_sa_mem_leak" comments all over the source.
This caused us to drop F29 from the CI earlier, see 1225f421c0, but
really we just shouldn't use something that's so unreliable as part of our CI.
The main issue continues to be the use of __attribute__((cleanup)) but others
give us false positives too.
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>
Use the default Python class, it's not perfect but still makes more sense than
the javascript class.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The SVG guidelines specify a minimal vertical distance of 40px. There
were two lines in the G Pro SVG that had less, leading to the buttons
overlapping. This is visible in #607.
The elements that were supposed to be in the Device layer were
accidentally placed in the Buttons layer, making Piper not render them
in the button page.
Fixes#607.
* data: added Logitech G603 svg
* data: added Logitech G603 svg
* data: added Logitech G603 svg
* data: updated Logitech G603 svg
I fixed an issue with the right and left click buttons missing and the middle button being on the incorrect layer. I also removed the logo on the mouse as I was having some issues in Inkscape due to my unfamiliarity with the software. I figured properly configured buttons is good enough for the time being.
This brings initial support for the Logitech G402, as discussed in #471.
I used the G502 svg and modified it, without changing the graphics. The two mice are aesthetically similar.
* Added G402 device file
* Added G402 svg file
* Add G402 files to build
[bentiss] squashed the 3 patches as one
As mentioned in the code:
We revert to HW control of the LEDs.
This effectively disable the capability of changing the DPI/profile
LEDs, but this allows to make them work with the internal DPI/profile
switches.
The net result is:
- DPI/profiles can't be controlled (but who wants this?)
- The logo can properly controlled
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Since a0830a8aaa, we can re-add the simple
keybindings capabilities. It's time the HID++ 2.0 devices get this.
This used to be working with the KEY API, but this has been dropped in
favor of the macro one.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
* 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>
A non-zero value for the remapped field means the button is mapped to that
button.
"diverted" means to decouple it from normal HID reports and report it via
HID++ only. In our case here, we "map" it, which is different.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Add HIDPP_PAGE_RESET, HIDPP_PAGE_DEVICE_NAME, and
HIDPP_PAGE_WIRELESS_DEVICE_STATUS. These feature names are found in the
"features.xml" of an LogiOptions installation. Probably not very useful
for now.
The MX Anywhere 2 mouse has a problematic special key (index=7). When
trying to get the reporting value of this key, the device returns an
"invalid argument" error. [1]
To avoid giving up all good information about other keys, ignore error
(and the cause) when enumerating special keys.
[1] https://github.com/libratbag/libratbag/issues/558#issuecomment-439732655
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>
A few of the device files didn't get installed, let's add them to the list.
This reshuffles the list a bit because the easiest way to make sure all files
are included is to run git ls-files, so let's stick to that.
Fixes#552
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This wasn't added to the meson.build file so the test didn't run on it. And
the test fails. Issues found include:
- DPIRange and DPIList must not be in the Device section
- Only one of those two, not both
- The svg file was in the 'default' theme rather than in gnome
This needs to be fixed first, not sure how this would've worked at all.
This reverts commit 2371960a1d.
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>
Turns out this driver never got updated for the 'new' DPI list provided by
libratbag and thus broke with bacdab2596 when we
enforced that DPI list.
Set a fixed DPI list based on the hardcoded values we use elsewhere in this
driver.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Notable: parts of the instructions have been punted to the wiki now where it's
faster to edit and be verbose about the specific instructions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This reverts commit 874d7eccb8.
Looks like 18.10 fails at every pipeline build, so better
punting this for later.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
I'm pretty sure all callers rely on this command to return either 0 or a
negative errno. There's a quirky occasion where if we get a HID error (a
positive number) during hidpp20_special_keys_buttons_get_reporting, that
number eventually ends up as the 'num_controls' value in
hidpp20_special_key_mouse_get_controls().
Since the only time we care about HID++ errors is during
hidpp20_root_get_protocol_version, let's just always return -EPROTO on HID++
errors.
Fixes#558
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
- New svg and device file. Updated meson.build.
- New device version (version 3).
- Refactored led cycle to be general for v2 and v3.
- New defines for v3.
Some change in F29 breaks the CI runs, so lets switch back to what we had
before so we can merge patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we can successfully read a profile but hidpp10_get_current_profile() fails
we end up with one profile, but not set to active. Fix this by always forcing
the single profile to be active.
Fixes#526
Taken from libinput, we need to define a few gcc7 types that coverity doesn't
know about. To submit a coverity build, run meson with -Dcoverity=true
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>
Open an extra hidraw to read current onboard settings.
Initially DPI and static LED color can be read from the rival
310. Other data/devices can be added as the protocol is better
understood.
The protocol used to extract the data seems to be both device
and firmware version specific. To be able to switch on both
cases we now store the firmware information in the drv_data.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
For some devices we have to send reports on one endpoint
but read the reply on another. This commit allows us to
open and store multiple hidraws and adds API to specify
which hidraw to use for open, close, and read input report.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
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>
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>
value and dpi are unsigned so the delta calculations was wrong when
dpi is larger than than value. Casting to int should be fine for the
expected range of values in those variables.
Adds a setting to specify the max length of key press macros that the
device supports.
Setting MacroLength to 1 means that the device supports normal key presses,
(key + modifiers) but not multi key press macros.
0 can be used to indicate that buttons cannot be set as keys at all.
Initial support for the original Rival mouse.
Setting resolutions, report rate and LED color and
modes.
No key mappings yet, and breathing duration is fixed.
The steelseries mice have 2 resolutions. The range/interval
is different per device. We cannot query the devices, so we
have to pick some defaults. Before we took the two first in
the list to be safe. It is a pretty bad default though. Using
800 and 1600 is supported by all known devices and seem as
more reasonable defaults.
The default button mapping the sensei 310 does not match
the table for the two known steelseries mice. The 6th button
is no longer resolution cycle, so the single table no longer
fits. Let's construct the table depending on the number of
buttons on the device.
This change makes it possible to pass '-Ddbus-group=<group>' to limit
the access to the ratbagd D-Bus service. The default remains to allow
everyone access to the service.
This allows integrators to choose more conservative security settings
e.g. only allowing users in the 'games' group to talk to the ratbagd
daemon.
To specify the colors to cycle trough we write a list of
colors and their individual share of the total cycle duration.
Solid colors only have a single color in their list.
Breathing mode will cycle to and from the picked color and black.
Cycle mode will cycle through red, green, and blue.
When using ratbagctl.devel we would use the .device files
from the source dir. This patch also makes it use the .svg
files from the source dir. This makes it easier to edit the
svg and less surprising now that it follows the .devices files.
To match the source file layout the .devices files are now
installed into a 'devices' subdirectory.
The steelseries driver used some hardcoded values for as the
only supported device was the rival 310. This moves that data
to the .device file.
The default resolutions used are changed from hardcoded 1000
and 2000, to the two first entries in the dpi list. Picking
actual values from the specified dpi list or range is safer.
Add a section in the .device files for SteelSeries mice.
The mice cannot be queried and we need to store data for each
device of number of buttons, leds, and dpi list/range. Lastly
a "device version" is added. The latest models use a slightly
different protocol, so we needed something to distinguish them
with.
Set the list of DPIs directly instead of use the _from_range call.
The G300 has few and coarse resolution options. Using the
exponential'ish range is not a good fit for devices with so
few dpis.
The logitech G300 can set:
250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500
but piper would offer:
250, 300, 350, 400, 450, 500, 550, 600, 650, 700, 750,
800, 850, 900, 950, 1000, 1100, 1200, 1300, 1400, 1500,
1600, 1700, 1800, 1900, 2000, 2100, 2200, 2300, 2400, 2500
We overpromise by offering more finegrainded options than the
mouse can do and end up with three times as many options than
we should.
No-one appears to be using these and the efforts to create SVGs
go into the GNOME ones (used by piper). Leave them in the git tree in case
someone wants to pick them up but until we have a consumer it's not worth it
installing them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libratbag@sha/libratbag.c: In function ‘_wrap_error__varargs__’:
libratbag@sha/libratbag.c:6392:3: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
error((char const *)arg1,arg2);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There is no point anymore to have an extra 'action' argument, and make
both type of function look the same.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
action->macro is supposed to be allocated once and stay for the
entire life of the button. However, it was outrageously overwritten
when setting the action. Take some actions and keep the macro action
around.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The driver does not yet support button mappings or any
non-solid LED modes.
The device does not support reading out the current
configuration. On probe some default values are used
to get a usable profile.
The bitmask in the 8060 report is for ms between reports. We could do all, but
really we only care about a few resolutions, anything else is too niche to
bother with.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least in the DBus API we can't just say "doesn't exist", so let's allow for
a zero-sized list.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
$> 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>
And use it to create ratabg-command.py
Benefits are that we bypass ratbagd, meaning we can attach gdb or run
valgrind on the tools themselves.
Problem is the python wrapper doesn't clean up after itself, and so
running valgrind is moot
Fixes#274
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
To be able to query which modes are available.
Exposed via ratbagctl as
./build/ratbagctl.devel led 0 capabilities event4
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We are reusing a lot the fedora container, but we need to always download
and install the same set of packages. Store them in the workspace to
speed up the tests.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Note that the push requires a specific private key in the libratbag
circle CI organization, meaning that only the master branch of libratbag
will be allowed to push to the doc repo.
Note also that only the master branch will trigger the request:
- any PR will not trigger the request
- any push on the master branch of a personal repo will fail while
attempting to write the docs, if the repo is setup to use circleCI too.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If our device only has a discrete number of DPIs, pass it on as-is to
libratbag rather than pretending it's a range and then failing to set the
DPIs.
For the actual ranged devices we use libratbag's now-exponential range
mapping rather than passing all possible ones on. This relies on us having the
same steps that libratbag uses, should be safe enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we could get a min/max value but there was no guarantee that it
any value in between would actually work on the device. Some devices have a
discrete number of resolutions (e.g. 500, 1000, 2000, 2500), most others have
at least a minimum step size (so 1234 isn't a valid dpi value).
Change the min/max to a discrete list of which resolutions are supported. This
allows a UI to adjust its interface dynamically - e.g. a combobox if there are
only 3 resolutions or a slider if there are a million of them.
This is a DBus API break
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Better than the markdown we were using before, even though we're currently
(ab)using the js/c++ domains for the structure. There is no DBus domain in
sphinx yet.
The main motivation was to get the enums into the documentation since they are
exported ABI.
Generating the documentation is quirky - we use doxygen to extract the
comments from the C header file and then use XSLT to convert to .rst which
sphinx can use. Still better than having to maintain even more copies of the
enums.
Since this is only of interest for maintainers that need to upload the
documentation, it is turned off by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libratbag is not a library anymore. Move all the stuff that we need for the
DBus interface (i.e. the enum values) into its own header file so they're
all in one place and we don't have to worry about it anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, probe() would call ratbag_init_profiles() which in turn would call
the various function pointers in the driver to fill in profiles, buttons and
leds (the latter while filling in profiles). This made the probe() function
harder to understand than necessary and unreliable because it wasn't always
clear which bits were already set up while some driver function was called and
which ones weren't yet.
This patch switches to a flat probe(). The driver still needs to call
ratbag_init_profiles(), libratbag sets up everything (to default values). Then
the driver can fill in the rest as it wants.
This patch still makes use of the current infrastructure, the drivers
just call the read_profile and read_button functions manually now.
Fixes#370
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Resolutions were still stored in an array over a linked list like the
buttons/leds/profiles and initializing them from a driver was different than
buttons or leds. This brings the resolutions in line with the buttons and
leds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We can't guarantee it's a sysname even though that is what we use for evdev
devices. Future devices may just be some custom-assigned name for a remote
dbus API
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least on HID++ 2.0, the LED types appear to be random and don't match the
protocol specs. Other protocols don't even have those bits, so let's make this
a generic entry.
This is pre-filled for all LEDs but drivers can override it where required.
Fixes#377
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tools/ratbagctl.in:146:92: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:147:92: E126 continuation line over-indented for hanging indent
tools/ratbagctl.in:154:91: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:155:91: E126 continuation line over-indented for hanging indent
tools/ratbagctl.in:161:118: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:162:118: E126 continuation line over-indented for hanging indent
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
A driver is supposed to know what type an LED is, unknown doesn't help anyone
here. So replace this with a private #define and abort when a driver doesn't
set the type. This also adds a requirement that any driver initializing a LED
must have the read_led() function, otherwise we can't fill it in correctly.
And bump the enum up by one, the first valid value should start at 1 (or some
other non-boolean value).
Related #365Fixes#364
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If HIDPP_PAGE_COLOR_LED_EFFECTS fails but the profile returns a nonzero LED
count we crash later in hidpp20drv_read_led() because all the led info is
null.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
struct hidpp20_led_sw_ctrl_led_info holds a u8 for the .type field.
Attempting to convert a value which is already a u8 ends up setting
0 and thus discarding the type information.
Fix by removing the extra step.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
With the swtich to the commit style the function
hidpp10drv_write_resolution_dpi is doing too much work.
Before commit style the function would:
* get the profile
* get the current resolution
* write the profile (resets it to default dpi)
* set the current (updated) resolution
With the commit style we call the function for every resolution
in every dirty profile we now:
* get the current resolution
* set the current (updated) resolution
Then later:
* write the profile (resets to default dpi)
This patch changes this to only doing one set of the current resolution
when the active profile has been written. This reduces the traffic to the
device and sets the current resolution after the profile write.
It's a fixed value so it's much easier to set this in the test binaries rather
than requiring the user to set this in the env before running a test manually.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For the device I have I do not see a way to get
this information by querying the device.
If the value is set in the .device file it will
override anything that the hidpp10 driver itself
would have found.
1-bit RGB is needed for the Logitech G300, let's rename the main RGB to
indicate how many bits we actually have.
See #335
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since we unconditionally call unlink() on that path later, let's make sure
we actually copy to that file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The initial value of 400 in the enum is chosen so it looks weird when someone
tries to interpret the value as integer. Values of 1, 2, 4, etc. could be
confused with something realistic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Writing multiple changed profiles was broken as we would exit the
loop after the first profile write. We were returning the number
of bytes written and this was interpreted as an error.
Fix it my returning 0 when we have written the correct number of
bytes to the mouse.
If we could not start the process, there is a high chance we are running
the tests against a different ratbagd implementation so there is no point.
Also, an exception will get raised later during the tear down of the
module saying that "'NoneType' object has no attribute 'terminate'".
This is less than ideal to notify that the process has not been started.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If the other commands try to access a node, there will be an other error
("Unable to find device X"). So there is no points in having this as a
global check.
For the .devel and .test versions, we are guaranteed to have the
test_device at least, so no worries on this side too.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If a profile is either wrong or not there, we rely on the ROM to get
a correct profile.
Fixes#280
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The driver is supposed to prepare everything in memory and then, at the
end commit on the device.
Bug #280 is still not fixed as we should initialize empty profiles first.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Only reading/writing full sectors are allowed (because we need to set and
read the crc anyway).
Fixes#122
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
allocate was actually both initializing and allocating through initialize.
Things started to get complicated.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Starting with -vv, we print out the ratbagd log messages to stdout/stderr,
-vvv switches ratbagd to raw mode. We start at level 2 so that we can have the
single -v reserved for ratbagctl itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For the active profile we read the active resolution
from the mouse during probe.
When changing the active profile we set the default
resolution to active.
Plan is to remove the key mapping altogether and make it transparent from the
Macro mappings (in libratbag/the drivers). Meanwhile, remove the DBus API so
nothing can actually start using it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that we use the .ini style device configuration and everything has been
migrated, we don't need the hwdb/rules files anymore
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we leave ratbagctl.devel too soon, ratbagd gets killed before it even
receives the async call for commmit(), meaning everything we do on the
device is lost.
0.5 is empirical. It seems on my system 0.2 is enough (0.1 doesn't seem
to work). Hopefully this value is not device dependent.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
not sure why, but stat.S_IEXEC only sets exec permission for the user,
meaning that the installed file can't be run by anybody else than root.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
A quick and easy way to sync anything coming from dbus (like property updates)
without needing to be hooked into a glib mainloop directly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not sure why it thinks we're potentially dereferencing a NULL-pointer here but
from the trace it looks like it thinks macro and a previously nullified
profile->macros are the same. They aren't, macro was just allocated here and
shouldn't be NULL if we get here.
Anyway, add an assert and move on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure that the index we pass into long_clear_bit is never higher than the
number of bits in the single long we use as array here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Simply abort if the macro value is bad, that's a libratbag bug and should
never happen.
Found in #312
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Checks for the three layers we need and that any buttons in the files are
consecutive and have the right layers
Fixes#196
Co-authored-by: Jente Hidskes <hjdskes@gmail.com>
We keep the hardcoded fallback.svg for the test device, otherwise we get an
error every time we start ratbagd.devel
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>
The hwdb was a quick and easy way to add entries for new devices but we need
more and more info about the various types of devices. It's better to move
this to a proper database.
Side-effect: this also gives us an easy way to point to the list of devices
supported and makes checking for e.g. missing svgs easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have autodetection for Logitech, but let's always specify the driver for
devices we have in the hwdb.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we couldn't find the name on the bus or the ratbagd process already
terminated, return None and fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I originally intended to have a dynamic use of argparse to generate
the commands, but it turned out to be a nightmare.
Just go down the tree of arguments and format the help properly.
Fixes#288
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We shouldn't try to access input_string[0] if len(input_string) is null.
Meaning a condition in the break in the while loop could be checked
earlier (or later).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
ns is never reset, so once it has a subparser, it'll keep it, so the try
catch is just too much
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Calling "ratbagctl profile -t" resulted in an infinite loop because it
tried again and again to parse "-t" in the profile
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
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.
Our DBus interface is the only API now and libratbag is just the internal
library. Let's not build doxygen for it, there's no need.
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>
Configuring with 'meson builddir' would fail with:
Program build/ratbagctl.test found: NO
Meson encountered an error in file meson.build, line 512, column 0:
Program "build/ratbagctl.test" not found or not executable
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>
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>
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>
libratbag is now a static library only and the only exposed interface is the
DBus interface. We have ratbagctl for that interface.
ratbag-command shouldn't be installed, it becomes a pure developer tool now.
We still keep it around for that reason, but let's not install it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that ratbagd is part of libratbag, the DBus interface is the preferred way
to interact with a device. Shipping libratbag as a .so file means we have to
worry about two ABIs when it's unlikely that anyone ever uses the libratbag.so
directly.
Make it a static library internally instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Bunch of errors while processing the dictionary of enabled profiles.
Got everything working out quite well on the G900 and G403, so I guess
others should behave properly.
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>
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>
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>
When running in a container (CircleCI), dbus may not be available. Throw one
of our errors to be consistent with our behavior when the name owner isn't
available.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a driver succeeded but then fails sanity checks, leave the driver set and
let the cleanup code handle the rest. Otherwise, memory allocated by the
driver's probe() function is never released.
Fixes a valgrind memory leak complaint when running tests for invalid devices
(e.g. device_profiles_num_0).
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>
We are using a custom python script to generate the final ratbagctl
so we can strip out the headers.
Now merging and testing ratbagd.py in piper will be easier than ever.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This reduces the time to run the tests from (now with previous commit) 10s
to a mere 2 seconds.
The --subprocess argument is voluntarily masked from the help message,
because I couldn't figure out how to add it to the unittest parser.
And OTOH, we should not run in subprocess unless debugging...
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Otherwise we get build errors when rawhide is broken, like today. Not worth
chasing that moving target.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Any specific capability like 'switchable resolution' requires the basic
'resolution' capabilty to be set.
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>
Now that we have a method which resets the device, use it so we can
rely on the state of the device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
If the profile is not active, we do not know which resolution is currently
used. Instead of having ratbagd complaining, just set the default as
active.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This shuts up a scan-build warning about a memleak that looked like a false
positive but I couldn't get rid of.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
rc may be a negative errno or a positive hidpp error code. If the latter we
used to continue with a NULL macro pointer, eventually crashing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just logging and error and continuing is not enough, we'll eventually
dereference garbage values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The G403 comes in a (optional) wireless version too; the dongle
that come with it has the product id c539, which is already
handled and also works (by the G900) entry.
Signed-off-by: Christian Kellner <christian@kellner.me>
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>
File "./build/ratbagctl", line 713, in main
cmd.func(r, cmd)
UnboundLocalError: local variable 'r' referenced before assignment
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* 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>
ratbagd unconditionally called set_resolution_xy while libratbag expects
the caller to check on the capabilities. Instead of letting this burden
to the dbus user, have ratbagd handle this for us.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The previous approach had no effect, it wasn't doing things correctly.
Add a proper valgrind setup, run with:
mesontest --setup=valgrind
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[fixed rebase conflict]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It doesn't cost much to actually install the files, so we can check
where they are installed.
Also add mesonconf before building so we can see in the logs
the various configure environment.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Fedora uses /usr/lib64 as libdir but systemd uses /usr/lib for its files. We
used libdir to install the unit files, which then end up in
/usr/lib64/systemd/systemd where it will be ignored. There's no good way to
avoid this beyond detecting this mismatch and hacking around it.
To keep custom prefixes intact, this patch detects a /usr prefix and checks
with systemd's pkconfig, if the libdir and the systemd unitdir mismatch, then
we adjust the path.
https://github.com/libratbag/libratbag/issues/188
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Circle CI uses docker, so nothing prevents us from running several
tests in parallel for different distributions. Ideally, we should also
be able to test the install and be sure we can talk to ratbagd
with the dbus activation on those various distributions.
This version runs both Fedora rawhide and Ubuntu 17.04 at the same
time.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We install everything, so rather than having commands that aren't needed,
simply describe what we're doing and hope for the best.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No-one reads anything longer than 140 char anymore, so let's move the DBus
Interface description out. The average visitor to this site won't care.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Semaphore only provides Ubuntu 14.04 which is too old for us. We now have
CircleCI integration which can run docker images, so let's leave that and drop
Semaphore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Semaphore CI is still using Ubuntu 14.04, and the shipped systemd version
is just too old.
OTOH, Circle CI 2.0 (still beta as of today) allows to use any docker
image as a base for running the tests. Meaning that we can have a fedora
rawhide image as a base and we do not have to handle the update of systemd
meson and others.
Ship a basic circle.yml for Circle CI to run our tests and add the badge
in the README.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This merges ratbagd into libratbag, keeping the histories of both projects intact (hence the rather large merge). The meson.build files are merged and a few things are shuffled around to look like one normal project directory. The build artifacts are still the same, i.e. we still build libratbag and ratbagd.
I couldn't get the subdir() to work, it would throw exceptions somewhere
internal to meson. So instead, just merge the two together.
This still builds everything as before, it's just a single meson file now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The instructions still referred to in-source builds. Meson instead uses
an out of tree build directory, hence we update the paths to point to
the build directory.
Fixes#32.
This makes code that just checks for general abilities easier to write, the
specific thing we can do (e.g. switch profiles) is expressed as separate bit.
This is an ABI break
Related to #172
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The python bindings were mostly boilerplate and a 1:1 mapping of the dbus
interface anyway. Packaging them for distributions is difficult, so given how
little benefit they provide, let's just stop shipping them.
Those who need those bindings (like piper) can either make their own or copy
them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
- changed licence of rb-tree to have a consistent MIT licence
- new signal for active resolution changes
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
- convert Logitech devices to the commit API (those compatible)
- fixes for ratbag-command regarding LEDs (still few caveats left)
- some coverity fixes
- a brand new lur-command man page
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We somehow now know how to write effects.
No need to carry around some left overs from previous configurations.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It's a mix of tabs and spaces. Let's use spaces to keep the formatting.
And move "switch-etekcity" back to the end, it's a special case.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Or we will take the defaults that are not intuitive (like white color
when setting to on).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Shouldn't change the behavior, but this allows adding the other effects
found in the documentation.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Currently we only support mice with 2 LEDs in the profile. No need
to have 32 placeholders.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We are using a uint in the end, so better have proper order in the
multiplications/divisions than using doubles.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Allows to follow the usage message: we do not need to provide the
currently active profile.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
profile->dpi_modes[i].led[] is an array of boolean.
Given that the callers (hidpp10_fill_dpi_modes_*()) already are doing the
comparison against 0x02, I guess this is just copy/paste error.
Fixes#152
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
When using the G502 without RGB LEDs, the feature 8070 is not here.
And this segfaults :)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Rename "breath" in the help text and reporting for the led mode to
"breathing". The actual command to set the mode was already called
that way.
Signed-off-by: Christian Kellner <christian@kellner.me>
This implements a signal that is fired whenever the active resolution
changes. For now the signal is only fired when the resolution changes
through the setter, ratbagd_resolution_set_resolution, as profile changes may
not always be hooked up in the hardware.
Reference #8.
This implements a signal that is fired whenever the active profile
changes. For now the signal is only fired when the profile changes
through the setter, ratbagd_profile_set_active, as profile changes may
not always be hooked up in the hardware.
Fixes#7.
- coverity fixes
- new --version to ratbag-command
- cleaning up the meson build tools
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Unsurprisingly, meson does not support the ratbag keyword argument. Though it
should, because we're great. But anyway, this lead to the argument being
ignored which means it didn't get an 'input' argument, which means that
libratbag-version.h.in was ignored. And since it all works anyway (Behold! The
magic! Ooooh! Aaaah!) we can just drop that file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because, well, that's what we're supposed to do. Unless you want to think
outside the (array) box, but that has never helped anyone, has it?
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that we use meson exclusively and meson uses this for its config.h, you
wouldn't get around it anyway. Besides, the main compilers support it and
libratbag is too niche to worry about others.
This also *adds* the pragma to tools/shared.h where it was previously missing,
and changes it to be the top statement in hidpp-generic.h
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we don't change count, the value of count < MAX_RETRY is always true.
Coverity is a champ, isn't it?
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than having a bunch of gotos just define a cleanup for this device and
let the magic do the rest.
Found by coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A semi false-positive from Coverity, because action.macro is unset. Doesn't
matter because we never use it, but having it zeroed is the nice thing to do
(and what we do in the other functions).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As pointed out elsewhere, the build directory is decided by the user and
should thus be a user-specific gitignore configuration.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
By now you should have 229.
And replace the instructions with actual ratbagd build instructions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
pkgconfig.generate() does not (yet) have a parameter for setting custom
variables - we need that for pkgdatadir to point to the SVG files. Swap to
using configure_file with the old .pc.in file that was forgotten in the tree
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And thus drop the code to parse the top_srcdir from the arguments to the
symbols-leak-test, not the env.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For a builddir called 'builddir', the following commands are sufficient now:
meson builddir
ninja -C builddir
sudo ninja -C builddir install
Meson only needs to be run once after checkout or after the removal of the
builddir.
Fixes https://github.com/libratbag/libratbag/issues/142
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Prep work for meson, even though we'll eventuall drop the env bit. This just
removes the extra symbols-leak-test.in step.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Always build the tests, if someone doesn't want it disable it with a configure
flag but at least be explicit about it.
Justification: any developer should build the full stack as intended by
default. Distributions may disable bits and pieces, but they shouldn't rely on
auto-detection to figure it out, they should explicity disable those bits they
don't want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Always build the documentation, if someone doesn't want it disable it with a
configure flag but at least be explicit about it.
Justification: any developer should build the full stack as intended by
default. Distributions may disable bits and pieces, but they shouldn't rely on
auto-detection to figure it out, they should explicity disable those bits they
don't want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And use this to start using C99 variable style, for pure loop variables it's
better to have them declared in the loop itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
../tools/shared.c:132:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Gio.bus_get_sync may return None when the DBus service is not available (see
libratbag/piper#2). In addition to this, the service may time out when it is
being started in which case Gio.DBusProxy.new_sync will raise a GLib.Gerror.
This commit checks for both scenarios and raises a RatbagdDBusUnavailable
exception when either one of them occurs. This will in turn be caught in for
example Piper to properly deal with this.
driver-gskill.c: In function ‘gskill_read_button’:
driver-gskill.c:791:3: warning: ‘event_data’ may be used uninitialized in this function [-Wmaybe-uninitialized]
ratbag_button_macro_set_event(macro, event_idx, type,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
event_data);
~~~~~~~~~~~
driver-gskill.c:791:3: warning: ‘type’ may be used uninitialized in this function [-Wmaybe-uninitialized]
ratbag_button_macro_set_event(macro, event_idx, type,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
event_data);
~~~~~~~~~~~
Add a default case which should never get reached.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Apparently the mouse can be configured to send scancodes
for buttons 6-9.
Note: there's no meaning attached to scancode 0x118 in the kernel,
which is sent by button 9, but xev does detect it.
I fixed resolution cycle up actually being resultion cycle down and added the missing cycle actions for resolutions and profiles.
Signed-off-by: Clément Vuchener <clement.vuchener@gmail.com>
Supports the common functionality exposed by libratbag:
- selecting profile 1-3 (profiles cannot be disabled)
- selecting resolution 1-4 (can also not be disabled)
- report frequency
- default resolution per profile
- button actions: mouse button numbers or key+modifier
(modifiers are just a bit field and can easly be set
in the driver, but not included as libratbag does not
support it yet)
- LEDs are not yet hooked up but are just a table of 7
different predifined colors.
- Seting active profile and resolution are both implemented
but only profile activation is in use. The resolution
activation code is commented until supported from libratbag
itself.
The G300 has an unusual way of numbering buttons:
Left:1, Right:2, Middle: 3
The purpose of report type 0xF2 is not known.
In hidpp10_get_hidpp_notifications(), we want all three bytes from
parameters[], not parameters[0] twice. This matches
hidpp10_set_hidpp_notifications().
Signed-off-by: Stephen Kitt <skitt@redhat.com>
This is especially important for the mx780, so we can get rid of the
rude workaround we currently have in the driver for it.
Signed-off-by: Lyude <lyude@redhat.com>
Changes since v1:
- Just have profile enable/disable in ratbag-command
- Use bool instead of int
Changes since v2:
- Remove leftover function, whoops
- Fix leftover ints to bools
- Lots of style fixes
Make sure that there can only be one resolution marked
as default.
The previous code allowed to set multiple resolutions
as default. To clean up any bad state we allways loop
all other resolutions and unset the default if neccesary.
Only managed to notice then while working on enabling/disabling
profiles. Somewhere down the line the encoding we pass to
ratbag_utf8_to_enc() managed to get typoed, causing it to actually fail
and not show anything because of the iconv helpers not returning
negative error codes.
After learning that just using this mouse was not the greatest way of
figuring out whether or not the iconv helpers worked, I decided to
write a few simple tests to ensure silly things like this don't happen
again.
Changes since v1:
- fix indentation
- Fix year in copyright on test-iconv-helper.c
- Use an encoding that's definitely invalid for the
iconv_invalid_encoding test
- Add tests for a bunch of bad utf16le strings
- Add tests for converting emojis to/from utf16le. Just so we have some
actually multibyte characters in here.
Signed-off-by: Lyude <thatslyude@gmail.com>
Changes since v1:
- has_changed→dirty
Changes since v2:
- Change loop in gskill_commit_profiles(). Ended up being different then
what we needed for enabling/disabling profiles. Anyway, we also needed to
move around the call to gskill_reload_profile_data() so that we call it
only once per commit, not once per profile write.
Changes since v3:
- commit_profiles->commit
Almost all of the devices we've worked with here are the same: they have
some sort of profile on them, and if they don't (which is quite rare)
it's rather easy to simulate one in the driver. In fact basically all of
the device drivers in ratbag just update the profile and rewrite it on
calls to the write_resolution_dpi() and write_button() calls. This is
annoying since profile writes can take a good bit of time, and we're
wasting a lot of time with redundant profile writes that way.
During XDC this year, we came up with an idea that makes more sense: a
profile oriented API. Instead of having multiple entrypoints in the API
to writing and updating the profile we just cache all of the profile
changes until ratbag_device_commit_profiles() is called, at which point
we do a single set of writes for each profile and button that changed.
This has a lot of advantages:
- Where the profile is and is not written out to the device is now
explicit.
- Changing attributes of each profile won't result in any sort of delay
up until the library user commits the profiles, allowing us to avoid
hanging the application every time a simple attribute is changed.
- We can cut down on workarounds in drivers to cater to the previous
API.
Since this commit doesn't handle converting all of the device drivers
over to the new API, we also add a temporary wrapper for devices that
haven't yet been converted to this new API so that they're still usable.
Once all of the drivers have been converted to the new API, the wrapper
will be removed along with the internal driver API calls.
Signed-off-by: Lyude <thatslyude@gmail.com>
Changes since v1:
- has_changed→dirty
- Change namespace to LIBRATBAG_0.5.0
Changes since v2:
- Remove unneeded note about not setting dirty bit
- commit_profiles->commit
- Make FIXMEs more obvious
- Minor styling nitpicks
- Split up capability check fixes into seperate patch
This commit adds complete (with the exception of LEDs and a few other
small things) support for configuring the G.Skill Ripjaws MX780. So far
this has been tested on firmware versions 19 and 21, and both of them
seem to work perfectly with this.
Changes since v1:
- Lots of style fixes
- Remove reset hook, comment out with #if 0 in case of usage in the
future
- Add ret = -EAGAIN check in the loop in gskill_general_cmd()
- Explain why we wait longer then the spec says to in
gskill_general_cmd()
- Check that buf[0] is set to GSKILL_GENERAL_CMD in gskill_general_cmd()
- Add some notes as to why we don't use gskill_general_cmd() in
gskill_select_profile()
- Cleanup return codes, change gskill_general_cmd() so it only returns
valid error codes. In places not using gskill_general_cmd(), do
return rc < 0 ? rc : -EPROTO;
- Split command for selecting the macro to read/write from into it's own
function, just like we do with the profile
- Move profile count workaround into it's own function, make explicit
note of why it's needed
- Add proper support for reading/writing profile/macro names, ensure
they aren't left blank so as to not confuse G.Skill's software
- Use HID kbd modifier codes for translating macro kbd modifier codes
- Use AS_MASK instead of (1 << foo) (apparently we already had this :)
Signed-off-by: Lyude <cpaul@redhat.com>
Some simple helpers to make converting strings to/from UTF-8 easier.
Required for the G.Skill driver since the profile/macro names are stored
in UTF16-LE on the mouse, and must be non-empty in order to prevent
confusing the default G.Skill config software.
Changes since v1:
- Fix potential erroneous free() if we fail to decide the target string
The new version is called "G502 Proteus Spectrum", so the older version comment is changed to "G502 Proteus Core" (its complete name) to avoid confusion.
Signed-off-by: Clément Vuchener <clement.vuchener@gmail.com>
Was off by one, the message content only includes one byte of extra information
before the serial number. And add a BE 32-bit helper while we're at it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The onboard profile do not store the current value but the default.
To retrieve the current value, we need to access the switchable resolution
feature.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The G900 advertises 5 profiles, which do not fit in only 16 bytes.
We need to read at least 32 bytes, so be it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The device can report how much rom it has through profile_count_oob.
Make sure we have something in ROM before accessing it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If the macro has not been retrieved, it's more likely that the button
is not bound to anything.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
A negative error means a communication error, while a positive one means
a HID++ one. Make sure we abort early enough.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
rc is set to 0 by ratbag_open_hidraw_node(), and if matched failed, we
close the hidraw node and end the loop.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Once we start probing devices for multiple drivers we shouldn't just print
error messages for every failed driver. In the hidpp20 case an error would be
printed for any hidpp10 logitech device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device is not specifically assigned a driver, try hidpp20 and then
hidpp10 hoping that one of them will work.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Prep work for being able to probe multiple drivers on a device. The function
that tests the actual driver simply takes a const char * with the driver name,
so in the future we can loop through multiple driver names easily.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No need for two separate cleanup blocks, they're doing the same thing anyway.
Just make the function more robust to uninitalized fields and we're good to
go.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
hidpp10 devices have their own driver, let's not initialize them here and just
fail. If a hidpp10 device is assigned the hidpp20 driver this is a bug.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No reason for the drivers to have their own printf each, just return the
negative errno and let the common code print it.
This now also means that we only return -ENODEV on something that's not really
an error, for anything else we print the strerror.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We now get an error message for all devices that have duplicate event nodes
because we use -ENODEV for 'device not found', 'device is a duplicates' and
'device doesn't have the hidraw report'.
The original commit was triggered by a misunderstanding of the error message,
will be fixed in a follow-up.
This reverts commit 855a6bd831.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't really expect more than 2-3 devices even on a test box. This function
serves little purpose, we can easily require a caller to just get all devices
(usually just one anyway) and then go from there.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the terminology used in libratbag as well (and everywhere else where
we deal with input devices).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Strings can suffer from locale issues, the official recommendation for DBus
APIs is to use enums here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Strings can suffer from locale issues, the official recommendation for DBus
APIs is to use enums here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't shut down once activated but that doesn't mean we need to run when
never requested.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Now that we clean up properly, the most common crash should be fixed. Restart
on abort by default so ideally all we need to do is restart piper or whatever
consumes the API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This configure.ac is largely a copy from systemd so it included things that we
don't use locally.
- we don't use grep, awk or ln
- AC_SYS_LARGEFILE and AC_CANONICAL_HOST are unecessary
- pkg.m4 - if that's missing you don't have pkgconfig installed. stop trying
to build things then :)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Exporting just the filename requires the caller to know where that file sits.
That's useful for things like e.g. icons where callers may several sets to
chose from but here most callers will just use the default svg provided by
libratbag.
Export that, so that we don't have build-time dependencies in the callers just
for that single path.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's a lot easier to interact with ratbagd from a python script than it is
with C code. Plus this means we test the bindings whenever we use ratbagctl.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This reverts the version number but ratbagd is nowhere near stable (because
libratbag itself isn't stable yet) and the dbus API can change at any time.
I'm not committing to keeping the current dbus API around for backwards
compatibility reasons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This just exports the button index so far and makes sure we can write clients
that deal with button objects instead of making stuff up to test for buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Returning the object path makes it harder for the client to identify which
object is the active one. A simple index into the devices array is easier to
handle.
Note: another approach was to have an IsActive property on the profile
directly. This would require updating all properties when the active profile
is changed, it's simpler to just have one index.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
sd_bus_encode_many() escaps elements starting with a digit so our 0 profile
has an object path of /.../_30. This is quite confusing during debugging.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Lets use the new get_device_path() helper to allow calling show-device
without any argument. This follows what show-profile does already.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
New verb: show-profile
This simply prints a profile of a given device by querying ratbagd for
all information on the selected profile.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Add a new property to profiles that exposes resolutions on the bus. We
simply expose a dictionary entry for each resolution, hence, we can
easily extend it in the future. However, we avoid the full overhead of
real dbus objects, as there is no real need for it.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Add two new helpers to query ratbagd for the object-paths of a specific
object:
GetDeviceByName: Return device given a device name
GetProfileByIndex: Return a profile given a profile index
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
We should always provide valid data if requested via Get().
Unfortunately, DBus still does not include 'maybe' types, so we just
return something that is clearly invalid data.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Two new verbs for ratbagctl:
- list-devices: list all available devices
- show-device: show detailed information about a single device
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Expose a list of profiles, including a tag for the active profile, from
within each ratbagd device via DBus.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Never return information about non-existant profiles. Just skip NULL
profiles silently, when iterating.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Refrain from hierarchical paths and instead use object prefixes with
unique paths each. This avoids several nasty DBus-enforced behaviors
regarding deep hierarchies. Furthermore, it keeps the names shorter,
which is always a nice side-effect.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Provide two new profile accessors that return the path and index of a
profile. This also requires us to cache the dbus path in the profile
itself.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
New helper to return the name of a device. This will be required to build
hierarchical paths in the sub-classes, like profiles.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Instead of relying on the cricket ObjectManager interface, use our own
manager interface. This gets rid of ridiculous recursive behavior of the
ObjectManager interface and instead allows us to control the behavior.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
This is no longer needed. Use the device-iterator in ratbagd.c directly
and then drop ratbagd_device_list().
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Add helper to retrieve the device path from outside of ratbagd-device.c.
This will be needed for the non-object-manager based enumerators and
signals introduced to org.freedesktop.ratbag1.Manager.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Profiles are static children of devices. Expose them as 2nd-level objects
underneath their parent devices on the bus.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Make sure the device management (lookup and enumeration and registration)
is done from the parent, not the child. Hence, move it into ratbagd.c over
ratbagd-device.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Make sure our dbus callbacks to not contain any logic themselves. They
should be simple wrappers around our internal object handling.
This also makes use of the new sd-bus pat helpers, to-be-released with
systemd-v227 next week.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
This does not work, we cannot flag properties as UNPRIVILEGED. Drop it.
Lets figure out later what exactly we want as privilege level to
enumerate and query device properties.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Add two device properties:
- Id: Returns the string ID to identify the device
- Description: Returns the ratbag-device name
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Make sure to create libratbag_device contexts for each device we add. If
libratbag returns NULL, we just ignore the devices. Otherwise, we keep
the context around and manage the device.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Make sure the ratbagd context has a reference to a valid libratbag
context at all times. We need this to access libratbag devices, so lets
reference on in our own context.
This also adds a dependency for libratbag via autotools.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Add safe_close() helper that makes close(2) a bit nicer to use. This also
introduces PROTECT_ERRNO, which makes sure a function does not clutter
errno if called.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
This adds two new components:
1) ratbagd
The ratbagd daemon is a very basic dbus daemon that provides an
org.freedesktop.DBus.ObjectManager based enumeration and modification
API for libratbag devices. So far, all it does is enumerate input
devices on the bus. However, this will be extended to advertise full
libratbag hierarchies on the bus and allow clients to modify
properties via DBus.
So far, it is root-only, but the DBus policy can be losened and PolKit
support can be added.
2) ratbagctl
A very basic command-line tool to manage ratbagd. It's basically a
command-line interface for the DBus API of ratbagd.
So far, it has no hookup for anything. This will be added once ratbagd
gains further DBus APIs.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Initial commit for the ratbagd project, a dbus daemon to manage libratbag
devices and proxy user accesses.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
2015-09-24 16:45:22 +02:00
199 changed files with 26835 additions and 17330 deletions
AC_ARG_WITH(udev-base-dir, AS_HELP_STRING([--with-udev-base-dir=DIR], [where udev base directory is]))
if test -n "$with_udev_base_dir" ; then
UDEV_BASE_DIR="$with_udev_base_dir"
else
UDEV_BASE_DIR="/usr/lib/udev"
fi
AC_SUBST(UDEV_BASE_DIR)
AC_ARG_ENABLE([documentation],
[AC_HELP_STRING([--enable-documentation],
[Enable building the documentation (default=auto)])],
[build_documentation="$enableval"],
[build_documentation="auto"])
if test "x$build_documentation" = "xyes" -o "x$build_documentation" = "xauto"; then
AC_PATH_PROG(DOXYGEN, doxygen)
if test "x$DOXYGEN" = "x"; then
if test "x$build_documentation" = "xyes"; then
AC_MSG_ERROR([Documentation build requested but doxygen not found. Install doxygen or disable the documentation using --disable-documentation])
fi
else
AC_MSG_CHECKING([for compatible doxygen version])
doxygen_version=`$DOXYGEN --version`
AS_VERSION_COMPARE([$doxygen_version], [1.6.0],
[AC_MSG_RESULT([no])
DOXYGEN=""],
[AC_MSG_RESULT([yes])],
[AC_MSG_RESULT([yes])])
if test "x$DOXYGEN" = "x" -a "x$build_documentation" = "xyes"; then
AC_MSG_ERROR([Doxygen $doxygen_version too old. Doxygen 1.6+ required for documentation build. Install required doxygen version or disable the documentation using --disable-documentation])
fi
fi
AC_PATH_PROG(DOT, dot)
if test "x$DOT" = "x"; then
if test "x$build_documentation" = "xyes"; then
AC_MSG_ERROR([Documentation build requested but graphviz's dot not found. Install graphviz or disable the documentation using --disable-documentation])
if test "x$DOT" = "x" -a "x$build_documentation" = "xyes"; then
AC_MSG_ERROR([Graphviz dot $dot_version too old. Graphviz 2.26+ required for documentation build. Install required graphviz version or disable the documentation using --disable-documentation])
fi
fi
if test "x$DOXYGEN" != "x" -a "x$DOT" != "x"; then
build_documentation="yes"
else
build_documentation="no"
fi
fi
AC_ARG_ENABLE(tests,
AS_HELP_STRING([--enable-tests], [Build the tests (default=auto)]),
d="m 244.0293,281.64062 c -11.87933,0.21005 -21.28719,4.70945 -25.45899,14.41407 l -7.76367,15.2207 c 4.63005,-8.00151 13.38623,-11.7657 24.20703,-11.95703 13.84985,-0.24489 31.05521,5.35529 47.24414,15.31641 4.24517,-2.44738 6.87171,-7.03619 7.65625,-8.34375 0.83684,-1.39473 3.09281,-4.54246 4.70703,-7.20118 -17.13681,-11.29215 -35.78244,-17.71107 -50.59179,-17.44922 z m -33.22266,29.63477 c -0.45292,0.78273 -0.88022,1.59229 -1.25195,2.45703 l 1.25195,-2.45703 z"
d="m -295.16094,608.46281 6.625,27.125 27.125,5.875 c 0,0 38.75,14.5 45.75,29.125 l 5.5,0.875 2.375,-4.625 c 0,0 -13.875,-23.75 -49.625,-33.375 l -1,-1.25 2.25,-11.25 z"
d="m -386.31433,498.06271 -5.65686,48.08326 c 45.99186,2.07336 100.55399,7.85718 167.23075,21.21321 l 1.06066,3.0052 c 23.24045,-1.15617 46.44002,-2.32824 77.95852,-0.26516 l 3.35876,3.62392 -10.6066,-78.48885 c -119.63944,-15.8417 -179.55343,-5.16228 -233.34523,2.82842 z"
d="m 270.88842,559.80819 26.12051,4.09732 62.14289,-30.90074 c 11.97455,-20.17142 5.93562,-23.53024 5.29239,-31.92505 l -91.50713,47.4608 c -3.16993,2.58552 -6.42443,5.13123 -2.04866,11.26767 z"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.