PLZ Fix the CAPS LOCK response time glitch in Linux Distros!
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Your interrupts look good. The only option is probably a preemptable or real-time kernel. What kind of computer and linux distrubtion are you using. It might be that a kernel recompile with the right options is enough.
The OP states that this does not occur in Windows (presumably on the same/similar computer). Ergo, it has nothing to do with interrupts or any other hardware.
The "problem" occurs because in X Caps Lock (and Numlock etc.) are only turned off upon key RELEASE, not key press. You can see this with xev: run xev, turn off all modifiers, press CapsLock (or Numlock), now press and HOLD CapsLock/Numlock and type 'a'. Check the 'state' field, it is still 0x02 (or 0x10 if you pressed Numlock), i.e. CapsLock/Numlock is still active, even though you turned it off (LED should go out), because the state is not updated until you release the key, hence the perceived delay. You'd need to modify the xserver keyboard handling code to 'fix' this.
One thing that I noticed the other day is that I seem to only have the issue when logged into a gui.
Upon doing some research I found out about the kbdrate command and how I could make adjustments there, but I still had my issues.
In the meantime, I have removed the caps lock key from all of my keyboards and I am going to relearn how to type. I figured I might be able to resolve the issue on my install, but I would continue to run into the problem logging into other Linux boxes that are outside of my control.
I guess in the meantime I'll have to deal with typing at 50 wpm.
I am using Mint right now. But it had done this with all distros. Even with BSD if I am not mistaken. Mac and Windows are the only 2 that do not have this problem.
One thing that I noticed the other day is that I seem to only have the issue when logged into a gui.
Obviously. As I said, the issue is caused by the way X handles the modifier keys.
Quote:
Originally Posted by Nylex
Have you already tried reporting the problem to the kernel developers, X developers, or both?
It has nothing to do with the kernel.
Quote:
Originally Posted by cedricsm
If someone can modify a distro to solve this problem, I would pay a it if I have to.
It has nothing to do with any distro, it is the X server. If you feel like recompiling the xserver, here's a quick patch. It makes (should make) {Caps,Num,Scroll,Shift}Lock work on keypress, rather than key release. Caveat: I knocked this out in a couple of minutes so it may not work, or be the best apporach, and/or I may have missed something. This is UNTESTED, use at own risk, etc etc.
Untar the xserver source, cd to source dir (xorg-server-X.Y.Z) and apply with
Code:
patch -p1 -i <filename>
Patch was made against xorg-server-1.7.7 (Slackware 13.1), should work with newer versions? (If you're using Slackware, you can just bung it in the patches directory and use the x11.SlackBuild script (remove the txt extension of course, and gzip the diff)).
I'm still not sure I understand why you want to use caps lock rather than shift for typing single upper case characters. I'm a fast typist (learned touch typing at school on typewriters with no letters on the keys) and and find the shift-key suits my needs. I've never heard of anyone, fast or slow, using the caps lock key in the way you describe.
ciao,
jdk
I've never heard of anyone, fast or slow, using the caps lock key in the way you describe.
Neither have I. It is an idiotic thing to do since it is, by definition, slower than using Shift. But, humans often go to great lengths to preserve their ingrained habits, no matter how inefficient. My mother for example, add up prices (shopping lists) etc. by typing them into a word processor, adding them up with a desktop calculator and typing in the result! I have attempted to show her how to use a spreadsheet, but, what can you do? Women...
I anyone tries my patch, let me know how it goes, I do not have time to test it myself (I don't need it personally).
Its only on when I want there to be a capital letter. At the beginning of a sentence.
That's what the Shift key is for.
There may well be a problem with the Caps Lock response time and fascinating as the technical discussion may be to some, the fact is you're basically typing wrong. You're using the Caps Lock key it for a purpose it is not intended for. There are two other keys on your keyboard that are there specifically for the purpose you are using the Caps Lock for and they are easier to use for that purpose. So you can worry and complain about this obscure issue with Caps Lock, or you can just learn to use the Shift key.
It has nothing to do with any distro, it is the X server. If you feel like recompiling the xserver, here's a quick patch. It makes (should make) {Caps,Num,Scroll,Shift}Lock work on keypress, rather than key release. Caveat: I knocked this out in a couple of minutes so it may not work, or be the best apporach, and/or I may have missed something. This is UNTESTED, use at own risk, etc etc.
Untar the xserver source, cd to source dir (xorg-server-X.Y.Z) and apply with
Code:
patch -p1 -i <filename>
Patch was made against xorg-server-1.7.7 (Slackware 13.1), should work with newer versions? (If you're using Slackware, you can just bung it in the patches directory and use the x11.SlackBuild script (remove the txt extension of course, and gzip the diff)).
Thanks for your attempt to help. What do I do with patch -p1 -i <filename> ? Do I put that as a command in terminal?
Thanks for your attempt to help. What do I do with patch -p1 -i <filename> ? Do I put that as a command in terminal?
Yes, the patch command is used to apply diffs (patches). See the man page for further details. Make sure you're in the source directory. Or, depending on your distro, your build system may be able to apply it automatically (as mentioned, Slackware can do this). You may want to compile an unmodified server first to familiarize yourself with the process (though compiling X these days is much easier than it used to be).
Distribution: openSUSE, Ubuntu, Kubuntu, Arch Linux
Posts: 8
Rep:
Quote:
Originally Posted by lej
Obviously. As I said, the issue is caused by the way X handles the modifier keys.
It has nothing to do with the kernel.
It has nothing to do with any distro, it is the X server. If you feel like recompiling the xserver, here's a quick patch. It makes (should make) {Caps,Num,Scroll,Shift}Lock work on keypress, rather than key release. Caveat: I knocked this out in a couple of minutes so it may not work, or be the best apporach, and/or I may have missed something. This is UNTESTED, use at own risk, etc etc.
Untar the xserver source, cd to source dir (xorg-server-X.Y.Z) and apply with
Code:
patch -p1 -i <filename>
Patch was made against xorg-server-1.7.7 (Slackware 13.1), should work with newer versions? (If you're using Slackware, you can just bung it in the patches directory and use the x11.SlackBuild script (remove the txt extension of course, and gzip the diff)).
I just tested your theory on my debian box using OpenOffice Writer and GNOME-terminal. I specifically did not release the Caps lock while I was typing. I use a USB keyboard, and It still types caps even on Keypress. GNOME responds on Keypress. I do have this problem that he mentions, but I'm not a buffoon who uses his Caps Lock to type single capital letters. I learned a long time ago to not be stupid.
Also, Whizje had the right answer, even it it left out a small detail that I'm going to add here.
Quote:
Originally Posted by whizje
The problem is that when you press caps lock linux waits for confirmation from the keyboard controller. This is done with a interrupt that's a signal to the processor that a device has data or can receive data. This confirmation can take 6 to 7 ms. But there are also other devices that send interrupts to the processor. And when there a multiple interrupts they are handled in priorities historically the ps2 keyboard had one of the highest priorities. But with the arrival from usb this has changed. A usb device can have a much lower priority so that it can take 200 or 300 ms before the keyboard interrupt is handled. In this time you can have pressed another key but as long the confirmation from the keyboard is not handled linux says caps lock is not enabled or disabled. So by using a ps2 keyboard you can be assured that a interrupt from the keyboard is handled as quickly as possible. The alternative is giving usb a high priority irq in the bios. Or fiddling with priority schemes as a last resort.
I am not 100% sure about this extra information, but I remember something to this effect was explained on a Wiki, or in my comp. sci class a few years ago.
Besides what Whizje said, the PS2 keyboard, which connects directly to the motherboard circuit panels, has the ability to write its state changes directly to a reserved section of your RAM, without relying on the CPU to read a hardware buffer. I'm having trouble remembering all the extra information that rationalizes this assessment, but I remember this technique was used by another device as well, but not all the devices make use of this, since it isn't sophisticated. The other hardware was probably just the PS2 mouse, if I were to make a guess. Feel free to point me to a proof against my statement if any of you can find one. Thanks.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
