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