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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
