The G900 advertises 5 profiles, which do not fit in only 16 bytes.
We need to read at least 32 bytes, so be it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The device can report how much rom it has through profile_count_oob.
Make sure we have something in ROM before accessing it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
A negative error means a communication error, while a positive one means
a HID++ one. Make sure we abort early enough.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
hidpp10 devices have their own driver, let's not initialize them here and just
fail. If a hidpp10 device is assigned the hidpp20 driver this is a bug.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The G303 shares the same profile than the G402/G502. The only difference
is an extension at the end of the profile, but they are compatible.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Get_Profile_Info gives valuable information to know if we are compatible
with a given device. Use it and bail out if we are not able to support
the device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Spec says the profile count is stored in byte 3 of
CMD_ONBOARD_PROFILES_GET_PROFILES_DESCR, so use this to allocate the proper
number of profiles.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Same commit for hidpp20:
Previously, we would put a random address in the macro value, meaning we
lose the content of the macros.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
The button mapping of the hid++ 2.0 devices is close to the one from
HID++ 1.0, but not entirely (1.0 have a size of 3 while and 2.0 a size
of 4).
The parsing was not clean, so reuse a the same logic than hidpp10.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Most should be fine, though I did not tested each key.
HID++ 1.0 and 2.0 use it now, though HID++ 2.0 needs refinments (only a u8
is used though we need a u16)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Looks like the hid++ 1.0 devices are also using the same crc computation,
so put it in the generic part.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Removes the magic constants here and there, though the description
of the struct is not very nice and clean.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Looks like the crc needs to be passed anyway, so have a common helper to
set the crc and write the whole page.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If the device has never been configured under Windows, the dictionary
of the profiles might be blank. When it is blank, any changes made to
the profiles are ignored by the mouse.
Update a new dictionary if the profile was previously not enabled.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Still missing the consumer control HID keys, but the rest works (minus
the modifier keys).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Not completely full features, but works to set the DPI, report rate and
buttons assignments (no macros yet).
The current code reads first the current values, changes that needs to be
changed and writes back the data. Long term, we want to build the data
directly from the profiles and just write them.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
profiles_list is not used anymore in hidpp20_onboard_profiles_get_current_profile
let's remove it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It looks like we can not use a section > 0xff and that the first
parameter corresponds to the type of the available memory (rom or flash).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It looks like we can not use a section > 0xff and that the first
parameter corresponds to the type of the available memory (rom or flash).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We already know the indexes in the table, so there is no point in making
a round trip to the device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We need hidpp20 to handle the list of available features. So we need to be
sure in hidpp20 that we are talking to a hidpp20 device.
Move the version retrieval in hidpp20 where it makes sense.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This struct will be used to store the table features/index and probably
others. It also allows a single entry point to set the device index.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
