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.
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>
Macros are somewhat properly parsed in hidpp10.
The driver, however, supports only key press/release and delays.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
The complexity when writing the profile to ROM at first allows:
- to prevent the user to temper with a non full profile
- in case of a USB failure (disconnect or loss of power for the batteries)
we don't use partially overwrite the profile.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To not have a giant patch that writes profiles to the HID++1.0 mice,
this first patch only convert the user profile into the actual data
that needs to be sent to the mouse.
We use hidpp_error to output it but no end user will ever see that
because it will be removed in a later commit.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Store them in a table in hidpp10_device.
When the dpi list is filled in, we need to invalidate
the profiles.
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>
If the crc is wrong, the device will ignore the page.
This technically multiply by 6 the time to access the device, but this is
because we do not cache anything currently in hidpp10.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
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>
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>
The current API takes offset in 2-byte values. Taking a byte value
is more natural. We need to upgrade the type of offset to uint16_t
to handle values > 256.
We now only use libratbag for logging. Abstract that away so we can use
hidpp10 separate from libratbag where needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part 2 of disentangling libratbag from the hidpp10 library. Copy the hidraw_fd
into the hidpp_device struct and use that during read/write.
This temporarily disables logging, will be re-enabled with an upcoming commit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Requires a ratbag_device argument (with the hidraw fd open) but then tries to
list them - that doesn't quite work.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have documentation for that, it does what it's already doing. It's called
sector + entry in the doc, but leave it at page + offset since we've been
using this in other comments.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The caller doesn't need to worry about registers or something here, let's just
expose one single bitmask, provided by an enum.
This also adds s couple of missing bits from the previous implementation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The caller doesn't need to worry about registers or something here, let's just
expose one single bitmask, provided by an enum.
This also adds s couple of missing bits from the previous implementation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
First: there are 6 LEDs, not just 4. If the LEDs don't exist, the value is
UNCHANGED on the read request.
The value is more than a simple on/off, though at least the G500s only looks
at the lower two bits, so heartbeat and slow off both translate into "on" and
blink and slow on both translate to "off".
There doesn't seem to be a detection mechanism for what a device really
supports.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For supported devices this can get and set the led colors in RGB.
This patch just adds the support in the lib. Later patches will
add it to the driver and expose it in libratbag.
Profiles are... interesting
https://github.com/cvuchener/g500/blob/master/doc/profile.md is pretty
detailed on the information, but there's some oddities.
The profile configured on my mouse is on page 5, not sure if that's the OS X
logitech tool though (which doesn't do profile configuration btw). Pages 3 and
3 are valid too, the rest looks to be garbage.
There's probably some magic string to detect a profile (cvuchener says maybe
FF 00 00 80), so more profiles may be lying around elsewhere in memory...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
