This commit adds complete (with the exception of LEDs and a few other
small things) support for configuring the G.Skill Ripjaws MX780. So far
this has been tested on firmware versions 19 and 21, and both of them
seem to work perfectly with this.
Changes since v1:
- Lots of style fixes
- Remove reset hook, comment out with #if 0 in case of usage in the
future
- Add ret = -EAGAIN check in the loop in gskill_general_cmd()
- Explain why we wait longer then the spec says to in
gskill_general_cmd()
- Check that buf[0] is set to GSKILL_GENERAL_CMD in gskill_general_cmd()
- Add some notes as to why we don't use gskill_general_cmd() in
gskill_select_profile()
- Cleanup return codes, change gskill_general_cmd() so it only returns
valid error codes. In places not using gskill_general_cmd(), do
return rc < 0 ? rc : -EPROTO;
- Split command for selecting the macro to read/write from into it's own
function, just like we do with the profile
- Move profile count workaround into it's own function, make explicit
note of why it's needed
- Add proper support for reading/writing profile/macro names, ensure
they aren't left blank so as to not confuse G.Skill's software
- Use HID kbd modifier codes for translating macro kbd modifier codes
- Use AS_MASK instead of (1 << foo) (apparently we already had this :)
Signed-off-by: Lyude <cpaul@redhat.com>
The new version is called "G502 Proteus Spectrum", so the older version comment is changed to "G502 Proteus Core" (its complete name) to avoid confusion.
Signed-off-by: Clément Vuchener <clement.vuchener@gmail.com>
This allows to read but not write profiles from the G9.
The dpi mode sturct is a little different as the mouse only supports
symetrical dpi for x/y. Given the current naming a suffix of _sym
was the best I could come up with.
The G9 profile has some additional unknown bytes compared to the
others. Unfortunately the content of them varies for the 4 first
profiles and the last. So adding a default value for the like with
the G700 is not possible. For this reason I dropped implementing
the write part for now.
Something else to address is that this mouse only has 10 buttons
compared to the usual 13 that we have in PROFILE_NUM_BUTTONS. For
now I just hardcoded it in the profile and hidpp10_get_profile.
The G700 can use a wireless receiver too. It is close enough to the
normal Logitech Unifying receiver, but is truncated as it can not pair
multiple devices.
We currently don't treat it in the kernel as an Unifying device, and
so giving the device index of 0x00 fails as the device is actually on 0x01.
While there is no proper kernel solution (if there will ever be one),
allow to add a parameter in the hwdb to specify the device index.
We might need it for some other devices too, we will see.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Allows to specify a type of profile and speed up the discovery of
hidpp10 devices when they are not actual gaming with a known profile.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Each hidpp10 device should have a udev property named either
RATBAG_HIDPP10_DPI or RATBAG_HIDPP10_DPI_LIST. These properties ensure
that we know the mapping between the raw value of the dpi reported by the
mouse and the actual value.
Older devices (using the scheme 1 or 2 of hidpp10_get_current_resolution)
have to use the DPI_LIST to be able to map 0x80+.
Newer devices (using scheme 3) use the DPI setting with min, max, step.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The MX Master is using BLE to connect, and so the system sees it as a uhid
device. The current rule ignores it because uhid devices do not have the
ID_BUS set.
Fix that by detecting uhid devices and put the bus in the hwdb accordingly.
For completeness, also add usb through uhid so we can also replay devices
and test their drivers.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This adds udev rules/hwdb that sets RATBAG_DRIVER and RATBAG_SVG
properties to the event devices. We then use this property to select
the correct driver instead of checking the hardcoded list in the
drivers. Having this in a hwdb makes it easier for users to test
if drivers match their mouse with a system installed libratbag.
Each driver now has an "id" which is used to match the driver set
in RATBAG_DRIVER. A SVG can optionally be set as well.
All entries in the hwdb are currently without a name as that
information was not available in the hardcoded lists.
Note that this patch breaks the test-driver.
