[Guide]Making the Logitech G510 Work On Linux!

Question

Update April 23, 2015: I've got a new keyboard (Corsair K95) so I personally probably won't touch this code ever again if I can help it, however it should be working just fine in it's current state without my dabbling, I've set the code up so that the macros are recorded to script files in /usr/share/g15daemon/macros/ with a provided example script, it should be easy enough to read or modify, and if desired the scripts can be replaced by custom executables. When the buttons on the keyboard are pressed they execute these scripts with a command line argument corresponding to the current M-Key state (so we have different functions for M1, M2 and M3 keys), but I thought this was the easiest and most versatile approach, I feel I've got a lot more freedom to customize the macro keys than I ever did in windows this way. As for the MR Key, it is functioning in that it will record a macro (through Xev) and output it to a text file: /usr/share/g15daemon/macros/Macros by running the MacroRecord script located at /usr/share/g15daemon/macros/MacroRecord, you need to ensure that these scripts are made executable when you install this (unless you use my custom pkgbuild on arch which does this automatically) to use these recorded Macros you just have to copy them over to one of the other scripts (for the respective key you wish to use). The Macro Recording script works for recording most normal macros, but if you try to break it, you will (You should be able to use up to 4 modifier keys on one button press (for a total of 5 buttons held down) without running into any problems, as a limitation) but this script is not complex so it should be easy for anyone using it to open it up and try to improve it or increase the amount of modifier keys supported per macro.
I was working on a Qt5 application that would allow these files to be edited through a Qt based GUI, which also shows the macros recorded by MR for easily copying them over and saving the file. Everything is done except the save function, if someone asks me in a message, I will finish this application for them or send them the source code once I get it.
Latest Source (Comes with Arch PKGBUILDs, install with makepkg -i)
Older Source (Before I coded in the MR key)
Source of Qt GUI Front-End (I never finished this program, you need qt-creator to open these source files and finish them yourself. Without this program you can just manually edit the files in /usr/share/g15daemon/macros as described below, the only parts that haven't been coded in yet are the save code, and the test button code. It should be easy to do though, there is example code in the saveFiles function which you can use to finish it (comment this function out if you want to compile it before you finish up coding it, this function breaks the code since it is not written in functional code) if you just adjust it based on the loadFiles function that is above it which does work for loading all the files, it should be pretty easy to finish this program up. If you finish coding it, feel free to send me a message so that I can link to your complete sources instead. These sources I'm releasing in public domain (do whatever you want with them) but Qt5 is LGPL 3.0 licensed.)
There is now a wiki page for this, but it's content is slightly different from this thread and doesn't offer much support for other distributions.
I have a logitech G510 keyboard, and 2 years back I spent about a week applying several patches I had scoured from around the net as well as making my own modifications as needed to make this work with the old g15daemon drivers (as in, I forked g15daemon, without actually changing the programs name). An alternative to this method is using the gnome15 project (just as g15daemon it is no longer being developed) but I had severe (and quite unacceptable) input lag when I used gnome 15 as well as other major issues and as such I vastly prefer my own method. (Besides I worked hard to make this work, I was toying with source code in a programming language I am not really familiar with (C) and did so non-stop for a week, it'd be a total waste if it wasn't better than the alternative!)
And on february 11th 2015 I made yet another update to these drivers that made them significantly easier to use (before this time, the source code had to be manually edited and the drivers had to be then recompiled ino rder to edit the functionality of the G-Keys (not to mention the source code was an ugly mess because of this roundabout approach) this had to be done because the g15macro part of g15daemon never worked well with this keyboard, so I decided to hardcode the keys into the drivers as a temporary solution, now I've found a more permanent solution which is redirecting the keypresses to bash scripts. One script file for each button, I will explain how to do this later on.
Here is the  original thread I made on this if anyone wants to see the ugly mess I went through to get here, luckily that's far behind me now and the code is getting more and more mature over time as I fix it little by little.
How to do it:
What you will need to do is apply these patches for libg15 and g15daemon. (If you want to do it the hard way, use the older Hardcode Patch but I don't recommend it unless you really know that you want it, and know why you want it.)
This can be done on any distro I would assume, for gentoo refer to this thread. To get the sources Download this (latest source) and extract it with unrar, (on arch use makepkg -i to install) in the following order: "libg15 -> libg15render -> g15daemon -> g15stats" (Note: You can edit the macros in the macros folder before installing g15daemon. If you are not on arch you need to manually copy the macros folder to /usr/share/g15daemon/macros/, otherwise the pkgbuild will do it for you. If you are running in another distro you can delete the PKGBUILD file in the folders. I included the unmodified libg15render and g15stats too for the sake of convenience, and as a safety net if they disappear off the face of the internet, which is what they seem to be about to do. If you do not feel like trusting the sources I provided then fear not! the ones I provided are just the original sources (md5sum should match with those found there) (as development for the project seems to have been dropped and these were the final versions ever made) but I assure you, the sources I provided are the original ones downloaded straight from sourceforge. If you are on arch you can use ABS to get the sources from the official repositories and then replace the PKGBUILDs with the ones in my rar (or change them yourself, see wiki). If you want to download your own sources (remember to get my patches too!) then here is an alternative download for the default macros.
Note: In the arch package there were other patches(config-write, recv-oob-answer and uinput) in the package in the official repositories, I added these three to my own file to avoid clutter, the first two are the first two entries of my file, the third is at line 40-71 (two entries) as a part of the same file where I coded in the G-Keys. Depending on your distro and how you get your hands on the sources you may have to adjust this as these patches may already have been applied for you (meaning mine will fail to patch because of mismatching sources). I have no idea what these patches are actually for (would be nice to know) but I imagine they're there for a reason and as such stuck with them.
For other distros figure out how to compile packages from the sources (sorry Arch and Gentoo are the only distros I really use so I can't help with others, but I assure you this can be done on all distros. If it comes down to it ask on their forums for help!)
In the libg15 patch I disabled support for other keyboard models in the first few lines (you will see which if you read the patch) as I suspect many of the changes made might break support for the other devices, but if you want to take your chances just remove the minus sign in front of the device you want to use and hope for the best. If you have a keyboard that was already supported by these drivers, the biggest benefit of getting my version working would be the smoother G-Key functions (since they aren't run through a third party program like g15macro, it's bound to be a little faster and less prone to bugs.) also if you have a G510s and want to try these drivers on that board, you will have to add your keyboards id into this section (or replace the one I added with the appropriate ID for your board) using lsusb to find the right values.
I couldn't get g15macro to work properly with my keyboard and noticed several issues with it (it seemed like it was underdeveloped to me) so my solution to that problem was originally to hardcode the G-key functionalities into the base drivers; But later on I realized I could instead redirect the code to script files that I would create outside of the install, to avoid the load of pain that comes with hardcoding something you may frequently want to change. These drivers are run as root and as such you must be careful and use sudo where applicable to run the commands as your user rather than as root. By default all G-Key presses will be read as commands from the user with uid "#1000", which is in most cases the first user account created on the system. The bonus from this approach is that the G-Keys work much faster than they would using the g15macro and they are also much more customizable than they ever were in windows, the minus is that you need to know/learn bash/shell scripting in order to use it this way. That or find a way to edit the script files to be in a programming language you understand, but bash scripting is the most convenient since you get all the versatility of a terminal in your keyboard that way.
To change the colors of your keyboard you need to edit the libg15.patch file below line 338 (//Set keyboard color based on M led state.) The code there uses the basic RGB format, and each M-Key has it's own line. The default is: Dark-ish Blue(M1/Fallback), Dark-ish Red(M2), Dark-ish Green(M3)
To change the macros, you can (if you installed with my pkgbuild on arch) go to /usr/share/g15daemon/macros/ and within you will find 19 files, an "Example" file (this is like a backup, it's what can be used to reset files back to their defaults if you get lost.) The files are named after the keys they affect, each file has statements for M1, M2 and M3 and then a few extras for errors that uses libnotify for error messages. The default setup also uses libnotify to tell you which key was pressed, and which key was released. If you are not on arch or gentoo and could not install directly from my sources, you will need to either copy the files from my rar to "/usr/share/g15daemon/macros/" and edit them from there, or create them yourself from scratch on that path (the names of the scripts are G# where # is the number of the key, make sure that the files are executable with chmod +x if you are more advanced, you can edit the g15daemon.patch file if the location of the macros isn't to your liking and change the path to the scripts to something more convenient for you (e.g. ".../.config/g15daemon/")
By default, the scripts will look something like this:
#!/bin/sh
declare -i mkey=$(( $2 + 1 ))
declare -r key="G1"
#M1
if [[ "$1" == "on" && $2 -eq 0 ]]; then
/usr/bin/notify-send $key: 'M'$mkey', state='$1
elif [ $2 -eq 0 ]; then
/usr/bin/notify-send $key: 'M'$mkey', state='$1
fi
#M2
if [[ "$1" == "on" && $2 -eq 1 ]]; then
/usr/bin/notify-send $key: 'M'$mkey', state='$1
elif [ $2 -eq 1 ]; then
/usr/bin/notify-send $key: 'M'$mkey', state='$1
fi
#M3
if [[ "$1" == "on" && $2 -eq 2 ]]; then
/usr/bin/notify-send $key: 'M'$mkey', state='$1
elif [ $2 -eq 2 ]; then
/usr/bin/notify-send $key: 'M'$mkey', state='$1
fi
#Else (Errors)
#If there is no input
if [[ -z "$@" ]]; then
/usr/bin/notify-send $key": Error!" 'There was no input'
fi
#If M key state is out of range (less than zero or more than 2)
if [[ $2 -lt 0 || $2 -gt 2 ]]; then
/usr/bin/notify-send $key": Error!" 'There is no M'$mkey'! (State='$1')'
fi
#If the first input variable (on/off) is incorrect. This should never happen.
if [[ -n "$1" && "$1" != "on" && "$1" != "off" ]]; then
/usr/bin/notify-send $key": Warning!" '"'$1'" is not a valid state! (M'$mkey'), defaulting to "off".'
fi
And here is an example of how the M1-M3 keys could be edited in this file. The "if" statements are events that occur when you press down on the button, and the elif statements are for the key release.
#M1
if [[ "$1" == "on" && $2 -eq 0 ]]; then
thunar /mnt/stash/movies & disown
fi
#^elif is not needed and can be erased for this command to avoid the notification of key-release. The & disown part is extremely important, if you forget to add this to the end of every line where you execute a program that will keep running after you release the button, you will not be able to use any G-Keys until you terminate the program. If you remember to add the & disown, everything will be fine.
#M2
if [[ "$1" == "on" && $2 -eq 1 ]]; then
xdotool keydown Ctrl && xdotool keydown Page_Down
elif [ $2 -eq 1 ]; then
xdotool keyup Ctrl && xdotool keyup Page_Down
fi
#^The above executes the keyboard combo Ctrl+Page Down (Next Tab) and holds these buttons down until your key release is detected.
#M3
if [[ "$1" == "on" && $2 -eq 2 ]]; then
xdotool keydown Super && xdotool keydown F1 && xdotool keyup Super && xdotool keyup F1
fi
#^The above is my keyboard shortcut for changing workspaces, (Meta + F1-F6), since I won't ever need to hold these buttons down, I set them up to press and release on keydown, with no need to detect the key release, this is good to do to avoid a bug I mention lower in the guide.
That's the gist of it, all you need to know. You can test-fire the commands in your terminal before you add them to the files. Recompiling and re-installing the G15Daemon (at least on arch) will overwrite your existing macros in /usr/lib/g15daemon/macros. Last but not least, you should remember the sleep command (for example, to restart g15daemon, do g15daemon -k && sleep 5 && g15daemon this is how you can set up timed commands and macros on your G-Keys as well. I may later on develop a GUI front-end for editing the macros, and program the MR-key to work like it does on Windows, but right now I'm satisfied with what I've got, so that will have to wait.
You need to know:
-The g15daemon service should be started after X11/Xorg-Server is started or any commands that require X (like opening a folder, or graphical notifications) will not work. (You can either just wait till you log in and use xinitrc or an autostart script for your desktop environment to start the service, or you can set up a restart script which kills the original instance (g15daemon -k) and starts a new one, this may be good to know if you would like the service to be started on bootup so you wont have to look at white leds until you have logged in. You can use sudo to run these services as a user). You can also try to have the g15daemon initiate after your display manager loads. (For example make the initscript depend on kdm if you're using kde, I have not tried this though)
Add this to the sudo configuration with visudo so you can run the g15daemon with sudo and no password (this should work on most distros, if not find the executable, could be in sbin (is on gentoo) like so: "/usr/sbin/g15daemon")
ALL ALL = (root) NOPASSWD: /usr/bin/g15daemon
(You can replace the first "ALL" with a username or % group if you want to limit the command to just one user)
-I have not tested the headphone/mic plugs on the keyboard (please do comment your results if you try to use that)
-This is not completely bug free.
-There is no support for tracking launched/focused application and changing the M-Key mode depending on what you are doing (this would be useful though)
-The MR key is not supported, but the LED works.
Known Issues: (ordered by severity, if you want to contribute fixing these issues is the best thing you can do to help as I seem incapable of it)
Sometimes the Key Release of G keys is not detected (this means if you have a key bound to the button that is held until the key is released, the release may not be detected properly. This only happens if you press the key quickly, not if you hold it for a short period before releasing it this is solved by either pressing the key again, or not relying on the key-release state, the latter is fairly easy to do as you can use "variables" and "if"s and "do/while" or "for" in C to set keys with toggle functions.
Keypress detection for the G-Keys isn't 100% reliable, it will work completely fine 95% of the time or so, but sometimes (usually only if a G key has not been pressed in a while) the key needs to be pressed twice (This was much worse when g15macro was used and the keys almost always had to be pressed twice if I recall correctly). This may look like it's a huge bother at first, but really I hardly ever notice this when I'm using the keyboard and it is a very rare occurance.
The Volume Wheel is erratic, I used patches from the net to make the wheel work but the wheel was unusable, I managed to make it just barely usable but I wouldn't call it "reliable" in it's current state. It does however work "ok". The wheel worked fine with generic keyboard drivers so maybe there is something in there to shed light on how to make them properly work (remember that there was a bit in libg15.c that made the wheel work, the other half of it is in uinput.c)
The M-Key leds (M1, M2 and M3) will not light up until a G-Key or one of the M keys is pressed (very minor, I tried to fix this but failed, gave up since it's not really important)
Run "g15daemon -d" for debug mode to see output from the driver when it is running you will repeatedly get the following error, I have no idea what this is but I do not like it
libg15: Unknown usb error: Keyboard Read !! (err is -75 (Value too large for defined data type))
look around line 471 of the patched libg15.c to see where the error is being printed from.
Terminating the g15daemon (g15daemon -k) will render the keyboard unusable and can result in bugs (for example your next keypress may be detected but release will not be detected) so be careful when doing something like that. Unplugging the keyboard and plugging it back in solves this issue.
Scroll-Lock led does not work (this is not specific to this keyboard, it is a Linux problem and affects all keyboards as far as I am aware)
I personally prefer using this keyboard in Linux over using it in Windows because of how much more configurable it is (there's nothing I can't do with the press of a button now) and switching workspaces with just one button each for a total of 6 is a joy!
Feel free to comment below with any questions or thoughts, any suggestions to improve the code or other contributions are greatly appreciated! I am not skilled in C programming and as such some of my code may look hideous to those who would know what they're doing so better ways to achieve the same results will not be ignored either and I will add any significant updates to the OP when I see them.
Good Luck and Enjoy
PS: I know the libg15 patch is rather "unclean" (contains a lot of redundant patches, i.e. replacing a line with the same line) but I was too lazy to clean it up. I tried once but it did not work out so well
If you have a G510s and this did not work for you, I may be able to help you get that working, comment if you want help with that (the first step to try is on the wiki)
Last edited by rabcor (2015-05-08 14:41:34)

Answer 1

Major Update: The G-Keys can now be edited without recompiling by editing shell scripts at "/usr/share/g15daemon/macros/"
Each button has it's own script file named by it's label (e.g. to edit the functionality of G1, open the script named G1.) The button will try to execute the scripts as programs, so make sure they are executable (chmod +x) and as long as the name remains the same, if you want to replace the files with something different, know that the arguments currently given to the files ($1 and $2) are ($1)on/off and ($2)0-2  (where 0 is M1 and 2 is M3)
To download the updated sources, go here (only the g15daemon source/patch was updated). This thread's OP has been updated.
Last edited by rabcor (2015-02-12 04:46:48)