Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII

[Alexey Dobriyan <adobriyan@gmail.com>]

On Mon, Nov 16, 2009 at 11:27:39PM +0100, Samuel Thibault wrote:
> Alexey Dobriyan, le Mon 16 Nov 2009 22:53:13 +0300, a écrit :
> And you could probably also read bug #7746 which is probably now a dup
> (yes, the original report mixes several issues).
> 
> > My keymap contains
> > 
> > 				keycode 44 = +z
> > 		shift           keycode 44 = +Z
> > 	altgr                   keycode 44 = U+044F        # CYRILLIC SMALL LETTER YA
> > 	altgr   shift           keycode 44 = U+042F        # CYRILLIC CAPITAL LETTER YA
> 
> And U+044F / U+042F is not KT_LETTER.
> 
> Yes, there's no way you can express a unicode character in KT_LETTER.
> Limited interface, but that's not a reason to break other interfaces.

What other interfaces?

Here, U+044F is sent, now (correctly) U+042F.

> > > > Note: patch relies on keymap being consistent wrt SMALL/CAPITAL symbols.
> > > 
> > > And that's not true for a lot of keyboard symbols.
> > 
> > That's why patch implies keymap is not fucked up.
> 
> However you can't changed the "fucked up" keyboard of people.  They have
> bought it and it's printed like that on it...

keymap is loadable, what are you talking about?
/usr/share/keymaps/i386/qwerty/ru.map.gz

> > > One issue however is that then the capslock keyboard led doesn't
> > > light up while in caps mode.
> > 
> > Interesting breakage you have.
> 
> It's not breakage.  It's because instead of using the KT_LETTER way to
> get the caps lock behavior, console-setup uses a modifier, since it's
> much more powerful (you just decide what exactly will be the upper case,
> and not have to rely on the shifted keysym to be the expected one), but
> the kernel doesn't permit to assign a modifier to a keyboard LED.