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>
