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