Hi,
I have a notebook (Dell Latitude D800) which has some keys (actual
fn+something combinations) that generate Down events but no Up events
(clever, isn't it).
This makes those keys unusable with 2.6.0 as it is because the input
layer insists on there being up events. Once it sees a down, it will
ignore any future down events until it sees an up event. It will
also auto-repeat the key until some other key is pressed. On the
whole, not very useful for these keys.
After some thought, the simplest way I could think of to fix it was
to have a bitmap of keys that don't generate up events themselves.
For these keys the auto-repeat code can then generate an "UP" event
(val==0) instead of a "repeat" event (val==2) after the timeout.
The following patch does that and I can now use those keys (after
using the relevant ioctl to associate the scan code with a keycode).
This may not be the best way to do it, and I am happy to discuss
other approaches, including different ioctls for getting the new
status bits into and out-of the kernel.
NeilBrown
----------- Diffstat output ------------
./drivers/input/evdev.c | 13 +++++++++++++
./drivers/input/input.c | 7 +++++--
./include/linux/input.h | 3 +++
3 files changed, 21 insertions(+), 2 deletions(-)
diff ./drivers/input/evdev.c~current~ ./drivers/input/evdev.c
--- ./drivers/input/evdev.c~current~ 2003-08-15 13:44:46.000000000 +1000
+++ ./drivers/input/evdev.c 2003-08-15 14:48:52.000000000 +1000
@@ -246,9 +246,21 @@ static int evdev_ioctl(struct inode *ino
if(INPUT_KEYCODE(dev, t) == u) break;
if (i == dev->keycodemax) clear_bit(u, dev->keybit);
set_bit(INPUT_KEYCODE(dev, t), dev->keybit);
+ clear_bit(INPUT_KEYCODE(dev, t), dev->key);
return 0;
+ case EVIOCSKEYNOUP:
+ if (get_user(t, ((int *) arg) + 0)) return -EFAULT;
+ if (t < 0 || t > dev->keycodemax) return -EINVAL;
+ if (get_user(u, ((int *) arg) + 1)) return -EFAULT;
+ if (u & ~1) return -EINVAL;
+ if (u)
+ set_bit(t, dev->keynoup);
+ else
+ clear_bit(t, dev->keynoup);
+ return 0;
+
case EVIOCSFF:
if (dev->upload_effect) {
struct ff_effect effect;
@@ -303,6 +315,7 @@ static int evdev_ioctl(struct inode *ino
switch (_IOC_NR(cmd) & EV_MAX) {
case 0: bits = dev->evbit; len = EV_MAX; break;
case EV_KEY: bits = dev->keybit; len = KEY_MAX; break;
+ case EV_REP: bits = dev->keynoup; len = KEY_MAX; break;
case EV_REL: bits = dev->relbit; len = REL_MAX; break;
case EV_ABS: bits = dev->absbit; len = ABS_MAX; break;
case EV_LED: bits = dev->ledbit; len = LED_MAX; break;
diff ./drivers/input/input.c~current~ ./drivers/input/input.c
--- ./drivers/input/input.c~current~ 2003-08-15 13:44:46.000000000 +1000
+++ ./drivers/input/input.c 2003-08-15 13:44:46.000000000 +1000
@@ -191,8 +191,11 @@ static void input_repeat_key(unsigned lo
if (!test_bit(dev->repeat_key, dev->key))
return;
-
- input_event(dev, EV_KEY, dev->repeat_key, 2);
+ if (test_bit(dev->repeat_key, dev->keynoup))
+ /* don't auto-repeat, just auto-up */
+ input_event(dev, EV_KEY, dev->repeat_key, 0);
+ else
+ input_event(dev, EV_KEY, dev->repeat_key, 2);
input_sync(dev);
mod_timer(&dev->timer, jiffies + dev->rep[REP_PERIOD]);
diff ./include/linux/input.h~current~ ./include/linux/input.h
--- ./include/linux/input.h~current~ 2003-08-15 12:16:16.000000000 +1000
+++ ./include/linux/input.h 2003-08-15 13:44:46.000000000 +1000
@@ -60,6 +60,7 @@ struct input_absinfo {
#define EVIOCSREP _IOW('E', 0x03, int[2]) /* get repeat settings */
#define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /* get keycode */
#define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /* set keycode */
+#define EVIOCSKEYNOUP _IOW('E', 0x05, int[2]) /* set 'no-repeat' bit */
#define EVIOCGNAME(len) _IOC(_IOC_READ, 'E', 0x06, len) /* get device name */
#define EVIOCGPHYS(len) _IOC(_IOC_READ, 'E', 0x07, len) /* get physical location */
@@ -790,6 +791,8 @@ struct input_dev {
int abs[ABS_MAX + 1];
int rep[REP_MAX + 1];
+ unsigned long keynoup[NBITS(KEY_MAX)]; /* set if key doesn't generate up event */
+
unsigned long key[NBITS(KEY_MAX)];
unsigned long led[NBITS(LED_MAX)];
unsigned long snd[NBITS(SND_MAX)];
On Fri, Aug 15, 2003 at 03:16:18PM +1000, Neil Brown wrote:
> I have a notebook (Dell Latitude D800) which has some keys (actual
> fn+something combinations) that generate Down events but no Up events
> (clever, isn't it).
>
> This makes those keys unusable with 2.6.0 as it is because the input
> layer insists on there being up events. Once it sees a down, it will
> ignore any future down events until it sees an up event. It will
> also auto-repeat the key until some other key is pressed. On the
> whole, not very useful for these keys.
>
> After some thought, the simplest way I could think of to fix it was
> to have a bitmap of keys that don't generate up events themselves.
I think we should go for a much simpler fix: only enable the timer-induced
repeat when the user asks for that (say, by boot parameter).
The keyboard already knows which keys repeat and which don't.
If we forget about the kernel-invented repetition, we solve, I suppose,
the problems of those people who see impossibly fast repeat, and
also your problem.
Your solution, which involves an ioctl, would force changes to user space.
Too inconvenient.
Andries
[By the way, I am a collector of data on strange keyboards - could you
on a 2.4 system use showkey -s and tell me about the combinations
without Up events? - [email protected]]
On Fri, Aug 15, 2003 at 09:46:04AM +0200, Andries Brouwer wrote:
> > I have a notebook (Dell Latitude D800) which has some keys (actual
> > fn+something combinations) that generate Down events but no Up events
> > (clever, isn't it).
> >
> > This makes those keys unusable with 2.6.0 as it is because the input
> > layer insists on there being up events. Once it sees a down, it will
> > ignore any future down events until it sees an up event. It will
> > also auto-repeat the key until some other key is pressed. On the
> > whole, not very useful for these keys.
> >
> > After some thought, the simplest way I could think of to fix it was
> > to have a bitmap of keys that don't generate up events themselves.
>
> I think we should go for a much simpler fix: only enable the timer-induced
> repeat when the user asks for that (say, by boot parameter).
> The keyboard already knows which keys repeat and which don't.
That won't solve it - the key, while not repeating would be still
considered 'down' by the kernel and any more pressing of the key
wouldn't do anything.
> If we forget about the kernel-invented repetition, we solve, I suppose,
> the problems of those people who see impossibly fast repeat, and
> also your problem.
Only for those with PS/2 keyboards. We still need the kernel repeat for
all other kinds of keyboards. And the impossibly fast repeat problem
actually needs solving elsewhere - it's a bad interaction betwen ACPI
and kernel timer, and that'll cause more trouble than just fast repeat.
> Your solution, which involves an ioctl, would force changes to user space.
> Too inconvenient.
My proposed solution is to do an input_report_key(pressed) immediately
followed by input_report_key(released) for these keys straight in
atkbd.c. Possibly based on some flag in the scancode->keycode table for
that scancode.
> [By the way, I am a collector of data on strange keyboards - could you
> on a 2.4 system use showkey -s and tell me about the combinations
> without Up events? - [email protected]]
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, Aug 15, 2003 at 12:58:02PM +0200, Vojtech Pavlik wrote:
> > > I have a notebook (Dell Latitude D800) which has some keys (actual
> > > fn+something combinations) that generate Down events but no Up events
> > > (clever, isn't it).
> > > This makes those keys unusable with 2.6.0 as it is
> > I think we should go for the simple fix: only enable the timer-induced
> > repeat when the user asks for that (say, by boot parameter).
> > The keyboard already knows which keys repeat and which don't.
> That won't solve it - the key, while not repeating would be still
> considered 'down' by the kernel and any more pressing of the key
> wouldn't do anything.
Yes, it would still be considered down. But that does not imply
that pressing it doesnt do anything. It is up to the driver
to discard key presses, and I think it shouldnt.
(Unless of course the user asks for that behaviour - it may be required
on some broken laptops.)
Just the simple: a keypress generates an interrupt and we see a keystroke.
Use a kernel timer only when we know or the user tells us that it is needed.
Not in the default situation.
> My proposed solution is to do an input_report_key(pressed) immediately
> followed by input_report_key(released) for these keys straight in
> atkbd.c. Possibly based on some flag in the scancode->keycode table for
> that scancode.
But that would require users to report on precisely which keys are affected
and would give complications where I suppose 2.4 did not have any.
This is the way towards an ever more complicated keyboard driver.
Not what you would want.
Andries
On Fri, Aug 15, 2003 at 02:36:41PM +0200, Andries Brouwer wrote:
> On Fri, Aug 15, 2003 at 12:58:02PM +0200, Vojtech Pavlik wrote:
>
> > > > I have a notebook (Dell Latitude D800) which has some keys (actual
> > > > fn+something combinations) that generate Down events but no Up events
> > > > (clever, isn't it).
> > > > This makes those keys unusable with 2.6.0 as it is
>
> > > I think we should go for the simple fix: only enable the timer-induced
> > > repeat when the user asks for that (say, by boot parameter).
> > > The keyboard already knows which keys repeat and which don't.
>
> > That won't solve it - the key, while not repeating would be still
> > considered 'down' by the kernel and any more pressing of the key
> > wouldn't do anything.
>
> Yes, it would still be considered down. But that does not imply
> that pressing it doesnt do anything. It is up to the driver
> to discard key presses, and I think it shouldnt.
> (Unless of course the user asks for that behaviour - it may be required
> on some broken laptops.)
>
> Just the simple: a keypress generates an interrupt and we see a keystroke.
>
> Use a kernel timer only when we know or the user tells us that it is needed.
> Not in the default situation.
I'm not very fond of making special exception for the (hopefully soon to
be doing) PS/2 genre of keyboards. For USB for example you don't get an
interrupt and a scancode per keypress. You get the current keyboard
state. So I prefer to keep the keyboard state in the kernel, too, since
that is a model that fits more devices. Also not just keyboards.
> > My proposed solution is to do an input_report_key(pressed) immediately
> > followed by input_report_key(released) for these keys straight in
> > atkbd.c. Possibly based on some flag in the scancode->keycode table for
> > that scancode.
>
> But that would require users to report on precisely which keys are affected
> and would give complications where I suppose 2.4 did not have any.
> This is the way towards an ever more complicated keyboard driver.
> Not what you would want.
I definitely want one single driver being more complicated than the core
getting more complicated.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Friday August 15, [email protected] wrote:
>
> My proposed solution is to do an input_report_key(pressed) immediately
> followed by input_report_key(released) for these keys straight in
> atkbd.c. Possibly based on some flag in the scancode->keycode table for
> that scancode.
Something like this?
I use bit 32 in the keycode setting to mean "don't expect an 'up'
event".
It seems to work (though some of the keys actually generate 'down'
events for both the down and up transitions, so it seems that the key
is pressed twice. I'm happy that that is just a buggy keyboard and I
can work around it).
NeilBrown
----------- Diffstat output ------------
./drivers/input/evdev.c | 13 ++++++++++---
./drivers/input/keyboard/atkbd.c | 7 +++++++
./include/linux/input.h | 1 +
3 files changed, 18 insertions(+), 3 deletions(-)
diff ./drivers/input/evdev.c~current~ ./drivers/input/evdev.c
--- ./drivers/input/evdev.c~current~ 2003-08-15 21:31:47.000000000 +1000
+++ ./drivers/input/evdev.c 2003-08-15 21:35:00.000000000 +1000
@@ -233,15 +233,22 @@ static int evdev_ioctl(struct inode *ino
case EVIOCGKEYCODE:
if (get_user(t, ((int *) arg) + 0)) return -EFAULT;
if (t < 0 || t > dev->keycodemax || !dev->keycodesize) return -EINVAL;
- if (put_user(INPUT_KEYCODE(dev, t), ((int *) arg) + 1)) return -EFAULT;
+ u = (dev->keycode_noup && test_bit(t, dev->keycode_noup)) ? (1<<31) : 0;
+ if (put_user(u | INPUT_KEYCODE(dev, t), ((int *) arg) + 1)) return -EFAULT;
return 0;
case EVIOCSKEYCODE:
if (get_user(t, ((int *) arg) + 0)) return -EFAULT;
if (t < 0 || t > dev->keycodemax || !dev->keycodesize) return -EINVAL;
u = INPUT_KEYCODE(dev, t);
- if (get_user(INPUT_KEYCODE(dev, t), ((int *) arg) + 1)) return -EFAULT;
-
+ if (get_user(i, ((int *) arg) + 1)) return -EFAULT;
+ INPUT_KEYCODE(dev, t) = i;
+ if (dev->keycode_noup) {
+ if (i & (1<<31))
+ set_bit(t, dev->keycode_noup);
+ else
+ clear_bit(t, dev->keycode_noup);
+ }
for (i = 0; i < dev->keycodemax; i++)
if(INPUT_KEYCODE(dev, t) == u) break;
if (i == dev->keycodemax) clear_bit(u, dev->keybit);
diff ./drivers/input/keyboard/atkbd.c~current~ ./drivers/input/keyboard/atkbd.c
--- ./drivers/input/keyboard/atkbd.c~current~ 2003-08-15 21:35:00.000000000 +1000
+++ ./drivers/input/keyboard/atkbd.c 2003-08-15 22:12:50.000000000 +1000
@@ -112,6 +112,7 @@ static unsigned char atkbd_set3_keycode[
struct atkbd {
unsigned char keycode[512];
+ unsigned long keycode_noup[NBITS(512)];
struct input_dev dev;
struct serio *serio;
char name[64];
@@ -198,6 +199,10 @@ static irqreturn_t atkbd_interrupt(struc
input_regs(&atkbd->dev, regs);
input_report_key(&atkbd->dev, atkbd->keycode[code], !atkbd->release);
input_sync(&atkbd->dev);
+ if (!atkbd->release && test_bit(code, atkbd->keycode_noup)) {
+ input_report_key(&atkbd->dev, atkbd->keycode[code], 0);
+ input_sync(&atkbd->dev);
+ }
}
atkbd->release = 0;
@@ -512,6 +517,7 @@ static void atkbd_connect(struct serio *
atkbd->dev.keycode = atkbd->keycode;
atkbd->dev.keycodesize = sizeof(unsigned char);
atkbd->dev.keycodemax = ARRAY_SIZE(atkbd_set2_keycode);
+ atkbd->dev.keycode_noup = atkbd->keycode_noup;
atkbd->dev.event = atkbd_event;
atkbd->dev.private = atkbd;
@@ -549,6 +555,7 @@ static void atkbd_connect(struct serio *
memcpy(atkbd->keycode, atkbd_set3_keycode, sizeof(atkbd->keycode));
else
memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
+ memset(atkbd->keycode_noup, 0, sizeof(atkbd->keycode_noup));
atkbd->dev.name = atkbd->name;
atkbd->dev.phys = atkbd->phys;
diff ./include/linux/input.h~current~ ./include/linux/input.h
--- ./include/linux/input.h~current~ 2003-08-15 21:31:47.000000000 +1000
+++ ./include/linux/input.h 2003-08-15 21:35:00.000000000 +1000
@@ -778,6 +778,7 @@ struct input_dev {
unsigned int keycodemax;
unsigned int keycodesize;
void *keycode;
+ unsigned long *keycode_noup;
unsigned int repeat_key;
struct timer_list timer;
On Fri, Aug 15, 2003 at 10:46:07PM +1000, Neil Brown wrote:
> On Friday August 15, [email protected] wrote:
> >
> > My proposed solution is to do an input_report_key(pressed) immediately
> > followed by input_report_key(released) for these keys straight in
> > atkbd.c. Possibly based on some flag in the scancode->keycode table for
> > that scancode.
>
> Something like this?
>
> I use bit 32 in the keycode setting to mean "don't expect an 'up'
> event".
> It seems to work (though some of the keys actually generate 'down'
> events for both the down and up transitions, so it seems that the key
> is pressed twice.
Now that is suspicious. This smells of some scancode mangling happening.
Can you try with i8042_direct=1? And with both i8042_direct=1 and atkbd_set=3?
> I'm happy that that is just a buggy keyboard and I
> can work around it).
>
> NeilBrown
>
>
> ----------- Diffstat output ------------
> ./drivers/input/evdev.c | 13 ++++++++++---
> ./drivers/input/keyboard/atkbd.c | 7 +++++++
> ./include/linux/input.h | 1 +
> 3 files changed, 18 insertions(+), 3 deletions(-)
>
> diff ./drivers/input/evdev.c~current~ ./drivers/input/evdev.c
> --- ./drivers/input/evdev.c~current~ 2003-08-15 21:31:47.000000000 +1000
> +++ ./drivers/input/evdev.c 2003-08-15 21:35:00.000000000 +1000
> @@ -233,15 +233,22 @@ static int evdev_ioctl(struct inode *ino
> case EVIOCGKEYCODE:
> if (get_user(t, ((int *) arg) + 0)) return -EFAULT;
> if (t < 0 || t > dev->keycodemax || !dev->keycodesize) return -EINVAL;
> - if (put_user(INPUT_KEYCODE(dev, t), ((int *) arg) + 1)) return -EFAULT;
> + u = (dev->keycode_noup && test_bit(t, dev->keycode_noup)) ? (1<<31) : 0;
> + if (put_user(u | INPUT_KEYCODE(dev, t), ((int *) arg) + 1)) return -EFAULT;
> return 0;
>
> case EVIOCSKEYCODE:
> if (get_user(t, ((int *) arg) + 0)) return -EFAULT;
> if (t < 0 || t > dev->keycodemax || !dev->keycodesize) return -EINVAL;
> u = INPUT_KEYCODE(dev, t);
> - if (get_user(INPUT_KEYCODE(dev, t), ((int *) arg) + 1)) return -EFAULT;
> -
> + if (get_user(i, ((int *) arg) + 1)) return -EFAULT;
> + INPUT_KEYCODE(dev, t) = i;
> + if (dev->keycode_noup) {
> + if (i & (1<<31))
> + set_bit(t, dev->keycode_noup);
> + else
> + clear_bit(t, dev->keycode_noup);
> + }
> for (i = 0; i < dev->keycodemax; i++)
> if(INPUT_KEYCODE(dev, t) == u) break;
> if (i == dev->keycodemax) clear_bit(u, dev->keybit);
>
> diff ./drivers/input/keyboard/atkbd.c~current~ ./drivers/input/keyboard/atkbd.c
> --- ./drivers/input/keyboard/atkbd.c~current~ 2003-08-15 21:35:00.000000000 +1000
> +++ ./drivers/input/keyboard/atkbd.c 2003-08-15 22:12:50.000000000 +1000
> @@ -112,6 +112,7 @@ static unsigned char atkbd_set3_keycode[
>
> struct atkbd {
> unsigned char keycode[512];
> + unsigned long keycode_noup[NBITS(512)];
> struct input_dev dev;
> struct serio *serio;
> char name[64];
> @@ -198,6 +199,10 @@ static irqreturn_t atkbd_interrupt(struc
> input_regs(&atkbd->dev, regs);
> input_report_key(&atkbd->dev, atkbd->keycode[code], !atkbd->release);
> input_sync(&atkbd->dev);
> + if (!atkbd->release && test_bit(code, atkbd->keycode_noup)) {
> + input_report_key(&atkbd->dev, atkbd->keycode[code], 0);
> + input_sync(&atkbd->dev);
> + }
> }
>
> atkbd->release = 0;
> @@ -512,6 +517,7 @@ static void atkbd_connect(struct serio *
> atkbd->dev.keycode = atkbd->keycode;
> atkbd->dev.keycodesize = sizeof(unsigned char);
> atkbd->dev.keycodemax = ARRAY_SIZE(atkbd_set2_keycode);
> + atkbd->dev.keycode_noup = atkbd->keycode_noup;
> atkbd->dev.event = atkbd_event;
> atkbd->dev.private = atkbd;
>
> @@ -549,6 +555,7 @@ static void atkbd_connect(struct serio *
> memcpy(atkbd->keycode, atkbd_set3_keycode, sizeof(atkbd->keycode));
> else
> memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
> + memset(atkbd->keycode_noup, 0, sizeof(atkbd->keycode_noup));
>
> atkbd->dev.name = atkbd->name;
> atkbd->dev.phys = atkbd->phys;
>
> diff ./include/linux/input.h~current~ ./include/linux/input.h
> --- ./include/linux/input.h~current~ 2003-08-15 21:31:47.000000000 +1000
> +++ ./include/linux/input.h 2003-08-15 21:35:00.000000000 +1000
> @@ -778,6 +778,7 @@ struct input_dev {
> unsigned int keycodemax;
> unsigned int keycodesize;
> void *keycode;
> + unsigned long *keycode_noup;
>
> unsigned int repeat_key;
> struct timer_list timer;
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Andries Brouwer wrote:
> Yes, it would still be considered down. But that does not imply
> that pressing it doesnt do anything. It is up to the driver
> to discard key presses, and I think it shouldnt.
> (Unless of course the user asks for that behaviour - it may be required
> on some broken laptops.)
It should discard multiple presses of the same key in very rapid
succession, when that is immediately after the first press of that
key. (After a time has passed, rapid successive presses are due to
auto-repeat, which is ok).
Several laptops seem to send a key down event 3, 5 or very many times
in response to a single press.
-- Jamie
On Fri, Aug 15, 2003 at 02:04:50PM +0100, Jamie Lokier wrote:
> Andries Brouwer wrote:
> > Yes, it would still be considered down. But that does not imply
> > that pressing it doesnt do anything. It is up to the driver
> > to discard key presses, and I think it shouldnt.
> > (Unless of course the user asks for that behaviour - it may be required
> > on some broken laptops.)
>
> It should discard multiple presses of the same key in very rapid
> succession, when that is immediately after the first press of that
> key. (After a time has passed, rapid successive presses are due to
> auto-repeat, which is ok).
>
> Several laptops seem to send a key down event 3, 5 or very many times
> in response to a single press.
One way this could be handled fairly nicely (although the method is
maybe too clever to be good) would be to leave the autorepeat up to the
sw, ignore any successive presses without a release and watch whether
the keyboard will start autorepeating the key after 250 msec. If it does
not, then force the key to be released even if we got no release
scancode.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Vojtech Pavlik wrote:
> > Several laptops seem to send a key down event 3, 5 or very many times
> > in response to a single press.
>
> One way this could be handled fairly nicely (although the method is
> maybe too clever to be good) would be to leave the autorepeat up to the
> sw, ignore any successive presses without a release and watch whether
> the keyboard will start autorepeating the key after 250 msec. If it does
> not, then force the key to be released even if we got no release
> scancode.
Perhaps it's too clever, because some users configure the repeat delay
in their BIOS to longer than 250ms.
It is fine if you are able to reliably program the keyboard to use the
250ms delay, though.
Aren't there some keys which report DOWN and UP but which don't repeat?
The PS/2 keyboard protocol is utterly absurd.
-- Jamie
Vojtech Pavlik wrote:
> I'm not very fond of making special exception for the (hopefully soon to
> be doing) PS/2 genre of keyboards. For USB for example you don't get an
> interrupt and a scancode per keypress. You get the current keyboard
> state. So I prefer to keep the keyboard state in the kernel, too, since
> that is a model that fits more devices. Also not just keyboards.
I think you just have to accept that there are two designs in common
use, and neither maps in a predictable way on to the other: keyboards
which send the state (USB), and keyboards which never reveal the state
(PS/2 with strange mixtures of DOWN+UP, DOWN only, repeating and
non-repeating keys).
Anything else is going to do the wrong thing with the other kind of
keyboard, until the user does something special, which will be beyond
many users to configure themselves.
> > > My proposed solution is to do an input_report_key(pressed) immediately
> > > followed by input_report_key(released) for these keys straight in
> > > atkbd.c. Possibly based on some flag in the scancode->keycode table for
> > > that scancode.
> >
> > But that would require users to report on precisely which keys are affected
> > and would give complications where I suppose 2.4 did not have any.
> > This is the way towards an ever more complicated keyboard driver.
> > Not what you would want.
>
> I definitely want one single driver being more complicated than the core
> getting more complicated.
The point is moot if the set of special keys on PS/2 keyboards is the
same for all keyboards, though. Then nothing special is required of
the user. That would be the best, if it is possible.
But if not
----------
How about the PS/2 driver auto-discovers special (no UP event) keys:
1. The range of known reliable keys, such as letters, can use software
mode (repeat, depends on UP reports) from the beginning.
2. Set up _every_ other key to be non-repeating in software, with
(a) consecutive DOWN events causing a synthetic UP just before
the second and subsequent DOWNs.
(b) a synthetic UP after a timeout in the DOWN state.
3. Whenever the keyboard sends an UP, change that key (only that key) to
be in software mode like 1.
After booting, if the user presses "r", it will behave as expected -
it's covered by 1.
If the user presses "Fn+F1" or some other unknown key which doesn't
report UP events, it won't repeat and it will report DOWN then UP
input events, once each time it is pressed.
If the user presses another unknown key such as "PrevTrack" which does
report UP events, that will not repeat the first time it is pressed
and released, but subsequently it will.
In all cases, the driver errs on the side of not creating more press
events than it knows is safe.
-- Jamie
On Fri, Aug 15, 2003 at 10:46:07PM +1000, Neil Brown wrote:
> It seems to work (though some of the keys actually generate 'down'
> events for both the down and up transitions, so it seems that the key
> is pressed twice.
Maybe it really is as you say. But your description sounds fishy.
It would be nice to know what really happens.
(And it would be nice to know which scancodes are involved.)
On Fri, Aug 15, 2003 at 02:33:07PM +0100, Jamie Lokier wrote:
> Vojtech Pavlik wrote:
> > > Several laptops seem to send a key down event 3, 5 or very many times
> > > in response to a single press.
> >
> > One way this could be handled fairly nicely (although the method is
> > maybe too clever to be good) would be to leave the autorepeat up to the
> > sw, ignore any successive presses without a release and watch whether
> > the keyboard will start autorepeating the key after 250 msec. If it does
> > not, then force the key to be released even if we got no release
> > scancode.
>
> Perhaps it's too clever, because some users configure the repeat delay
> in their BIOS to longer than 250ms.
The driver programs the delay. The BIOS setting is irrelevant.
> It is fine if you are able to reliably program the keyboard to use the
> 250ms delay, though.
I am.
> Aren't there some keys which report DOWN and UP but which don't repeat?
No.
> The PS/2 keyboard protocol is utterly absurd.
Yep. It's a dozen or more years of hack upon a hack.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Vojtech Pavlik wrote:
> > 2. Set up _every_ other key to be non-repeating in software, with
> >
> > (a) consecutive DOWN events causing a synthetic UP just before
> > the second and subsequent DOWNs.
>
> Won't work on keyboards which send more than one DOWN before an UP.
> There are a bunch of these, notably the broken notebook keyboards.
I forgot to mention 2b: if subsequent DOWNs appear in rapid succession
_soon_ after the first DOWN, it's a buggy laptop. Ignore those
subsequent DOWNs.
> > After booting, if the user presses "r", it will behave as expected -
> > it's covered by 1.
> >
> > If the user presses "Fn+F1" or some other unknown key which doesn't
> > report UP events, it won't repeat and it will report DOWN then UP
> > input events, once each time it is pressed.
>
> Fn+F1 won't most likely generate a keypress event. It'll just change the
> contrast via the BIOS or something.
I meant the keys which started this thread:
I have a notebook (Dell Latitude D800) which has some keys (actual
fn+something combinations) that generate Down events but no Up events
(clever, isn't it).
> I really believe that keys which generate the same scancode when pressed
> and released (as per the report which started the thread) usually happen
> because the keyboard is in some non-native mode.
>
> I have keyboards which report the same scancode for both press and
> release of several keys (making the keys undistinguishable) unless
> switched to scancode set 3.
If switching to scancode set 3 solves the whole problem, that's great :)
-- Jamie
On Fri, Aug 15, 2003 at 02:27:06PM +0100, Jamie Lokier wrote:
> I think you just have to accept that there are two designs in common
> use, and neither maps in a predictable way on to the other: keyboards
> which send the state (USB), and keyboards which never reveal the state
> (PS/2 with strange mixtures of DOWN+UP, DOWN only, repeating and
> non-repeating keys).
Well, all keyboards but PS/2 are able to report (or keep track) of the
state quite well, and regarding PS/2 only buggy keyboards that deviate
from the basic rules of sanity are a problem.
> Anything else is going to do the wrong thing with the other kind of
> keyboard, until the user does something special, which will be beyond
> many users to configure themselves.
Maybe.
> > > But that would require users to report on precisely which keys are affected
> > > and would give complications where I suppose 2.4 did not have any.
> > > This is the way towards an ever more complicated keyboard driver.
> > > Not what you would want.
> >
> > I definitely want one single driver being more complicated than the core
> > getting more complicated.
>
> The point is moot if the set of special keys on PS/2 keyboards is the
> same for all keyboards, though.
It is not. There is only ONE key that is not repeated on normal PS/2
keyboards and that is the Pause key. All other keys (including shift,
etc) are repeated. The Pause key, though, sends both Down and Up events
on the keypress, so it doesn't confuse the software.
> Then nothing special is required of
> the user. That would be the best, if it is possible.
The best is never possible.
> But if not
> ----------
>
> How about the PS/2 driver auto-discovers special (no UP event) keys:
>
> 1. The range of known reliable keys, such as letters, can use software
> mode (repeat, depends on UP reports) from the beginning.
Ok.
> 2. Set up _every_ other key to be non-repeating in software, with
>
> (a) consecutive DOWN events causing a synthetic UP just before
> the second and subsequent DOWNs.
Won't work on keyboards which send more than one DOWN before an UP.
There are a bunch of these, notably the broken notebook keyboards.
> (b) a synthetic UP after a timeout in the DOWN state.
That's what I'm planning to implement, with the timeout being the
hardware autorepeat delay. This way the sw autorepeat never kicks in
unless the hardware one does, too. On the PS/2 keyboards only.
> 3. Whenever the keyboard sends an UP, change that key (only that key) to
> be in software mode like 1.
>
> After booting, if the user presses "r", it will behave as expected -
> it's covered by 1.
>
> If the user presses "Fn+F1" or some other unknown key which doesn't
> report UP events, it won't repeat and it will report DOWN then UP
> input events, once each time it is pressed.
Fn+F1 won't most likely generate a keypress event. It'll just change the
contrast via the BIOS or something.
I really believe that keys which generate the same scancode when pressed
and released (as per the report which started the thread) usually happen
because the keyboard is in some non-native mode.
I have keyboards which report the same scancode for both press and
release of several keys (making the keys undistinguishable) unless
switched to scancode set 3.
> If the user presses another unknown key such as "PrevTrack" which does
> report UP events, that will not repeat the first time it is pressed
> and released, but subsequently it will.
>
> In all cases, the driver errs on the side of not creating more press
> events than it knows is safe.
>
> -- Jamie
--
Vojtech Pavlik
SuSE Labs, SuSE CR
[email protected] said:
> be doing) PS/2 genre of keyboards. For USB for example you don't get an
> interrupt and a scancode per keypress. You get the current keyboard
> state.
Then how am I getting infinitely repeating keys with a USB keyboard? I
recently switched to a kinesis ergo USB keyboard, and I had to disable
autorepeat in X because I had problems with keys occasionally repeating
infinitely until I hit something else to make it stop. I haven't tracked
down whether that's a hardware problem or in software.
Are you aware of that happening with USB keyboards?
Jason
On Fri, Aug 15, 2003 at 03:52:48PM +0200, Andries Brouwer wrote:
> On Fri, Aug 15, 2003 at 10:46:07PM +1000, Neil Brown wrote:
>
> > It seems to work (though some of the keys actually generate 'down'
> > events for both the down and up transitions, so it seems that the key
> > is pressed twice.
>
> Maybe it really is as you say. But your description sounds fishy.
> It would be nice to know what really happens.
> (And it would be nice to know which scancodes are involved.)
Indeed. Neil, please enable DEBUG in i8042.c ... both with and without the
i8042_direct=1 and atkbd_set=3 options from my previous e-mail.
And for Andries, if you can, do the showkey -s test on 2.4, too ...
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Friday August 15, [email protected] wrote:
> On Fri, Aug 15, 2003 at 03:52:48PM +0200, Andries Brouwer wrote:
> > On Fri, Aug 15, 2003 at 10:46:07PM +1000, Neil Brown wrote:
> >
> > > It seems to work (though some of the keys actually generate 'down'
> > > events for both the down and up transitions, so it seems that the key
> > > is pressed twice.
> >
> > Maybe it really is as you say. But your description sounds fishy.
> > It would be nice to know what really happens.
> > (And it would be nice to know which scancodes are involved.)
>
> Indeed. Neil, please enable DEBUG in i8042.c ... both with and without the
> i8042_direct=1 and atkbd_set=3 options from my previous e-mail.
>
> And for Andries, if you can, do the showkey -s test on 2.4, too ...
Well...
There are 5 keys in question. Each one is fn + something else.
Some of them (wireless, brighter, darker) cause the bios to do
something, and only generate a keyboard event on a down transition.
The others (battery, cdeject) don't appear to cause the bios to do
anything, and generate a keyboard event on both the up and down
transition, and it is always the same scancode.
Key Meaning 2.6 scancode 2.4 (direct) scancode
fn-F2 wireless 0x13d e0 08
fn-F3 battery 0x136 e0 07
fn-F10 cdeject 0x13e e0 09
fn-down darker 0x125 e0 05
fn-up brighter 0x12e e0 06
The "2.6 scancode" is the scancode reported in the
atkbd.c: Unknown key (set 2, scancode ...)
message, and it is always a "pressed" message. It is also the
scancode I use in the EVIOCSKEYCODE ioctl to associate a keycode with
the key.
The "2.4 (direct) scancode" is what I get back from "showkey -s".
When I set i8042_direct=1, the keyboard doesn't work sensibly at all.
Many keys cause "Unknown key" messages, other cause unrelated
characters to start autorepeating.
The 5 keys in question generate scancodes reported as 0x100 plus the
second number in the "2.4 (direct) scancode" column.
Setting atkbd_set=3 doesn't appear to affect things at all. It is
still reported as an "AT Set 2 keyboard".
When I enable debug in i8042.c, I get lots of messages about bytes to
and from the i8042. There are no surprises in the bytes relating to
keystrokes. They are exactly what is in the "2.4 (direct) scancode"
column.
I can send you the i8042 initialisation conversations if they will
help.
For my purposes, I need to use an "ioctl" to set a keycode for each
scancode, so adding an ioctl to set the no-keyup status is no hassle
for me. However the suggest approach of auto-detecting keys which
have no up event would probably a good idea.
NeilBrown
On Fri, 15 Aug 2003, Jamie Lokier wrote:
> Aren't there some keys which report DOWN and UP but which don't repeat?
>
> The PS/2 keyboard protocol is utterly absurd.
In mode #3 you can configure press/release/repeat characteristics of
every key separately, although the sane default might be to set all keys
to report all three kinds of events. The exception might of course be
buggy hardware.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Fri, 15 Aug 2003, Vojtech Pavlik wrote:
> > The PS/2 keyboard protocol is utterly absurd.
>
> Yep. It's a dozen or more years of hack upon a hack.
Well, mode #3 with no translation in the i8042 looks quite sanely.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
Maciej W. Rozycki wrote:
> On Fri, 15 Aug 2003, Vojtech Pavlik wrote:
> > > The PS/2 keyboard protocol is utterly absurd.
> > Yep. It's a dozen or more years of hack upon a hack.
> Well, mode #3 with no translation in the i8042 looks quite sanely.
What are the known problems with mode #3, then?
That is, why doesn't everyone use it and why haven't they always used it?
For that matter, what does Windows use?
-- Jamie
> > > > The PS/2 keyboard protocol is utterly absurd.
> > > Yep. It's a dozen or more years of hack upon a hack.
> > Well, mode #3 with no translation in the i8042 looks quite sanely.
> What are the known problems with mode #3, then?
It's poorly implemented by a lot of keyboards.
Has anybody actually verified that the keyboards that are presenting
the problem in quesiton are not specifically identifyable by their ID
string, or some other means - E.G. they only exist on specific, known
laptops?
My keyboard has a distinct ID, and works fine in set 3, but isn't
detected as set 3 capable. I'll have to make a patch some time...
John
On Sat, Aug 16, 2003 at 03:09:01PM +0100, Jamie Lokier wrote:
> Maciej W. Rozycki wrote:
> > On Fri, 15 Aug 2003, Vojtech Pavlik wrote:
> > > > The PS/2 keyboard protocol is utterly absurd.
> > > Yep. It's a dozen or more years of hack upon a hack.
> > Well, mode #3 with no translation in the i8042 looks quite sanely.
>
> What are the known problems with mode #3, then?
It's broken on many keyboards (on some only slightly, like some keys not
working properly). Other (special, either unix workstation or point of
sale) keyboards need it to work properly.
> That is, why doesn't everyone use it and why haven't they always used it?
Because old AT keyboards didn't support it. Because the XT keyboard
didn't support it. Because history sticks.
> For that matter, what does Windows use?
Translated Set 2. Actually an emulated XT keyboard.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sat, 16 Aug 2003, John Bradford wrote:
> > What are the known problems with mode #3, then?
>
> It's poorly implemented by a lot of keyboards.
Specifically, it wasn't used much at the beginning (see e.g. when we came
to trying it -- it's already ~15 years since it was introduced) and then
the crapware era began and some manufacturers stopped taking care of less
commonly used standard functionality.
> Has anybody actually verified that the keyboards that are presenting
> the problem in quesiton are not specifically identifyable by their ID
> string, or some other means - E.G. they only exist on specific, known
> laptops?
I recall testing an i486 laptop around 1996 and not only it accepted
switching mode to #3, but it reported it as being active then as well.
Yet it generated #2 codes regardless...
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Sun, 17 Aug 2003, Vojtech Pavlik wrote:
> > What are the known problems with mode #3, then?
>
> It's broken on many keyboards (on some only slightly, like some keys not
> working properly). Other (special, either unix workstation or point of
> sale) keyboards need it to work properly.
IIRC, OSF/1 running on later Alphas with a PS/2 keyboard interface
(earlier oned had an LK201 one) uses mode #3. I can't comment on the VMS.
> > That is, why doesn't everyone use it and why haven't they always used it?
>
> Because old AT keyboards didn't support it. Because the XT keyboard
> didn't support it. Because history sticks.
Since the 8042+keyboard combo supports a PC/XT compatibility mode there
was no incentive -- why bother modifying software if the hardware works
with the old one? Even if that sucks.
> > For that matter, what does Windows use?
>
> Translated Set 2. Actually an emulated XT keyboard.
For mode #3 explicit handling for hot-plugging would be required -- I
guess the change would be much too intrusive. And untranslated mode #2 is
nearly the same as an emulated PC/XT keyboard: codes are different and the
release bit is replaced by the release code, but the multibyte mess for
PS/2-specific keys remains -- no gain at all.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Sat, Aug 16, 2003 at 03:02:50PM +0200, Maciej W. Rozycki wrote:
> Well, mode #3 with no translation in the i8042 looks quite sanely.
In theory perhaps. In practice it isnt sane at all.
(That is, the majority of the keyboards sold today do not do as one
would wish. Since Microsoft does not require anything for Set 3,
behaviour in Set 3 is essentially random, especially for these
additional keys and buttons. A single keypress may give several
scancodes, or none at all. Many laptops do not have any support
for Set 3. USB compatibility only implements compatibility with
translated Set 2.)
On Sat, Aug 16, 2003 at 05:57:41PM +1000, Neil Brown wrote:
> On Friday August 15, [email protected] wrote:
> > On Fri, Aug 15, 2003 at 03:52:48PM +0200, Andries Brouwer wrote:
> > > On Fri, Aug 15, 2003 at 10:46:07PM +1000, Neil Brown wrote:
> > >
> > > > It seems to work (though some of the keys actually generate 'down'
> > > > events for both the down and up transitions, so it seems that the key
> > > > is pressed twice.
> > >
> > > Maybe it really is as you say. But your description sounds fishy.
> > > It would be nice to know what really happens.
> > > (And it would be nice to know which scancodes are involved.)
> >
> > Indeed. Neil, please enable DEBUG in i8042.c ... both with and without the
> > i8042_direct=1 and atkbd_set=3 options from my previous e-mail.
> >
> > And for Andries, if you can, do the showkey -s test on 2.4, too ...
>
> Well...
>
> For my purposes, I need to use an "ioctl" to set a keycode for each
> scancode, so adding an ioctl to set the no-keyup status is no hassle
> for me. However the suggest approach of auto-detecting keys which
> have no up event would probably a good idea.
How about this patch? It tries to be a bit clever, but hopefully not too
much ...
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Monday August 18, [email protected] wrote:
>
> How about this patch? It tries to be a bit clever, but hopefully not too
> much ...
>
Uhmm.. mixed.
It behaved REALLY strangly until I fixed these typoes:
> + mod_timer(&atkbd->timer,
> + (test_bit(atkbd->keycode[code], &atkbd->dev.key)
> + ? HZ/30 : HZ/4) + HZ/100);
should be
> + mod_timer(&atkbd->timer, jiffies +
> + (test_bit(atkbd->keycode[code], atkbd->dev.key)
> + ? HZ/30 : HZ/4) + HZ/100);
Then it sort-of worked - my problem keys gave nice up/down
transitions.
However the hardware autorepeat and the software autorepeat seemed to
interfere with each other and auto-repeat was rather erratic.
More of a problem was that control and shift would auto-repeat, and
would often appear to be "up" when I was holding them "down", so
control-X keys strokes were not reliable.
Thanks,
NeilBrown
On Tue, Aug 19, 2003 at 09:40:24PM +1000, Neil Brown wrote:
> On Monday August 18, [email protected] wrote:
> >
> > How about this patch? It tries to be a bit clever, but hopefully not too
> > much ...
> >
>
> Uhmm.. mixed.
>
> It behaved REALLY strangly until I fixed these typoes:
>
> > + mod_timer(&atkbd->timer,
> > + (test_bit(atkbd->keycode[code], &atkbd->dev.key)
> > + ? HZ/30 : HZ/4) + HZ/100);
>
> should be
>
> > + mod_timer(&atkbd->timer, jiffies +
> > + (test_bit(atkbd->keycode[code], atkbd->dev.key)
> > + ? HZ/30 : HZ/4) + HZ/100);
Thanks for spotting that! I originally had "!test_bit" there, and then
removed the ! and forgot to swap the conditional values.
> Then it sort-of worked - my problem keys gave nice up/down
> transitions.
Good to know. I'll test the rest on my keyboards here.
> However the hardware autorepeat and the software autorepeat seemed to
> interfere with each other and auto-repeat was rather erratic.
Yep, you'll need to make the software autorepeat settings longer.
They're HZ/4 and HZ/33 now, and need to be bigger than the in the above
fixed statement.
> More of a problem was that control and shift would auto-repeat, and
This is normal.
> would often appear to be "up" when I was holding them "down", so
> control-X keys strokes were not reliable.
Hmm, this is bad. I thought the code shouldn't be able to cause this (I
tried to make it so), I'll try to fix it.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Mon, 18 Aug 2003, Andries Brouwer wrote:
> > Well, mode #3 with no translation in the i8042 looks quite sanely.
>
> In theory perhaps. In practice it isnt sane at all.
Yep, the design is clean. And we can handle it for good devices, for its
additional functionality (e.g. autorepeat of <Pause> ;-) ) and to have a
clean reference design of code. I see no reason to "punish" good devices
for the faults of bad ones.
> (That is, the majority of the keyboards sold today do not do as one
> would wish. Since Microsoft does not require anything for Set 3,
> behaviour in Set 3 is essentially random, especially for these
> additional keys and buttons. A single keypress may give several
> scancodes, or none at all. Many laptops do not have any support
Well, we need not take care of non-standard keys -- as such they need to
be handled on a case-by-case basis (with customized key maps). The sort
of standard Win keys seem to have a consistent definition across devices;
at least it was the case with the ones I've encountered.
If standard keys are broken, then we can still revert to mode #2 with all
its limits as we do now. At least we can disable the translation in the
i8042 to get full and unambiguous scan codes.
> for Set 3. USB compatibility only implements compatibility with
> translated Set 2.)
That's actually irrelevant -- it's already an emulation. AFAIK, we can
handle USB keyboards natively just fine, so we don't need to make use of
this translation layer.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Tue, Aug 19, 2003 at 03:04:58PM +0200, Maciej W. Rozycki wrote:
> > > Well, mode #3 with no translation in the i8042 looks quite sanely.
> >
> > In theory perhaps. In practice it isnt sane at all.
>
> Yep, the design is clean. And we can handle it for good devices, for its
> additional functionality (e.g. autorepeat of <Pause> ;-) ) and to have a
> clean reference design of code. I see no reason to "punish" good devices
> for the faults of bad ones.
Your reasoning is backwards.
For the user the only thing that matters is that the keyboard works.
Which codes certain chips send to each other is completely irrelevant.
Everybody uses translated Set 2. It works.
Anything else gives obscure problems.
If we exchange ugly code that fails for one in a million users
for nice code that fails for one in tenthousand users,
that is no progress.
> > (That is, the majority of the keyboards sold today do not do as one
> > would wish. Since Microsoft does not require anything for Set 3,
> > behaviour in Set 3 is essentially random, especially for these
> > additional keys and buttons. A single keypress may give several
> > scancodes, or none at all. Many laptops do not have any support
>
> Well, we need not take care of non-standard keys -- as such they need to
> be handled on a case-by-case basis (with customized key maps).
If the keyboard is in Set 3, then these keys may not give any scancode at all.
In order for the non-standard keys to work we need Set 2.
My laptop has function buttons that bring me to a setup menu where
I can set various timeouts related to power saving. These built-in
menus react to translated scancode Set 2 only. There is no way to get
out if one first chooses Set 3.
Etc. Set 3 is a pain. Nobody wants it, except the people who have read
the spec only and say - look, neat, a single code for a single keystroke.
Reality is very different.
> If standard keys are broken, then we can still revert to mode #2 with all
> its limits as we do now. At least we can disable the translation in the
> i8042 to get full and unambiguous scan codes.
Also disabling translation causes all kinds of obscure troubles.
It is extremely unwise to go for obscure modes that were supported by
most keyboards ten years ago, and may or may not have any support today.
Andries
> Etc. Set 3 is a pain. Nobody wants it, except the people who have read
> the spec only and say - look, neat, a single code for a single keystroke.
> Reality is very different.
I totally agree that in 99.9% of cases, Set 2 is a more sensible
choice than Set 3.
On the other hand, a configuration option to only support Set 3, and
not implement all of the work-arounds would shrink the kernel by a few
K, which would be nice.
Also, the keyboard I'm using requires Set 3 to operate fully, although
as it's quite possible that I am the only person on the planet who
uses this model of keyboard with Linux, that might not be a very valid
argument :-).
John.
On Tuesday August 19, [email protected] wrote:
> > It behaved REALLY strangly until I fixed these typoes:
> >
> > > + mod_timer(&atkbd->timer,
> > > + (test_bit(atkbd->keycode[code], &atkbd->dev.key)
> > > + ? HZ/30 : HZ/4) + HZ/100);
> >
> > should be
> >
> > > + mod_timer(&atkbd->timer, jiffies +
> > > + (test_bit(atkbd->keycode[code], atkbd->dev.key)
> > > + ? HZ/30 : HZ/4) + HZ/100);
>
> Thanks for spotting that! I originally had "!test_bit" there, and then
> removed the ! and forgot to swap the conditional values.
I swapped the "30" and the "4", it is is better still. Auto-repeat of
normal keys is ok (I think - didn't test extensively).
control/shift is still a problem, though not quite as a bad
When I hold right-control down, evtest shows:
Event: time 1061335715.975639, type 1 (Key), code 97 (RightCtrl), value 1
Event: time 1061335715.975639, -------------- Config Sync ------------
Event: time 1061335716.014658, type 1 (Key), code 97 (RightCtrl), value 0
Event: time 1061335716.014659, -------------- Config Sync ------------
Event: time 1061335716.485899, type 1 (Key), code 97 (RightCtrl), value 1
Event: time 1061335716.485899, -------------- Config Sync ------------
Event: time 1061335716.734535, type 1 (Key), code 97 (RightCtrl), value 2
Event: time 1061335716.734536, -------------- Config Sync ------------
Event: time 1061335716.764555, type 1 (Key), code 97 (RightCtrl), value 2
Event: time 1061335716.764556, -------------- Config Sync ------------
so if I type another char between 30ms and 500ms after pressing
control, the control isn't noticed, else it is.
NeilBrown
John Bradford wrote:
> Also, the keyboard I'm using requires Set 3 to operate fully, although
> as it's quite possible that I am the only person on the planet who
> uses this model of keyboard with Linux, that might not be a very valid
> argument :-).
It's unfortunate if there are some keyboards that only work properly
in one mode, and others that need the other mode, given that there is
no way to automatically detect which keyboard is which.
If your keyboard requires Set 3 to operate fully, how does it behave
under Windows? I think it was Andries who said Windows uses translated set 2.
-- Jamie
> > Also, the keyboard I'm using requires Set 3 to operate fully, although
> > as it's quite possible that I am the only person on the planet who
> > uses this model of keyboard with Linux, that might not be a very valid
> > argument :-).
>
> It's unfortunate if there are some keyboards that only work properly
> in one mode, and others that need the other mode, given that there is
> no way to automatically detect which keyboard is which.
It does work in Set 2, but the Japanese keys generate the same
scancode as the space bar. Those keys are only generate unique
scancodes in Set 3. Most Japanese keyboards do work fully in Set 2,
this one is an exception.
John.
John Bradford wrote:
> > > Also, the keyboard I'm using requires Set 3 to operate fully, although
> > > as it's quite possible that I am the only person on the planet who
> > > uses this model of keyboard with Linux, that might not be a very valid
> > > argument :-).
> >
> > It's unfortunate if there are some keyboards that only work properly
> > in one mode, and others that need the other mode, given that there is
> > no way to automatically detect which keyboard is which.
>
> It does work in Set 2, but the Japanese keys generate the same
> scancode as the space bar. Those keys are only generate unique
> scancodes in Set 3. Most Japanese keyboards do work fully in Set 2,
> this one is an exception.
So do the Japanese keys fail to work in Windows, too, without a
special driver?
-Jamie
On Sat, Aug 16, 2003 at 05:57:41PM +1000, Neil Brown wrote:
> There are 5 keys in question. Each one is fn + something else.
> Some of them (wireless, brighter, darker) cause the bios to do
> something, and only generate a keyboard event on a down transition.
> The others (battery, cdeject) don't appear to cause the bios to do
> anything, and generate a keyboard event on both the up and down
> transition, and it is always the same scancode.
>
> Key Meaning 2.6 scancode 2.4 (direct) scancode
> fn-F2 wireless 0x13d e0 08
> fn-F3 battery 0x136 e0 07
> fn-F10 cdeject 0x13e e0 09
> fn-down darker 0x125 e0 05
> fn-up brighter 0x12e e0 06
Thanks - added to the data base.
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html#ss1.12
> For my purposes, I need to use an "ioctl" to set a keycode for each
> scancode, so adding an ioctl to set the no-keyup status is no hassle
> for me. However the suggest approach of auto-detecting keys which
> have no up event would probably a good idea.
I would be unhappy.
We need a solid keyboard driver that actually works.
Not some fragile construction that has tricks built-in
so as to make things work for every kernel developer.
How many non-kernel-developers are there?
How many strange keyboards?
Andries
Andries Brouwer wrote:
> > For my purposes, I need to use an "ioctl" to set a keycode for each
> > scancode, so adding an ioctl to set the no-keyup status is no hassle
> > for me. However the suggest approach of auto-detecting keys which
> > have no up event would probably a good idea.
>
> I would be unhappy.
> We need a solid keyboard driver that actually works.
> Not some fragile construction that has tricks built-in
> so as to make things work for every kernel developer.
Synthesising an UP event after receiving a DOWN from the keyboard, and
nothing else for that key for > (repeat delay + a bit more) time looks
like a good plan to me, UNLESS there are keys which do report UP when
the key is released (as opposed to immediately after the DOWN), and
also don't repeat.
Unrelated: I have some messages from my laptop, Toshiba Satellite 4070CDT:
atkbd.c: Unknown key (set 2, scancode 0x94, in isa0060/serio0) pressed.
atkbd.c: Unknown key (set 2, scancode 0xbf, in isa0060/serio0) pressed.
atkbd.c: Unknown key (set 2, scancode 0xa1, in isa0060/serio0) pressed.
Enjoy,
-- Jamie
On Wed, Aug 20, 2003 at 11:58:12PM +0100, Jamie Lokier wrote:
> Synthesising an UP event after receiving a DOWN from the keyboard, and
> nothing else for that key for > (repeat delay + a bit more) time looks
> like a good plan to me, UNLESS there are keys which do report UP when
> the key is released (as opposed to immediately after the DOWN), and
> also don't repeat.
And there are keyboards with such keys.
> Unrelated: I have some messages from my laptop, Toshiba Satellite 4070CDT:
>
> atkbd.c: Unknown key (set 2, scancode 0x94, in isa0060/serio0) pressed.
> atkbd.c: Unknown key (set 2, scancode 0xbf, in isa0060/serio0) pressed.
> atkbd.c: Unknown key (set 2, scancode 0xa1, in isa0060/serio0) pressed.
Do you know what keystrokes cause this?
It looks like this cannot come from i8042_unxlate_table[].
Do you set i8042_direct?
Vojtech, this sounds like a bug in i8042.c:
We do
if (data > 0x7f) {
index = (data & 0x7f);
if (test_and_clear_bit(index, i8042_unxlate_seen)) {
data = i8042_unxlate_table[data & 0x7f];
}
} else {
data = i8042_unxlate_table[data];
}
serio_interrupt(&i8042_kbd_port, data, dfl, regs);
In other words, the keyboard sends something in translated Set 2,
but we fake that it is untranslated, unless it was
a key release and we didnt know that the key was down.
Thus, atkbd.c gets a mixture of untranslated and translated codes.
Andries
Andries Brouwer wrote:
> > Synthesising an UP event after receiving a DOWN from the keyboard, and
> > nothing else for that key for > (repeat delay + a bit more) time looks
> > like a good plan to me, UNLESS there are keys which do report UP when
> > the key is released (as opposed to immediately after the DOWN), and
> > also don't repeat.
>
> And there are keyboards with such keys.
Alas.
For programs which are only interested in key presses, there is no
problem including a synthesised UP event.
But for programs which want to monitor a key and know its state
continuously (this presently includes the software autorepeater, but
it also includes games), none of the behaviours is right.
So the decision must be: shall we do the wrong thing for keyboards
which report DOWN only (the key will appear stuck to some programs),
or shall we do the wrong thing for keyboards which report DOWN, no
repeat and then UP, by making it look like the key was released early?
-- Jamie
On Thu, Aug 21, 2003 at 01:03:02AM +0100, Jamie Lokier wrote:
> So the decision must be: shall we do the wrong thing for keyboards
> which report DOWN only (the key will appear stuck to some programs),
> or shall we do the wrong thing for keyboards which report DOWN, no
> repeat and then UP, by making it look like the key was released early?
There are many more problems with your synthesized events.
Look at your "repeat delay + a bit more". Can you specify how much
"a bit more" is?
In times of heavy disk activity we lose interrupts.
Indeed, if I copy a CD image or untar a kernel tree
my keyboard and mouse are dead for several seconds.
There is no guaranteed "a bit more" within which we will see a
keyboard event.
If the only events that are seen are actual events, and on rare
occasions we miss an event, that is not so bad. We just hit that
key again. But if we synthesize events, then a missed key up
causes autorepeat.
In fact I see unwanted autorepeat - maybe once a day suddenly
a single keystroke causes three to five identical characters to
appear - but I am not sure what mechanism causes this.
Andries
Andries Brouwer wrote:
> There are many more problems with your synthesized events.
> Look at your "repeat delay + a bit more". Can you specify how much
> "a bit more" is?
>
> In times of heavy disk activity we lose interrupts.
> Indeed, if I copy a CD image or untar a kernel tree
> my keyboard and mouse are dead for several seconds.
>
> There is no guaranteed "a bit more" within which we will see a
> keyboard event.
I think we can safely arrange that if the timer expires, we can be
sure to check the 8042 for an event before synthesising one.
> If the only events that are seen are actual events, and on rare
> occasions we miss an event, that is not so bad. We just hit that
> key again. But if we synthesize events, then a missed key up
> causes autorepeat.
You've mixed the question synthetic UP with software autorepeat. They
are unrelated, and othogonal.
If you use software autorepeat, you have that problem of runaway
events _anyway_, nothing to do with UP. And if you don't use software
autorepeat, UP doesn't create a problem.
In fact, the synthetic UP is quite helpful if you miss real events.
For programs which, say, grab the keyboard focus until the user lets
go of a particular key, it is good that the program is eventually sent
an UP. Otherwise it won't give up the focus at all. Similarly, in a
game which does something as long as the player holds a key down,
missing the real event results in the game assuming the key is
perpetually held down.
> In fact I see unwanted autorepeat - maybe once a day
> suddenly a single keystroke causes three to five identical
characters to appear - but I am not sure what mechanism causes this.
Faulty laptop keyboards. I get it too, with 2.4 and 2.5 kernels.
It's not autorepeat, it's an instant burst of events.
Possibly bad debouncing.
-- Jamie
On Thu, Aug 21, 2003 at 01:03:02AM +0100, Jamie Lokier wrote:
> Andries Brouwer wrote:
> > > Synthesising an UP event after receiving a DOWN from the keyboard, and
> > > nothing else for that key for > (repeat delay + a bit more) time looks
> > > like a good plan to me, UNLESS there are keys which do report UP when
> > > the key is released (as opposed to immediately after the DOWN), and
> > > also don't repeat.
> >
> > And there are keyboards with such keys.
>
> Alas.
>
> For programs which are only interested in key presses, there is no
> problem including a synthesised UP event.
>
> But for programs which want to monitor a key and know its state
> continuously (this presently includes the software autorepeater, but
> it also includes games), none of the behaviours is right.
>
> So the decision must be: shall we do the wrong thing for keyboards
> which report DOWN only (the key will appear stuck to some programs),
> or shall we do the wrong thing for keyboards which report DOWN, no
> repeat and then UP, by making it look like the key was released early?
I vote for the synthetised event and possibly making it disableable.
It's a much bigger annoyance if your key stays stuck than if it goes up
even when you're holding it. And remember that the keys affected will
probably be special function keys only.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Thu, Aug 21, 2003 at 02:33:45AM +0200, Andries Brouwer wrote:
> > So the decision must be: shall we do the wrong thing for keyboards
> > which report DOWN only (the key will appear stuck to some programs),
> > or shall we do the wrong thing for keyboards which report DOWN, no
> > repeat and then UP, by making it look like the key was released early?
>
> There are many more problems with your synthesized events.
> Look at your "repeat delay + a bit more". Can you specify how much
> "a bit more" is?
>
> In times of heavy disk activity we lose interrupts.
> Indeed, if I copy a CD image or untar a kernel tree
> my keyboard and mouse are dead for several seconds.
This needs to be fixed. ;)
> There is no guaranteed "a bit more" within which we will see a
> keyboard event.
Worst case we instead of autorepeat will generate a complete keypress
and key release, not too bad, you won't even notice when your system has
a second long response time.
> If the only events that are seen are actual events, and on rare
> occasions we miss an event, that is not so bad. We just hit that
> key again. But if we synthesize events, then a missed key up
> causes autorepeat.
>
> In fact I see unwanted autorepeat - maybe once a day suddenly
> a single keystroke causes three to five identical characters to
> appear - but I am not sure what mechanism causes this.
If you can find this, I'd be really grateful - some people see that, and
I don't and I can't find any problem in the code.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Thu, Aug 21, 2003 at 01:52:58AM +0200, Andries Brouwer wrote:
> > Synthesising an UP event after receiving a DOWN from the keyboard, and
> > nothing else for that key for > (repeat delay + a bit more) time looks
> > like a good plan to me, UNLESS there are keys which do report UP when
> > the key is released (as opposed to immediately after the DOWN), and
> > also don't repeat.
>
> And there are keyboards with such keys.
Are there? Nevertheless the synthetic UP probably wouldn't hurt much,
because it will only happen some 270 ms after the press at which time
the user did probably already release the key, and if he did not, we
just ignore the real release event.
I have that logic running on my computer and so far it doesn't cause any
trouble.
> > Unrelated: I have some messages from my laptop, Toshiba Satellite 4070CDT:
> >
> > atkbd.c: Unknown key (set 2, scancode 0x94, in isa0060/serio0) pressed.
> > atkbd.c: Unknown key (set 2, scancode 0xbf, in isa0060/serio0) pressed.
> > atkbd.c: Unknown key (set 2, scancode 0xa1, in isa0060/serio0) pressed.
>
> Do you know what keystrokes cause this?
>
> It looks like this cannot come from i8042_unxlate_table[].
> Do you set i8042_direct?
>
> Vojtech, this sounds like a bug in i8042.c:
> We do
> if (data > 0x7f) {
> index = (data & 0x7f);
> if (test_and_clear_bit(index, i8042_unxlate_seen)) {
> data = i8042_unxlate_table[data & 0x7f];
> }
> } else {
> data = i8042_unxlate_table[data];
> }
> serio_interrupt(&i8042_kbd_port, data, dfl, regs);
>
> In other words, the keyboard sends something in translated Set 2,
> but we fake that it is untranslated, unless it was
> a key release and we didnt know that the key was down.
> Thus, atkbd.c gets a mixture of untranslated and translated codes.
It's not perfect, but it's the best what we can do if we don't want to
move translated mode support to atkbd, which I definitely don't.
The problem is that only data below 0x7f is translated, by a mostly 1:1
table (there are two exceptions, 0x83 and 0x84). Data above 0x80
inclusive is not translated.
So, if you get a 0x9f code, you need to decide whether it really was
0x9f coming from the wire, or if it was actually 0xf0 0x27 coming from
the wire.
The code has a slight problem with multiple key releases for a single
key without a press event inbetween (which is what the toshiba does, and
I've got another keyboard which does it, too). I already have a fix for
that.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Tue, 19 Aug 2003, Andries Brouwer wrote:
> > Yep, the design is clean. And we can handle it for good devices, for its
> > additional functionality (e.g. autorepeat of <Pause> ;-) ) and to have a
> > clean reference design of code. I see no reason to "punish" good devices
> > for the faults of bad ones.
>
> Your reasoning is backwards.
> For the user the only thing that matters is that the keyboard works.
> Which codes certain chips send to each other is completely irrelevant.
The codes might not matter much to a user. But mode #3 gives additional
control over the keyboard which can be made user-visible.
> Everybody uses translated Set 2. It works.
> Anything else gives obscure problems.
It mostly works, indeed. With all its limitations.
> If we exchange ugly code that fails for one in a million users
> for nice code that fails for one in tenthousand users,
> that is no progress.
I see no reason to force that 99 people per million to use anything
beyond they had so far. But why have the remaining 999900 people got to
suffer?
Fortunately we already have an option to force one set or another.
> > Well, we need not take care of non-standard keys -- as such they need to
> > be handled on a case-by-case basis (with customized key maps).
>
> If the keyboard is in Set 3, then these keys may not give any scancode at all.
> In order for the non-standard keys to work we need Set 2.
Interesting...
> My laptop has function buttons that bring me to a setup menu where
> I can set various timeouts related to power saving. These built-in
> menus react to translated scancode Set 2 only. There is no way to get
> out if one first chooses Set 3.
Well, that's a design error. Can you do that when running Linux? I
suppose so. That means the SMM is involved with its all obscurities. The
design error is it should be under the control of the OS.
> Etc. Set 3 is a pain. Nobody wants it, except the people who have read
> the spec only and say - look, neat, a single code for a single keystroke.
Plus the symmetry of keys -- no more strange behaviour of "special" keys.
That's more important -- all keys behave the same way and they do not
magically depend on modifiers.
> Reality is very different.
Actually the spec is a standard and standard hardware performs as
expected (e.g. hardware released by IBM). The rest is non-standard and if
a manufacturer claims PS/2-compliance for any of these items, then he
lies.
> > If standard keys are broken, then we can still revert to mode #2 with all
> > its limits as we do now. At least we can disable the translation in the
> > i8042 to get full and unambiguous scan codes.
>
> Also disabling translation causes all kinds of obscure troubles.
> It is extremely unwise to go for obscure modes that were supported by
> most keyboards ten years ago, and may or may not have any support today.
Note the translation is done outside the keyboard -- the onboard 8042
controller is responsible for it. And it's an obstacle for normal
operation, most notably you cannot handle hot-plug events as they are
undistinguishable from a <Shift> release.
To summarize -- I do not want anyone to suffer unnecessarily because of
having bad hardware (i.e. beyond what's directly caused by the limitations
of such hardware). But those who have good hardware should be able to
make good use of it. And I prefer the defaults to assume good hardware --
for bad hardware a command line option may override the defaults. This
way bad hardware becomes visible -- right now a user cannot easily
distinguish between a good keyboard and a broken one, so he has no obvious
choice and also there is no incentive for manufacturers to fix broken
devices for those who care (I wouldn't mind a statement on a keyboard box
e.g.: "Windows-compliant" or "PS/2-compliant" or both, so that I know what
to choose).
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Thu, 21 Aug 2003, Jamie Lokier wrote:
> But for programs which want to monitor a key and know its state
> continuously (this presently includes the software autorepeater, but
> it also includes games), none of the behaviours is right.
X11 is another example of software that wants to know the state of keys
continuously. And that's not a piece of software to ignore easily.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
> Note the translation is done outside the keyboard -- the onboard 8042
> controller is responsible for it.
How do we currently handle devices connected via bit-banging on the
parallel port,(as we have no onboard 8042 in that case)?
John
On Thu, Aug 21, 2003 at 01:11:53PM +0100, John Bradford wrote:
> > Note the translation is done outside the keyboard -- the onboard 8042
> > controller is responsible for it.
>
> How do we currently handle devices connected via bit-banging on the
> parallel port,(as we have no onboard 8042 in that case)?
You write a 'serio' driver for those keyboards - a driver which will do
the bit-banging on the parallel port and send bytes from and to the
device. See the parkbd.c module for that.
The keyboard/mouse driver always sees the bytes that are on the wire,
regardless whether there is an 8042 inbetween - in that case the 8042
driver tries to undo the damage caused by translation.
This way we can have a single atkbd.c driver for any at-style keyboard
attached over whatever interface is in the machine.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Thu, Aug 21, 2003 at 01:37:34PM +0200, Maciej W. Rozycki wrote:
> > Etc. Set 3 is a pain. Nobody wants it, except the people who have read
> > the spec only and say - look, neat, a single code for a single keystroke.
>
> Plus the symmetry of keys -- no more strange behaviour of "special" keys.
On my BTC keyboard, the macro key produces e0 6f in Set 3, yes, two scancodes.
On my Safeway keyboard, the multimedia keys do not produce any scancode
at all in Set 3. The same holds for my Compaq Easy Access Keyboard.
The correspondence between Set 2 codes and Set 3 codes varies from
keyboard to keyboard.
Things are not pretty in reality.
Only on paper, and only if you disregard all "new" keys.
On Thu, 21 Aug 2003, Andries Brouwer wrote:
> > X11 is another example of software that wants to know the state of keys
> > continuously. And that's not a piece of software to ignore easily.
>
> You are both inventing the situation that games, or X11, ask the kernel
> for a bitmap of pressed keys. But they don't. The mechanism doesn't
> even exist.
I don't know of any games, but X11 doesn't work that way. What I mean
X11 needs to know what keys are currently pressed and which are not. It
handles that itself by tracking key presses and releases for all keys, so
both kinds of events need to be reported properly. OTOH, the console
doesn't really care about key releases except from modifier keys.
I'm sorry if my statement was ambiguous.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
Andries Brouwer wrote:
> > > But for programs which want to monitor a key and know its state
> > > continuously (this presently includes the software autorepeater, but
> > > it also includes games), none of the behaviours is right.
> >
> > X11 is another example of software that wants to know the state of keys
> > continuously. And that's not a piece of software to ignore easily.
>
> You are both inventing the situation that games, or X11, ask the kernel
> for a bitmap of pressed keys. But they don't. The mechanism doesn't
> even exist.
I have no idea what X wants. What non-X "action" games want is simple
(I have written a few): to know when the user is pushing particular keys.
Those games achieve this by observing a DOWN event when a key is
pressed, an UP when it is released, to change their knowledge of a key
state, and ignoring events which don't change their knowledge of the
state: auto-repeat DOWN events or spurious UP events.
-- Jamie
Maciej W. Rozycki wrote:
> > My laptop has function buttons that bring me to a setup menu where
> > I can set various timeouts related to power saving. These built-in
> > menus react to translated scancode Set 2 only. There is no way to get
> > out if one first chooses Set 3.
Perhaps the BIOS is listening for translated set 2 scancodes. Maybe some
different keys would have the power saving functions in other modes?
> Actually the spec is a standard and standard hardware performs as
> expected (e.g. hardware released by IBM). The rest is non-standard and if
> a manufacturer claims PS/2-compliance for any of these items, then he
> lies.
The user doesn't care if it's PS/2 compliant or not. It must work,
that is the only important thing. Even more so, given it is flawless
> Note the translation is done outside the keyboard -- the onboard 8042
> controller is responsible for it. And it's an obstacle for normal
> operation, most notably you cannot handle hot-plug events as they are
> undistinguishable from a <Shift> release.
Perhaps you can detect a keyboard being unplugged by periodically
sending it Echo commands (EE), or any other command to which it responds.
-- Jamie
On Thu, Aug 21, 2003 at 01:40:33PM +0200, Maciej W. Rozycki wrote:
> On Thu, 21 Aug 2003, Jamie Lokier wrote:
>
> > But for programs which want to monitor a key and know its state
> > continuously (this presently includes the software autorepeater, but
> > it also includes games), none of the behaviours is right.
>
> X11 is another example of software that wants to know the state of keys
> continuously. And that's not a piece of software to ignore easily.
You are both inventing the situation that games, or X11, ask the kernel
for a bitmap of pressed keys. But they don't. The mechanism doesn't
even exist.
On Thu, 21 Aug 2003, Andries Brouwer wrote:
> > > Etc. Set 3 is a pain. Nobody wants it, except the people who have read
> > > the spec only and say - look, neat, a single code for a single keystroke.
> >
> > Plus the symmetry of keys -- no more strange behaviour of "special" keys.
>
> On my BTC keyboard, the macro key produces e0 6f in Set 3, yes, two scancodes.
> On my Safeway keyboard, the multimedia keys do not produce any scancode
> at all in Set 3. The same holds for my Compaq Easy Access Keyboard.
So if you need these keys, then just use what works for you. Thanks for
mentioning these -- I'll know what to avoid.
BTW, for completeness, have you tried set #1?
> The correspondence between Set 2 codes and Set 3 codes varies from
> keyboard to keyboard.
> Things are not pretty in reality.
> Only on paper, and only if you disregard all "new" keys.
There are good devices out there (mine inclusive :-) ) that comply to
what papers require and I see no reason not to handle them fully.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Thu, 21 Aug 2003, Jamie Lokier wrote:
> The user doesn't care if it's PS/2 compliant or not. It must work,
> that is the only important thing. Even more so, given it is flawless
Yep, but "work" is ambiguous. What one considers working, someone else
may consider insufficient. That's why there are various quality goods out
there -- someone might want to sacrifice quality to get a low price and
someone else might want to get best quality he can afford.
> Perhaps you can detect a keyboard being unplugged by periodically
> sending it Echo commands (EE), or any other command to which it responds.
Due to communication latencies and the system load it would be
unreasonable to send an echo request more often than once, perhaps twice
per second. And it's quite easy to unplug and then plug a keyboard back
in a shorter time.
Disabling the translation in the onboard 8042 solves the problem and I am
quite surprised there are problems with that. After all a pass-through
mode is easier to implement than a cooked one -- it's essentially a no-op.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Thu, Aug 21, 2003 at 04:08:30PM +0200, Maciej W. Rozycki wrote:
> Disabling the translation in the onboard 8042 solves the problem and I am
> quite surprised there are problems with that. After all a pass-through
> mode is easier to implement than a cooked one -- it's essentially a no-op.
Yes, but on a notebook, you often don't have a microcontroler in the
keyboard itself, and there is no wire over which the untranslated set2
scancodes would be passed. The i8042 directly scans the keyboard matrix.
Then it's easy to forget about the set3 scancode set ...
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Thu, Aug 21, 2003 at 03:45:15PM +0200, Maciej W. Rozycki wrote:
> So if you need these keys, then just use what works for you.
I am not sure what you are discussing.
But I am talking about the Linux keyboard driver.
It must not touch Set 3, or lots of people will have problems.
Only when the user explicitly asks for Set 3 is it reasonable
to switch to it.
On Thu, 21 Aug 2003, Vojtech Pavlik wrote:
> Yes, but on a notebook, you often don't have a microcontroler in the
> keyboard itself, and there is no wire over which the untranslated set2
> scancodes would be passed. The i8042 directly scans the keyboard matrix.
> Then it's easy to forget about the set3 scancode set ...
Hmm, that would make some sense, but how does it work when an external
keyboard is attached?
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Thu, 21 Aug 2003, Andries Brouwer wrote:
> Only when the user explicitly asks for Set 3 is it reasonable
> to switch to it.
I have expressed my preference, but it's not strong enough for me not to
accept your one. As long as I can select untranslated mode #3 somehow, I
can live with that.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Thu, Aug 21, 2003 at 04:33:04PM +0200, Maciej W. Rozycki wrote:
> Hmm, that would make some sense, but how does it work when an external
> keyboard is attached?
Usually the keyboard and mouse commands are sent to all attached
keyboards resp. mice. Thus, with an internal keyboard that only
knows about Set 2 and an external keyboard that also knows about
Set 3 you can change the kbds to Set 3. Now the internal one is
dead, but the external one functions.
On Thu, 21 Aug 2003, Andries Brouwer wrote:
> > Hmm, that would make some sense, but how does it work when an external
> > keyboard is attached?
>
> Usually the keyboard and mouse commands are sent to all attached
> keyboards resp. mice. Thus, with an internal keyboard that only
> knows about Set 2 and an external keyboard that also knows about
> Set 3 you can change the kbds to Set 3. Now the internal one is
> dead, but the external one functions.
I meant: how does the translation work if there is only a single onboard
controller that does scanning of the embedded keyboard and presents set #1
of codes directly? But after a bit of thinking I suppose it does support
translation for an external keyboard (which presents set #2 by default and
a lot of PC software expects set #1) and probably a pass-through mode for
it as well.
What the big fault of all these limited implementations is, there is no
reliable way to query what is supported. If a device does not support
mode switching or a particular mode, it should NAK a command that does it,
or at least report the original mode if queried afterwards. Another
possibility is to return a different device ID -- IBM chose a single value
of 256 possible for its PS/2 keyboards -- why couldn't the incompatible
others have chosen something different, sigh?...
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Thu, Aug 21, 2003 at 05:03:33PM +0200, Maciej W. Rozycki wrote:
> I meant: how does the translation work if there is only a single onboard
> controller that does scanning of the embedded keyboard and presents set #1
> of codes directly? But after a bit of thinking I suppose it does support
> translation for an external keyboard (which presents set #2 by default and
> a lot of PC software expects set #1) and probably a pass-through mode for
> it as well.
>
> What the big fault of all these limited implementations is, there is no
> reliable way to query what is supported. If a device does not support
> mode switching or a particular mode, it should NAK a command that does it,
> or at least report the original mode if queried afterwards.
Most do, most do ...
> Another
> possibility is to return a different device ID -- IBM chose a single value
> of 256 possible for its PS/2 keyboards -- why couldn't the incompatible
> others have chosen something different, sigh?...
Some do ...
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Thu, Aug 21, 2003 at 10:01:45AM +0200, Vojtech Pavlik wrote:
> > > UNLESS there are keys which do report UP when the key
> > > is released (as opposed to immediately after the DOWN),
> > > and also don't repeat.
> >
> > And there are keyboards with such keys.
>
> Are there?
I owe you an example. See, for example,
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-5.html#ss5.29
Abbreviated version:
Serge van den Boom reports that his LiteOn MediaTouch Keyboard has 18
additional keys: Suspend, Coffee, WWW, Calculator, Xfer, Switch window,
Close, |<<, >|, [], >>|, Record, Rewind, Menu, Eject, Mute, Volume +,
and Volume -. Of these, the keys |<<, >>|, Volume +, Volume - repeat.
The others do not, except for the rather special Switch window key.
Upon press it produces the LAlt-down, LShift-down, Tab-down, Tab-up sequence;
it repeats Tab-down; and upon release it produces the sequence Tab-up,
LAlt-up, LShift-up.
(Up events are as usual for the other 17 keys.)
On Fri, Aug 22, 2003 at 02:27:09AM +0200, Andries Brouwer wrote:
> On Thu, Aug 21, 2003 at 10:01:45AM +0200, Vojtech Pavlik wrote:
>
> > > > UNLESS there are keys which do report UP when the key
> > > > is released (as opposed to immediately after the DOWN),
> > > > and also don't repeat.
> > >
> > > And there are keyboards with such keys.
> >
> > Are there?
>
> I owe you an example. See, for example,
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-5.html#ss5.29
Thanks.
> Abbreviated version:
> Serge van den Boom reports that his LiteOn MediaTouch Keyboard has 18
> additional keys: Suspend, Coffee, WWW, Calculator, Xfer, Switch window,
> Close, |<<, >|, [], >>|, Record, Rewind, Menu, Eject, Mute, Volume +,
> and Volume -. Of these, the keys |<<, >>|, Volume +, Volume - repeat.
> The others do not, except for the rather special Switch window key.
> Upon press it produces the LAlt-down, LShift-down, Tab-down, Tab-up sequence;
> it repeats Tab-down; and upon release it produces the sequence Tab-up,
> LAlt-up, LShift-up.
> (Up events are as usual for the other 17 keys.)
The code as is now (with the autorepeat and the forced up if the
keyboard itself doesn't start repeating) won't have any problems with
this keyboard.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, 22 Aug 2003, Andries Brouwer wrote:
> The others do not, except for the rather special Switch window key.
> Upon press it produces the LAlt-down, LShift-down, Tab-down, Tab-up sequence;
> it repeats Tab-down; and upon release it produces the sequence Tab-up,
> LAlt-up, LShift-up.
What an interesting "design" of hardware trying to fit some version of
software. Do you know if the key behaves consitently if either or both
<LAlt> and <LShift> are already depressed? And do cursor/editor keys work
properly while <Switch_window> is depressed? Can I unambiguosly map the
sequence the key generates e.g. to a "Multi_key" keysym? :->
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
Although I cannot keep up with the list, I saw this.
"Jamie Lokier" <[email protected]> asked John Bradford:
> So do the Japanese keys fail to work in Windows, too, without a
> special driver?
I cannot answer for John Bradford's particularly odd keyboard, but can
answer for ordinary Japanese PS/2 and Japanese USB keyboards.
If a Monopolysoft Windows system is running with a US-101 keyboard driver,
then in principle the Japanese keys produce no input, they are ignored, they
are no-ops. The US-101 driver can be combined with the US layout driver to
match an actual US keyboard, or combined with a German layout driver to
match an actual German keyboard, etc. If the US layout driver is used but
the keyboard is actually Japanese then the hankaku/zenkaku key produces
input of ` and ~ or something like that, because the US keyboard has that
key in that place. If the German layout driver is used but the keyboard is
actually Japanese then I don't know if something similar might happen.
For non-Japanese versions of Windows 95 or 98 or NT4, there are hacks, not
supported by Microsoft, to combine the US-101 driver with the Japanese
layout driver copied from the corresponding Japanese version of Windows 95
or 98 or NT4. In these cases the Japanese keys might or might not produce
input, depending on other random software and settings.
For Japanese versions of Windows 95 or 98 or NT4, of course the Japanese
keys do produce input. Of course the Japanese layout driver is involved. I
don't recall if the lower-level keyboard driver has a name that
distinguishes it from the US-101 driver, but the binaries are almost
certainly different.
For Windows 2000 and XP, essentially the same drivers are available in both
Japanese and non-Japanese versions of the OS, though Japanese Windows 2000
includes some extra compounding of hacks to work around one particular
installation-time bug instead of fixing the installation-time bug. Anyway,
the Japanese-106 keyboard driver is a competitor of the US-101 keyboard
driver. If the US-101 keyboard driver is installed then the Japanese layout
driver doesn't work even if it's selected, except in the case of the
compounded hack just mentioned. If the Japanese-106 keyboard driver is
installed then I think it's possible to install either the US-101 layout
driver or Japanese-106 layout driver. When the Japanese-106 layout driver
is running, of course the Japanese keys produce input. When the US-101
layout driver is running, the Japanese keys are no-ops, except that the
hankaku/zenkaku key produces ` and ~ for same reason as earlier.
If a USB keyboard is used with an OS that has USB drivers (i.e. not NT4 or
early 95) then I think the OS is smart enough to figure out the actual
layout of the keyboard, at least sometimes. Then the Japanese keys might
produce input even when the user expected them to be no-ops. But if the
Japanese IME isn't running then I think the input will still turn into
no-ops, just a bit later in the chain of events than they would otherwise.
If you consider the Japanese-106 driver to be more special than the US-101
driver, then the answer to your question is usually yes, but you need an
attitude adjustment :-) If the US-101 driver can be hacked to work with a
larger number of national or linguistic layouts than the Japanese-106 driver
can, then the US-101 driver is the one that's special :-)
Norman Diamond wrote:
> For Japanese versions of Windows 95 or 98 or NT4, of course the Japanese
> keys do produce input. Of course the Japanese layout driver is involved. I
> don't recall if the lower-level keyboard driver has a name that
> distinguishes it from the US-101 driver, but the binaries are almost
> certainly different.
Do you know what the Japanese keys do under Linux?
Thanks,
-- Jamie
> > Serge van den Boom reports that his LiteOn MediaTouch Keyboard
> > has 18 additional keys: Suspend, Coffee, WWW, Calculator, Xfer,
> > Switch window, Close, |<<, >|, [], >>|, Record, Rewind, Menu,
> > Eject, Mute, Volume +, and Volume -. Of these, the keys |<<,
> > >>|, Volume +, Volume - repeat. The others do not, except for
> > the rather special Switch window key. Upon press it produces
> > the LAlt-down, LShift-down, Tab-down, Tab-up sequence; it
> > repeats Tab-down; and upon release it produces the sequence
> > Tab-up, LAlt-up, LShift-up.
> > (Up events are as usual for the other 17 keys.)
Vojtech Pavlik wrote:
> The code as is now (with the autorepeat and the forced up if the
> keyboard itself doesn't start repeating) won't have any problems with
> this keyboard.
That works well for typing, but if someone tries to use these keys in
an action game, they will disappointed with the forced-up code - the
game will see the key pressed and released, even when the user holds
the key down for a long time.
Unfortunately, not doing the forced-up thing causes much worse
problems, with the keys which started this thread.
There is only one solution which works well that I can see: do the
forced-up thing by default, but as soon as you see a real UP event
from a key, disabled forced-up _for that key_ in future.
That gives perfect results for typing, and after the first press of a
key it is perfect for games too.
-- Jamie
>
> --
> Vojtech Pavlik
> SuSE Labs, SuSE CR
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, Aug 25, 2003 at 05:22:35AM +0100, Jamie Lokier wrote:
> > > Serge van den Boom reports that his LiteOn MediaTouch Keyboard
> > > has 18 additional keys: Suspend, Coffee, WWW, Calculator, Xfer,
> > > Switch window, Close, |<<, >|, [], >>|, Record, Rewind, Menu,
> > > Eject, Mute, Volume +, and Volume -. Of these, the keys |<<,
> > > >>|, Volume +, Volume - repeat. The others do not, except for
> > > the rather special Switch window key. Upon press it produces
> > > the LAlt-down, LShift-down, Tab-down, Tab-up sequence; it
> > > repeats Tab-down; and upon release it produces the sequence
> > > Tab-up, LAlt-up, LShift-up.
> > > (Up events are as usual for the other 17 keys.)
>
> Vojtech Pavlik wrote:
> > The code as is now (with the autorepeat and the forced up if the
> > keyboard itself doesn't start repeating) won't have any problems with
> > this keyboard.
>
> That works well for typing, but if someone tries to use these keys in
> an action game, they will disappointed with the forced-up code - the
> game will see the key pressed and released, even when the user holds
> the key down for a long time.
Indeed. Are you expecting a game to be able to use the WWW or Calculator
keys for anything useful?
> Unfortunately, not doing the forced-up thing causes much worse
> problems, with the keys which started this thread.
>
> There is only one solution which works well that I can see: do the
> forced-up thing by default, but as soon as you see a real UP event
> from a key, disabled forced-up _for that key_ in future.
Won't work. There are keyboards that forget to send a key up event
sometimes. They usually send it, but from time to time they don't.
We need to cover these keyboards, too. It's actually the main reason for
the whole forced up thingy.
> That gives perfect results for typing, and after the first press of a
> key it is perfect for games too.
I'll give you a kernel/module option to disable the forced up effect if
you have a perfect keyboard. You can then also enable the untranslated
mode and set 3. But the default will be translated set 2 with forced
keyups if a key is not repeating.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
> > > > Serge van den Boom reports that his LiteOn MediaTouch Keyboard
> > > > has 18 additional keys: Suspend, Coffee, WWW, Calculator, Xfer,
^^^^^^
What does that do?
> I'll give you a kernel/module option to disable the forced up effect if
> you have a perfect keyboard. You can then also enable the untranslated
> mode and set 3. But the default will be translated set 2 with forced
> keyups if a key is not repeating.
Exactly - code to accomodate any PS/2 keyboard that doesn't do
untranslated set 3 is a workaround, in my opinion. People with
perfect keyboards should be able to benefit from the simplicity they
allow. Obviously 'set 2 + workarounds' needs to be the default,
because of the hardware in existance, but there is still an advantage
to using set 3 where possible.
John.
"Jamie Lokier" <[email protected]> replied to me:
> > For Japanese versions of Windows 95 or 98 or NT4, of course the Japanese
> > keys do produce input. Of course the Japanese layout driver is
> > involved. I don't recall if the lower-level keyboard driver has a name
> > that distinguishes it from the US-101 driver, but the binaries are
> > almost certainly different.
[And for Japanese versions of Windows 2000 and Windows XP, of course the
Japanese keys do produce input. Of course the Japanese layout driver is
involved, but also the lower-level driver is named for the Japanese-106
keyboard.]
> Do you know what the Japanese keys do under Linux?
I don't recall them doing anything under Linux. I think I've read some
people say that the Japanese keys yield spaces for them, which would not be
too bad because three of those keys are next to the space bar anyway. But I
think I get no input at all for them, which also isn't too bad (mostly --
but see below).
Of course the problem which is too bad is getting no input for the keys
yen-sign or-bar and backslash underscore.
In 2.4, after the USB-to-emulated-PS/2 translation level in the driver was
finally patched, I think that all of the Japanese keys were finally patched
to yield the same as the PS/2 translations of the USB keys. The patch was
different from the one which I sent which was ignored, for which the
difference is OK (the effect is the same) but it really bugged me that it
was ignored for months. Anyway, after the patch in 2.4, the potential of
letting the Japanese keys do something in Linux depended only on the
possibility of acting at the PS/2 layer or above.
In 2.6, I have a feeling that there might be one or two levels of breakage,
as there has been for the yen-sign or-bar and backslash underscore keys.
Sorry I neglected to test them two days ago. But for that matter, the test
which I reported two days ago seems to have been ignored again. I can only
volunteer about one day a week, but some people get paid to do this as their
job, and I wonder why my report has been ignored.
Now, I think I've read that ATOK can run under Linux. Monopolysoft's IME is
based on ATOK's IME so a lot of people are used to it. There are also other
IMEs under development for Linux. For me and at least one other Usenetter
in Japan, it is a nuisance that Shift+Space turns on the X-11 IME, because
we often type it when we just want a space (if our thumb is still on the
Shift key from typing the previous character). It really would be nice if
we could configure the hankaku/zenkaku key to turn the IME on or off the way
ATOK and Monopolysoft do, and then configure Shift+Space to just input a
Space. But this would depend on making the Japanese keys do something in
Linux. By the way the hankaku/zenkaku key is the one which isn't next to
the space bar, it's in the position which yields ` and ~ on a US keyboard.
(As for why the hankaku/zenkaku key turns the IME on and off instead of
switching between hankaku and zenkaku, the reason is yet another compound of
hacks, but people are used to it now. Actually Alt+hankaku/zenkaku does
still also turn the IME on and off as it always did. Except under Linux of
course. I think it's still a no-op under Linux.)
> > Do you know what the Japanese keys do under Linux?
>
> I don't recall them doing anything under Linux. I think I've read some
> people say that the Japanese keys yield spaces for them
That is a peculiarity of my keyboard, as far as I know, and it only
happens in Set 2, because the Japanese keys are indistinguishable from
the space bar in that mode. Normal Japanese keyboards produce
distinct codes for the Japanese keys in Set 2, which do nothing by
default on the Linux console.
John.
Vojtech Pavlik wrote:
> > That works well for typing, but if someone tries to use these keys in
> > an action game, they will disappointed with the forced-up code - the
> > game will see the key pressed and released, even when the user holds
> > the key down for a long time.
>
> Indeed. Are you expecting a game to be able to use the WWW or Calculator
> keys for anything useful?
Of course. It's not unusual for a game to have a "define keys"
option, where you press a key for each action, to set the key
bindings. Sometimes you pick mnemonic keys; other times, you pick
keys because of how their position feels, like making a custom joypad.
On my Microsoft multimedia keyboard there are about 20 keys that I
could see being useful for that, especially as mnemonic keys.
> > There is only one solution which works well that I can see: do the
> > forced-up thing by default, but as soon as you see a real UP event
> > from a key, disabled forced-up _for that key_ in future.
>
> Won't work. There are keyboards that forget to send a key up event
> sometimes. They usually send it, but from time to time they don't.
> We need to cover these keyboards, too. It's actually the main reason for
> the whole forced up thingy.
:( That's a shame, and a peculiar bug too. Then I agree that
forced-up is needed all the time, if we do not know what triggers the
keyboard to forget to send one or have any way to detect it.
It is not so bad, because even the multimedia keys will be fine on
good quality keyboards.
> I'll give you a kernel/module option to disable the forced up effect if
> you have a perfect keyboard. You can then also enable the untranslated
> mode and set 3. But the default will be translated set 2 with forced
> keyups if a key is not repeating.
Fair enough, I agree.
-- Jamie
Hi!
> > > There is only one solution which works well that I can see: do the
> > > forced-up thing by default, but as soon as you see a real UP event
> > > from a key, disabled forced-up _for that key_ in future.
> >
> > Won't work. There are keyboards that forget to send a key up event
> > sometimes. They usually send it, but from time to time they don't.
> > We need to cover these keyboards, too. It's actually the main reason for
> > the whole forced up thingy.
>
> :( That's a shame, and a peculiar bug too. Then I agree that
> forced-up is needed all the time, if we do not know what triggers the
> keyboard to forget to send one or have any way to detect it.
Can we at least report keyboard as broken to the syslog?
Its usefull if we want manufacturers to eventually fix
their hw (and its extremely usefull when someone gives
you pre-production hw "see if you can break it")
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...