Bug 11516 - ctrl:swapcaps doesn't work (fully) correctly
Summary: ctrl:swapcaps doesn't work (fully) correctly
Status: RESOLVED NOTABUG
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: xkb
QA Contact:
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-09 15:20 UTC by Mohammed Adnène Trojette
Modified: 2007-09-01 06:50 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Mohammed Adnène Trojette 2007-07-09 15:20:11 UTC
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
Comment 1 Sergey V. Udaltsov 2007-07-09 15:28:20 UTC
If you output your XKB configuration using "xkbcomp :0 -xkb out.xkb" - is there any difference in mapping between keys 1 and 2?
Comment 2 Peter Baumann 2007-08-11 06:29:14 UTC
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?
> 

Comment 3 Sergey V. Udaltsov 2007-08-14 14:41:10 UTC
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?
Comment 4 Peter Baumann 2007-08-14 21:47:47 UTC
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.
Comment 5 Sergey V. Udaltsov 2007-08-15 01:06:10 UTC
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.
> 

Comment 6 Peter Baumann 2007-08-15 04:19:07 UTC
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.
Comment 7 Peter Baumann 2007-08-15 04:26:29 UTC
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.
Comment 8 Sergey V. Udaltsov 2007-08-15 05:07:17 UTC
> 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.

Comment 9 Peter Baumann 2007-09-01 06:50:42 UTC
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.