dvorak works fine, but ctrl+<foo> is wrong (not even qwerty)

[Dieter Plaetinck]

Peter Hutterer wrote:
> On Thu, Nov 20, 2008 at 09:24:56AM +0100, Dieter Plaetinck wrote:
>   
>> 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.
>>     
>
> 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.
>
>   
>> * 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
>>     
>
> 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
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>   
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20081125/663d841d/attachment.html>