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

From: Alexey Dobriyan
Date: Mon Nov 16 2009 - 17:54:18 EST


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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/