If I start a session in an Xnest window, my 'm' key doesn't work properly. An m appears exactly every second time I press the key. I went through the Xnest source and found what is happening. In dix/getevents.c, in the routine: GetKeyboardValuatorEvents near line 448, there is a check to see if the event is a KeyRelease of a modifier key. This check is catching the release of the 'm' and interpreting it as the release of Shift_Lock, rather than as m. So I had this print out the keysyms of every keypress, and this routine sees all the keysyms scrambled badly, compared to what's listed keysymdef.h in xproto. Running xev inside the Xnest though sees the correct keysyms - but it only ever sees every second m. I can 'fix' this by simply commenting out the check for the Shift_Lock, but that's obviously not a good fix - it seems the keysym mapping isn't getting set up correctly. I am using xorg-server-1.4.0.90. I tried building current xorg-server from git, but Xnest segfaults on startup: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b52b9e55d10 (LWP 13988)] 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x000000000043abd9 in miPointerDeviceInitialize (pDev=0x967c20, pScreen=0x7aa570) at mipointer.c:269 #2 0x00000000004e513a in ActivateDevice (dev=0x967c20) at devices.c:373 #3 0x00000000004e8145 in InitAndStartDevices () at devices.c:555 #4 0x0000000000501c1e in main (argc=2, argv=0x7ffff348c508, envp=<value
> I tried building current xorg-server from git, but Xnest segfaults on startup: > [...] I just pushed a couple of fixes to Xnest in master. There's a lot of artefacts in the cursor rendering code, but it doesn't crash anymore.
thanks. My keysym problem seems to be be fixed here. Any idea if the fix for this is something easy to backport?
> --- Comment #2 from Carl Michal <michal@physics.ubc.ca> 2008-06-08 22:51:34 PST --- > My keysym problem seems to be be fixed here. Any idea if the fix for this is > something easy to backport? Not sure, I haven't actually looked at the real issue. I have another set of patches to get rid of the artefacts, but I'll try to look at the keysyms problem tomorrow.
Xnest inits the keyboard map by calling XGetKeyboardMapping. This would query the parent server for the current map. Now since this code is only called when xkb is disabled (but the parent server probably doesn't disable xkb) - could it be that it gets the xkb map for a non-xkb server and that puts it out of sync? I'm still a bit hazy on that stuff. (updating version to 7.3, that's what hardy runs)
I tried disabling Xkb in the parent server by adding: Section ServerFlags Option XkbDisable EndSection to my xorg.conf. The problem is still there, although its slightly different. Now an m appears only about every 4th press of the m key, event though xev still sees every press (which it interprets as alternating presses and releases). If I use metacity as a wm inside the Xnest, it does complain that it can't find the XKB extension (regardless of whether its enabled in the parent server).
On Tue, Jun 10, 2008 at 09:57:30AM -0700, bugzilla-daemon@freedesktop.org wrote: > If I use metacity as a wm inside the Xnest, it does complain that it can't find > the XKB extension (regardless of whether its enabled in the parent server). start Xnest with "+kb" on the commandline, that should enable xkb.
if I add +kb my problem goes away... for me that's a completely acceptable work around. In my defense, that option isn't in the man page.
On Tue, Jun 10, 2008 at 09:11:18PM -0700, bugzilla-daemon@freedesktop.org wrote: > In my defense, that option isn't in the man page. Xnest --help lists ist, there may be other options of interest for you there.
commit c42427f63f0e0495e56909ee99ad1e3c4321c39b Author: Ander Conselvan de Oliveira <ander@mandriva.com.br> Date: Wed Jul 9 10:50:21 2008 -0300 Fix incorrect test regarding keyboard map. In the map stored in each keyboard device, the first line refers to minimum keycode, i.e., the 0th line refers to keycode 8. When not using XKB the wrong test caused some keys to be interpreted as locks ('m' for instance). The had to be pressed twice to generate both KeyPress and KeyRelease events. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Backport found in server-1.5-branch, closing bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.