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>
Previously, we could get a min/max value but there was no guarantee that it
any value in between would actually work on the device. Some devices have a
discrete number of resolutions (e.g. 500, 1000, 2000, 2500), most others have
at least a minimum step size (so 1234 isn't a valid dpi value).
Change the min/max to a discrete list of which resolutions are supported. This
allows a UI to adjust its interface dynamically - e.g. a combobox if there are
only 3 resolutions or a slider if there are a million of them.
This is a DBus API break
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libratbag is not a library anymore. Move all the stuff that we need for the
DBus interface (i.e. the enum values) into its own header file so they're
all in one place and we don't have to worry about it anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, probe() would call ratbag_init_profiles() which in turn would call
the various function pointers in the driver to fill in profiles, buttons and
leds (the latter while filling in profiles). This made the probe() function
harder to understand than necessary and unreliable because it wasn't always
clear which bits were already set up while some driver function was called and
which ones weren't yet.
This patch switches to a flat probe(). The driver still needs to call
ratbag_init_profiles(), libratbag sets up everything (to default values). Then
the driver can fill in the rest as it wants.
This patch still makes use of the current infrastructure, the drivers
just call the read_profile and read_button functions manually now.
Fixes#370
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Resolutions were still stored in an array over a linked list like the
buttons/leds/profiles and initializing them from a driver was different than
buttons or leds. This brings the resolutions in line with the buttons and
leds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least on HID++ 2.0, the LED types appear to be random and don't match the
protocol specs. Other protocols don't even have those bits, so let's make this
a generic entry.
This is pre-filled for all LEDs but drivers can override it where required.
Fixes#377
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
