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.
For protocol debugging, it's a lot easier to go have a simple helper than
having to go through the whole of libratbag.
And remove the page-dump helper from the main code.
Note that this tool needs a /dev/hidraw device directly, not an event node. It
is a debugging tool after all.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
HID++ 1.0 doesn't need hidraw other than the fd itself, and this is the first
step to disentangling the hidpp10 code from libratbag.
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>
The request length doesn't tell us what the expected response length is, e.g.
0x63 (current resolution) is set with a long request but replies with a short
ack.
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>
Command 0xA2 (Read Sector) takes only a one byte argument for the offset
(entry in the documentation).
Clean up the code and return an error if the page (sector in the doc)
is invalid (to avoid querying the device which would output an
ERR_INVALID_VALUE).
Fixes#15
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Might not be the best solution for hidpp10, because it just removes the
duplicates, but this way all of the other drivers can benefit from the
raw debug parameter.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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.
On the M705 I frequently get usb timeouts here if the device has
not been active for a while. Retrying after 10 ms seems to reliably
fix the timeout problem.
We could have just added the 10 ms sleep directly but it does not
seem to be neccesary on wired devices so I chose not to. Setting the
ret value to a face positive number and looping would also work but
we risk an endless loop. In the end I just went for a single retry
as that fixed the problem for me.
This caused a problem since the hidpp10_device would keep a ref to
the ratbag_device - and the hidpp10_device would only get destroyed
when the ratbag_device got a ref count 0.
We do not check dev for null in any of the other functions. If it
was actually null then we would also already have got a null pointer
dereference earlier in the function.
The kernel overwrites the device ID with the correct one for our device, so we
can just use 0x00 for all devices and skip the search for the unifying
receiver hidraw device.
Since we're not talking to the receiver anymore, we can/have to drop the
pairing information queries and the related info. Since we weren't using this
anyway it's not a big loss.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
HID++ 1.0 doesn't have an index of functions available, so we pretty much
have to bang every request against the device, full of hope and optimism.
Reality demands that some of them fail and we handle that, but we don't need
to worry the user by screaming errors.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
