* data: added Logitech G603 svg
* data: added Logitech G603 svg
* data: added Logitech G603 svg
* data: updated Logitech G603 svg
I fixed an issue with the right and left click buttons missing and the middle button being on the incorrect layer. I also removed the logo on the mouse as I was having some issues in Inkscape due to my unfamiliarity with the software. I figured properly configured buttons is good enough for the time being.
This brings initial support for the Logitech G402, as discussed in #471.
I used the G502 svg and modified it, without changing the graphics. The two mice are aesthetically similar.
* Added G402 device file
* Added G402 svg file
* Add G402 files to build
[bentiss] squashed the 3 patches as one
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>
* tools: canonicalize path first in udev_device_from_path
This fixes a problem in which running ratbag-command with the path to a
device node symlink (e.g. /dev/logi-g502 -> /dev/input/event4), such as
one created by a udev rule, would not work correctly, due to the code
failing to resolve the symlink prior to checking for the presence of the
"/dev/input/event" prefix.
This resulted in nonsensical error messages (shown below) and the
curious inability to run ratbag-command successfully with anything but
the actual raw path to the device node itself (e.g. /dev/input/event4
would work fine, but /dev/logi-g502 would not, despite both being valid
ways of getting to the same device node).
Error: Can't open '/dev/logi-g502': Success
Error: Device '/dev/logi-g502' is not supported
Note that this same problem also prevented the usage of autogenerated
symlinks by udev, i.e. '/dev/input/by-id/' and '/dev/input/by-path/'.
* Update tools/shared.c
Co-Authored-By: jgottula <justin@jgottula.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>
ratbagd now implements commit as normal always-successful call with a
potential Resync signal later if something failed on the device.
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
Schedule the actual operation as a callback to handle at the end of the event
loop and return success. The Resync signal will handle the rest.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A few of the device files didn't get installed, let's add them to the list.
This reshuffles the list a bit because the easiest way to make sure all files
are included is to run git ls-files, so let's stick to that.
Fixes#552
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This wasn't added to the meson.build file so the test didn't run on it. And
the test fails. Issues found include:
- DPIRange and DPIList must not be in the Device section
- Only one of those two, not both
- The svg file was in the 'default' theme rather than in gnome
This needs to be fixed first, not sure how this would've worked at all.
This reverts commit 2371960a1d.
ratbagd is not something that needs stay around forever just because we
configured a mouse once. We have DBus activation and we don't store anything
anyway, so we might as well exit after a period of inactivity (20 min).
There's a slight race condition where if something comes in at exactly the
20min mark, we may shut down anyway and the messages get lost. This is too
narrow to worry about.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Notable: parts of the instructions have been punted to the wiki now where it's
faster to edit and be verbose about the specific instructions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This reverts commit 874d7eccb8.
Looks like 18.10 fails at every pipeline build, so better
punting this for later.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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.
Some change in F29 breaks the CI runs, so lets switch back to what we had
before so we can merge patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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
