I have written a basic kernel module driver for the G13. It would be nice to make it work with g15daemon and the other g15tools. http://eutyche.swe.uni-linz.ac.at/g13/
Didn't get it working with the latest revision (r531). What happened was
- evtest reports events only after pressing 3-4 keys. With the joystick it reports events on every move.
- g15test reports every press, however they are all unknown keys
- I used the xmodmap config in contrib/, then replaced the keys with letters and such, however it didn't work
I've just ordered the g13, because I thought it would be detected like a normal joystick/HID device...that will be the first and last time that I've buyed something without looking if it works with linuxoid systems ootb.
However: I'm thankfull that there are ppl like you who know how to deal with such stuff an giving it to other ppl.
Hoper your driver works. Do I only need to install the g15daemon or do I've to compile this one (http://www.nexoid.at/g13/), too?
...
Hoper your driver works. Do I only need to install the g15daemon or do I've to compile this one (http://www.nexoid.at/g13/), too?
You only need g15tools and g15daemon, this complete different, g15tools are running 100% in userspace using libusb, while the nexoid driver is a kernelmodule that supports the load of keymap.
My G13 is not working with SVN 321 on Debian x86_64... some little problems i allready solved in my privat experimental version i use since last autumn.
I wrote a patch for SVN 321 and send it to aneurysm9, hoping that the night i spend was not meaningless.
With this patch i have only a few problems and TODO's left:
LED/Backlight control has to be implemented ("monitored" on windows, to get the right control codes)
First Keystroke is not recogniced after load of g15damon (maybee some trouble with wrong LED/Backlight control)
Some optimisation with a flag i guessed as "Next report is ready"
Joystick and its keys have to be implemented (my idea is to creade a getPressedKeyEx with a unsigned long * for pressed keys and use the jostick like a hud switch, looks easy but i need at least support of g15daemon)
That driver is different from the G15Tools system. I don't think they play well together. I have recently committed a patch to libg15 that should add G13 support to G15Tools. If you can try building libg15 from SVN and let me know if g15daemon then works it would be greatly appreciated.
okay, I've compiled the libg15 and the daemon and started the daemon.
I got the clock and yeh...that's all. Light goes on and off (that was even possible without the g15tools/lib) but now it is green, not white (and I can't change it).
no key reacts on pressing it...at least I don't get an output in xev and in games it doesn't work, too. The joystick is not detected (at least Vendetta Online does not detect it) so...yeh...something is wrong here I guess ;)
*edit
I tested the tool from the nexoid website and it worked :)
I think I forgot to add the usbhid thingi to the modprobe file...
nah. still nothing.
*edit2
okay...that's funny: I rebooted my PC and after that, the g13 driver from nexoid was not able to detect the g13.
I tried and tried but nothing...after a while I remembered the only "real" difference between the first time it worked and now: I used your g15daemon and killed it...30 minutes later I used the g13 driver.
I tried that again: loading g15daemon, killed it and loaded the g13 driver and...yeh, it worked.
kinda strange...
oh and what's really cool: the g13 supports the joystick of the g13...
If I can do further tests with your driver, could you say how? In this thread are some logmessages (for the light for example) that are showing keycodes, I don't get those log messages...
You can get debugging output from g15daemon by running it with -d 10 for lots and lots of verbose cruft. At some point I'll have to take a look at what the other g13 driver is doing differently. Maybe I can figure out why the keys aren't responding.
...as in the subject field, I think I know why they don't respond.
When using the g13 driver, I've to load a "keymap" into the device. The keymap consits out of the hexadecimal numbers of the keys from /usr/src/linux/include/linux/input.h.
(which is annoying, because you've to use existing keys. When using a "real" joystick, you've "special" keys which are only used by the joystick...)
an exact description is on the website of the driver, I'll quote it here:
/sys/kernel/g13/keymap
This sets the keymap for all the keys and buttons on the G13. The values are four digit hexadecimal integers representing the keycodes (from /usr/src/linux/include/linux/input.h) that the respective key or button sends. The values are in order:
Key Explanation
G1 - G22 The Gxx keys
Button-Left The button to the left of the stick
Button-Down The button below the stick
Button-Stick The button that is activated when pushing the stick hard
M1 - MR The Mx keys
Next The round key to the left of the LCD
Left The leftmost key right below the LCD
Left-Center The second-to-left key right below the LCD
Right-Center The second-to-right key right below the LCD
Right The rightmost key right below the LCD
Light The key that toggles the LCD backlight, with a small sun on it
Thanks for the patch. I've applied it with minimal formatting changes and committed it to SVN, bumping the version number to 1.3 in the process. Please let me know if it works for you and maybe we can have a long overdue next release shortly :)
For the joystick, it's analogic so the values depend on the position, you might want to use it as a mouse and you can guess the speed like halfway up and left would be bd, 39.
I guess you can just set the values to the max or detect some middle values to send up down left or right
For the light, if I activate the light on the pad, the value for G15_KEY_LIGHT is returned with the value for the key pressed :
Nice! Real nice, you make me want to go buy a G13 :) (Now if only Logitech would lower the price for the G19 to something reasonable and it too had a linux interface..)
The issue you run into with the enum is most likely due to the format used, 1<<32 would simply shift the 1 bit too far and it would come back on the other side, equaling 1<<0. If there's a way to tell it that the enum is 64bits long instead it would give you an additional 32 keys to work with, which would be sufficient.
BUT, there may be other limitations like the variable size used in various applications might be 32 bits when it asks for the keycode, could be a hassle. (For example g15macro, but if that's the only case then It's easy to change)
Joystick - well, is the middle positions useful? If so i would go check up on writing it to actually work as a joystick. Else i would put it as keys, but since you said it did return codes for when the joystick was in a middle position I think it would do better as a joystick.
Also, the light question, could you rephrase it so my feeble mind understands it :p?
I've worked on integrating the g13 into libg15 and so far I'm confident this will work.
I added the entry in the devices list and I watched what it gave me with testlibg15
I had to add me in the usb group in order to be able to read the inputs being a user
for now I get all the keys except the joystick to produce an expected output with testlibg15 :)
the keyboard return 9 byte on a key pressed but it is not like previous implementation:
the buffer[0] is 0x25 so it could not get into processKeyEvent9Byte
So I added a test on this byte in getPressedKeys and made a function processKeyEventG13 to parse the output.
buffer[1] and buffer[2] are the joystick position :
buffer[1] is for left and right from 0(left) to ff(right)
buffer[2] is for up and down 0 for up and ff for down
the rest position is in the middle with something like 80-80
the remaining buffer is for the buttons, I used the kernel module code and libtestg15 to find them.
buffer[8] is always to 1, I didn't find what it could be used for.
There are 3 keys I couldn't add to the enum, gcc told me it's to short to add them it's commented for now, it is for the two buttons around the joystick and the joystick button itself
I don't know how to handle the joystick so any help is welcome
The LCD screen is working fine, I recompiled g15daemon and g15daemontest, I had some nice output :)
Is it normal that the code for light is always sent if the light is turned on ?
I've just bought a g13, and after reading your post I think could help you enhancing the driver, I'm not really a linux kernel driver developer but anyway I know how to write some code :) and really looking forward to do something about this project :)
did you push your code to the svn ? I've just pulled it but I don't find any mention of the g13 inside
Also if you have some links about hal/udev/ ... and what can be done to make this work.
I tried to build the g13 kernel module but I have an error and didn't have the time to look at it seriously, but I'll look how it is done.
Who is interested in developing / expand the driver with me? The display works fine. I have problems with ubuntu 9.10 Karmic with reading the pressed key. I think it is a problem of the privelegs - defined by udev.
Please contact me!
cu forscher
Man you have odd timing... I was just going to ask if you could post a patch against the libg15 source.
At first look, I don't think it would be too difficult to take craven's kernel driver and take the key parts and integrate them into libg15. (Which IMO is a better solution than trying to fix the kernel drivers so that they don't cause evdev and thus xorg to crash on a keypress - it's a lot easier to work in userspace! Plus ecraven seems to have gone missing.)
Main tasks for keys look like:
1) Add the G13's device ID
2) Add some enumerations in libg15.h for the extra G keys going up to 22
3) It looks like the G13 returns 8 bytes, so add an 8-byte handler to the existing 9-byte and 5-byte handlers
4) Maybe some g15daemon tweaks?
5) Ignore the analog stick return at first, deal with that later or write a crude handler that maps it to keypresses for each quadrant if the x/y axis values are far enough from center. Eventually I'd love to see the option of using it as either:
a) keypresses
b) joystick
c) mouse in a manner similar to eraser sticks on laptops - Windows G13 drivers don't do this one.
I haven't had time to do much more than a cursory look-over of ecraven's kernel driver and libg15 so far though.
Aneurysm9: As far as I can tell, the G15_DEVICE_5BYTE_RETURN flag doesn't actually do anything in your code? It looks like the handler is chosen not based on this flag, but on how many bytes come out of the USB interrupt in getPressedKeys?
Probably irrelevant as the capabilities member of libg15_devices_t is an int not a char - plenty more space for new flags. I'm guessing the G13 will require completely different illumination handling code and hence a COLOR_BACKLIGHT capability flag. G15 has independent monochrome brightness for LCD and keys, G13 has an RGB backlight that is common to both keys and LCD. Thinking about how to do that cleanly makes my head hurt so I'll leave that to someone else for now. :P
I'm going to browse through the code some more this afternoon, probably do a first go at changes on my desktop, and then test on my laptop. (Minimize the chances of a G15 vs. G13 conflict on the desktop while I debug, once the 13 is debugged I can test it for conflicts with my G15v1.)
Hi,
I need help. I am sitting in front of a big elephant and don't know to eat it:
I use Ubuntu Karmic and no pressed key of G13 reached the daemon. I search a solution for 6 weeks, learned much about udev/evdev/usb/hal and so on but I never reached the aim. I saw the pressed keys in the hiddev-file ...
I think that I have to configure something in an udev-rule, so hal know how to handle the G13 as standard input instead of usb hid raw data device. But which has to be written in the file ...
while I search a G13 driver I found this thread. :)
I looked into both sources and start to expand the g15tools for G13. I integrate the produkt ID etc. and write a new function for 8-byte messages.
The display works now. The G-keys don't work because the pressed keys never reach the daemon. I use ubuntu karmic (developing this G13 support leaded me from ubuntu 8.04 to karmic - discovering xorg.conf + xmodmap to hal + evdev incl. devicekit + udev).
If I will managed the keystrokes I have to change the key offset addresses in g15daemon code, so 22 G-keys will be supported (maybe this should be defined in a h-file).
The stick is a different topic. It is an analog stick and so there is to support the analog function and the function to translate this into keystrokes. The user should have the choice what he needs.
Do you have some links where I could get some more information about hal/devicekit/evdev/udev?
Very cool, I hadn't heard about that. The starting point would be libg15. The LCD seems to be of the same size, so I'd presume it uses the same format. The main difficulty will probably be the G keys as libg15 only enumerated 1-18. Constants for the new keys will need to be added in libg15.h and getPressedKeys() may need to be updated. If the key data packet is 9 bytes then the existing method can be updated, otherwise a new method will be needed to handle the key data packets. If that all works you should then be able to run g15daemon. Let me know if you have any luck!
Tested latest version
Didn't get it working with the latest revision (r531). What happened was
- evtest reports events only after pressing 3-4 keys. With the joystick it reports events on every move.
- g15test reports every press, however they are all unknown keys
- I used the xmodmap config in contrib/, then replaced the keys with letters and such, however it didn't work
just ordered the g13...
hi there,
I've just ordered the g13, because I thought it would be detected like a normal joystick/HID device...that will be the first and last time that I've buyed something without looking if it works with linuxoid systems ootb.
However: I'm thankfull that there are ppl like you who know how to deal with such stuff an giving it to other ppl.
Hoper your driver works. Do I only need to install the g15daemon or do I've to compile this one (http://www.nexoid.at/g13/), too?
Driver from nexoid is incompatible to g15tools and g15daemon
You only need g15tools and g15daemon, this complete different, g15tools are running 100% in userspace using libusb, while the nexoid driver is a kernelmodule that supports the load of keymap.
My G13 is not working with SVN 321 on Debian x86_64... some little problems i allready solved in my privat experimental version i use since last autumn.
I wrote a patch for SVN 321 and send it to aneurysm9, hoping that the night i spend was not meaningless.
With this patch i have only a few problems and TODO's left:
LED/Backlight control has to be implemented ("monitored" on windows, to get the right control codes)
First Keystroke is not recogniced after load of g15damon (maybee some trouble with wrong LED/Backlight control)
Some optimisation with a flag i guessed as "Next report is ready"
Joystick and its keys have to be implemented (my idea is to creade a getPressedKeyEx with a unsigned long * for pressed keys and use the jostick like a hud switch, looks easy but i need at least support of g15daemon)
If someone wants the diff, send me PM
Emmo
Why does a chicken cross the road?
Hello, I did not had the time
Hello, I did not had the time to work on this.
But I'd like to have your patch and test it on my setup.
I don't know how to pm you through drupal and it seems a little bit broken :/
Apparently I missed this
Apparently I missed this patch. Can you send it again and we'll see if we can't get a version of libg15 working with the G13. Thanks!
libg15 SVN
That driver is different from the G15Tools system. I don't think they play well together. I have recently committed a patch to libg15 that should add G13 support to G15Tools. If you can try building libg15 from SVN and let me know if g15daemon then works it would be greatly appreciated.
RE: G13 on Linux
okay, I've compiled the libg15 and the daemon and started the daemon.
I got the clock and yeh...that's all. Light goes on and off (that was even possible without the g15tools/lib) but now it is green, not white (and I can't change it).
no key reacts on pressing it...at least I don't get an output in xev and in games it doesn't work, too. The joystick is not detected (at least Vendetta Online does not detect it) so...yeh...something is wrong here I guess ;)
*edit
I tested the tool from the nexoid website and it worked :)
I think I forgot to add the usbhid thingi to the modprobe file...
nah. still nothing.
*edit2
okay...that's funny: I rebooted my PC and after that, the g13 driver from nexoid was not able to detect the g13.
I tried and tried but nothing...after a while I remembered the only "real" difference between the first time it worked and now: I used your g15daemon and killed it...30 minutes later I used the g13 driver.
I tried that again: loading g15daemon, killed it and loaded the g13 driver and...yeh, it worked.
kinda strange...
oh and what's really cool: the g13 supports the joystick of the g13...
If I can do further tests with your driver, could you say how? In this thread are some logmessages (for the light for example) that are showing keycodes, I don't get those log messages...
Debugging
You can get debugging output from g15daemon by running it with -d 10 for lots and lots of verbose cruft. At some point I'll have to take a look at what the other g13 driver is doing differently. Maybe I can figure out why the keys aren't responding.
I think I know why...
...as in the subject field, I think I know why they don't respond.
When using the g13 driver, I've to load a "keymap" into the device. The keymap consits out of the hexadecimal numbers of the keys from /usr/src/linux/include/linux/input.h.
(which is annoying, because you've to use existing keys. When using a "real" joystick, you've "special" keys which are only used by the joystick...)
an exact description is on the website of the driver, I'll quote it here:
/sys/kernel/g13/keymap
This sets the keymap for all the keys and buttons on the G13. The values are four digit hexadecimal integers representing the keycodes (from /usr/src/linux/include/linux/input.h) that the respective key or button sends. The values are in order:
Key Explanation
G1 - G22 The Gxx keys
Button-Left The button to the left of the stick
Button-Down The button below the stick
Button-Stick The button that is activated when pushing the stick hard
M1 - MR The Mx keys
Next The round key to the left of the LCD
Left The leftmost key right below the LCD
Left-Center The second-to-left key right below the LCD
Right-Center The second-to-right key right below the LCD
Right The rightmost key right below the LCD
Light The key that toggles the LCD backlight, with a small sun on it
# set my custom dvorak keymap
echo "003b 003c 002d 0033 0020 003d 003e 003f 0040 001e 0027 0023 0041 0042 0043 0035 0030 0017 0044 000e 001c 0039 0110 0111 0112 0002 0003 0004 0005 0006 0007 0008 0009 000a 000b " > /sys/kernel/g13/keymap
http://www.nexoid.at/g13/
yeh, I can test your tool
yeh, I can test your tool first ;).
I should be able to test it tomorrow because the package with the g13 arrives tomorrow
Re: Driver for G13
Thanks for the patch. I've applied it with minimal formatting changes and committed it to SVN, bumping the version number to 1.3 in the process. Please let me know if it works for you and maybe we can have a long overdue next release shortly :)
Re: Driver for G13
For the joystick, it's analogic so the values depend on the position, you might want to use it as a mouse and you can guess the speed like halfway up and left would be bd, 39.
I guess you can just set the values to the max or detect some middle values to send up down left or right
For the light, if I activate the light on the pad, the value for G15_KEY_LIGHT is returned with the value for the key pressed :
light on
light off
Arg, the value for buffer[0] has changed, now it returns 3b ....
Re: Driver for G13
Nice! Real nice, you make me want to go buy a G13 :) (Now if only Logitech would lower the price for the G19 to something reasonable and it too had a linux interface..)
The issue you run into with the enum is most likely due to the format used, 1<<32 would simply shift the 1 bit too far and it would come back on the other side, equaling 1<<0. If there's a way to tell it that the enum is 64bits long instead it would give you an additional 32 keys to work with, which would be sufficient.
BUT, there may be other limitations like the variable size used in various applications might be 32 bits when it asks for the keycode, could be a hassle. (For example g15macro, but if that's the only case then It's easy to change)
Joystick - well, is the middle positions useful? If so i would go check up on writing it to actually work as a joystick. Else i would put it as keys, but since you said it did return codes for when the joystick was in a middle position I think it would do better as a joystick.
Also, the light question, could you rephrase it so my feeble mind understands it :p?
Re: Driver for G13
Hello again,
I've worked on integrating the g13 into libg15 and so far I'm confident this will work.
I added the entry in the devices list and I watched what it gave me with testlibg15
I had to add me in the usb group in order to be able to read the inputs being a user
for now I get all the keys except the joystick to produce an expected output with testlibg15 :)
the keyboard return 9 byte on a key pressed but it is not like previous implementation:
the buffer[0] is 0x25 so it could not get into processKeyEvent9Byte
So I added a test on this byte in getPressedKeys and made a function processKeyEventG13 to parse the output.
buffer[1] and buffer[2] are the joystick position :
buffer[1] is for left and right from 0(left) to ff(right)
buffer[2] is for up and down 0 for up and ff for down
the rest position is in the middle with something like 80-80
the remaining buffer is for the buttons, I used the kernel module code and libtestg15 to find them.
buffer[8] is always to 1, I didn't find what it could be used for.
There are 3 keys I couldn't add to the enum, gcc told me it's to short to add them it's commented for now, it is for the two buttons around the joystick and the joystick button itself
I don't know how to handle the joystick so any help is welcome
The LCD screen is working fine, I recompiled g15daemon and g15daemontest, I had some nice output :)
Is it normal that the code for light is always sent if the light is turned on ?
I created a patch here : http://nopaste.info/edfafe8f74.html
it maybe needs some review
I still have to try it with g15daemon
Re: Driver for G13
Hello,
I've just bought a g13, and after reading your post I think could help you enhancing the driver, I'm not really a linux kernel driver developer but anyway I know how to write some code :) and really looking forward to do something about this project :)
did you push your code to the svn ? I've just pulled it but I don't find any mention of the g13 inside
Also if you have some links about hal/udev/ ... and what can be done to make this work.
I tried to build the g13 kernel module but I have an error and didn't have the time to look at it seriously, but I'll look how it is done.
Thank you
Re: Driver for G13
Who is interested in developing / expand the driver with me? The display works fine. I have problems with ubuntu 9.10 Karmic with reading the pressed key. I think it is a problem of the privelegs - defined by udev.
Please contact me!
cu forscher
Re: Driver for G13
Man you have odd timing... I was just going to ask if you could post a patch against the libg15 source.
At first look, I don't think it would be too difficult to take craven's kernel driver and take the key parts and integrate them into libg15. (Which IMO is a better solution than trying to fix the kernel drivers so that they don't cause evdev and thus xorg to crash on a keypress - it's a lot easier to work in userspace! Plus ecraven seems to have gone missing.)
Main tasks for keys look like:
1) Add the G13's device ID
2) Add some enumerations in libg15.h for the extra G keys going up to 22
3) It looks like the G13 returns 8 bytes, so add an 8-byte handler to the existing 9-byte and 5-byte handlers
4) Maybe some g15daemon tweaks?
5) Ignore the analog stick return at first, deal with that later or write a crude handler that maps it to keypresses for each quadrant if the x/y axis values are far enough from center. Eventually I'd love to see the option of using it as either:
a) keypresses
b) joystick
c) mouse in a manner similar to eraser sticks on laptops - Windows G13 drivers don't do this one.
I haven't had time to do much more than a cursory look-over of ecraven's kernel driver and libg15 so far though.
Aneurysm9: As far as I can tell, the G15_DEVICE_5BYTE_RETURN flag doesn't actually do anything in your code? It looks like the handler is chosen not based on this flag, but on how many bytes come out of the USB interrupt in getPressedKeys?
Probably irrelevant as the capabilities member of libg15_devices_t is an int not a char - plenty more space for new flags. I'm guessing the G13 will require completely different illumination handling code and hence a COLOR_BACKLIGHT capability flag. G15 has independent monochrome brightness for LCD and keys, G13 has an RGB backlight that is common to both keys and LCD. Thinking about how to do that cleanly makes my head hurt so I'll leave that to someone else for now. :P
I'm going to browse through the code some more this afternoon, probably do a first go at changes on my desktop, and then test on my laptop. (Minimize the chances of a G15 vs. G13 conflict on the desktop while I debug, once the 13 is debugged I can test it for conflicts with my G15v1.)
Re: Driver for G13 - Help wanted!
Hi,
I need help. I am sitting in front of a big elephant and don't know to eat it:
I use Ubuntu Karmic and no pressed key of G13 reached the daemon. I search a solution for 6 weeks, learned much about udev/evdev/usb/hal and so on but I never reached the aim. I saw the pressed keys in the hiddev-file ...
I think that I have to configure something in an udev-rule, so hal know how to handle the G13 as standard input instead of usb hid raw data device. But which has to be written in the file ...
Help!
cu forscher
Re: Driver for G13
Hi,
while I search a G13 driver I found this thread. :)
I looked into both sources and start to expand the g15tools for G13. I integrate the produkt ID etc. and write a new function for 8-byte messages.
The display works now. The G-keys don't work because the pressed keys never reach the daemon. I use ubuntu karmic (developing this G13 support leaded me from ubuntu 8.04 to karmic - discovering xorg.conf + xmodmap to hal + evdev incl. devicekit + udev).
If I will managed the keystrokes I have to change the key offset addresses in g15daemon code, so 22 G-keys will be supported (maybe this should be defined in a h-file).
The stick is a different topic. It is an analog stick and so there is to support the analog function and the function to translate this into keystrokes. The user should have the choice what he needs.
Do you have some links where I could get some more information about hal/devicekit/evdev/udev?
cu :D
Re: Driver for G13
Very cool, I hadn't heard about that. The starting point would be libg15. The LCD seems to be of the same size, so I'd presume it uses the same format. The main difficulty will probably be the G keys as libg15 only enumerated 1-18. Constants for the new keys will need to be added in libg15.h and getPressedKeys() may need to be updated. If the key data packet is 9 bytes then the existing method can be updated, otherwise a new method will be needed to handle the key data packets. If that all works you should then be able to run g15daemon. Let me know if you have any luck!