Hi,
When I upgraded my Debian Sid box today I ran into an issue with xorg. My G keys stopped working. From xorg.log:
"G15 Extra Keys": dropping event due to full queue!
After struggling with this for a while, a kind spirit from #debian-x pointed out that it probably wasn't sending EV_SYN after EV_KEY.
Turns out that was indeed the case. Attached is a patch to fix this against current trunk, but can be applied to probably any version of g15daemon.
This should fix a number of issues reported here and there (http://bugs.gentoo.org/show_bug.cgi?id=291244, http://bbs.archlinux.org/viewtopic.php?pid=683942)
enjoy!
Index: g15daemon/g15daemon/g15_uinput.c<br />
===================================================================<br />
--- g15daemon/g15daemon/g15_uinput.c (revision 526)<br />
+++ g15daemon/g15daemon/g15_uinput.c (working copy)<br />
@@ -106,6 +106,14 @@<br />
event.value = G15KEY_DOWN;</p>
<p> write (uinp_fd, &event, sizeof(event));<br />
+<br />
+ /* Need to write sync event */<br />
+ memset(&event, 0, sizeof(event));<br />
+ event.type = EV_SYN;<br />
+ event.code = SYN_REPORT;<br />
+ event.value = 0;<br />
+ write(uinp_fd, &event, sizeof(event));<br />
+<br />
}</p>
<p> void g15_uinput_keyup(unsigned char code)<br />
@@ -118,6 +126,13 @@<br />
event.value = G15KEY_UP;</p>
<p> write (uinp_fd, &event, sizeof(event));<br />
+<br />
+ /* Need to write sync event */<br />
+ memset(&event, 0, sizeof(event));<br />
+ event.type = EV_SYN;<br />
+ event.code = SYN_REPORT;<br />
+ event.value = 0;<br />
+ write(uinp_fd, &event, sizeof(event));<br />
}</p>
<p> #endif
Objective: Hot flush is the
Objective: Hot flush is the most. Generic for premarin. Premarin is the top selling pharmaceutical JN0-350 drug in the United States. You see, Premarin is an estrogen substitute. Natural alternatives exist, but women. Premarin cream. 12 Jul 2009. buy Premarin buy Fosamax buy Danazol buy Prozac buy Inderal. premarin online 650-195 buy Aventyl buy Altace allegra online buy Atarax. 2009 premarin and prempro earnings. Premarin vaginal cream, cozaar, hgh oral spray, zoloft and weight gain. Premarin & synthroid. Maximum NS0-163 intelligence regarding europe premarin. You up to get some report as respects top-catalog as well. Premarin SK0-002 iv for coagulability. CLICK HERE TO BUY PREMARIN ONLINE! High Quality Premarin Only Low Prices
g15daemon/g15_uinput.c not
g15daemon/g15_uinput.c not found. And I can't see this file in latest (1.9.5.3) sources.
UPD: this file is g15daemon/plugins/g15_plugin_uinput.c. Patch successfull, all work (arch x86_64, all latest soft)! Thnx! :)
Re: Patch to add EV_SYN to g15daemon
Hi, this worked for me in Debian SID, building g15daemon from sources (Debian way):
Re: Patch to add EV_SYN to g15daemon
Yes it does check properly and works ok.
Re: Patch to add EV_SYN to g15daemon
One thing you could perhaps test for me is the commit I just made to ensure that g15font support is present in libg15render before building g15daemon. Thanks.
Re: Patch to add EV_SYN to g15daemon
I finally gave up tracing this problem because the code is too untidy and confusing for me.
I found a workaround using the old 1.2.7 version on my Gentoo (see comments here: http://www.g15tools.com/forum/viewtopic.php?f=9&t=302#p1112)
Probably I need to add some clarifying notes i mentioned in my other posts:
1. Everything is done on an amd64 platform.
2. On Ubuntu karmic x86 (my laptop), the unmodified 1.9.5.3 version works as expected.
3. The SVN as of today 12.00 UTC does not work too (actually it has a missing structure for g15font which breaks the compilation but i did worked around that)
4. It turns out that the whole 1.9.5.3 version actually did never worked on my Gentoo PC (see comments here: http://www.g15tools.com/forum/viewtopic.php?f=9&t=302#p1112)
If you need some more code testing of the future versions just let me know.
I will stick to the old 1.2.7 version for now.
EDIT:P.S. BTW there are some hardcoded paths like the pid path etc that i think should be made dependent on the configure build options...
Re: Patch to add EV_SYN to g15daemon
Ok, I take that back again. I don't see what you're seeing. Not really at least. Because the uinput plugin is loaded from the install path rather than the build path, as soon as I ran `make install` the debugging statements in the plugin event handlers appeared.
Re: Patch to add EV_SYN to g15daemon
So, it seems that keyevents() should be registered as the keyboard_handler and called in g15daemon/main.c at line 89. Can you throw some debugging statements in there to see if it is hitting that conditional and, if not, which branch is failing?
Er, nevermind that. I see what you're talking about now. The interesting thing is that the keyboard handler is registered correctly and the function pointer is still pointing at the correct memory address, but it doesn't seem to be called properly. It just returns 0 immediately without executing any code in keyevents().
Re: Patch to add EV_SYN to g15daemon
Hi,
I have already done some tracing/debugging of the whole thing and the problem is that those calls are never hit.
Actually what seems the problem is that the uinput plugin event handler - keyevents() (in fact both plugins that work in advanced mode lack reaction of their event handlers created during initialisation) seems not to work at all (log statement on first line of it). So g15_process_keys() never hit the keyup and keydown calls.
I am still not sure if the g15daemon_send_event() in main.c should get a NULL for lcd->g15plugin->info so it breaks; and does not create a new event.
From the short time i had what i got for all internals is this:
1. When started, the daemon through libg15(through libusb) and the uiplugin ("step" 2 here) creates all the usb/input devices needed - works
2. When initialized the uinput plugin creates the eventX device for the extra keys - works
3. The daemon creates a thread that polls for keypresses the libg15 - this one works
4. When keypress is received during the call in 3, it should be transfered for handling to the keyevents() handler of the uiplugin - this step is broken
5. The keyevents() handler of the plugin creates an event through uinput for the kernel and the rest relying on /dev/input/eventX - this works when called directly simulating a keyup/down event).
Now i am stuck with the problem why the event handler of the plugin (both advanced mode plugins infact) does not respond.
Advice, help ?
Re: Patch to add EV_SYN to g15daemon
Sadly, I'm no mlampard, but I have some understanding of how the internals of g15daemon work. It seems that libusb is not a likely culprit because libg15 is receiving and reporting the keypresses. Unfortunately, this points to the uinput module, which I don't know as well. The g15_init_uinput() method seems to complete without issue as you say the device is created. Can you try putting g15daemon_log() statements before and after each write() call in g15_uinput_keyup() and g15_uinput_keydown(). After verifying that the write() calls are returning immediately, add O_DSYNC to the options when open()-ing uinp_fd in g15_init_uinput(). That should cause the write() calls to block until they are delivered. Let me know if the g15daemon_log() statements after the write calls are still being hit.
Re: Patch to add EV_SYN to g15daemon
Oh ok...
Thanks for the answer...
Till now i actually hoped the programmer will try to do some research and give some hints... but since there is noone anymore... i guess i have to try doing it myself.. probably with some help...
I am also limited by time and do not have much experience in coding kernel level stuff... That is why i stayed with broken G keys :D... but now i guess i have to find some time working on that... I will post here when i find a way to fix it...
Any help will be welcome..
Thanks again.
Re: Patch to add EV_SYN to g15daemon
There has only been one developer to my knowledge actually working on libg15 & g15daemon and the lower parts of it all, mlampard. Sadly he is not active no longer.
Me I can't help you much with these issues, but If you know how to code I'm sure you could read either another keyboard'ish driver to see what they do with uinput to work or try to write one. I'm afraid my time is very limited with regards to programming, and thus can't really do anything of this (besides I have no real knowledge of the underlying architechture).
I was hoping this patch would work for users, since it did for one at least, but so far people do not seem to actually return to see if there has been any progress..
Re: Patch to add EV_SYN to g15daemon
The EV_SYN patch (rev 527) is not fixing the problem that I have reported for Gentoo here and on the Gentoo's bug system (https://bugs.gentoo.org/show_bug.cgi?id=291244).
From my further investigation it turns out that hal, udev, evdev etc has
nothing to do with the problem. In fact the problem is with the uinput<->kernel
communication (could it be because of a libusb version upgrade/conflict
problem? - i have both new and old libusb installed -> 0.1.12 and 1.0.6)
When the G15daemon is started it creates the eventX in the /dev/input tree but
this eventX never receives any changes:
Using the -d 10 option of the daemon shows that event is genereted (libg15:
Keyboard: 2, 1, 0, 0, 0, 0, 0, 0, 0 etc.), but evtest (or cat) of the
dev/input/eventX is always silent no matter what keys are pressed of the extra
G keys.
I guess the whole libg15/g15daemon etc needs a rewrite... and i am surprised at
the total lack of reaction by the developers (http://www.g15tools.com/forum/viewtopic.php?f=9&t=302) :S
BTW are there any active developers at all on this project?
Any debug suggestions are welcome.
Thanks
Re: Patch to add EV_SYN to g15daemon
This is marvellous! Thanks for taking the time to hunt this down.
Applied it to trunk (g15daemon-wip is actually what was used as the 1.9.5.3 release), now i just need some people who have this error to test it out and then see about making a new release.
Applied as of revision 527. People with the "G15 Extra keys: dropping events due to full queue!" issue, please either grab the latest svn or this snapshot and test it out, and report back.