driver-gskill.c: In function ‘gskill_read_button’:
driver-gskill.c:791:3: warning: ‘event_data’ may be used uninitialized in this function [-Wmaybe-uninitialized]
ratbag_button_macro_set_event(macro, event_idx, type,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
event_data);
~~~~~~~~~~~
driver-gskill.c:791:3: warning: ‘type’ may be used uninitialized in this function [-Wmaybe-uninitialized]
ratbag_button_macro_set_event(macro, event_idx, type,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
event_data);
~~~~~~~~~~~
Add a default case which should never get reached.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Apparently the mouse can be configured to send scancodes
for buttons 6-9.
Note: there's no meaning attached to scancode 0x118 in the kernel,
which is sent by button 9, but xev does detect it.
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>
Supports the common functionality exposed by libratbag:
- selecting profile 1-3 (profiles cannot be disabled)
- selecting resolution 1-4 (can also not be disabled)
- report frequency
- default resolution per profile
- button actions: mouse button numbers or key+modifier
(modifiers are just a bit field and can easly be set
in the driver, but not included as libratbag does not
support it yet)
- LEDs are not yet hooked up but are just a table of 7
different predifined colors.
- Seting active profile and resolution are both implemented
but only profile activation is in use. The resolution
activation code is commented until supported from libratbag
itself.
The G300 has an unusual way of numbering buttons:
Left:1, Right:2, Middle: 3
The purpose of report type 0xF2 is not known.
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>
This is especially important for the mx780, so we can get rid of the
rude workaround we currently have in the driver for it.
Signed-off-by: Lyude <lyude@redhat.com>
Changes since v1:
- Just have profile enable/disable in ratbag-command
- Use bool instead of int
Changes since v2:
- Remove leftover function, whoops
- Fix leftover ints to bools
- Lots of style fixes
Make sure that there can only be one resolution marked
as default.
The previous code allowed to set multiple resolutions
as default. To clean up any bad state we allways loop
all other resolutions and unset the default if neccesary.
Only managed to notice then while working on enabling/disabling
profiles. Somewhere down the line the encoding we pass to
ratbag_utf8_to_enc() managed to get typoed, causing it to actually fail
and not show anything because of the iconv helpers not returning
negative error codes.
Signed-off-by: Lyude <thatslyude@gmail.com>
Changes since v1:
- has_changed→dirty
Changes since v2:
- Change loop in gskill_commit_profiles(). Ended up being different then
what we needed for enabling/disabling profiles. Anyway, we also needed to
move around the call to gskill_reload_profile_data() so that we call it
only once per commit, not once per profile write.
Changes since v3:
- commit_profiles->commit
Almost all of the devices we've worked with here are the same: they have
some sort of profile on them, and if they don't (which is quite rare)
it's rather easy to simulate one in the driver. In fact basically all of
the device drivers in ratbag just update the profile and rewrite it on
calls to the write_resolution_dpi() and write_button() calls. This is
annoying since profile writes can take a good bit of time, and we're
wasting a lot of time with redundant profile writes that way.
During XDC this year, we came up with an idea that makes more sense: a
profile oriented API. Instead of having multiple entrypoints in the API
to writing and updating the profile we just cache all of the profile
changes until ratbag_device_commit_profiles() is called, at which point
we do a single set of writes for each profile and button that changed.
This has a lot of advantages:
- Where the profile is and is not written out to the device is now
explicit.
- Changing attributes of each profile won't result in any sort of delay
up until the library user commits the profiles, allowing us to avoid
hanging the application every time a simple attribute is changed.
- We can cut down on workarounds in drivers to cater to the previous
API.
Since this commit doesn't handle converting all of the device drivers
over to the new API, we also add a temporary wrapper for devices that
haven't yet been converted to this new API so that they're still usable.
Once all of the drivers have been converted to the new API, the wrapper
will be removed along with the internal driver API calls.
Signed-off-by: Lyude <thatslyude@gmail.com>
Changes since v1:
- has_changed→dirty
- Change namespace to LIBRATBAG_0.5.0
Changes since v2:
- Remove unneeded note about not setting dirty bit
- commit_profiles->commit
- Make FIXMEs more obvious
- Minor styling nitpicks
- Split up capability check fixes into seperate patch
This commit adds complete (with the exception of LEDs and a few other
small things) support for configuring the G.Skill Ripjaws MX780. So far
this has been tested on firmware versions 19 and 21, and both of them
seem to work perfectly with this.
Changes since v1:
- Lots of style fixes
- Remove reset hook, comment out with #if 0 in case of usage in the
future
- Add ret = -EAGAIN check in the loop in gskill_general_cmd()
- Explain why we wait longer then the spec says to in
gskill_general_cmd()
- Check that buf[0] is set to GSKILL_GENERAL_CMD in gskill_general_cmd()
- Add some notes as to why we don't use gskill_general_cmd() in
gskill_select_profile()
- Cleanup return codes, change gskill_general_cmd() so it only returns
valid error codes. In places not using gskill_general_cmd(), do
return rc < 0 ? rc : -EPROTO;
- Split command for selecting the macro to read/write from into it's own
function, just like we do with the profile
- Move profile count workaround into it's own function, make explicit
note of why it's needed
- Add proper support for reading/writing profile/macro names, ensure
they aren't left blank so as to not confuse G.Skill's software
- Use HID kbd modifier codes for translating macro kbd modifier codes
- Use AS_MASK instead of (1 << foo) (apparently we already had this :)
Signed-off-by: Lyude <cpaul@redhat.com>
Some simple helpers to make converting strings to/from UTF-8 easier.
Required for the G.Skill driver since the profile/macro names are stored
in UTF16-LE on the mouse, and must be non-empty in order to prevent
confusing the default G.Skill config software.
Changes since v1:
- Fix potential erroneous free() if we fail to decide the target string
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>
The onboard profile do not store the current value but the default.
To retrieve the current value, we need to access the switchable resolution
feature.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The G900 advertises 5 profiles, which do not fit in only 16 bytes.
We need to read at least 32 bytes, so be it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The device can report how much rom it has through profile_count_oob.
Make sure we have something in ROM before accessing it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If the macro has not been retrieved, it's more likely that the button
is not bound to anything.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
A negative error means a communication error, while a positive one means
a HID++ one. Make sure we abort early enough.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
rc is set to 0 by ratbag_open_hidraw_node(), and if matched failed, we
close the hidraw node and end the loop.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Once we start probing devices for multiple drivers we shouldn't just print
error messages for every failed driver. In the hidpp20 case an error would be
printed for any hidpp10 logitech device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
