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

[Samuel Thibault]

Alexey Dobriyan, le Thu 19 Nov 2009 16:18:54 +0300, a écrit :
> > More precisely, in the kbd source code, in the add_capslock function, in
> > the unicode case, instead of ignoring the '+', add 0xD800 to the unicode
> > value if it is below 0x0800.
> 
> You suggest to change kernel and keymap and kbd and introduce 0xD800 hack.
> This is not going to fly.

Sure, that's precisely what I said here:

> > But again, that's a very limited fix and just fixing the LED interface
> > would allow to just use modifiers and permit much more powerful keymaps.

Just to make sure you understand my point: your bug is _not_ in the
kernel, but in kbd, see what the add_capslock() function does when in
unicode mode:

	fprintf(stderr, _("plus before %s ignored\n"), p);

No wonder capslocked keys don't work, kbd doesn't even tell the kernel
which keys should get capslock behavior. Breaking the capslock behavior
to make it a shiftlock to compensate kbd's bug is not going to fly
either.

Now, as I said, kbd's issue is that it doesn't have any way to express
that a unicode keysym should get capslock behavior, due to kernel
interface limitation.  But as I said, it can do like console-setup: use
a modifier instead of the limited capslock interface. A side issue is
that modifier locks don't get advertised through keyboard leds. That can
be solved by adding an interface to make that happen.

Instead of breaking an interface (capslock by making it a shiftlock
instead), add one that makes sense (being able to configure how modifier
locks are advertised through LEDs). _That_ will fly.

Samuel
--
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/