Before this patch, ratbagd would abort initialization of the device because
no profiles are returned.
Once that was handled more gracefully, ratbagd would fail because it doesn't
read the DpiList from its own config file, as no ProfileType is specified.
Specifying G500 as the closest match.
Right now we initialize any hidpp10 device with one profile and then go and
fetch the data. But we never check for return codes, so it always succeeds
even when we can't get anything out of the device at all. Eventually we fail
the sanity checks with "invalid dpi list" which is confusing at best.
Let's avoid this by requiring at least the current profile to work. This will
break devices that have a single emulated profile, i.e. those that don't have
profiles but rely on libratbag to emulate one based on the
current-resolution/current-... calls. Not sure we actually support any of
those, so let's see.
Closes#738 though it doesn't fix it, it just bails out better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than bail out completely, let's pretend the factory profile is profile
0 and keep going. This gives us a pretend-function mouse, though whether this
actually works is questionable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
hidpp10_read_memory will return the HID++ error if the request fails.
right now, the error code from hidpp10_read_memory is transparently
passed through hidpp10_onboard_profiles_read_macro. This is problematic
because hidpp10_onboard_profiles_parse_macro only aborts on rc < 0 and
HID++ error are > 0.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
value and dpi are unsigned so the delta calculations was wrong when
dpi is larger than than value. Casting to int should be fine for the
expected range of values in those variables.
If our device only has a discrete number of DPIs, pass it on as-is to
libratbag rather than pretending it's a range and then failing to set the
DPIs.
For the actual ranged devices we use libratbag's now-exponential range
mapping rather than passing all possible ones on. This relies on us having the
same steps that libratbag uses, should be safe enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure that the index we pass into long_clear_bit is never higher than the
number of bits in the single long we use as array here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The hwdb was a quick and easy way to add entries for new devices but we need
more and more info about the various types of devices. It's better to move
this to a proper database.
Side-effect: this also gives us an easy way to point to the list of devices
supported and makes checking for e.g. missing svgs easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We need to read the directory and the profiles only once.
Nothing tells us how many profiles are supported, so use the specifications
from Logitech website, and add a hwdb entry for those.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Just logging and error and continuing is not enough, we'll eventually
dereference garbage values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
profile->dpi_modes[i].led[] is an array of boolean.
Given that the callers (hidpp10_fill_dpi_modes_*()) already are doing the
comparison against 0x02, I guess this is just copy/paste error.
Fixes#152
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
I fixed resolution cycle up actually being resultion cycle down and added the missing cycle actions for resolutions and profiles.
Signed-off-by: Clément Vuchener <clement.vuchener@gmail.com>
In hidpp10_get_hidpp_notifications(), we want all three bytes from
parameters[], not parameters[0] twice. This matches
hidpp10_set_hidpp_notifications().
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Was off by one, the message content only includes one byte of extra information
before the serial number. And add a BE 32-bit helper while we're at it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the G9 the response to a 0x63 is a short report. The G9 does
not have individual resolutions for X and Y and thus only needs
to report a single value.
The set version of 0x63 should probably also be updated. However,
while my testing of such a change worked better than with long
reports there are still strange side effects of setting resolution,
like turning off all the LED's. LGS also seems to do a full profile
read/write instead of using 0x63 when changing the resolution.
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>
unknown3 in G700 is the constant string "LGS02". This string is a marker
for LGS to specify that the rest of the data is the names of the profiles
and macros.
SetPoint doesn't set those, so they are considered as metadata.
In libratbag, we will parse those properly and always set them, no matter
if the user used SetPoint or not.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
The mouse accept them, so they are not invalid.
Only the profile directory seems to be checking for the CRC.
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>
The G500 uses only one bit in the usage code (thus the holes in the table).
So for the G500, RATBAG_BUTTON_ACTION_SPECIAL_RESOLUTION_CYCLE_UP is
the same as RATBAG_BUTTON_ACTION_SPECIAL_RESOLUTION_DOWN for instance.
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>
