Re: [rfc] keytables - the new keycode->keysym mapping

[Andries Brouwer <Andries.Brouwer@cwi.nl>]

On Wed, Feb 09, 2005 at 05:55:00PM +0100, Vojtech Pavlik wrote:
> On Wed, Feb 09, 2005 at 05:38:56PM +0100, Andries Brouwer wrote:
>> On Wed, Feb 09, 2005 at 05:03:45PM +0100, Vojtech Pavlik wrote:
>> 
>>>> It seems very unlikely that you cannot handle Czech with all
>>>> combinations of 8 keys pressed, and need 9.
>>> 
>>> A czech keyboard has the letters 'escrzyaie' with accents on the number
>>> row of keys. With a Shift, they are supposed to produce the original
>>> numbers, but with a CapsLock, they're supposed to produce the uppercase.
>>> With a right alt or one of three czech dead keys they should produce
>>> the !@#$%^&*() symbols.
>>> 
>>> It's kind of logical, kind of stupid, but anyway it's the national standard.
>>> 
>>> You can't do that currently. The main problem is that CapsLock is
>>> hardcoded to work as a Shift on keys and you can't make it work
>>> differently for normal letter keys and for the upper row of keys.
>> 
>> I think the fallacy in that reasoning is the idea that the key
>> labeled CapsLock has to be bound to the kernel function named capslock.
>  
> How do you make it control the CapsLock LED then?

OK - I agree. The keyboard can do what you want,
but there is no independent CapsLock LED control.

Andries


[not that I think the proposed change is a good idea,
but now I understand why one would want to extend functionality]