Bug 5780

Summary:	multimedia keys shouldn't repead
Product:	Drivers	Reporter:	Imre Péntek (pentek.imre)
Component:	Input Devices	Assignee:	Dmitry Torokhov (dmitry.torokhov)
Status:	REJECTED INVALID
Severity:	normal	CC:	bunk
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.14	Subsystem:
Regression:	---	Bisected commit-id:

Description Imre Péntek 2005-12-24 10:06:51 UTC

Most recent kernel where this bug did not occur: don't know, but I can loog for
a kernel version with intended operation if you need.
Distribution: UHU-Linux dev
Hardware Environment: Albacomp laptop
Software Environment: UHU-Linux dev
Problem Description:
If I press a letter-button (or any normal button) for a moment, it will type one
letter. If I press it for a long time it will type several letters. Now that is
OK. The problem is if I press a multimedia button for a moment it won't have any
effect. If I press it too long time it will launch the application several times
(so I will have several instances of (say) Mozilla). So these buttons shouldn't
have to repeat. Previously it worked correctly...
Affected buttons are: 178,236 and scan code e001
And anyways volume up and volume down (174 and 176) is intended to repeat

Comment 1 Dmitry Torokhov 2005-12-28 21:29:33 UTC

Is this PS/2 keyboard? Are you using softrepeat option?

Comment 2 Imre Péntek 2005-12-29 04:01:18 UTC

This is a laptop keyboard, identified by lshal as:
udi = '/org/freedesktop/Hal/devices/pnp_PNP0303'
  info.udi = '/org/freedesktop/Hal/devices/pnp_PNP0303'  (string)
  linux.subsystem = 'pnp'  (string)
  linux.hotplug_type = 1  (0x1)  (int)
  info.product = 'IBM Enhanced (101/102-key, PS/2 mouse support)'  (string)
  pnp.description = 'IBM Enhanced (101/102-key, PS/2 mouse support)'  (string)
  pnp.id = 'PNP0303'  (string)
  info.linux.driver = 'i8042 kbd'  (string)
  info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
  info.bus = 'pnp'  (string)
  linux.sysfs_path_device = '/sys/devices/pnp0/00:07'  (string)
  linux.sysfs_path = '/sys/devices/pnp0/00:07'  (string)

I don't know if I am using softrepeat, I didn't enabled it explicitly. How can I
check if it is enabled?

Comment 3 Dmitry Torokhov 2005-12-29 12:56:52 UTC

What does "cat /sys/bus/serio/devices/serioX/softrepeat" show, where serioX is 
serio port your keyboard is attached to?

Comment 4 Imre Péntek 2005-12-29 13:10:00 UTC

I just guess only this is my keyboard:
root:/sys/bus/serio/devices/serio4# cat driver
atkbd
root:/sys/bus/serio/devices/serio4# cat softrepeat
0

Comment 5 Dmitry Torokhov 2005-12-29 14:13:28 UTC

Ok, so you are using hardware repeat. Now, if you do:

      echo 1 > /sys/modules/i8042/parameters/debug
      then press and hold your multimedia button (while in console)
      echo 0 > /sys/modules/i8042/parameters/debug

and then look in your dmesg - do you see that keyboard generates repeat 
keypresses for the key?

Comment 6 Imre Péntek 2005-12-30 04:54:43 UTC

It generates 3 dmesg/syslog messages no matter how long I press the button:
Dec 30 13:57:45 localhost kernel: [  227.398980] drivers/input/serio/i8042.c: 6c
<- i8042 (interrupt, KBD, 1) [103207]
Dec 30 13:57:58 localhost kernel: [  233.170336] drivers/input/serio/i8042.c: e0
<- i8042 (interrupt, KBD, 1) [106457]
Dec 30 13:57:58 localhost kernel: [  233.172610] drivers/input/serio/i8042.c: ec
<- i8042 (interrupt, KBD, 1) [106458]

the first one arrives when key is pressed, the other two is reported when I
release the key.

Comment 7 Vojtech Pavlik 2006-01-03 11:06:11 UTC

The keyboard doesn't generate autorepeat scancodes by design. The only way
around it is to enable softrepeat by setting atkbd.softrepeat=1.

Comment 8 Vojtech Pavlik 2006-01-03 11:20:03 UTC

Oops, sorry, I just noticed you wanted the opposite. Please disregard my
previous comment.

Now, in Linux, currently, there is no way to specify repeat behavior on a
per-key basis. It's either all keys or no keys on a device, in this case your
internal keyboard.

As a result of that, it is normal that the keys do autorepeat, and the application
launching software should be able to detect a repeat event from a normal
keypress event and not lauch the application in that case.

What looks like a bug, however, is that you get no action on a short keypress.
What does 'xev' say in such case?

Comment 9 Imre Péntek 2006-01-03 11:53:59 UTC

xev reports several keypress events. But when using Kernel 2.6.9 it only reports
one key pressed event, and one key released. I don't know how it worked, but (at
least for me) that was the intended behaviour.

Comment 10 Dmitry Torokhov 2006-01-03 12:38:35 UTC

Vojtech,

From the raw i8042 data that Imre provided it looks like the hardware does not 
do autorepeat but atkbd does. Unfortunately my laptop autorepeats everything.

Comment 11 Imre Péntek 2006-01-28 00:47:33 UTC

Can I help with more details? What should I check?

Comment 12 Dmitry Torokhov 2006-01-29 19:53:42 UTC

Hmm, could you please do another test - while in text console (not X) start 
"showkey" utility and verify that you see autorepeats when pressing your 
multimedia keys. That will prove whether it is kernel generating autorepeat 
events or not.

Comment 13 Imre Péntek 2006-01-30 07:16:30 UTC

I tested all three affected multimedia keys. Only one press and one release is
reported no matter how long I press the button.

kb mode was UNICODE
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...
keycode  28 release
keycode 155 press
keycode 155 release
keycode 150 press
keycode 150 release
keycode 160 press
keycode 160 release

Comment 14 Dmitry Torokhov 2006-01-30 07:54:50 UTC

Ok, then it is not a kernel but rather userspace issue. You have just proven 
that kernel does not auto-repeat those multi-media keys. Have you upgraded X 
recently?

Comment 15 Imre Péntek 2006-01-30 08:07:24 UTC

I upgraded X several times :)
Anyways, thanks for supporting me.

Comment 16 Dmitry Torokhov 2006-01-30 08:40:53 UTC

Please try logging a bug against X (X.org I presume?) I am rejecting the bug 
here.