Doing just a first release of libratbag with its current features and
problems. This will help other tools to properly link against anything
libratbag >= 0.2
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Missing from 960ee73da9.
In case a hid++ 1.0 device has only 1 profile enabled under LGS, libratbag
exports only 1 profile, and thus the profile and button keys capabilities
are missing.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We do not have any driver using it, and we are not sure this will even
be required. Before releasing a version with this, remove it. We
can always re-add this later if the need appears.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Most of the capabilities can be inferred from
ratbag_device_init_profiles():
- if a device has more than one profile, we should be able to switch
between its profiles
- likewise, more than one profile means that the buttons can be remapped
- more than one resolution means that we can change the resolution.
We need to add a stub in driver-test for .set_active_profile() now that
RATBAG_DEVICE_CAP_SWITCHABLE_PROFILES is correctly set.
We manually add the macro capability for all drivers that present it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We were limited to MAX_RESOLUTIONS (10). Also, this allows to know
during ratbag_device_init_profiles() if the device supports
switchable resolutions.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Do not interleave some internal ratbag initialisation with the hidpp20
initial reading.
During early init, we are just interested in knowing how many
profiles/resolutions/buttons the device supports, so we should not read
more than required.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The current code might call some other function when the device supports
onboard profiles. We should not query those extra functions given that
the profiles should give us all we need.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Dissociate the reading of the data from the device of the actual storing
of those data in the profiles. This will allow to call
hidpp20drv_read_resolution_dpi_2201() without having profiles to know how
many sensors are in the device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The driver hook .get_active_profile() has been removed for a while now,
so remove this ugly #if 0.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It does not make sense to check for .set_active_profile() and then
use .set_default_profile().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
libratbag external API is currently not aware whether a given profile is
enabled or not. Before switching to a disabled profile, we need to enable
it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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.
Same commit for hidpp20:
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>
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>
This prevents the M705 to shout that we need to set RATBAG_HIDPP10_DPI
and also allows the mice with only 1 profile to be configured.
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 button mapping of the hid++ 2.0 devices is close to the one from
HID++ 1.0, but not entirely (1.0 have a size of 3 while and 2.0 a size
of 4).
The parsing was not clean, so reuse a the same logic than hidpp10.
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>
Most should be fine, though I did not tested each key.
HID++ 1.0 and 2.0 use it now, though HID++ 2.0 needs refinments (only a u8
is used though we need a u16)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
The G700 can use a wireless receiver too. It is close enough to the
normal Logitech Unifying receiver, but is truncated as it can not pair
multiple devices.
We currently don't treat it in the kernel as an Unifying device, and
so giving the device index of 0x00 fails as the device is actually on 0x01.
While there is no proper kernel solution (if there will ever be one),
allow to add a parameter in the hwdb to specify the device index.
We might need it for some other devices too, we will see.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
