The G700 has 5 available profiles, bump HIDPP10_NUM_PROFILES.
On the other hand, hidpp10_get_device_info() doesn't fill anything...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
The command get_profile can either return an index in the directory (in
the page 0x01 of the memory) or an absolute address. If the address is
returned, it is unclear whether the directory is updated.
This commit also includes changes from Peter:
hidpp10: if the profile index exceeds the number of directory index, use 0
hidpp10: factor out directory fetching
hidpp10: use the profile directory only in hidpp10_get_profile
Fixes#26
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Add a convenient function to retrieve a udev property.
Returns NULL if the property is not found.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.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>
No real reason to keep the two separate, and if we do and need to include both
libraries, we get double-defined symbols (all the ones in hidpp-generic.c).
This is a helper lib only anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Or we need to maintain the list of supported capabilities in a different
place, and it gets error prone.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Allows to navigate in the source more easily if they share a common
name.
However, this is still not good because we need to know which feature
number is which.
Though the format is now in sync with write_button.
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>
To support profiles assignments, we need to split the various write
button functions.
Start with 1b04.
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>
There is only one constructor left.
Get rid of the static hidpp10_device_new() that is not adding much.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
hidpp10_device_new_from_wpid() can not work anymore given that we are not
talking to the receiver anymore, but directly to the device.
The proof being that .wpid is never set in struct hidpp10_device.
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>
Etekcity and Roccat are using raw HID code to send the macros. The Logitech
hid++ 2.0 are too so let's centralize the code in hidraw and simplify
the code per-driver.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
RATBAG_BUTTON_ACTION_SPECIAL_RESOLUTION_ALTERNATE (for the "sniper switch")
RATBAG_BUTTON_ACTION_SPECIAL_RESOLUTION_DEFAULT -> means what it means
And fix one missing entry in str_to_special_action.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
