When the windows driver puts a device in host mode it will mark all 8100
profiles as disabled. If no 8100 profile is enabled no libratbag profile
will get enabled. This patch prevents this by marking the first profile
as enabled if no profile is already enabled.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
TBH I don't know why I wrote the original code in the first place, it
clearly doesn't follow the spec.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
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>
This is confusing because we do have a test driver and we have an optional
test_device argument here too.
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>
Because our profile struct can never have an NULL name, let's assume the
empty string equals NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're initializing them with incrementing indices, let's make sure the list is
initialized that way too. Makes things more obvious in the log when the first
profile to be queried from the device isn't profile 4.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No real functional changes since they just forward to the existing function.
But it reduces the cognitive load a bit when reading the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
currently if any use profile is not valid we fallback to the firmware
profiles. this is quite annoying because the user might have only one
valid profile. this patch will keep valid profiles and only fallback to
firmware profiles on a profile by profile basis.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
when we read the memory from the device we already align the offset so
that it matches the end of the sector. for ex, for a 255 sector size the
offset will be set to 255-16.
when we copy the memory (using memcpy) we just copy the bytes that will
finish filling the buffer, ignoring that the offset was aligned. we need
to copy the full 16 bytes, otherwise it will fail when sector_size does
not align with 16.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
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>
_cleanup_ is deallocating the pointer returned by
ratbag_device_data_steelseries_get_dpi_{range,list}(). Deallocating
dpi_list results in a wrong step value, and a wrong step value then
results in a wrong step count when we try to set the dpi.
Fixes#436 and #702
At some point meson #defined NDEBUG depending on the build type, thus
disabling asserts. libratbag relies on those, so let's error out if NDEBUG is
defined.
Related #685
There is no guarantees the current value of dpi_index will be correct.
On my G502 the profiles are read in reverse order meaning that setting the
dpi_index can be applied to a wrong value.
Look for the correct libratbag dpi index before setting it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We don't have mice that can do report rates per resolutions, so let's not
commit to that.
This is a DBus API break but also a break in ratbagd, piper will need to
update to fetch the rate/rates from the profile object now.
It's a ratbagctl break as well, ratbagctl info changes slightly and the
resolution is not argument anymore for the rate.
Fixes#645
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The SVGs must not be part of any stable API, there is too much behavior
implied that we cannot/do not specify. So it's perfectly likely that a future
change in the SVGs or rendering libraries breaks things in some detail. But
then we cannot update the SVGs without risking breaking other clients that
rely on the current behavior.
Besides: we only have one theme, called "gnome" because a push
towards having SVGs for other themes never happened.
And that theme isn't gnome-specific, it merely looks GNOMEy. The theme is very
much piper-specific in that it requires certain elements that piper cares
about. Currently anyway, if we make this part of our API, piper cannot change
that behavior ever without breaking others.
So let's drop SVG handling completely and rely on the clients to sort it out
for themselves.
For now the SVGs are left in the tree to make it easier to copy to Piper. Once
that's done, we will remove those too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the SVGs need to be maintained elsewhere, we need something reliable to
match devices with SVGs. The easiest is to provide a unique model string,
usually composed from the usb/bluetooth information.
A string format was chosen to make it more flexible for the glorious future
where we have something other than usb or bluetooth devices. Meanwhile, the
format is the well-known "usb:1234:56ef:0" string (bus, vid, pid, version).
The version in this string is a future-proof safeguard for libratbag. It will
be used where libratbag supports two devices with the same VID/PID and where
this is not otherwise differentiable. We don't have any such devices yet, so
libratbag just returns a hardcoded 0.
The format is currently defined for usb and bluetooth, in the future we may
have other strings.
The base guarantee is that this is a reliable identifier for the model that
will never change for that model. IOW this is what piper can use to map
devices to their SVGs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The led type was the physical led type to describe where the LED sits.
This property is basically unused and of questionable use anyway. GUI
applications would need to rely on drawings of the mouse anyway. Scripts don't
really care because ratbagctl uses the led index anyway. The only time this
matters is when we're looking at (human) device discovery. But even then just
trying to set the LED is enough to figure out which one is which.
So let's drop this API on the assumption that it's not really needed and
maintaining and extending that enum forever is not necessary.
This is not a full purge, merely the DBus API that gets dropped.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
