Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

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

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


adobriyan at gmail

Nov 16, 2009, 5:51 AM

Post #1 of 20 (375 views)
Permalink
[PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII

Steps to reproduce:

[log into console (not xterm)]
[load non-trivial keymap]
[turn on CapsLock]
[type something]

Symbols won't be capital despite CapsLock and despite Shift+* working
as expected.

Note: patch relies on keymap being consistent wrt SMALL/CAPITAL symbols.
Though extracting SMALL <=> CAPITAL mapping from unicode tables and
putting it into kernel may be more correct.

Fix long-standing http://bugzilla.kernel.org/show_bug.cgi?id=7063

Signed-off-by: Alexey Dobriyan <adobriyan [at] gmail>
---

drivers/char/keyboard.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -1261,8 +1261,14 @@ static void kbd_keycode(unsigned int keycode, int down, int hw_raw)
param.value = keysym;
if (atomic_notifier_call_chain(&keyboard_notifier_list, KBD_UNICODE, &param) == NOTIFY_STOP)
return;
- if (down && !raw_mode)
+ if (down && !raw_mode) {
+ if (vc_kbd_led(kbd, VC_CAPSLOCK)) {
+ key_map = key_maps[shift_final ^ (1 << KG_SHIFT)];
+ if (key_map)
+ keysym = key_map[keycode];
+ }
to_utf8(vc, keysym);
+ }
return;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Nov 16, 2009, 6:40 AM

Post #2 of 20 (365 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

On Mon, 16 Nov 2009 16:51:15 +0300
Alexey Dobriyan <adobriyan [at] gmail> wrote:

> Steps to reproduce:
>
> [log into console (not xterm)]
> [load non-trivial keymap]
> [turn on CapsLock]
> [type something]
>
> Symbols won't be capital despite CapsLock and despite Shift+* working
> as expected.
>
> Note: patch relies on keymap being consistent wrt SMALL/CAPITAL symbols.
> Though extracting SMALL <=> CAPITAL mapping from unicode tables and
> putting it into kernel may be more correct.
>
> Fix long-standing http://bugzilla.kernel.org/show_bug.cgi?id=7063
>
> Signed-off-by: Alexey Dobriyan <adobriyan [at] gmail>

Acked-by: Alan Cox <alan [at] linux>

The assumptions seem reasonable and if not we'll find out. Either way its
going to be an improvement.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


samuel.thibault at ens-lyon

Nov 16, 2009, 11:07 AM

Post #3 of 20 (362 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Alexey Dobriyan, le Mon 16 Nov 2009 16:51:15 +0300, a écrit :
> Steps to reproduce:
>
> [log into console (not xterm)]
> [load non-trivial keymap]
> [turn on CapsLock]
> [type something]
>
> Symbols won't be capital despite CapsLock and despite Shift+* working
> as expected.

Fix your keymap, it should use KT_LETTER instead of KT_LATIN.

> Note: patch relies on keymap being consistent wrt SMALL/CAPITAL symbols.

And that's not true for a lot of keyboard symbols. Strictly speaking,
caps lock is caps lock, not shift lock. If you really want a shift
lock, then set your caps lock key to produce shift lock. Applying your
patch would turn the existing capslock behavior into shift lock, we
_don't_ want that.

> Though extracting SMALL <=> CAPITAL mapping from unicode tables and
> putting it into kernel may be more correct.

That's what console-setup does by using various symbol levels and it
just _works_. One issue however is that then the capslock keyboard
led doesn't light up while in caps mode. Maybe we should rethink the
interface to light keyboard leds instead.

Nacked-By: Samuel Thibault <samuel.thibault [at] ens-lyon>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


samuel.thibault at ens-lyon

Nov 16, 2009, 11:08 AM

Post #4 of 20 (360 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Alan Cox, le Mon 16 Nov 2009 14:40:03 +0000, a écrit :
> The assumptions seem reasonable and if not we'll find out. Either way its
> going to be an improvement.

Nope, it turns the caps lock into a shift lock, which is really not the
same.

Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


adobriyan at gmail

Nov 16, 2009, 11:53 AM

Post #5 of 20 (366 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

On Mon, Nov 16, 2009 at 08:07:39PM +0100, Samuel Thibault wrote:
> Alexey Dobriyan, le Mon 16 Nov 2009 16:51:15 +0300, a écrit :
> > Steps to reproduce:
> >
> > [log into console (not xterm)]
> > [load non-trivial keymap]
> > [turn on CapsLock]
> > [type something]
> >
> > Symbols won't be capital despite CapsLock and despite Shift+* working
> > as expected.
>
> Fix your keymap, it should use KT_LETTER instead of KT_LATIN.

You have read bugzilla and patch, haven't you?

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

> > 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.

> Strictly speaking, caps lock is caps lock, not shift lock. If you really
> want a shift lock, then set your caps lock key to produce shift lock.
> Applying your patch would turn the existing capslock behavior into shift
> lock, we _don't_ want that.
>
> > Though extracting SMALL <=> CAPITAL mapping from unicode tables and
> > putting it into kernel may be more correct.
>
> That's what console-setup

What is it?

$ sudo emerge -s console-setup
Searching...
[ Results for search key : console-setup ]
[ Applications found : 0 ]

> does by using various symbol levels and it just _works_.

Ubuntu user?

> One issue however is that then the capslock keyboard
> led doesn't light up while in caps mode.

Interesting breakage you have.

[presses CapsLock several times]

> Maybe we should rethink the interface to light keyboard leds instead.

Oh, and there no need to reply at every place as if Linus is going to
grab it from bugzilla and apply in hurry.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


samuel.thibault at ens-lyon

Nov 16, 2009, 2:27 PM

Post #6 of 20 (353 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Alexey Dobriyan, le Mon 16 Nov 2009 22:53:13 +0300, a écrit :
> > Fix your keymap, it should use KT_LETTER instead of KT_LATIN.
>
> You have read bugzilla and patch, haven't you?

Yes.

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.

> > > 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...

> > Strictly speaking, caps lock is caps lock, not shift lock. If you really
> > want a shift lock, then set your caps lock key to produce shift lock.
> > Applying your patch would turn the existing capslock behavior into shift
> > lock, we _don't_ want that.
> >
> > > Though extracting SMALL <=> CAPITAL mapping from unicode tables and
> > > putting it into kernel may be more correct.
> >
> > That's what console-setup
>
> What is it?

google tells packages.debian.org/console-setup

> $ sudo emerge -s console-setup
> Searching...
> [ Results for search key : console-setup ]
> [ Applications found : 0 ]

emerge is not universal, that's all.

> > does by using various symbol levels and it just _works_.
>
> Ubuntu user?

Nope.

> > 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.

> [presses CapsLock several times]

No need to be sarcastic.

> > Maybe we should rethink the interface to light keyboard leds instead.
>
> Oh, and there no need to reply at every place

People posting in the bugzilla usually don't read linux-kernel, that's
why I posted a sum up there.

Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


adobriyan at gmail

Nov 16, 2009, 2:53 PM

Post #7 of 20 (353 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

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 [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


samuel.thibault at ens-lyon

Nov 16, 2009, 2:54 PM

Post #8 of 20 (353 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Samuel Thibault, le Mon 16 Nov 2009 23:27:38 +0100, a écrit :
> > 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.

One way to go would be to decrete that keysyms between 0xD800 and 0xE000
(unused anyway) are "KT_LETTER" versions of the unicode 0x0000 - 0x0800.
That however covers only part of Unicode and doesn't solve the case of
keyboards where the upper case of a letter is not simply at the shifted
position.

The real correct solution is really to have kbd use modifiers just like
console-setup and provide a way for them to configure which leds should
be lit when some modifier is locked. That way building a keymap becomes
just orthogonal, no need to upload a table of lower/upper pairs (which
depend on the locale see for instance i/I vs i/İ).

Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


samuel.thibault at ens-lyon

Nov 16, 2009, 3:04 PM

Post #9 of 20 (354 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Alexey Dobriyan, le Tue 17 Nov 2009 01:53:51 +0300, a écrit :
> 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?

The caps lock interface. As I said, caps lock is caps lock, it's not
shift lock. For now Linux uses caps lock. If you make it use shift
lock it completely changes the behavior.

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

Yes, that's shift lock. But then any other key will also be shifted,
not only the KT_LETTER ones, while it's exactly the purpose of KT_LETTER
and caps lock.

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

It seems we don't understand each other, I'll repeat what I have
understood and explain more:

- you say
> Note: patch relies on keymap being consistent wrt SMALL/CAPITAL symbols.

- I understand
patch relies that keymaps always have the capital variant of letters at
the shifted position of each keys.

- I answer
> And that's not true for a lot of keyboard symbols.

- I mean
Some keyboard (physical, bought at the local store, not just keymaps
from CrazyHacker) do _not_ always have the capital variant of letters at
the shifted position of each keys. On a french keyboard for instance, É
is not at shift+é, but altgr+shift+é. So your patch won't work and
actually do harm.

- You answer
> That's why patch implies keymap is not fucked up.

- I understand
That's why patch implies that french keyboard is not fucked up.

- I answer
> However you can't changed the "fucked up" keyboard of people. They have
> bought it and it's printed like that on it...

- I mean
Maybe it's fucked up, but all the french keyboards are like that, you
can't change that fact.

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

- I didn't understand anything.

Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


adobriyan at gmail

Nov 16, 2009, 3:05 PM

Post #10 of 20 (349 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

On Mon, Nov 16, 2009 at 11:54:29PM +0100, Samuel Thibault wrote:
> Samuel Thibault, le Mon 16 Nov 2009 23:27:38 +0100, a écrit :
> > > 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.
>
> One way to go would be to decrete that keysyms between 0xD800 and 0xE000

And this is going to help me with U+042F/U+044F how?

> (unused anyway) are "KT_LETTER" versions of the unicode 0x0000 - 0x0800.
> That however covers only part of Unicode and doesn't solve the case of
> keyboards where the upper case of a letter is not simply at the shifted
> position.
>
> The real correct solution is really to have kbd use modifiers just like
> console-setup and provide a way for them to configure which leds should
> be lit when some modifier is locked. That way building a keymap becomes
> just orthogonal, no need to upload a table of lower/upper pairs (which
> depend on the locale see for instance i/I vs i/İ).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


samuel.thibault at ens-lyon

Nov 16, 2009, 3:15 PM

Post #11 of 20 (355 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Alexey Dobriyan, le Tue 17 Nov 2009 02:05:23 +0300, a écrit :
> On Mon, Nov 16, 2009 at 11:54:29PM +0100, Samuel Thibault wrote:
> > Samuel Thibault, le Mon 16 Nov 2009 23:27:38 +0100, a écrit :
> > > > 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.
> >
> > One way to go would be to decrete that keysyms between 0xD800 and 0xE000
>
> And this is going to help me with U+042F/U+044F how?

This way:

diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index 737be95..264db17 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -1258,6 +1258,15 @@ static void kbd_keycode(unsigned int keycode, int down, int hw_raw)
type = KTYP(keysym);

if (type < 0xf0) {
+ if (keysym >= 0xD800 && keysym < 0xE000) {
+ /* Surrogates in Unicode, here KT_LETTER variants of unicode U+0000-U+07FF */
+ keysym -= 0xD800;
+ if (vc_kbd_led(kbd, VC_CAPSLOCK)) {
+ key_map = key_maps[shift_final ^ (1 << KG_SHIFT)];
+ if (key_map)
+ keysym = key_map[keycode];
+ }
+ }
param.value = keysym;
if (atomic_notifier_call_chain(&keyboard_notifier_list, KBD_UNICODE, &param) == NOTIFY_STOP)
return;

Which BTW is correct while the proposed patch earlier wasn't: the
param.value needs to be the final keysym.

But again, that only solves the problem of the limited range
U+0000-U+0800 and doesn't solve the é/É french keyboard problem.

Adding an interface to change the modifier lock / LED assignation would
on the other hand permit kbd and console-setup to properly do proper
capslock processing correctly.

Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


adobriyan at gmail

Nov 17, 2009, 3:55 AM

Post #12 of 20 (349 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

On Tue, Nov 17, 2009 at 12:15:20AM +0100, Samuel Thibault wrote:
> Alexey Dobriyan, le Tue 17 Nov 2009 02:05:23 +0300, a écrit :
> > On Mon, Nov 16, 2009 at 11:54:29PM +0100, Samuel Thibault wrote:
> > > Samuel Thibault, le Mon 16 Nov 2009 23:27:38 +0100, a écrit :
> > > > > 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.
> > >
> > > One way to go would be to decrete that keysyms between 0xD800 and 0xE000
> >
> > And this is going to help me with U+042F/U+044F how?

> --- a/drivers/char/keyboard.c
> +++ b/drivers/char/keyboard.c
> @@ -1258,6 +1258,15 @@ static void kbd_keycode(unsigned int keycode, int down, int hw_raw)
> type = KTYP(keysym);
>
> if (type < 0xf0) {
> + if (keysym >= 0xD800 && keysym < 0xE000) {

keysym is 0x044F at this point.

> + /* Surrogates in Unicode, here KT_LETTER variants of unicode U+0000-U+07FF */
> + keysym -= 0xD800;
> + if (vc_kbd_led(kbd, VC_CAPSLOCK)) {
> + key_map = key_maps[shift_final ^ (1 << KG_SHIFT)];
> + if (key_map)
> + keysym = key_map[keycode];
> + }
> + }
> param.value = keysym;
> if (atomic_notifier_call_chain(&keyboard_notifier_list, KBD_UNICODE, &param) == NOTIFY_STOP)
> return;
>
> Which BTW is correct while the proposed patch earlier wasn't: the
> param.value needs to be the final keysym.

OK, this I should fix.

> But again, that only solves the problem of the limited range
> U+0000-U+0800 and doesn't solve the é/É french keyboard problem.
>
> Adding an interface to change the modifier lock / LED assignation would
> on the other hand permit kbd and console-setup to properly do proper
> capslock processing correctly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


samuel.thibault at ens-lyon

Nov 17, 2009, 5:23 AM

Post #13 of 20 (346 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Alexey Dobriyan, le Tue 17 Nov 2009 14:55:03 +0300, a écrit :
> On Tue, Nov 17, 2009 at 12:15:20AM +0100, Samuel Thibault wrote:
> > Alexey Dobriyan, le Tue 17 Nov 2009 02:05:23 +0300, a écrit :
> > > On Mon, Nov 16, 2009 at 11:54:29PM +0100, Samuel Thibault wrote:
> > > > Samuel Thibault, le Mon 16 Nov 2009 23:27:38 +0100, a écrit :
> > > > > > 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.
> > > >
> > > > One way to go would be to decrete that keysyms between 0xD800 and 0xE000
> > >
> > > And this is going to help me with U+042F/U+044F how?
>
> > --- a/drivers/char/keyboard.c
> > +++ b/drivers/char/keyboard.c
> > @@ -1258,6 +1258,15 @@ static void kbd_keycode(unsigned int keycode, int down, int hw_raw)
> > type = KTYP(keysym);
> >
> > if (type < 0xf0) {
> > + if (keysym >= 0xD800 && keysym < 0xE000) {
>
> keysym is 0x044F at this point.

I'm precisely suggesting that instead of 0x044F, the keymap provides
0xdc4f, just like for +z the keysym is not K(KT_LATIN,0x0079), but
K(KT_LETTER,0x79) (that's the difference between just z and +z, i.e.
whether it's KT_LATIN or KT_LETTER, i.e. whether capslock acts on it or
not, that's the whole point of capslock vs shift lock!).

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.

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.

Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


adobriyan at gmail

Nov 19, 2009, 5:18 AM

Post #14 of 20 (345 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

On Tue, Nov 17, 2009 at 02:23:58PM +0100, Samuel Thibault wrote:
> Alexey Dobriyan, le Tue 17 Nov 2009 14:55:03 +0300, a écrit :
> > On Tue, Nov 17, 2009 at 12:15:20AM +0100, Samuel Thibault wrote:
> > > Alexey Dobriyan, le Tue 17 Nov 2009 02:05:23 +0300, a écrit :
> > > > On Mon, Nov 16, 2009 at 11:54:29PM +0100, Samuel Thibault wrote:
> > > > > Samuel Thibault, le Mon 16 Nov 2009 23:27:38 +0100, a écrit :
> > > > > > > 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.
> > > > >
> > > > > One way to go would be to decrete that keysyms between 0xD800 and 0xE000
> > > >
> > > > And this is going to help me with U+042F/U+044F how?
> >
> > > --- a/drivers/char/keyboard.c
> > > +++ b/drivers/char/keyboard.c
> > > @@ -1258,6 +1258,15 @@ static void kbd_keycode(unsigned int keycode, int down, int hw_raw)
> > > type = KTYP(keysym);
> > >
> > > if (type < 0xf0) {
> > > + if (keysym >= 0xD800 && keysym < 0xE000) {
> >
> > keysym is 0x044F at this point.
>
> I'm precisely suggesting that instead of 0x044F, the keymap provides
> 0xdc4f, just like for +z the keysym is not K(KT_LATIN,0x0079), but
> K(KT_LETTER,0x79) (that's the difference between just z and +z, i.e.
> whether it's KT_LATIN or KT_LETTER, i.e. whether capslock acts on it or
> not, that's the whole point of capslock vs shift lock!).
>
> 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.

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


samuel.thibault at ens-lyon

Nov 19, 2009, 5:28 AM

Post #15 of 20 (342 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

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 [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


samuel.thibault at ens-lyon

Nov 19, 2009, 5:37 AM

Post #16 of 20 (346 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Just to make sure you really understand.

Samuel Thibault, le Thu 19 Nov 2009 14:28:28 +0100, a écrit :
> 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.

And that's precisely why I just showed how such limitation could be
lifted:

> > > 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.

So we agree, and so the right solution is to either completely rework
the interface (ugh), or just add LED routing (which can be very useful,
actually, I for instance don't care at all about the num lock state, but
I _do_ care about the lock that lets me shift between different keyboard
layouts).

Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Nov 19, 2009, 7:07 AM

Post #17 of 20 (341 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

On 11/19/2009 05:37 AM, Samuel Thibault wrote:
>
> So we agree, and so the right solution is to either completely rework
> the interface (ugh), or just add LED routing (which can be very useful,
> actually, I for instance don't care at all about the num lock state, but
> I _do_ care about the lock that lets me shift between different keyboard
> layouts).
>

Adding LED routing and using keyboard levels is so clearly The Right Thing.

We already allow the LEDs to be programmed; we should probably just
have, for each LED, the ability to program it off/on/flashing/connected
to modifier #X.

The current KDSETLED/KDGETLED interface is of course too limited for
this -- we need an interface with at least a byte per LED.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pavel at ucw

Nov 20, 2009, 11:07 AM

Post #18 of 20 (336 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Hi!

> > So we agree, and so the right solution is to either completely rework
> > the interface (ugh), or just add LED routing (which can be very useful,
> > actually, I for instance don't care at all about the num lock state, but
> > I _do_ care about the lock that lets me shift between different keyboard
> > layouts).
> >
>
> Adding LED routing and using keyboard levels is so clearly The Right Thing.
>
> We already allow the LEDs to be programmed; we should probably just
> have, for each LED, the ability to program it off/on/flashing/connected
> to modifier #X.
>
> The current KDSETLED/KDGETLED interface is of course too limited for
> this -- we need an interface with at least a byte per LED.

Actually, we already have very nice /sys/class/led interface, and we
should just use it for keyboard leds, too. Actually I have a patch,
somewhere...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


pavel at ucw

Nov 20, 2009, 12:46 PM

Post #19 of 20 (336 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

Hi!

> > > So we agree, and so the right solution is to either completely rework
> > > the interface (ugh), or just add LED routing (which can be very useful,
> > > actually, I for instance don't care at all about the num lock state, but
> > > I _do_ care about the lock that lets me shift between different keyboard
> > > layouts).
> > >
> >
> > Adding LED routing and using keyboard levels is so clearly The Right Thing.
> >
> > We already allow the LEDs to be programmed; we should probably just
> > have, for each LED, the ability to program it off/on/flashing/connected
> > to modifier #X.
> >
> > The current KDSETLED/KDGETLED interface is of course too limited for
> > this -- we need an interface with at least a byte per LED.
>
> Actually, we already have very nice /sys/class/led interface, and we
> should just use it for keyboard leds, too. Actually I have a patch,
> somewhere...

Like this... But it should probably be slightly more complex -- like
making numlock/capslock/scrollock leds into trigers, and then
move input LED lowlevels into drivers/led...

Signed-off-by: Pavel Machek <pavel [at] ucw> (but...)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index e4f599f..c80fee8 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -96,6 +96,13 @@ config LEDS_COBALT_RAQ
help
This option enables support for the Cobalt Raq series LEDs.

+config LEDS_INPUT
+ tristate "LED Support for input layer keyboards"
+ depends on LEDS_CLASS
+ help
+ This option enables support for LEDs on keyboards handled by
+ input layer.
+
config LEDS_SUNFIRE
tristate "LED support for SunFire servers."
depends on LEDS_CLASS && SPARC64
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 46d7270..71bde81 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_LEDS_NET48XX) += leds-net48xx.o
obj-$(CONFIG_LEDS_WRAP) += leds-wrap.o
obj-$(CONFIG_LEDS_ALIX2) += leds-alix2.o
obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
+obj-$(CONFIG_LEDS_INPUT) += leds-input.o
obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_SUNFIRE) += leds-sunfire.o
diff --git a/drivers/leds/leds-input.c b/drivers/leds/leds-input.c
new file mode 100644
index 0000000..8ffb4fc
--- /dev/null
+++ b/drivers/leds/leds-input.c
@@ -0,0 +1,151 @@
+/*
+ * LED <-> input subsystem glue
+ *
+ * Copyright 2007 Pavel Machek <pavel [at] ucw>
+ * Copyright 2007 Dmitry Torokhov
+ * Copyright 2005-2006 Openedhand Ltd.
+ *
+ * Author: Pavel Machek <pavel [at] ucw>
+ * Based on code by: Richard Purdie <rpurdie [at] openedhand>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/leds.h>
+
+#include <linux/module.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+#include <linux/init.h>
+
+struct blinker {
+ struct work_struct work;
+ struct input_handle handle;
+ int state;
+
+ struct led_classdev dev;
+};
+
+struct blinker *blinker;
+
+static void inputled_set(struct led_classdev *led_cdev, enum led_brightness value)
+{
+ struct blinker *blinker = container_of(led_cdev, struct blinker, dev);
+ blinker->state = value;
+ schedule_work(&blinker->work);
+}
+
+static void blink_task_handler(struct work_struct *work)
+{
+ struct blinker *blinker = container_of(work, struct blinker, work);
+ input_inject_event(&blinker->handle, EV_LED, LED_CAPSL, !!blinker->state);
+}
+
+static void blink_event(struct input_handle *handle, unsigned int type,
+ unsigned int code, int down)
+{
+ /*
+ * This is a very rare handler that does not process any input
+ * events; just injects them.
+ */
+}
+
+static int blink_connect(struct input_handler *handler, struct input_dev *dev,
+ const struct input_device_id *id)
+{
+ struct input_handle *handle;
+ struct led_classdev *led_dev;
+ static int counter;
+ int error;
+
+ blinker = kzalloc(sizeof(struct blinker), GFP_KERNEL);
+ if (!blinker) {
+ return -ENOMEM;
+ }
+
+ INIT_WORK(&blinker->work, blink_task_handler);
+
+ led_dev = &blinker->dev;
+ led_dev->name = kmalloc(10, GFP_KERNEL);
+ sprintf(led_dev->name, "input%d", counter++);
+ led_dev->brightness_set = inputled_set;
+
+ handle = &blinker->handle;
+ handle->dev = dev;
+ handle->handler = handler;
+ handle->name = "blink";
+ handle->private = blinker;
+
+ error = input_register_handle(handle);
+ if (error)
+ goto err_free_handle;
+
+ error = input_open_device(handle);
+ if (error)
+ goto err_unregister_handle;
+
+ error = led_classdev_register(NULL, led_dev);
+ if (error < 0)
+ goto err_input_close_device;
+
+ return 0;
+
+ err_input_close_device:
+ input_close_device(handle);
+ err_unregister_handle:
+ input_unregister_handle(handle);
+ err_free_handle:
+ kfree(handle);
+ return error;
+}
+
+static void blink_disconnect(struct input_handle *handle)
+{
+ struct blinker *blinker = handle->private;
+
+ led_classdev_unregister(&blinker->dev);
+ input_close_device(handle);
+ input_unregister_handle(handle);
+ kfree(blinker);
+}
+
+static const struct input_device_id blink_ids[] = {
+ {
+ .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_LEDBIT,
+ .evbit = { BIT(EV_LED) },
+ .ledbit = { [LED_CAPSL] = BIT(LED_CAPSL) },
+ },
+ { }
+};
+
+static struct input_handler blink_handler = {
+ .event = blink_event,
+ .connect = blink_connect,
+ .disconnect = blink_disconnect,
+ .name = "blink",
+ .id_table = blink_ids,
+};
+
+static int __init blink_handler_init(void)
+{
+ return input_register_handler(&blink_handler);
+}
+
+static void __exit blink_handler_exit(void)
+{
+ input_unregister_handler(&blink_handler);
+ flush_scheduled_work();
+}
+
+module_init(blink_handler_init);
+module_exit(blink_handler_exit);
+
+


--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Nov 20, 2009, 1:27 PM

Post #20 of 20 (332 views)
Permalink
Re: [PATCH] kbd: (#7063) make CapsLock work as expected even for non-ASCII [In reply to]

On 11/20/2009 12:46 PM, Pavel Machek wrote:
>
> Like this... But it should probably be slightly more complex -- like
> making numlock/capslock/scrollock leds into trigers, and then
> move input LED lowlevels into drivers/led...
>

In particular, all keyboard modifiers should be available triggers.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.