Re: AllowEmptyInput and HAL (SOLVED!!!)
Finally solved, after something like 60 hours of hacking. My libX11.so was old. This caused xkbcomp to fail to parse the keymap files - it didn't recognise ISO_Level5 stuff. It looks like xkbcomp generated a keymap with some sort of Any+Any definition that caused every key to toggle the modifiers. This morning I attempted to purge and re-install all of my X-related Debian packages. I got rid of the server stuff but I couldn't get rid of the client libraries because that would cause huge numbers of client programs to be removed too. But I didn't worry about that because the problem was clearly on the server side. I eventually latched on to the level 5 warnings and started looking for them with strings. Then ldd on xkbcomp pointed at the guilty library. I'm surprised that it didn't work with the xserver that I built using khbuild. Presumably this is because that was still using libraries from /usr/lib, not the ones that it had just built and put somewhere in $HOME. Is that an rpath issue with khbuild? What can we learn? - Debian needs a more strongly-versioned dependency between some of its packages. I'll take that up with them (if the appropriate people are already reading this, please let me know). - xkbcomp, when called by the server, claims that xkbcomp errors are not fatal to the server. And only some of its messages appear in the X log file. I feel that this particular error should be considered fatal. And ideally, the consequence of an unrecognised keysym should not be the Any Key effect that I got. (Is the person responsible for xkbcomp reading this?). Thanks to those of you who helped with suggestions. Regards, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL (SOLVED!!!)
Phil Endecott wrote: Finally solved, after something like 60 hours of hacking. My libX11.so was old. This caused xkbcomp to fail to parse the keymap files - it didn't recognise ISO_Level5 stuff. It looks like xkbcomp generated a keymap with some sort of Any+Any definition that caused every key to toggle the modifiers. This morning I attempted to purge and re-install all of my X-related Debian packages. I got rid of the server stuff but I couldn't get rid of the client libraries because that would cause huge numbers of client programs to be removed too. But I didn't worry about that because the problem was clearly on the server side. I eventually latched on to the level 5 warnings and started looking for them with strings. Then ldd on xkbcomp pointed at the guilty library. I'm surprised that it didn't work with the xserver that I built using khbuild. Presumably this is because that was still using libraries from /usr/lib, not the ones that it had just built and put somewhere in $HOME. Is that an rpath issue with khbuild? What can we learn? - Debian needs a more strongly-versioned dependency between some of its packages. I'll take that up with them (if the appropriate people are already reading this, please let me know). From the way you've described it, it sounds like you've uncovered a bug in an old version of libx11. If this is the case, then why does Debian need stronger versioned dependencies between the server and this lib? That's not a versioning issue after all, that's just a normal bug. The X server doesn't actually require the newer library version. - David Nusinow ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL (SOLVED!!!)
On Fri, May 8, 2009 at 10:46 AM, Phil Endecott spam_from_x...@chezphil.org wrote: Finally solved, after something like 60 hours of hacking. My libX11.so was old. This caused xkbcomp to fail to parse the keymap files - it didn't recognise ISO_Level5 stuff. It looks like xkbcomp generated a keymap with some sort of Any+Any definition that caused every key to toggle the modifiers. This morning I attempted to purge and re-install all of my X-related Debian packages. I got rid of the server stuff but I couldn't get rid of the client libraries because that would cause huge numbers of client programs to be removed too. But I didn't worry about that because the problem was clearly on the server side. I eventually latched on to the level 5 warnings and started looking for them with strings. Then ldd on xkbcomp pointed at the guilty library. I'm surprised that it didn't work with the xserver that I built using khbuild. Presumably this is because that was still using libraries from /usr/lib, not the ones that it had just built and put somewhere in $HOME. Is that an rpath issue with khbuild? It's because xkbcomp links with libX11.so, not the server. However, if you built xkbcomp and Xlib from jhbuild, it should pick up the new Xlib during the xkbcomp build. And libtool usually adds a rpath if it detects one of the libraries is outside of the standard linker path. You'd have to inspect what jhbuild is doing if that's not the case. What can we learn? - Debian needs a more strongly-versioned dependency between some of its packages. I'll take that up with them (if the appropriate people are already reading this, please let me know). - xkbcomp, when called by the server, claims that xkbcomp errors are not fatal to the server. And only some of its messages appear in the X log file. I feel that this particular error should be considered fatal. And ideally, the consequence of an unrecognised keysym should not be the Any Key effect that I got. (Is the person responsible for xkbcomp reading this?). No one is really responsible for xkbcomp currently. The entire interaction with xkbcomp by the server is a complete eye sore. I've been working to make this go away, but it took a lot of surgery and hasn't been reviewed yet. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
