My mom prefers the old typewriter-style caps/shift behavior: pressing shift drops the caps lock. I couldn't find an xkb option for this, so I wrote a small option (attached), which I activate as shift:breaks_caps option. Wouldn't be such option useful to include in xorg? (my proposed file probably needs reworking, though).
Created attachment 8301 [details] shift:breaks_caps option
Committed! Enjoy:) Thanks.
The implementation of the [shift:breaks_caps] option seems to be buggy. When I use it in Ubuntu 8.04 together with [caps:shiftlock] the ShiftLock is only released by pressing Shift _shortly_. And even then only capitalization is released, but the Caps LED remains ON. I have an inverse function of the Caps LED until I run through the whole procedure again. This old typewriter-style caps/shift behaviour is very important for acceptance of Linux/Ubuntu in a commercial context. You can not afford to deal frequently with oRTHOGRAPHICAL pROBLEMS in office life ... Can you fix this problem ? Thanks, Reinhard
> The implementation of the [shift:breaks_caps] option seems to be buggy. When > I use it in Ubuntu 8.04 together with [caps:shiftlock] the ShiftLock is only > released by pressing Shift _shortly_. Not exactly. It is just released on key release. If you look at http://pascal.tsu.ru/en/xkb/gram-action.html, there is a line: "if clearLocks=yes and between press and release of this key no one other key has been pressed the same modifiers will be removed from locked modifiers too.", so actually everything (at least on my system) happens on release, not on press. So, considering the way this option works - it cannot be fixed, I'm afraid. At least not on xk-c but somewhere below in XKB code (which I personally would not like to see "fixed" because it breaks compatibility). > And even then only capitalization is > released, but the Caps LED remains ON. That one I cannot reproduce - the LED on my machine works correctly. Is the issue with LED reproducable on several systems? Can you attach the result of "xkbcomp :0 -xkb out.xkb"?
Created attachment 21877 [details] out.xkb of my AMD 4850 System
Created attachment 21878 [details] out.xkb of my old Athlon System (1GHz)
Created attachment 21879 [details] out.xkb of our Intel Celeron 220 System
> > The implementation of the [shift:breaks_caps] option seems to be buggy. I have to correct myself: the behaviour I desribed appears _without_ the [shift:breaks_caps] option, but with [caps:shiftlock]. The [shift:breaks_caps] together with [caps:shiftlock] option sometimes just disables the Shift releasing function, sometimes it has no effect. > > I use it in Ubuntu 8.04 together with [caps:shiftlock] the ShiftLock is only > > released by pressing Shift _shortly_. > Not exactly. It is just released on key release. If you look at > http://pascal.tsu.ru/en/xkb/gram-action.html, there is a line: > "if clearLocks=yes and between press and release of this key no one other key > has been pressed the same modifiers will be removed from locked modifiers > too.", so actually everything (at least on my system) happens on release, not > on press. So, considering the way this option works - it cannot be fixed, I'm > afraid. At least not on xk-c but somewhere below in XKB code (which I > personally would not like to see "fixed" because it breaks compatibility). Constant action on releasing Shift would be fine. But it doesn't work exactly like that. When I release Shift before (!) typing any Shifted letter it works fine, but the sequence: (a) Lock (release Lock) (B) Shift (C) (release Shift) (D) will not release capitalization. My output is: aBCD, but I would expect it to be aBCd. Why is there a difference in releasing Shift with or without typing a letter in between ? This seems to be a problem with the [caps:shiftlock] option (and others). > > And even then only capitalization is > > released, but the Caps LED remains ON. This appears with Ubuntu 8.04 and the [caps:shiftlock] option (-> see out.xkb of both AMD and Intel). [shift:breaks_caps] has no effect here. > That one I cannot reproduce - the LED on my machine works correctly. Is the > issue with LED reproducable on several systems? Yes. The LED problem seems to appear under Ubuntu 8.04 only, the key release problem is the same on my old 1 GHz Athlon system as on our Intel Celeron 220 D201GLY2A and the new AMD 4850 (Brisbane EE) sytem. And there are numerous complaints describung similar problems in the German forum.ubuntuusers.de , with different kind of equipment. > Can you attach the result of "xkbcomp :0 -xkb out.xkb"? > I'll include all three of them. Thank you for your quick reaction !
BTW, wouldn't it be wise to split the options structure clearly into "CapsLock unlocking" (with shift:breaks_caps in it) and "CapsLock effects" (comprising *only* the effect on different key functions, *no longer* the lock behaviour) ? From a my (user's) point of view this would make things look much clearer. (Despite being a professional I have much problems to understand all the effects, side effects and differences of these caps:xxx options) Moreover, this would enable you to configure the desired behaviour more exactly. (and: could it be an advantage for debugging as well ?) Should I post this suggestion for further implementation ? If so, where ?
@NEEDINFO: Which information is still missing ? If I can provide something please let me know ! Reinhard
Sorry for delay, I remember about your case, I will try to look at it this week.
It seems you're using kbd driver. Would it be possible for you to test evdev driver as well? Also, I'd recommend upgrading to 8.10, to get the latest X drivers. Regarding separating the functions. Functionally, there is no difference. It is only matter of names and structure of base.xml.in. I do not think there is a real need.
I did, but it didn't change things. After changing the "kbd" line for the keyboard towards "evdev" I found the evdev driver in the lsmod listing. But the keyboard behaviour remained absolutely unchanged. >Also, I'd recommend upgrading to 8.10, to get the latest X drivers. We would rather not, since we are dealing with systems in a productive context. Stability over several years is an issue here. We cannot afford to change our running systems every 6 months. Improving the structure isn't mandatory indeed. I suggested it for clarity's sake, since it could encourage the confidence in Linux OS. BTW a faithful function of the "typewriter behaviour" is an issue for acceptance of any Linux system amongst office people (in Europe at least). This includes that the spec clearly should be: 1) make [Lock]: ShiftLock release [Lock]: (nothing) 2) make [Shift]: Shift + release Shiftlock + inhibit ShiftLock ** release [Shift]: release Shift + enable ShiftLock ** this behaviour is contrary to the definition of LatchMods indeed, but it IS important for a good implementation of the desired function. - for ergonomy: only with this strict definition hiting the [Lock] key inadvertently is defused effectively - for acceptance: people are used to a flawless implementation of this feature in the MS-world since DOS times (and they follow the strict one). - for principle: Linux is made for adopting to Human Beeings, not the other way round. But the final "solution" for this problem in most forums is: "you just have to accept it, you can't change it anyway". This I really disagree with. And please remember: literally every Linux user meets the kbd issues. Thank you Sergey. Reinhard
> >Also, I'd recommend upgrading to 8.10, to get the latest X drivers. > We would rather not, since we are dealing with systems in a productive context. > Stability over several years is an issue here. We cannot afford to change our > running systems every 6 months. I totally understand your concerns. But if you have something non-production, just to test things... I am attaching my own configuration. It works (for me) are you want (as I understand): Shift temporarily (while pressed) "pauses" Caps Lock action. The LED is controlled by Caps Lock state, Shift does not affect it. Could you please check it? > BTW a faithful function of the "typewriter behaviour" is an issue for > acceptance of any Linux system amongst office people (in Europe at least). I really cannot make any judgment here. I never actually see anyone using typewriter layout here in Ireland, but it is not a reason to argue. > ** this behaviour is contrary to the definition of LatchMods indeed, > but it IS important for a good implementation of the desired function. > - for ergonomy: only with this strict definition hiting the [Lock] key > inadvertently is defused effectively > "you just have to accept it, you can't change it anyway". > This I really disagree with. Well, I must admit, for some (not yours) X issues there cannot be any other answer. For example, acting on keypress, not on key release..
Created attachment 23184 [details] My simple configuration Try it with evdev driver, on 8.04 or 8.10 system
Thank you Sergey for your respose. I think you are right that this "typewriter" thing is not a problem to _all_ of europe. I just looked a bit left and right and found that it is _not_ a problem in Holland at all. In Germany it certainly is, I counted ±60 threads on ubuntuusers.de , on ubuntu-fr.org I even found ±100 threads (!) and on ubuntu-it.org there are still 5 on particularly this issue. So my impression was biased a bit by my local situation, but it is an issue. There is annother, practical problem: Your attachment arrived here as "attachment.cgi" I just don't know where and how to fit it in. Could you please give me a short HowTo ? Thank you. Regards, Reinhard
In Firefox, when I press "save", it shows the name out.xkb. But anyway, you're ok to save with any name. Then just do "xkbcomp -xkb savefilename :0"
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/74.
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.