<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Peter Hutterer wrote: <blockquote cite="mid:20081125104954.GA22284@dingo.unipark.net.au" type="cite"> <pre wrap="">On Thu, Nov 20, 2008 at 09:24:56AM +0100, Dieter Plaetinck wrote: </pre> <blockquote type="cite"> <pre wrap="">I'm using a regular ps/2 azerty keyboard but with dvorak layout. The problem is the dvorak layout by itself works fine, but when I press (and hold) ctrl the other buttons behave totally differently, some seem to be qwerty again but sometimes it's even different. I test this in urxvt and xterm, so no gtk or gnome is involved (not that I know) Examples: (xev output follows later) * ctrl+c becomes ctrl+i (dvorak c is on qwerty i) * ctrl+j on dvorak does not become ctrl+c (what it would be in qwerty). * ctrl+a only produces a ctrl character. </pre> </blockquote> <pre wrap=""> I tried reproducing your problem a few days ago but failed. Please open a bugreport and attach the output of xkbcomp -xkb :0 -. Don't think there'll be anything interesting, but it might be a start. </pre> <blockquote type="cite"> <pre wrap="">* xev ctrl+j KeyPress event, serial 29, synthetic NO, window 0x1c00001, root 0x188, subw 0x0, time 1240357, (171,-26), root:(197,69), state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 32, synthetic NO, window 0x1c00001, root 0x188, subw 0x0, time 1241550, (171,-26), root:(197,69), state 0x14, keycode 54 (keysym 0x6a, j), same_screen YES, XLookupString gives 1 bytes: (0a) " " XmbLookupString gives 1 bytes: (0a) " " XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x1c00001, root 0x188, subw 0x0, time 1241644, (171,-26), root:(197,69), state 0x14, keycode 54 (keysym 0x6a, j), same_screen YES, XLookupString gives 1 bytes: (0a) " " XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x1c00001, root 0x188, subw 0x0, time 1242297, (171,-26), root:(197,69), state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False </pre> </blockquote> <pre wrap=""> at least this one doesn't look weird, the other two are different. Have you tried starting a plain X server with nothing but xterm? Does this reproduce the issue? Cheers, Peter _______________________________________________ xorg mailing list <a class="moz-txt-link-abbreviated" href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </pre> </blockquote> Peter, thank you so much. I've spent way too much time searching in the wrong direction. When starting x with plain xterm/urxvt all was fine, so gradually I could build up my environment and check where it went wrong. As it turned out the culprit is compiz: compiz --replace --sm-disable --ignore-desktop-hints ccp <-breaks keys compiz --replace --sm-disable --ignore-desktop-hints <- doesn't break keys I'll now try to figure out why the 'core plugin' changes my keys (maybe it's me who configured something incorrectly) Thanks, Dieter </body> </html>