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>
The button type was the physical button type, not the logically assigned
button number.
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 button index anyway. The only time this
matters is when we're looking at (human) device discovery. But often clicking
around is enough to figure out the index.
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>
Make this implict - if the profile has a name, it's writable. Otherwise it's
not and you'll have to rely on the index or make up your own naming.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the have all moved or been removed, there is no need to keep this
API.
This is a DBus API break, the Capabilities property disappears.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is arguably a profile-specific thing since the device itself is static
(we still know button numbers, etc.), we just don't know the content of each
profile.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have a profiles/resolution/button/led, we can write to it. That is the
default assumption and where we don't have write-access to those, we should
simply not expose them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have more than one profile, we can switch between them. Because
otherwise having more than one profile is just showing off and we don't like
that type of behaviour, no no.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This capability is superfluous. If we have more than one resolution, we can
switch between them because ... well, why have more than one then?
Signed-off-by:Peter Hutterer <peter.hutterer@who-t.net>
This is a profile-specific capability, not a device-specific one so let's move
it there.
Arguably, the DBus API should not expose SetEnabled() where not available, but
that's a separate issue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Theoretical case is where some profiles cannot be set to be the default, but
realistically: this is a profile-specific attribute so let's move the flag
there.
Arguably, the DBus API should not expose SetDefault() where not available, but
that's a separate issue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We still need to read the data of all other profiles. This broke in f26de4bb,
the previous loop only did the is-active modification
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We started with event nodes for some reason lost in the distant past (probably
because that's what a lot of other tools use). But since we exclusively deal
with hidraw devices here and event nodes only serve to look up the hidraw
node, let's get rid of that indirection layer and work with hidraw directly.
Note that changes how ratbagctl works, it used the event nodes before. So
anyone who hardcoded the event node in one way or another is going to see
breakage. Then again, the "eventX" string was the device ID as advertised by
ratbagd, so it's supposed to be treated as an opaque string anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Strings on DBus need to be valid UTF8, some of the default profile names on
the G700 include the degree character (" Profile n° 1"), the whole string ends
up being invalid UTF8.
This results in two issues:
- ratbagd gets quietly kicked off the bus when it sends that string
- ratbag-command throws an exception because Python is unhappy about the
non-UTF8 string:
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcb0' in position 3: surrogates not allowed
The quick workaround here is to strip anything that's not ASCII from the
profile name. The same may be necessary for some device names too, but let's
wait until we see that.
For ratbag-command we convert the string to bytes and back using the 'ignore'
argument, this way we should see the original profile string without the
printf errors.
This is an incomplete fix, we'll have the same issue if a user tries to set a
non-ASCII name. The long-term fix is to convert whatever we have (probably ISO
8859-1, but can we detect that?) into UTF8 before passing it around. That
would also mean converting it back before writing to the device.
Fixes#617
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Coverity seems to think this can use uninitialized array elements but that can
only happen when hidpp10->dpi_count is 0. In which case the callee doesn't
touch it anyway but coverity doesn't care about that bit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As mentioned in the code:
We revert to HW control of the LEDs.
This effectively disable the capability of changing the DPI/profile
LEDs, but this allows to make them work with the internal DPI/profile
switches.
The net result is:
- DPI/profiles can't be controlled (but who wants this?)
- The logo can properly controlled
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Since a0830a8aaa, we can re-add the simple
keybindings capabilities. It's time the HID++ 2.0 devices get this.
This used to be working with the KEY API, but this has been dropped in
favor of the macro one.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
A non-zero value for the remapped field means the button is mapped to that
button.
"diverted" means to decouple it from normal HID reports and report it via
HID++ only. In our case here, we "map" it, which is different.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add HIDPP_PAGE_RESET, HIDPP_PAGE_DEVICE_NAME, and
HIDPP_PAGE_WIRELESS_DEVICE_STATUS. These feature names are found in the
"features.xml" of an LogiOptions installation. Probably not very useful
for now.
The MX Anywhere 2 mouse has a problematic special key (index=7). When
trying to get the reporting value of this key, the device returns an
"invalid argument" error. [1]
To avoid giving up all good information about other keys, ignore error
(and the cause) when enumerating special keys.
[1] https://github.com/libratbag/libratbag/issues/558#issuecomment-439732655
Turns out this driver never got updated for the 'new' DPI list provided by
libratbag and thus broke with bacdab2596 when we
enforced that DPI list.
Set a fixed DPI list based on the hardcoded values we use elsewhere in this
driver.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I'm pretty sure all callers rely on this command to return either 0 or a
negative errno. There's a quirky occasion where if we get a HID error (a
positive number) during hidpp20_special_keys_buttons_get_reporting, that
number eventually ends up as the 'num_controls' value in
hidpp20_special_key_mouse_get_controls().
Since the only time we care about HID++ errors is during
hidpp20_root_get_protocol_version, let's just always return -EPROTO on HID++
errors.
Fixes#558
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
- New svg and device file. Updated meson.build.
- New device version (version 3).
- Refactored led cycle to be general for v2 and v3.
- New defines for v3.
If we can successfully read a profile but hidpp10_get_current_profile() fails
we end up with one profile, but not set to active. Fix this by always forcing
the single profile to be active.
Fixes#526
Open an extra hidraw to read current onboard settings.
Initially DPI and static LED color can be read from the rival
310. Other data/devices can be added as the protocol is better
understood.
The protocol used to extract the data seems to be both device
and firmware version specific. To be able to switch on both
cases we now store the firmware information in the drv_data.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
For some devices we have to send reports on one endpoint
but read the reply on another. This commit allows us to
open and store multiple hidraws and adds API to specify
which hidraw to use for open, close, and read input report.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
A driver for the logitech G600. The behavior is similar to the
G300 but with enough differences that it seemed cleaner to implement
as a separate driver.
../src/liblur.c:46:3: warning: 'd' may be used uninitialized in this function [-Wmaybe-uninitialized]
hidpp10_device_destroy(*hidpp10_device);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/liblur.c:198:59: note: 'd' was declared here
_cleanup_hidpp10_device_destroy_ struct hidpp10_device *d;
And similar messages
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
