This brings initial support for the Logitech G402, as discussed in #471.
I used the G502 svg and modified it, without changing the graphics. The two mice are aesthetically similar.
* Added G402 device file
* Added G402 svg file
* Add G402 files to build
[bentiss] squashed the 3 patches as one
This wasn't added to the meson.build file so the test didn't run on it. And
the test fails. Issues found include:
- DPIRange and DPIList must not be in the Device section
- Only one of those two, not both
- The svg file was in the 'default' theme rather than in gnome
This needs to be fixed first, not sure how this would've worked at all.
This reverts commit 2371960a1d.
- New svg and device file. Updated meson.build.
- New device version (version 3).
- Refactored led cycle to be general for v2 and v3.
- New defines for v3.
A driver for the logitech G600. The behavior is similar to the
G300 but with enough differences that it seemed cleaner to implement
as a separate driver.
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 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.
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.
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>
For the device I have I do not see a way to get
this information by querying the device.
If the value is set in the .device file it will
override anything that the hidpp10 driver itself
would have found.
The hwdb was a quick and easy way to add entries for new devices but we need
more and more info about the various types of devices. It's better to move
this to a proper database.
Side-effect: this also gives us an easy way to point to the list of devices
supported and makes checking for e.g. missing svgs easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
