Make kbd_keycode() read param.value after calling the keyboard notification
chain, to let the callee change the translation on the fly. This for instance
permits to remap the physical positions of the keys independently of the
configured keymap, for e.g. single-handed people.
Signed-off-by: Samuel Thibault <[email protected]>
--- linux/drivers/char/keyboard.c.orig 2009-01-07 00:48:46.000000000 +0100
+++ linux/drivers/char/keyboard.c 2009-01-07 01:02:05.000000000 +0100
@@ -1248,6 +1248,7 @@ kbd_keycode
kbd->slockstate = 0;
return;
}
+ keycode = param.value;
if (keycode >= NR_KEYS)
if (keycode >= KEY_BRL_DOT1 && keycode <= KEY_BRL_DOT8)
@@ -1263,6 +1264,7 @@ kbd_keycode
param.value = keysym;
if (atomic_notifier_call_chain(&keyboard_notifier_list, KBD_UNICODE, ¶m) == NOTIFY_STOP)
return;
+ keysym = param.value;
if (down && !raw_mode)
to_utf8(vc, keysym);
return;
@@ -1282,6 +1284,7 @@ kbd_keycode
if (atomic_notifier_call_chain(&keyboard_notifier_list, KBD_KEYSYM, ¶m) == NOTIFY_STOP)
return;
+ keysym = param.value;
if (raw_mode && type != KT_SPEC && type != KT_SHIFT)
return;
--- linux/Documentation/input/notifier.txt.orig 2008-04-17 12:14:30.000000000 +0200
+++ linux/Documentation/input/notifier.txt 2009-01-07 01:04:16.000000000 +0100
@@ -21,7 +21,8 @@
For each kind of event but the last, the callback may return NOTIFY_STOP in
order to "eat" the event: the notify loop is stopped and the keyboard event is
-dropped.
+dropped. The callee can also modify param.value so as to change the key
+translation.
In a rough C snippet, we have:
@@ -33,18 +34,26 @@
notifier_call_chain(KBD_UNBOUND_KEYCODE,¶ms);
return;
}
+ keycode = param.value;
+
+ ...
if (unicode) {
param.value = unicode;
if (notifier_call_chain(KBD_UNICODE,¶ms) == NOTIFY_STOP)
return;
+ keysym = param.value;
emit unicode;
return;
}
+ ...
+
params.value = keysym;
if (notifier_call_chain(KBD_KEYSYM,¶ms) == NOTIFY_STOP)
return;
+ keysym = params.value;
+
apply keysym;
notifier_call_chain(KBD_POST_KEYSYM,¶ms);
}
Hello,
Came somebody have a look at this? The need is real, the only question
that comes to my mind is whether notifiers are allowed to modify the
param they are given. Since they are not marked const, I'd guess it'd
be ok?
Samuel
Samuel Thibault, le Wed 07 Jan 2009 01:58:13 +0100, a ?crit :
Make kbd_keycode() read param.value after calling the keyboard notification
chain, to let the callee change the translation on the fly. This for instance
permits to remap the physical positions of the keys independently of the
configured keymap, for e.g. single-handed people.
Signed-off-by: Samuel Thibault <[email protected]>
--- linux/drivers/char/keyboard.c.orig 2009-01-07 00:48:46.000000000 +0100
+++ linux/drivers/char/keyboard.c 2009-01-07 01:02:05.000000000 +0100
@@ -1248,6 +1248,7 @@ kbd_keycode
kbd->slockstate = 0;
return;
}
+ keycode = param.value;
if (keycode >= NR_KEYS)
if (keycode >= KEY_BRL_DOT1 && keycode <= KEY_BRL_DOT8)
@@ -1263,6 +1264,7 @@ kbd_keycode
param.value = keysym;
if (atomic_notifier_call_chain(&keyboard_notifier_list, KBD_UNICODE, ¶m) == NOTIFY_STOP)
return;
+ keysym = param.value;
if (down && !raw_mode)
to_utf8(vc, keysym);
return;
@@ -1282,6 +1284,7 @@ kbd_keycode
if (atomic_notifier_call_chain(&keyboard_notifier_list, KBD_KEYSYM, ¶m) == NOTIFY_STOP)
return;
+ keysym = param.value;
if (raw_mode && type != KT_SPEC && type != KT_SHIFT)
return;
--- linux/Documentation/input/notifier.txt.orig 2008-04-17 12:14:30.000000000 +0200
+++ linux/Documentation/input/notifier.txt 2009-01-07 01:04:16.000000000 +0100
@@ -21,7 +21,8 @@
For each kind of event but the last, the callback may return NOTIFY_STOP in
order to "eat" the event: the notify loop is stopped and the keyboard event is
-dropped.
+dropped. The callee can also modify param.value so as to change the key
+translation.
In a rough C snippet, we have:
@@ -33,18 +34,26 @@
notifier_call_chain(KBD_UNBOUND_KEYCODE,¶ms);
return;
}
+ keycode = param.value;
+
+ ...
if (unicode) {
param.value = unicode;
if (notifier_call_chain(KBD_UNICODE,¶ms) == NOTIFY_STOP)
return;
+ keysym = param.value;
emit unicode;
return;
}
+ ...
+
params.value = keysym;
if (notifier_call_chain(KBD_KEYSYM,¶ms) == NOTIFY_STOP)
return;
+ keysym = params.value;
+
apply keysym;
notifier_call_chain(KBD_POST_KEYSYM,¶ms);
}
On Fri, 9 Jan 2009 22:23:58 +0100
Samuel Thibault <[email protected]> wrote:
> Hello,
>
> Came somebody have a look at this? The need is real, the only question
> that comes to my mind is whether notifiers are allowed to modify the
> param they are given. Since they are not marked const, I'd guess it'd
> be ok?
The notifier code doesn't care.
> Make kbd_keycode() read param.value after calling the keyboard notification
> chain, to let the callee change the translation on the fly. This for instance
> permits to remap the physical positions of the keys independently of the
> configured keymap, for e.g. single-handed people.
Surely that is just a new keymap ?
Alan Cox, le Fri 09 Jan 2009 21:35:55 +0000, a ?crit :
> Samuel Thibault <[email protected]> wrote:
>
> > Came somebody have a look at this? The need is real, the only question
> > that comes to my mind is whether notifiers are allowed to modify the
> > param they are given. Since they are not marked const, I'd guess it'd
> > be ok?
>
> The notifier code doesn't care.
I know, but I'm asking about current practice.
> > Make kbd_keycode() read param.value after calling the keyboard notification
> > chain, to let the callee change the translation on the fly. This for instance
> > permits to remap the physical positions of the keys independently of the
> > configured keymap, for e.g. single-handed people.
>
> Surely that is just a new keymap ?
No. That would mean a lot of keymapSSS. Doing it the keymap way
would require to have us, us-revert-left, us-revert-right, en-uk,
uk-revert-left, uk-revert-right, etc. I really don't like that approach,
thus the "independently of the configured keymap".
This really is a problem that is orthogonal to keymaps: I'm here talking
about _physical_ keys remapping, not remapping what is printed on them
(which is done after that).
Samuel
> > Surely that is just a new keymap ?
>
> No. That would mean a lot of keymapSSS. Doing it the keymap way
Why - its an algorithmic question about how to edit them - remember you
can edit keymaps in programs at runtime and live.
> This really is a problem that is orthogonal to keymaps: I'm here talking
> about _physical_ keys remapping, not remapping what is printed on them
> (which is done after that).
Ok so this is analogous to the X key remapping. In which case a notifier
seems as sane as any other way to perform the action if you want it to be
an add on loadable feature.
Alan Cox, le Fri 09 Jan 2009 22:01:44 +0000, a ?crit :
> > > Surely that is just a new keymap ?
> >
> > No. That would mean a lot of keymapSSS. Doing it the keymap way
>
> Why - its an algorithmic question about how to edit them - remember you
> can edit keymaps in programs at runtime and live.
Right. I'm still afraid by that: we'd need to know how to remap the
various keycodes (amiga, atari, i386, mc, sun). And we'd have to
double the number of keymaps being used. Maybe I should have given an
example: somebody with one hand would rather not have to move it to
type everything. That means we should setup a key which, while being
pressed, changes the keys under his hand, e.g. for a left-handed,
putting l under the usual s, k under the usual d, j under the usual
f, etc. Of course we'd need to do that for all the shift/alt etc.
variations too, thus double the number of keymaps, which may not
possible, or else we'd drop some of them, but which ones?
I'm also afraid of how to plug that into distributions. Console
keyboard setup seemed to me quite heterogeous among distributions
already. (In case somebody wonders, no, a distribution "for disabled
people" is not a good idea, why should disabled people be left with just
one distribution and not have the choice?)
> > This really is a problem that is orthogonal to keymaps: I'm here talking
> > about _physical_ keys remapping, not remapping what is printed on them
> > (which is done after that).
>
> Ok so this is analogous to the X key remapping.
Not exactly: it's not 1-1, as examplified above.
Thanks,
Samuel
On Fri, Jan 09, 2009 at 11:23:41PM +0100, Samuel Thibault wrote:
> Alan Cox, le Fri 09 Jan 2009 22:01:44 +0000, a ?crit :
> > > > Surely that is just a new keymap ?
> > >
> > > No. That would mean a lot of keymapSSS. Doing it the keymap way
> >
> > Why - its an algorithmic question about how to edit them - remember you
> > can edit keymaps in programs at runtime and live.
>
> Right. I'm still afraid by that: we'd need to know how to remap the
> various keycodes (amiga, atari, i386, mc, sun).
Err - just use EVIOCSKEYCODE to swap the keycodes around, this works
in terms of the evdev keycodes. I use it in a small program to swap
around a bunch of keys.
A bit more of a challange would be listening to evdev, and when
detecting the 'swap' keycode, doing the reload with the actual swaps.
I'm not sure w/o reading the code if the kernel will allow this to be
shared between the tty and evdev on the same vt, but then one could
run a controller program talking through a pty and direct to the keyboard.
DF
Derek Fawcus, le Mon 12 Jan 2009 22:36:21 +0000, a ?crit :
> On Fri, Jan 09, 2009 at 11:23:41PM +0100, Samuel Thibault wrote:
> > Alan Cox, le Fri 09 Jan 2009 22:01:44 +0000, a ?crit :
> > > > > Surely that is just a new keymap ?
> > > >
> > > > No. That would mean a lot of keymapSSS. Doing it the keymap way
> > >
> > > Why - its an algorithmic question about how to edit them - remember you
> > > can edit keymaps in programs at runtime and live.
> >
> > Right. I'm still afraid by that: we'd need to know how to remap the
> > various keycodes (amiga, atari, i386, mc, sun).
>
> Err - just use EVIOCSKEYCODE to swap the keycodes around, this works
> in terms of the evdev keycodes. I use it in a small program to swap
> around a bunch of keys.
>
> A bit more of a challange would be listening to evdev, and when
> detecting the 'swap' keycode, doing the reload with the actual swaps.
Yes, that seems a bit unsafe to me. Another solution is to just grab
all the keyboard devices, and reemit the wanted evdev keycodes. Quite
clumsy.
> I'm not sure w/o reading the code if the kernel will allow this to be
> shared between the tty and evdev on the same vt,
What do you mean by "this"? The raw keycode -> input keycode
translation? My guess is that it is recorded for the device itself, not
related to things like VTs, and thus is global.
> but then one could run a controller program talking through a pty and
> direct to the keyboard.
Ugh. I'd prefer grabing evdev rather that using a pty.
Samuel
On Mon, Jan 12, 2009 at 11:51:12PM +0100, Samuel Thibault wrote:
> Derek Fawcus, le Mon 12 Jan 2009 22:36:21 +0000, a ?crit :
> > On Fri, Jan 09, 2009 at 11:23:41PM +0100, Samuel Thibault wrote:
> > > Alan Cox, le Fri 09 Jan 2009 22:01:44 +0000, a ?crit :
> > > > > > Surely that is just a new keymap ?
> > > > >
> > > > > No. That would mean a lot of keymapSSS. Doing it the keymap way
> > > >
> > > > Why - its an algorithmic question about how to edit them - remember you
> > > > can edit keymaps in programs at runtime and live.
> > >
> > > Right. I'm still afraid by that: we'd need to know how to remap the
> > > various keycodes (amiga, atari, i386, mc, sun).
> >
> > Err - just use EVIOCSKEYCODE to swap the keycodes around, this works
> > in terms of the evdev keycodes. I use it in a small program to swap
> > around a bunch of keys.
> >
> > A bit more of a challange would be listening to evdev, and when
> > detecting the 'swap' keycode, doing the reload with the actual swaps.
>
> Yes, that seems a bit unsafe to me. Another solution is to just grab
> all the keyboard devices, and reemit the wanted evdev keycodes. Quite
> clumsy.
reemit? as in inject back to the kernel? How does one prevent loops?
If one is able to in effect divert the event stream out of the kernel
and then back in to the normal evdev-> keyboard stream that would seem
a workable approach.
> > I'm not sure w/o reading the code if the kernel will allow this to be
> > shared between the tty and evdev on the same vt,
>
> What do you mean by "this"?
I was referring to being able to read the evdev data from the keyboard
while still allowing the vt to consume the data. Can one filter out
just keys of interest, or will reading the /dev/input/eventX prevent
the keys being fed to the vt and hence to /dev/ttyXX?
(Don't have source on this machine, so can't easily check).
> The raw keycode -> input keycode
> translation? My guess is that it is recorded for the device itself, not
> related to things like VTs, and thus is global.
Yup that is - my program for remapping affects all VTs - and more to
the point - X11 as well.
> > but then one could run a controller program talking through a pty and
> > direct to the keyboard.
>
> Ugh. I'd prefer grabing evdev rather that using a pty.
Well using the pty is not too bad, and some stuff seems unhappy unless
fed from a tty of some form (default line buffering for stdin/stdout,
job control with bash).
However, having written a prog for some of the pty interaction, it is
a lot larger that the diff you posted.
Anyway, wouldn't this all be easier with a app running on X and
XKEYBOARD/XKB manipulations? Have the key that does left/right
swapping simply be a group toggle action in the definition file.
DF
Derek Fawcus, le Tue 13 Jan 2009 01:06:13 +0000, a ?crit :
> > Yes, that seems a bit unsafe to me. Another solution is to just grab
> > all the keyboard devices, and reemit the wanted evdev keycodes. Quite
> > clumsy.
>
> reemit? as in inject back to the kernel?
Through uinput, yes.
> How does one prevent loops?
By not grabbing the evdev corresponding to your own uinput dev. IIRC it
can even work with several daemons doing so, the last being only able to
grab the last uinput's evdev. If a daemon hangs, no luck, however.
> > > I'm not sure w/o reading the code if the kernel will allow this to be
> > > shared between the tty and evdev on the same vt,
> >
> > What do you mean by "this"?
>
> I was referring to being able to read the evdev data from the keyboard
> while still allowing the vt to consume the data. Can one filter out
> just keys of interest, or will reading the /dev/input/eventX prevent
> the keys being fed to the vt and hence to /dev/ttyXX?
Grabbing does prevent it yes. But feeding through uinput puts it back
to the console.
> > > but then one could run a controller program talking through a pty and
> > > direct to the keyboard.
> >
> > Ugh. I'd prefer grabing evdev rather that using a pty.
>
> Well using the pty is not too bad, and some stuff seems unhappy unless
> fed from a tty of some form (default line buffering for stdin/stdout,
> job control with bash).
The problem with ptys too is that they manipulate letters, not physical
key position, thus loosing keyboard mapping independence.
> Anyway, wouldn't this all be easier with a app running on X and
> XKEYBOARD/XKB manipulations? Have the key that does left/right
> swapping simply be a group toggle action in the definition file.
Sure, but sometimes you're left without X, and that's not a reason for
suddenly completely loose typing speed.
Samuel
On Fri 2009-01-09 22:43:57, Samuel Thibault wrote:
> Alan Cox, le Fri 09 Jan 2009 21:35:55 +0000, a ?crit :
> > Samuel Thibault <[email protected]> wrote:
> >
> > > Came somebody have a look at this? The need is real, the only question
> > > that comes to my mind is whether notifiers are allowed to modify the
> > > param they are given. Since they are not marked const, I'd guess it'd
> > > be ok?
> >
> > The notifier code doesn't care.
>
> I know, but I'm asking about current practice.
>
> > > Make kbd_keycode() read param.value after calling the keyboard notification
> > > chain, to let the callee change the translation on the fly. This for instance
> > > permits to remap the physical positions of the keys independently of the
> > > configured keymap, for e.g. single-handed people.
> >
> > Surely that is just a new keymap ?
>
> No. That would mean a lot of keymapSSS. Doing it the keymap way
> would require to have us, us-revert-left, us-revert-right, en-uk,
> uk-revert-left, uk-revert-right, etc. I really don't like that approach,
> thus the "independently of the configured keymap".
...and that is ok if you autogenerate those keymaps, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek, le Thu 15 Jan 2009 08:40:44 +0100, a ?crit :
> On Fri 2009-01-09 22:43:57, Samuel Thibault wrote:
> > Alan Cox, le Fri 09 Jan 2009 21:35:55 +0000, a ?crit :
> > > Samuel Thibault <[email protected]> wrote:
> > > > Came somebody have a look at this? The need is real, the only question
> > > > that comes to my mind is whether notifiers are allowed to modify the
> > > > param they are given. Since they are not marked const, I'd guess it'd
> > > > be ok?
> > >
> > > The notifier code doesn't care.
> >
> > I know, but I'm asking about current practice.
> >
> > > > Make kbd_keycode() read param.value after calling the keyboard notification
> > > > chain, to let the callee change the translation on the fly. This for instance
> > > > permits to remap the physical positions of the keys independently of the
> > > > configured keymap, for e.g. single-handed people.
> > >
> > > Surely that is just a new keymap ?
> >
> > No. That would mean a lot of keymapSSS. Doing it the keymap way
> > would require to have us, us-revert-left, us-revert-right, en-uk,
> > uk-revert-left, uk-revert-right, etc. I really don't like that approach,
> > thus the "independently of the configured keymap".
>
> ...and that is ok if you autogenerate those keymaps, right?
> Pavel
I have already answered that, see
http://marc.info/?l=linux-kernel&m=123153985127010&w=2
Samuel