Here is a Debian bug report (#410060): From: Peter Baumann <waste.manager@gmx.de> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: xkb-data: ctrl:swapcaps doesn't work (fully) correctly Date: Wed, 07 Feb 2007 13:10:17 +0100 Package: xkb-data Version: 0.9-4 Severity: normal I'm having a strange problem concerning my keyboard setup. Let me describe: I have fvwm-crystal installed with 4 virtual desktops and setup a mapping by <ALT>+<CTRL>+1 do move the active window onto the virtual desktop 1 (of course, pressing <ALT>+<CTRL>+4 moves the window to desktop 4). If I setup my xkb config like this: $ setxkbmap -v Trying to build keymap using the following components: keycodes: xfree86+aliases(qwerty) types: complete compat: complete symbols: pc(pc105)+us geometry: pc(pc105) it works as expected. But as I like to have Caps_Lock as an additional CTRL Key, I run $ setxkbmap -layout us -option ctrl:nocaps $ setxkbmap -v Trying to build keymap using the following components: keycodes: xfree86+aliases(qwerty) types: complete compat: complete symbols: pc(pc105)+us+ctrl(nocaps) geometry: pc(pc105) and now Caps_Lock behaves like CTRL. I can move my window to every desktop *except* to desktop 1. That means pressing the keys <Caps_Lock>+<ALT>+1 does nothing. But pressing <CTRL>+<ALT>+1 behaves as it should. (so does <Caps_Lock>+<Alt>+2..4) If I could do anything more specific to resolve this issue feel free to ask. -Peter Baumann I don't now if it's usefull, but I attached the output of xev pressing <CTRL>+<ALT>+1 because <Caps_Lock>+<ALT>+1 had _NO_ output. [... snipping uninteresting stuff ...] KeymapNotify event, serial 15, synthetic NO, window 0x0, keys: 4294967218 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyPress event, serial 29, synthetic NO, window 0x2400001, root 0x4d, subw 0x0, time 2618586448, (-321,-257), root:(780,588), 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 0x2400001, root 0x4d, subw 0x0, time 2618586469, (-321,-257), root:(780,588), state 0x14, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False FocusOut event, serial 32, synthetic NO, window 0x2400001, mode NotifyGrab, detail NotifyAncestor ConfigureNotify event, serial 32, synthetic YES, window 0x2400001, event 0x2400001, window 0x2400001, (1101,845), width 178, height 178, border_width 0, above 0x8194ca, override NO PropertyNotify event, serial 32, synthetic NO, window 0x2400001, atom 0x191 (_WIN_AREA), time 2618591573, state PropertyNewValue FocusIn event, serial 32, synthetic NO, window 0x2400001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 32, synthetic NO, window 0x0, keys: 2 0 0 0 32 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyRelease event, serial 32, synthetic NO, window 0x2400001, root 0x4d, subw 0x0, time 2618591841, (-321,-257), root:(780,588), state 0x1c, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: KeyRelease event, serial 32, synthetic NO, window 0x2400001, root 0x4d, subw 0x0, time 2618591850, (-321,-257), root:(780,588), state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- debconf-show failed Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>: Bug#410060; Package xkb-data. Full text and rfc822 format available. Acknowledgement sent to Peter Baumann <siprbaum@stud.informatik.uni-erlangen.de>: Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available. Message received at submit@bugs.debian.org (full text, mbox): From: Peter Baumann <siprbaum@stud.informatik.uni-erlangen.de> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: Re: Bug#410060: xkb-data: ctrl:swapcaps doesn't work (fully) correctly Date: Fri, 9 Feb 2007 16:25:43 +0100 I could reproduce this behaviour on a etch machine at the university having a session which only starts xev and no windowmanager. I get no output for <Caps_Lock>+<Alt>+1 there, too. There are also some Sun PC's (Opterons) with sun keyboards. On that machine it works as expected if I run setxkbmap -layout us -option ctrl:nocaps I don't know if the xserver uses a different mapping for those sun keyboards. Perhaps this gives someone a clue what's wrong. -Peter Baumann
If you output your XKB configuration using "xkbcomp :0 -xkb out.xkb" - is there any difference in mapping between keys 1 and 2?
Ok. After looking for around 10 minutes in this file, I really can't find the info you are looking for. I put the output you asked on a website [1], because I was not sure what the policy here is for big attachments (>40k). I'll add it here as an attachment, if it is wanted/allowed. Just in case, the output was procudeced on an up-to-date debian unstable computer. Peter [1]: http://wwwcip.informatik.uni-erlangen.de/~siprbaum/out.xkb(In reply to comment #1) > If you output your XKB configuration using "xkbcomp :0 -xkb out.xkb" - is there > any difference in mapping between keys 1 and 2? > (In reply to comment #1) > If you output your XKB configuration using "xkbcomp :0 -xkb out.xkb" - is there > any difference in mapping between keys 1 and 2? >
Funny enough, I just loaded your out.xkb to my X server (so my configuration is exact copy of yours) - and Ctl-Alt-1 works the same way as Ctl-Alt-4 (I mean, both work correctly). It is not reproducable for me :( Also, looking at out.xkb itself, I see keys 1 - 4 are really same. There must be something with fvwm. May be, you'd try reproducing the behavior with other WM/app?
Ok. I tried it again here with an empty session consisting only of an xterm, no window manager involved. And <Key labeled CTRL>+<ALT>+1 produces some output in xev, whereas <Key labeled CapsLock>+<ALT>+1 does not. If this would only appear on my pc, I'd say I messed up with the xkb files (had some errors there from a packaging bug and had to fix those), but I double checked on another computer at universitity, (also with a session only consisting of an xterm) and it was totally reproducible. So blaming the window manager should be ruled out. From your comment it doesn't stand out if you pressed <CTRL>+<ALT>+1 or <CapsLock>+<ALT>+1, because only the later fails to produce the keysym ctrl+alt+1.
Interesting enough. What version of xkeyboard-config do you have? Though ... It should not matter - because once you created out.xkb, xkeyboard-config is not involved any more (and your version works ok for me). May be, there is something special about your X server? What version is it? Sure I pressed Caps-Alt-1. (In reply to comment #4) > Ok. I tried it again here with an empty session consisting only of an xterm, no > window manager involved. And <Key labeled CTRL>+<ALT>+1 produces some output in > xev, whereas <Key labeled CapsLock>+<ALT>+1 does not. If this would only > appear on my pc, I'd say I messed up with the xkb files (had some errors there > from a packaging bug and had to fix those), but I double checked on another > computer at universitity, (also with a session only consisting of an xterm) and > it was totally reproducible. So blaming the window manager should be ruled out. > > From your comment it doesn't stand out if you pressed <CTRL>+<ALT>+1 or > <CapsLock>+<ALT>+1, because only the later fails to produce the keysym > ctrl+alt+1. >
I have a standard Debian unstable here. (those at the uni have Debian Etch) Debian programm versions: xserver-xorg 1:7.2-5 xkb-data 1.0~cvs.20070721-1 Ok. Now wandering off to my brothers Ubuntu Feisty PC to see if I could reproduce it there, too.
Some problem there. Could this be in any way related to the brand of keyboard itself? As I stated, on the sun keyboards at university it worked, but not on those with the FSC keyboards. Me and my brother have one of those FSC keyboads, too.
> Some problem there. Could this be in any way related to the brand of keyboard > itself? It would be difficult to imagine such thing.. > As I stated, on the sun keyboards at university it worked, but not on those > with > the FSC keyboards. Me and my brother have one of those FSC keyboads, too. Well, try to find another keyboard (just for testing) and see whether you see that problem... Really odd one.
Ok. It took me a while to get another keyboard, but I tried this with a logitech keyboard and I can't reproduce the strange behaviour there, so it seems that this is really a hardware problem with the FSC keyboards (I have tried at least 3 of them). So I changed the bug status to "NOTABUG" (not sure if this is the right thing), but at least other people should be able to find this strange hardware problem.
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.