G502 X (wired) not fully supported
Opened this issue · 37 comments
Information
ratbagdversion (ratbagd --version): 0.17- Piper version: 0.7
- Distribution: Manjaro, KDE/Plasma
- Device: G502 X (wired, no RGB)
- Kernel version (ex.
uname -srmo):Linux 6.7.7-1-MANJARO x86_64 GNU/Linux
Describe the bug
the newest iteration of the G502 X (wired) does not appear to be fully supported - this is the version with the optical switches and a larger 'D' shaped PTFE pad on the heel of the mouse (part no. 810-007900)
ratbagctl correctly lists all 11 buttons while piper lists only 8 - for example, there are no options to re-assign the G7/G8 (9 and 10) buttons - also the image for the mouse defaults to the 404 image rather than what is expected (piper was installed from the Arch repo)
`$ ratbagctl 'Logitech G502 X' info`
warbling-mara - Logitech G502 X
Model: usb:046d:c099:0
Number of Buttons: 11
Number of Leds: 0
Number of Profiles: 5
Profile 0:
Name: n/a
Report Rate: 500Hz
Resolutions:
0: 800dpi
1: 1000dpi
2: 1600dpi (active) (default)
3: 2400dpi
4: 3200dpi
Button: 0 is mapped to 'button 1'
Button: 1 is mapped to 'button 2'
Button: 2 is mapped to 'button 3'
Button: 3 is mapped to 'button 4'
Button: 4 is mapped to 'resolution-alternate'
Button: 5 is mapped to 'button 5'
Button: 6 is mapped to 'wheel-left'
Button: 7 is mapped to 'wheel-right'
Button: 8 is mapped to 'profile-cycle-up'
Button: 9 is mapped to 'resolution-up'
Button: 10 is mapped to 'resolution-down'
Profile 1: (active)
Name: n/a
Report Rate: 1000Hz
Resolutions:
0: 800dpi
1: 1000dpi (active)
2: 1600dpi (default)
3: 2400dpi
4: 3200dpi
Button: 0 is mapped to 'button 1'
Button: 1 is mapped to 'button 2'
Button: 2 is mapped to 'button 3'
Button: 3 is mapped to 'button 4'
Button: 4 is mapped to 'second-mode'
Button: 5 is mapped to 'button 5'
Button: 6 is mapped to 'wheel-left'
Button: 7 is mapped to 'wheel-right'
Button: 8 is mapped to 'profile-cycle-up'
Button: 9 is mapped to 'resolution-up'
Button: 10 is mapped to 'resolution-down'
Profile 2: (disabled)
Profile 3: (disabled)
Profile 4: (disabled)
To Reproduce
install piper and notice missing buttons for the G502 X
Logs
skipping as i believe this is irreverent
Additional context
n/a
I have the same issue and I've been doing some research. I did find this: #879
unfortunately there seems to be other issues with piper's support for the g502 x other than the 404 image - libratbag supports it fully, but piper does not
i'm actually writing some documentation for how to program the mouse absent piper - if anyone is interested, let me know and i'll link it when it's done
I'm definitely interested
gotchya in my queue - i'll post when it's done, suffice to say that assigning buttons (all 11) to keyboard keys is easily doable with ratbagctl which is bundled with libratbag
If anybody uses Nix, I got it to work by copying the derivation from nixpkgs and replacing the version with the commit mentioned in #873. Not sure if there's a better way, but it works.
{ lib, meson, ninja, pkg-config, gettext, fetchFromGitHub, python3
, wrapGAppsHook, gtk3, glib, desktop-file-utils, appstream-glib, gnome
, gobject-introspection, librsvg }:
python3.pkgs.buildPythonApplication rec {
pname = "piper";
version = "104ee170c1028f9d2fac1859dc6dea72efc0648f";
format = "other";
src = fetchFromGitHub {
owner = "libratbag";
repo = "piper";
rev = "104ee170c1028f9d2fac1859dc6dea72efc0648f";
hash = "sha256-oy8jqwNhPNXed0ptWjkytztNM6uTPmPYYiGaZWbI6CE=";
};
nativeBuildInputs = [ meson ninja gettext pkg-config wrapGAppsHook desktop-file-utils appstream-glib gobject-introspection ];
buildInputs = [
gtk3 glib gnome.adwaita-icon-theme python3 librsvg
];
propagatedBuildInputs = with python3.pkgs; [ lxml evdev pygobject3 ];
mesonFlags = [
"-Druntime-dependency-checks=false"
"-Dtests=false"
];
postPatch = ''
chmod +x meson_install.sh # patchShebangs requires executable file
patchShebangs meson_install.sh data/generate-piper-gresource.xml.py
'';
meta = with lib; {
description = "GTK frontend for ratbagd mouse config daemon";
mainProgram = "piper";
homepage = "https://github.com/libratbag/piper";
license = licenses.gpl2;
maintainers = with maintainers; [ mvnetbiz ];
platforms = platforms.linux;
};
}
thanks @MichaelCDormann for that - in my case i decided to bypass piper and utilize ratbagctl...
Got a G502 X too! Waiting for an update to fix this mouse <3
Yep, piper issue... it doesn't remember which profile is active, it's as if the "profile list" page and the "button configuration" page aren't communicating fully. It gets confused deleting profiles, switching profiles, etc. It's very confusing behavior and I can't seem to make rhyme or reason to it yet.
EDIT: And yeah I think I'd be happy with just scripting different profiles using ratbagctl but... God, it's a lot of work.
thanks @MichaelCDormann for that - in my case i decided to bypass piper and utilize ratbagctl...
Thanks for your review... is there documentation on scripting time delays and such into a key sequence when assigning with ratbagctl? For instance, something like:
$ ratbagctl warbling-mara button 10 action set macro +KEY_SPACE WAIT-50MS +KEY_V -KEY_SPACE -KEY_V
Cheers.
there is: ratbagctl --help and look in the macro section for t, such as t1000 (pause for 1s)
Thanks much.
Piper isn't working for my G502 X, but I believe that's because there hasn't been a release tag in over 2 years, please make a v0.8 tag so distos update their packages!
Piper isn't working for my G502 X, but I believe that's because there hasn't been a release tag in over 2 years, please make a v0.8 tag so distos update their packages!
You can pull straight from github and it's still busted. Better (at least it finds it and has a graphic), but busted.
EDIT: You'll also want to pull straight from github libratbag, I believe. Not sure if there's a variance there, but just build those two together and you'll be up to date.
I tried aur/piper-git but it seems broken compared to extra/piper, I get ratbagd API version is 1 but we require 2 even though libratbag was also replaced with aur/libratbag-git
EDIT: aur/piper-git or more precisely aur/libbratbag-git hasn't been updated/fixed in 5 years either, I got extra/solaar working though.
I tried
aur/piper-gitbut it seems broken compared toextra/piper, I getratbagd API version is 1 but we require 2even though libratbag was also replaced withaur/libratbag-git
This github has the latest code. I suggest you look at some docs on how to pull the latest code from these and built libratbag/piper yourself. AUR has nothing to do with this, AUR is your distro's package manager. Pre-packaged distribution packages are very convenient and usually reliable, but it is not guaranteed to have the latest code. You will learn much, have fun.
I know how to compile from source and/or make/update a PKGBUILD, but I prefer not to use source packages if avoidable. I got Solaar to work which is good enough, if Piper gets an update I'll try it out.
I know how to compile from source and/or make/update a PKGBUILD, but I prefer not to use source packages if avoidable. I got Solaar to work which is good enough, if Piper gets an update I'll try it out.
OK, again, the PKGBUILD system is specific to Arch and builds the code they have in their repository, which still won't be the latest. Has nothing to do with pulling down the current state of the code and building it yourself. But hey, if you can't be arsed, and Solaar is working for you, all's well that ends well.
I tried aur/piper-git but it seems broken compared to extra/piper, I get ratbagd API version is 1 but we require 2 even though libratbag was also replaced with aur/libratbag-git
It's likely old ratbagd still running in the background, you can stop it with 'systemctl stop ratbagd' or restart your PC and it will work.
@ShayBox - there is another issue that i think has bitten many people, including myself
the doc for ratbagctl states that it writes to the active profile on the mouse by default, but that is not necessarily the case
also $ ratbagctl <device> profile active get can actually return an inactive profile
so the 'trick' is to set another profile as active and then test if changes to it affect the currently active profile
a potential solution i haven't really played with yet is to delete all but 1 profile and see what happens
did a little playing around to try and nail this down...
$ ratbagctl warbling-mara profile active get
2 # <-- wrong - profile 1 is the active one
$ ratbagctl warbling-mara profile 2 get
Profile 2: (disabled) (active) # <-- how can it be disabled and active?
$ ratbagctl warbling-mara profile active set 2 # <-- tested 2 and confirmed it was the wrong profile
$ ratbagctl warbling-mara profile active set 1
$ ratbagctl warbling-mara profile active get
1 # <-- now it picks up correct profileunfortunately there seems to be other issues with piper's support for the g502 x other than the 404 image - libratbag supports it fully, but piper does not
i'm actually writing some documentation for how to program the mouse absent piper - if anyone is interested, let me know and i'll link it when it's done
Did you ever finish this writeup?
unfortunately there seems to be other issues with piper's support for the g502 x other than the 404 image - libratbag supports it fully, but piper does not
i'm actually writing some documentation for how to program the mouse absent piper - if anyone is interested, let me know and i'll link it when it's doneDid you ever finish this writeup?
I'd like a comprehensive guide too. Although from my memory, even the command line tool has trouble keeping profiles straight, which are active, which changes are going into, etc. It's extremely laborious. If someone has it all figured out, it shouldn't be too difficult to write some wrapper script or something. I've given up on the thing and went back to my Corsair (ckb-next works well.)
@DylanChuckry @mercster - i finished my little guide long ago - the link is earlier in this thread
again, ratbagctl may not write to the selected profile on the mouse, but other than that it works ok - you may have to switch profiles after writing to see which one it wrote to - as i recall it write to the selected profile +1
@DylanChuckry @mercster - i finished my little guide long ago - the link is earlier in this thread
again, ratbagctl may not write to the selected profile on the mouse, but other than that it works ok - you may have to switch profiles after writing to see which one it wrote to - as i recall it write to the selected profile +1
Ahh yes, you're right, this is what I saw... it's not a full "guide" but enough to figure it out but.. yeah, the way it treated the current profile, active profile, it seemed to still jump back and forth and act in indeterminate ways. I appreciate your write up and I did start working at it, but honestly, in the end I just figured, I'll use mice that have better support and stick this in a drawer, maybe someday libratbag/piper/et al will be up to snuff. Thanks.
ratbagctl supports the mouse fine, it's just a matter of figuring out which profile it writes too - i think if you activate the lowest profile (i forget if it's 0 or 1) before writing, then you can count on the next one in line as being the one it wrote to
don't be afraid of the command-line stuff - once you figure it out, it's all very simple
don't be afraid of the command-line stuff - once you figure it out, it's all very simple
It's simple, but laborious. It's not so much a matter of being "afraid of the command-line stuff", but a cost/benefit analysis for someone who has limited time during a day. It would take me a few hours to set up scripts for 4 or 5 profiles, figuring out the keyscan codes I'd need to send, figuring out how the "pauses" work for timed macros... and then doing more work the next time I need another profile. It's laborious, especially when I have a mouse that is easy to program with a GUI (I'd rather use the Logitech, but the gap in functionality isn't that great.)
None of this is your fault of course, and I'm glad you figured out a system. Do you have any scripts you've written that contain the ratbagctl commands that reprogram the mouse for every "profile" you need? Posting those might at least give a template for others to go in and edit for their purposes. This was my goal original goal, set up some scripts that obfuscated the confusing way profiles work and presented the end-user with a consistent way, and then handle whatever f^&*ery was needed with the ratbagctl commands internal to the script(s).
My first step I actually got done, I figured out which mouse button was which "label" according to libratbag, I'll try to attach it to this message. Another problem I noticed was, every time I connected the mouse, libratbag assigned it a new "random label" that you needed to use with ratbagctl to tell the system which mouse you wanted to work on. I didn't know what the purpose of this was, or how easy/hard it would be to work around.
It's simple, but laborious.
agreed!!! the lack of good documentation + lengthy commands + figuring out the key codes is a pain in the ass
Do you have any scripts ...
negative, but i think it would be easy to write one along with a config file for storing profiles - can't say i'll do that, but i might :)
...every time I connected the mouse, libratbag assigned it a new "random label"...
hmmm, that's weird - i haven't dis/re-connected to check that (a bit of a pain in my case) - you should be able to use 'Logitech G502 X' instead (including the quotes)
@mercster - are you linux or windows? if the former, which DE?
Not sure why I'd be here if I was in Windows :) ... but I run KDE. I ran GNOME 0.x -> 1.x -> 2.x until it got goofy.
oh that's right, both piper and libratbag are linux only - i thought ratbag was x-platform
if you run anything other than arch or a derivative thereof, let me know what OS you're using as well as the path and file name of the key code file (Manjaro, and i assume Arch, is /usr/include/linux/input-event-codes.h)
i think i'll write that script which should make programming the mouse much easier
anyone else can provide the same info if interested
if you run anything other than arch or a derivative thereof, let me know what OS you're using as well as the path and file name of the key code file (Manjaro, and i assume Arch, is /usr/include/linux/input-event-codes.h)
The event codes should be the same regardless of distro... what would be useful is a script that asked: "OK what input would you like [Mouse Key 3] to be?" And then depending on user input, you would translate that into the specific keycodes ratbagctl wanted.
(To be fair even I wouldn't go that far, it'd require some doing.. of course this is what piper is for but, apparently none of those devs have a G502X for testing.)
Oh and having a look back at your document, I see that "warbling-mara" is the "nickname" the driver gives the mouse. I was thinking a script would need to poll the device and include that nickname when calling the ratbagctl command to set things, but if you can just use 'Logitech G502 X' that'd be easier... the documentation says it wants that randomly generated signifier (looking at the source, there's a couple of arrays they use, why the device gets a new random one at each connect, including reboots, I have no idea. Maybe if you have more than one connected, which seems like it would be a real outlier.) At any rate, I haven't looked at it in a few months.
the keycodes may be the same, but the path and file name isn't across OSs and i'm planning on grabbing that file so the user can easily figure out what the key names are, thus i would need to know the OS, path and file name
or...
if the keycodes are the same across OSs (EN vs non EN? i dunno), that would make it a lot easier, sans special keys like multimedia or keypad keys which not every board has
and yes, 'Logitech G502 X' can be used instead - i just tested
the keycodes may be the same, but the path and file name isn't across OSs and i'm planning on grabbing that file so the user can easily figure out what the key names are, thus i would need to know the OS, path and file name
What do you mean 'grab that file'? I think they are the same across all languages (I see nothing in the source that indicates not... the source is in English so just start with that.) You could include the keycodes in your script, it'll be the same for everyone. Honestly, first what would be useful the most to everyone (I think) is to get the different profiles worked out... abstract the profile labels 1-2-3-4-5 for the user so they don't have to memorize whatever goofy order things get applied when a script is run.
My other idea, since I couldn't figure out the way profiles were working, was just always use profile 1. This would necessitate someone running a script (whatever-application-mouse-profile.[sh|py]) every time they needed to switch profiles, but it's better than the alternative. Just ideas mind you, do whatever you think is best.
if the keycodes are the same across OSs (EN vs non EN? i dunno), that would make it a lot easier, sans special keys like multimedia or keypad keys which not every board has
Netch on stackoverflow:
These values are abstraction of keys as they are placed on a typical physical keyboard (see ISO 9995), after abstracting from all interface details (see e.g. three PC scancode sets and other mesh). But this does not take alternative layouts into account yet, neither national layouts like AZERTY nor special ones like Dvorak. They are implemented on the next layer, where independent keycodes are affected by modifiers and translated to resulting strings and events.
Not sure libratbag is taking any of that into account, I'd just target whatever your own locale is first.
and yes, 'Logitech G502 X' can be used instead - i just tested
That's useful then! In your document you use the randomized signifier, so I wasn't sure and was already thinking in my head how to solve that when I was looking at this a few months ago.
Oh and every single Linux system in existence will have /usr/include/linux/input-event-codes.h.
EDIT: Ok maybe not embedded systems, containers, etc. But most any desktop system.
for all interested, i've got a bash script working that loads profile configs from ini files - it can also set the active profile and print device info
i can't figure out is how to set the 'sniper' resolution - for ex., if button 4 is bound to 'resolution-alternate', how do you define what resolution is used while it's pressed?
for all interested, i've got a bash script working that loads profile configs from ini files - it can also set the active profile and print device info
i can't figure out is how to set the 'sniper' resolution - for ex., if button 4 is bound to 'resolution-alternate', how do you define what resolution is used while it's pressed?
I think I saw these in the source somwhere for libratbag, I'd have to take a look. Sorry for late reply.
there's instances of resolution-alternate and RESOLUTION_ALTERNATE in several of the files, but i didn't find how it's actually set
some stuff i tried...
ratbagctl 'Logitech G502 X' profile 1 resolution alternate get
ratbagctl 'Logitech G502 X' profile 1 resolution-alternate get
ratbagctl 'Logitech G502 X' profile 1 button 4 action set special dpi set 800
ratbagctl 'Logitech G502 X' profile 1 button 4 action set special resolution-alternate set 800