Bug 11790

Summary: Windows compatible caps lock behaviour missing
Product: xkeyboard-config Reporter: Christian Casteyde <casteyde.christian>
Component: GeneralAssignee: xkb
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on: 9546    
Bug Blocks:    

Description Christian Casteyde 2007-08-01 03:03:23 UTC 
Hello,

The X Keyboard Extension has at least one bug and one missing feature in the CAPS lock options. The fact is that it is impossible to get the behaviour of MS Windows XP working in X environment.

First, here is the behaviour of Windows:
CAPS is a toggle that uppercase everithing, but it is NOT a shift (home, end of line, insert, suppr still have their semantics, and are not translated respectively in "select to the begin of line", "select the end of line", "paste the clipboard" and "copy the selection to the clipboard". Moreover, both shift touch can unlock the CAPS lock (as old typewritters).

Now, this is impossible to get with XKB options:
- shiftlock would be the closest behaviour, since Shift unlocks the Shift lock. However, it is a Shift Lock, and it affects Home, End of Line, and so.
- capslock would have the expected semantic, however the shift keys are not CAPS keys and do not unkock the Caps lock.
- internal makes the shift key reverts to original behaviour while it is pressed, but do not unlock the lock.
- other options are not affected by the shift keys.
So, it misses the following option:
- ???, which would be: "Caps lock uses internal capitalization. Shift "cancels" CapsLock.".

Moreover, when I use shiftlock, there is a bug in the Shift behaviour:
a. I press CapsLock -> the keyboard shitch to shift/capitalization.
b. Then I press Shift + 'A'.
What I get is a capitalized 'A', with CAPS lock not unlocked. It should really be: first unlock the CAPS lock as soon as a Shift Key is pressed, the keep the shift state until the Shift key is released. So I should get 'a', with CAPS lock unlocked.

I guess that the missing option for Windows compatibility should behave the same: unlocks the caps as soon as shift is pressed, and do not consume the shift event.

For the records, I found this problem because I tried to switch my father to Linux and he simply cannot use the caps lock key anymore, causing grief and annoyance for me.

Best regards
Comment 1 Sergey V. Udaltsov 2007-08-01 14:59:55 UTC 
Would #9546 help your problem?
Comment 2 Christian Casteyde 2007-08-02 00:47:56 UTC 
The description given in 9546 seems to be the same as my problem.

It may be wise to seperate the shift unlocking behaviour from the caps behaviour, since each key should have its own rules. Moreover, this model is more powerfull, because this enable the use of all the caps option independently from the shift unlocking behaviour. That is, we can keep the local keyboard rules unchanged.

(Linux mapping is by far already better than Windows one for the French layout for example, because the CAPS lock leaves special letters such as capitalized e acute avalaible, and there is no way except Alt+0201 under Windows to get them for example. So uppercasing keys abouve alphabetic could be annoying (that would give numbers, already available in the numpad), even if totally compatible with Windows...)

However, i didn't manage to use the attachment (where should I put it to use this option?) and couldn't test it to see if it is usable for ex-Windows users (the test should be done by my father, not me actually, to be completly sure, me being behind him and hearing him grumbling - or not).
I couldn't test either if the Shift keypress unlocks first and is not consumed.
Comment 3 Sergey V. Udaltsov 2007-08-02 01:31:51 UTC 
ok, I'll first resolve 9546 and you'll see whether it would be good enough for you or not...
Comment 4 Sergey V. Udaltsov 2007-09-26 16:44:34 UTC 
Using shift:breaks_caps should work ok for you now

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.