CAPS lock not working on all letters in tty1 to tty6

zyga on IRC said that this was fixed in Breezy, so perhaps he can provide
information about the fix.

<limer> it was suggested I let you guys know: I have the stangest problem in
ubuntu. If I use TTY1 through 6, CAPS LOCK doesn't seem to affect certain letters
<limer> another in #ubuntu can confirm and I will post a bug in a min
<crimsun> hoary?
<limer> yes
<crimsun> odd.
<limer> does NOT happen in X
<-- nohar has quit (Read error: 104 (Connection reset by peer))
<limer> letters "c" and "e" noticed this far
<zyga> limer: it's fixed in breezy

*** Bug 17103 has been marked as a duplicate of this bug. ***

Hi,

I'm using a full upgraded version of Kubuntu preview release and this behaviour
still happens on tty1 to 6, with c, e, m and r. Follows my setup:

Kubuntu PR 1
Proc: AMD Athlon 2400+ XP
RAM: 1024 MB
Disks: 2 IDE Samsung 40 GB/80 GB
Video: Nvidia GeForce FX 5600XT
Keyboard: Microsoft Digital Keyboard Pro

Transcript from #ubuntu-bugs - 09/17/2005 - 10:52 (GMT -3)

[10:48] <amoraes> Hi, I'm running through Unconfirmed buglist and found that
this bug, albeit Unco, is still happen (Bug #16628:
http://bugzilla.ubuntu.com/show_bug.cgi?id=10344) can you test so we can confirm it?
[10:51] <klepas> i'm on it
[10:52] <\sh> confirmed
[10:52] <klepas> same

the following letters are affected (germany keyboard)

q e c m ö ä ü

I am using Ubuntu 5.10 review (Breezy Badger),and I can't type the uppercase letter 'c' and 'e' in text based console (not
in GUI) with capslock turned on unless I use the shift key

This is very puzzling, but it's happening to me as well, only with the letters
'e' and 'c'. I don't know what could be at fault. Did anyone notice when this
started happening? What triggered it?

freaky...

*** Bug 22801 has been marked as a duplicate of this bug. ***

