We do not check dev for null in any of the other functions. If it
was actually null then we would also already have got a null pointer
dereference earlier in the function.
The kernel overwrites the device ID with the correct one for our device, so we
can just use 0x00 for all devices and skip the search for the unifying
receiver hidraw device.
Since we're not talking to the receiver anymore, we can/have to drop the
pairing information queries and the related info. Since we weren't using this
anyway it's not a big loss.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
HID++ 1.0 doesn't have an index of functions available, so we pretty much
have to bang every request against the device, full of hope and optimism.
Reality demands that some of them fail and we handle that, but we don't need
to worry the user by screaming errors.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Profiles are... interesting
https://github.com/cvuchener/g500/blob/master/doc/profile.md is pretty
detailed on the information, but there's some oddities.
The profile configured on my mouse is on page 5, not sure if that's the OS X
logitech tool though (which doesn't do profile configuration btw). Pages 3 and
3 are valid too, the rest looks to be garbage.
There's probably some magic string to detect a profile (cvuchener says maybe
FF 00 00 80), so more profiles may be lying around elsewhere in memory...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This also changes from the "toggle" to a plain "set". If a caller needs to
toggle a specific function, it can run get + set instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only enabled for 4 leds and I'm not even sure they're the same on all
devices. Still, works on the G500s so that's a good enough start.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Looks a bit more like the hidpp20 driver now, and easier to get a handle on
everything. Command-specific functions/defines are grouped together and sorted
by command index.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only two receiver-specific requests have a 0-based index, everything else
wants 1-indexed devices. This currently makes it impossible to address wired
devices with a device index of 0. Switch it around, so that we use a 1-based
index.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Still try to run the other commands though, they're not receiver-related and
may work on a device that's not on a unifying receiver.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Starting with kernel v3.19, the hidraw node associated to the input node
talks the the actual device, no matter which device index is given.
There is no need to really know which device has which index thus.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
In file included from hidpp10.c:43:0:
hidpp10.c: In function 'hidpp10_get_device_info':
./libratbag-util.h:76:25: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
#define min(a, b) (((a) < (b)) ? (a) : (b))
^
hidpp10.c:251:12: note: in expansion of macro 'min'
dev->name[min(name_size, sizeof(dev->name) - 1)] = '\0';
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
