Cap lock key stuck in cap lock

I confirm this bug, I get the same caps-lock behaviour on Dapper with Xephyr 6.6.1ubuntu3. If I toggle the caps-lock on then off, even tough the led if off anykey I will type will be in CAPITAL LETTERS, even if I hold the shift key down.

I found this which might be helpful to anyone willing to solve this bug :
http://lists.freedesktop.org/archives/xorg/2005-December/011635.html

CAPS LOCK also gets stuck during a login interaction on Ubuntu Server Edition, 6.06 LTS.
Seems most likely to occur after terminal is logged out/idle for at least a few minutes, but I cannot confirm this 100%. To reproduce...
If monitor is blank, enable it by pressing shift key.
Type part of username and then press CAPS LOCK key.
Finish username (which will now partly be in the wrong case) and press enter.
Password prompt will appear in UPPERCASE!!!!! You will notice that you cannot disable CAPS LOCK by hitting CAPS LOCK or SHIFT key.
Type an incorrect password and press ENTER.
You will get a LOGIN INCORRECT message in UPPERCASE
And then LOGIN prompt will appear in UPPERCASE
CAPS LOCK is still stuck on!!!!

Seems to fix itself after login attempt expires. This would suggest that there is something seriously amiss with OS keyboard logic. I use a simple server configuration with VGA framebuffer on 1024x768 and PS/2 keyboard (no active mouse). The problem is NOT always repeatable which might indicate some timing issue whereby OS keyboard logic gets itself into an invalid state, possibly due to low OS task priority after idle periods.

If you change over to other virtual terminals (Ctrl-Alt-Fx), problem is not present, so it is definitely OS-related. Having said that, problem can be made to appear on any virtual terminal using above steps.

Surely a bug as serious as this (on a stable server platform with LTS) needs to be escalated.

This has been fixed in xorg-server 1.4 which is in hardy. I can't reproduce it.

As for the importance of LTS server, I can only say that X is not included on a server install :)

I'm glad the problem was fixed in Hardy. However, one might argue that
a terminal server IS a server, and running X is legitimate then... The
same goes for gnome too. I myself administer 3 Ubuntu terminal servers
accessed through thin clients. It may seem twisted to use Xephyr over a
remote X session or over VNC, but it's feasible and someone might have a
good reason to do so. Terminal server is maybe not a basic role on
Ubuntu install disc (like LAMP), but a lot of server software is not
included by default on a server install. So, does that mean LTS only
concerns the very few packages installed by default ?

Timo Aaltonen wrote:
> This has been fixed in xorg-server 1.4 which is in hardy. I can't
> reproduce it.
>
> As for the importance of LTS server, I can only say that X is not
> included on a server install :)
>
> ** Changed in: xorg-server (Ubuntu)
> Status: Confirmed => Fix Released
>
>

> As for the importance of LTS server, I can only say that X is not included on a server install :)

Sorry maybe I posted to wrong bug report. Actually, I don't use X at all. Just local VGA terminal and problem happens occassionally as I described above.