(In reply to comment #6)
> This is very puzzling, but it's happening to me as well, only with the letters
> 'e' and 'c'. I don't know what could be at fault. Did anyone notice when this
> started happening? What triggered it?

I have an Ubuntu Hoary, therefore the problem is in Hoary at most. Maybe earlier.

More info:

- In a text console (say, tty1), in caps lock mode on, all chars appears in
uppercase EXCEPT e, c, and ñ:

   QWeRTYUIOP
   ASDFGHJKLñ
   ZXcVBNM

- In caps lock mode, to get the upcase E, C and Ñ, I need to press the Shift key
with the corresponding key (E, C or Ñ).

- My keyboard is an Spanish keyboard.

- My locale is "es_ES.UTF-8".

The only special thing about the 'e' and the 'c' is that both keys refers to the
Euro:

 - € is AltGr-E
 - ¢ is AltGr-C

But what about ñ (in Spanish)?

This might be unrelated but for pl_PL.UTF-8:
Caps lock fails for *all* locale-dependant characters, for polish that is:
(in qwerty order) ęóąśłżźćń, each of these characters (without the accents, I'm
talking about pure latin characters) caps lock does not work.

Similar thing but not 100% corelating is also happening in X11.
If my comment is unclear please say so... I'm tired today.

aha, look there:

- go to real console. (console-data configured and locales configured to UTF8)
- type 'showcfont' and you can see accentuated keys
- type 'dumpkeys | grep compose' and you can see the table First+Second=Result,
but all of results are in blank, ''
- dump now the previous output to a file 'dumpkeys | grep compose > comp.txt',
go to X and open it with gedit, the blanks chars are been converted to the
correct form! (gedit notices that the file is on ISO8859-15 when it must be in
UTF-8!!)

I wonder if the problem is at the "compose table", it should have 2 tables, one
for iso, another for unicode.

I can confirm.
For pl_PL.UTF-8 I got iso-8859-2 keycodes... strange!

I don't know if this can help:

1. «dumpkeys > output.txt». The output.txt file is in ISO, not in UTF-8.
2. «recode latin9..utf8 output.txt». This convert the output.txt file into UTF-8
coding.
3. I try then «loadkeys output.txt», but I got a «syntax error» in the line
which the «compose» lines begins.

It seems that the loadkeys command doesn't supports a file codified in UTF-8. I
noticed that the command «dumpkeys --help» shows the following output:

available charsets:
iso-8859-{1,2,3,4,5,7,8,9,10,15},koi8-{r,u},mazovia,cp-1250,iso-10646-18,iso-ir-197,iso-ir-209

There's no UTF-8 there. Maybe the solution could be to recode the «loadkeys»
file to understand the compose keys in UTF-8...

The keys affected are those that have alternate characters on them, e.g. 'a'
will be affected on a keyboard that also has 'ą' or 'ä' etc. 'c' and 'e' are
affected for everyone because of the Euro symbols on AltGR

Note that caps lock isn't "broken", just inverted ... with caps lock on you get:
    ABcDeF

but with caps lock on and shift held down you get:
    abCdEf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 30 Sep 2005 05:55:26 +0100
Source: console-tools
Binary: kbd-compat console-tools-dev libconsole console-tools
Architecture: source
Version: 1:0.2.3dbs-56ubuntu5
Distribution: breezy
Urgency: low
Maintainer: Alastair McKinstry <email address hidden>
Changed-By: Scott James Remnant <email address hidden>
Description:
 console-tools - Linux console and font utilities
 console-tools-dev - Development files for Linux console and font manipulation
 kbd-compat - Wrappers around console-tools for backward compatibility with `kb
 libconsole - Shared libraries for Linux console and font manipulation
Changes:
 console-tools (1:0.2.3dbs-56ubuntu5) breezy; urgency=low
 .
   * Added 951_fix_unicode_loadkeys_capslock.patch:
     - When loading unicode key maps, apply KT_LETTER to values in the
       range a-z or A-Z rather than KT_LATIN. This seems to be necessary
       to make Caps Lock work properly. (Ubuntu: #10344).
Files:
 03f6f955c0cea70047e0480e23a87b94 657 base important
console-tools_0.2.3dbs-56ubuntu5.dsc
 5a83524b59d6df78cff86a4ecafdb135 1471313 base important
console-tools_0.2.3dbs-56ubuntu5.tar.gz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDPMdMSnQiFMl4yK4RApL8AJ0UtNfw6jB2OU8FXbtApb+FlweURgCfQufC
GxYZQDdMNEK9NzuY+LQHI6M=
=9bcR
-----END PGP SIGNATURE-----

Please note that this is only a partial fix, it will correct the basic latin
characters a-z and A-Z but not any of the accented or non-latin characters.

Unfortunately there's no way right now to fix it for those because there's no
way to set KT_LETTER on unicode characters. For a complete fix, the kernel's
keyboard stuff needs to change -- I'm guessing that's very very upstream?

Do you know if this issue is related to bug #19487 or bug #22804?

I don't think so -- the first I'd guess is just missing keymaps and the second
worksforme here

This bug has been flagged because it is old and possibly inactive. It may or may
not be fixed in the latest release (Breezy Badger 5.10). It is being marked as
"NEEDSINFO". In two weeks time, if the bug is not updated back to "NEW" and
validated against Breezy, it will be closed.

This is needed in order to help manage the current bug list for the kernel. We
would like to fix all bugs, but need users to test and help with debugging.

If this change was in error for this bug, please respond and make the
appropriate change (or email <email address hidden> if you cannot make the
change).

Thanks for your help.

This bug is definitely still open, we fixed it for the ASCII range in
console-tools but can't fix it for the rest because of kernel limitations

(In reply to comment #20)
> This bug is definitely still open, we fixed it for the ASCII range in
> console-tools but can't fix it for the rest because of kernel limitations

What sort of kernel limitations? I don't know a whole lot about character
conversions, so I'm a little ignorant of how the kernel is supposed to handle
the character mappings that console-data et al are setting.

(In reply to comment #21)
> (In reply to comment #20)
> > This bug is definitely still open, we fixed it for the ASCII range in
> > console-tools but can't fix it for the rest because of kernel limitations
>
> What sort of kernel limitations? I don't know a whole lot about character
> conversions, so I'm a little ignorant of how the kernel is supposed to handle
> the character mappings that console-data et al are setting.
>
tbh, I don't know much about it myself ... but from what I can tell, the kernel
doesn't yet have the capacity to describe modifiers such as caps lock for keys
other than the basic set.

This is still an issue with 2.6.19. Compare with this bug:

  https://launchpad.net/distros/ubuntu/+source/console-setup/+bug/69725

As far as I can tell from reading through the archives, this is a Really Hard Problem and pretty much requires a rewrite of big chunks of the kernel's console keyboard mapping code ...

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this linux-source-2.6.15 kernel bug to the new "linux" package. We appreciate your patience and understanding as we make this transition. Also, if you would be interested in testing the upcoming Intrepid Ibex 8.10 release, it is available at http://www.ubuntu.com/testing . Please let us know your results. Thanks!

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

This bug report was marked as Confirmed a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Now it works for me on 2.6.28-13-generic