Be careful, I am likely to take you up on your offer To be honest, there is lots in Gnome15 that could be done much better. Gnome15 was my 'python learning' project, and there is much I am not proud off. So .. even a second pair of eyes looking making it more pythonic would be great. Also, someone who knows a bit of C/C++ is good to know too. There are some areas of Gnome15 that may benefit from a little native code help. For example, both g15direct and kernel drivers have some slow routines in their paint() functions.



g15-system-service, are you sure? I would expect *g15-desktop-service* to have a load roughly equal to that with non-kernel drivers when you have a reasonably 'busy' Gnome15 setup (e.g. plugins that paint a lot). g15-system-service should be very very lightweight and even then it is only used with kernel drivers. It *could* get high CPU if you have something that rapidly adjusts the keyboard backlight or other LEDs (such as "Impulse" in Disco Mode).

Ok ... so, as I promised elsewhere, I've written a couple of tools to help narrow down where the multimedia keys / G-key problems are coming from.

The first is "libg15test". Just download the attachment somewhere, and run it with :-

python libg15test.py

This one works directly with with libg15 (well, the pylibg15 bindings which is fairly direct). The bit we are interested in the keyboard test (option 6). This will output the keycodes as libg15 interprets them.

The other tool is g15-diag. This works at the Gnome15 driver level, and so depends on your current driver configuration in g15-config. The particular command we want is :-



or



When it tells you too, you can start pressing keys (doing it earlier might cause a crash). The keys this tool outputs are the ones Gnome15 actually uses for macros.

I am interested in knowing :-

1. When running either of these tools. Does G1 also activate 'F1' (e.g. launch Desktop Help)
2. What codes are output from libg15 test when pressing G1
3. What codes are output from g15-diag test when pressing G1
4. What codes are output when using volume knob. And how often.
5. What happens when volume knob is used with none of Gnome15 running







Thanks,


Brett

I missed that. Lol. Sure. *backs away from code*.

Hi i have also the G510 since 2 weeks ago, with no good luck, same problems what the other users are having,

admin wrote:


maybe we can put some $ togetter to send you the keyboard ? it wil be easyer for you i guess,

PS: i'm using Gentoo and debian on two different machines. butt i'm not that of a good programmer to assist you i think...

Unfortunately, I have to take a break. The Space Bar Bug hit me, and I had to send in my G510 for replacement. Bear with me - I will be back soon

This seems to mirror my own experiences on Ubuntu 12.04 Precise Pangolin.

Thanks, but no need now. I've already picked up a reconditioned one on eBay (that will get sold when I'm done with this).

The good news is, I *think* I now know what is happening with at least the G-keys produce F-keys problem.

The story so far ...

The first thing I tried was using Wireshark to monitor the USB traffic. It turns out that the G-keys only (all others are fine) actually seem to send TWO USB interrupts for every key press. All other extra keys just send one. The first is an 8 byte sequence and the second is a 5 byte (all other extra keys send 5 byte sequences).

I wanted to see if this behavior was the same in Windows, so rebooted into that and installed a thing called "USB Trace". I already had "USBlyzer" but the trial on this has expired. So, I now have a 15 days in the trial to fix this

The results in Windows were interesting. If I tried monitoring the USB traffic BEFORE the Logitech Gaming Software was started, the behavior was exactly the same. Two USB interrupts for every key press. Also, with the Gaming software not running, a G1 press does the same as in Linux as presses F1 so the help screen pops up.

If I tried monitoring AFTER the Logitech Gaming Software then only single interrupts were being seen!

Unplugging / plugging in the keyboard again resets this state.

All this implies that the Logitech Gaming Software is sending some magic code to the keyboard to stop it behaving in that way. I suspect this is some kind of fallback mode the keyboard has, so the G keys at least do *something* if no driver software is installed.

I don't believe this issue can (easily) be worked around in either the kernel or the libg15 based driver. It would mean having to take control the main keyboard device from usbhid as well and filter out the additional keyboard presses, while emitting all others. This would be nasty, especially if something hangs or crashes Gnome15, it could take the keyboard down entirely with it.

So that leaves trying to find out what magic codes that are sent by the official Logitech software are, and adding the same thing to both libg15 and the kernel driver.

I will keep working on this, but in the meantime if anyone else wants to pour over the logs produced by USB Trace, and hack a bit on libg15, then these may help and save you having to go into Windows to do the same thing yourself

I'll keep you updated.


www.gnome15.org/logs/g510.xml

Update!

It works I've found the codes that need to be sent to the G510 to turn off the additional events. So far, all the G-key are working properly. A little more work needs to be done to support all of the multimedia keys properly (including the audio mute buttons), and the M-Key LEDs don't work for some reason, but everything else is looking good. The same fixes can also be applied to the kernel driver.