Summary: | app-misc/g15daemon-1.9.5.3-r2 stops working after a system update | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | PhobosK <phobosk> |
Component: | Current packages | Assignee: | Tony Vroon (RETIRED) <chainsaw> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | DanielBausch, infernix, lcd, mirabeaj, phobosk, plero_hero, the.root.life, tove |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Patch g15daemon to support EV_SYN after EV_KEY
updated g15daemon ebuild to apply the patch g15daemon uinput patch An ebuild fixing the syn events bug in the old 1.2.7 version A patch fixing the syn bug in the old 1.2.7 version of g15daemon |
Description
PhobosK
2009-10-31 01:15:52 UTC
I also have this bug. I noticed that using xev and pressing many times g15 extra keys in "Xorg.0.log" appears this message: " G15 Extra Keys: dropping event due to full queue!" (In reply to comment #1) > I also have this bug. > > I noticed that using xev and pressing many times g15 extra keys in "Xorg.0.log" > appears this message: > " G15 Extra Keys: dropping event due to full queue!" > Maybe this bug has something to do with the new udev changes and the dropping of keymap handling by hal..... I wrote to the developers of G15 but they seem not to be able to fix it... :( Maybe we do not need g15 daemon anymore and things can be handled by udev rules and the evdev X driver? I will investigate this further next week when i have more time.... Hope till then a developer of the G15 to investigate this problem better :S Created attachment 218094 [details, diff]
Patch g15daemon to support EV_SYN after EV_KEY
I've created a patch that works for me on Debian Sid. It adds EV_SYN events to g15daemon. Please try the attached patch and let me know if this works for you. Thanks for the idea but it does not work. Actually your patch is for the daemon's version of 1.2.7. The current version of the daemon in gentoo is 1.9.5.3 (it lacks the EV_SYN too so I patched it but no diff seen). 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), 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 suprised at the total lack of reaction by the developers :S (http://www.g15tools.com/forum/viewtopic.php?f=9&t=302) Any debug suggestions are welcome. Thanks Created attachment 218621 [details]
updated g15daemon ebuild to apply the patch
Created attachment 218623 [details, diff]
g15daemon uinput patch
Thanks for your patch infernix! I fixed it up and update it to work with the newest g15daemon in portage (1.9.5.3-r2). I confirmed it works and fixed the issue for me. I attached the ebuild that applies the patch and the patch file itself. Put them in the respective portage/files directory. Let me know how it works for you! Now i found what actually happened. The initial problem of g15daemon was that i upgraded it to version 1.9.5.3 and not that i upgraded anything else in the system. When i tried to revert back to version 1.2.7 it did not worked because Xorg was was already updated and this version of g15daemon has a bug in handling uinput key events (the EV_SYN and SYN_REPORT missing), so i decided something else caused the problem. Right at this moment v. 1.9.5.3 has a general keyevent handler issue that has to be resolved by upstream. The ev-syn patch does not work because key events are never handled by the uinput plugin. It could be a system/distro/arch specific issue, because the version works on Ubuntu karmic without any modification. Right now i advise the g15daemon-1.9.5.3* to be masked at least for amd64 because actually it is not stable there. I am attaching an ebuild for version 1.2.7-r2 that fixes the syn bug and adds some extra configuration handling like in version 1.9.5.3 (hotplug and udev rules). It works for me excellent. BTW there is a small change in the syn patch... Created attachment 218665 [details]
An ebuild fixing the syn events bug in the old 1.2.7 version
Created attachment 218667 [details, diff]
A patch fixing the syn bug in the old 1.2.7 version of g15daemon
Are you saying the 1.9.5.3 patch didnt let you use the G* keys? Because I can now, they are now being captured by XEV too. They seem to be, being processed by uinput just fine. I don't think 1.9.5.3 should be masked in amd64, working just fine for me with the above patch.. (In reply to comment #12) > Are you saying the 1.9.5.3 patch didnt let you use the G* keys? Because I can > now, they are now being captured by XEV too. They seem to be, being processed > by uinput just fine. I don't think 1.9.5.3 should be masked in amd64, working > just fine for me with the above patch.. > Well I run 2 PCs with Gentoo 64 and quite different hardware (except of course the G11 kbd). On both of them the daemon's version 1.9.5.3 does not work and as i explained above it has nothing to do with the uinput syn bug... (more info here: http://www.g15tools.com/forum/viewtopic.php?f=4&t=314) I guess there are not much users of G11, G15 etc keyboards respectively of the g15daemon, respectively of the amd64 g15daemon version... but from the 4 users that wrote here 2 have a problem... that is 50%.... is this a stable release situation according to you? Anyway i do not mind what happens to the arch flags... Usually when i have a problem i fixed it for myself and post it here for other users with similar problems... It's their decision what to do in this specific situation.... And what i wanted to add is that lately Gentoo has been accepting releases as stable too easy and that results in too many broken things... That is why people move to Arch etc... Anyway.... So then maybe it doesnt solve the G11 owners problems, but does G15? I did read his and your thread on g15tools, which lead me here. Well i cant argue with the stability of this package. however this seems to be an upstream issue. 1.9.5.3 was released 2008-02-09, it was also there last stable release. Another reason why they probably won't want to downgrade to 1.2.7 is the unknown security exploits detailed in bug 284520.. Lets hope for a stable release from the g15daemon devs. BTW, just to add I had the same issues on my laptop(a secondary PC) just now when using this keyboard. After applying the updated 1.9.5.3 and restarting g15daemon, all my extra G keys can be used, thus it resolved the issue. If anyone else wants to chime in if any of these works for them that'd be great. Thanks I won't argue on the vulnerability issues and security... As i said it is users' choice and having in mind the security issues mentioned by you, I would say that the whole package with all its versions should be masked... Anyway i prefer a fully working keyboard rather than being "protected" of vague, unknown, possible network vulnerability... A home desktop system running a properly configured firewall/hosts.allow etc and used only by family members should be enough protected against the mentioned above "vulnerability"... Anyway I agree with you - let's hope really for an upstream solution for the next version... (In reply to comment #15) > BTW, just to add I had the same issues on my laptop(a secondary PC) just now > when using this keyboard. After applying the updated 1.9.5.3 and restarting > g15daemon, all my extra G keys can be used, thus it resolved the issue. If > anyone else wants to chime in if any of these works for them that'd be great. > > Thanks > OK. 1. Is it a 64 bit system too? 2. What is your kbd model? 3. And can help testing (before you apply the ev-syn patch for 1.9.5.3): Can you see if the: evtest /dev/input/eventX (where X is the registered event when g15daemon is started) produce any output when clicking a G key? If it produces that means it is not the same problem as mine.... Portage 2.1.7.17 (default/linux/amd64/10.0/desktop, gcc-4.3.4, glibc-2.11-r1, 2.6.32-gentoo x86_64) ================================================================= System uname: Linux-2.6.32-gentoo-x86_64-AMD_Phenom-tm-_II_X4_965_Processor-with-gentoo-2.0.1 Timestamp of tree: Fri, 05 Feb 2010 18:30:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [enabled] ccache version 2.4 [enabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4-r1, 3.1.1-r1 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.0-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.4_p6-r1, 1.8.5-r3, 1.9.6-r2, 1.10.3, 1.11.1 sys-devel/binutils: 2.20 sys-devel/gcc: 4.3.4, 4.4.2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=amdfam10 -O2 -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=amdfam10 -O2 -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache distcc distlocks fixpackages news parallel-fetch prelink protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://gentoo.mirrors.tds.net/gentoo http://gentoo.netnitco.net" LDFLAGS="-Wl,-O1" LINGUAS="en en_US" MAKEOPTS="-j10" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/tmp/portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/java-overlay /usr/local/portage/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X a52 aac acl acpi alsa amd64 arts berkdb bluetooth branding bzip2 cairo cdr cli consolekit cracklib crypt cups custom-cflags custom-cxxflags custom-optimization custom-optimizations cxx dbus dri dts dvd dvdr eds emboss encode evo fam ffmpeg firefox flac fng fortran gdbm gif glitz gnome gpm gstreamer gtk hal iconv jpeg kde kdehiddenvisibility ldap libnotify mad mikmod mmx mng modules mp3 mp4 mpeg mudflap multilib mysql ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl pertty png ppds pppd python qt3support qt4 quicktime readline reflection samba sdl session spell spl sse sse2 sse3 ssl startup-notification svg sysfs tcpd thread threads thunar tiff truetype type1 unicode usb visualizations vorbis x264 xcomposite xinerama xml xorg xscreensaver xulrunner xv xvid xvmc zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS 1) Yes amd64 2) Option "xkb_model" "evdev" 3) Yes actually i can see activity in evtest, however i cant in xev, or use it anywhere else without the patch. I guess it is slightly a different issue then you, same as infernix it seems. I also got the same error as Plero H in my xorg log "G15 Extra Keys: dropping event due to full queue!" Well I guess that explains why it didnt fix it for you! I really don't know how to help you further debug this, and im sorry g15tools aren't very useful. Have you tried checking out their SVN? Have you tried updating your kernel, is uinput compiled as a module or directly into the kernel? I'm just trying to think of differences between our builds. >Right at this moment v. 1.9.5.3 has a general keyevent handler issue that has >to be resolved by upstream. The ev-syn patch does not work because key events >are never handled by the uinput plugin. It could be a system/distro/arch >specific issue, because the version works on Ubuntu karmic without any >modification. This does not appear to be a general keyevent handler issue. As I am the sole remaining g15daemon developer, all development occurs on a box running Gentoo on AMD64. The keyboard handler has been stable for quite some time and nobody has been able to replicate the issue you see. It is possible that it is a G11-specific issue, which is troublesome because I don't have that hardware to attempt to replicate your problem. However, the place where that difference would matter most, libg15, makes no distinction between the G11 and the G15v1 when handling keypress events. Also, your debugging information has reported that g15daemon is receiving the correct keypress events from libg15. >Right now i advise the g15daemon-1.9.5.3* to be masked at least for amd64 >because actually it is not stable there. Quite to the contrary, g15daemon-1.9 has been stable for almost two years. It has functioned correctly without issue for thousands of users until the somewhat recent EV_SYN issues apparently caused by changes in systems external to g15daemon. That seems to me to be the definition of stable. I will shortly be releasing a 1.9.5.4 version to rollup the EV_SYN and g15_send_cmd() fixes. I'd like to find and include a fix for your issue as well, but without being able to replicate it that is rather difficult. (In reply to comment #19) > I'd like to find and include a fix for your issue as well, but without being > able to replicate it that is rather difficult. > I am willing to help but i will either need a debug version that will provide you with the info you need or instructions on what exactly you wanna test/reproduce. And please do not get me wrong about all this. I do not question the qualities of the g15tools or whatever... i just found a bug concerning me and probably other users and i wish we could find out the problem and fix it... BTW I have tried every single version above 1.2.7 and they all have the problem... It looks like I have the same problem on a G15: "G15 Extra Keys: dropping event due to full queue!" in Xorg.0.log and the extra keys not working when g15daemon is running. I'm also on AMD64. |