Disable auto repeat for non standard keys?

[Daniel Stone]

On Mon, Jun 30, 2008 at 02:56:00PM +0200, Simon Thum wrote:
> > Matthew Garrett sent me a patch to test, which disables autorepeat for
> > keycodes > 146 and sends the down and up event.
> > It works fine on my laptop (my volume keys are now working fine).
> > 
> > Patch is attached, any comments/other suggestions?
> I don't think the maintainer (not me!) will accept that patch. It's for 
> your keyboard (keycde 146 is rather arbitrary I presume) and one can't 
> even switch it off.
> You should add an option so it can be configured per-device, so it may 
> fix (at least potentially) other quirky keyboards.
> That might improve chances.

Here's a discussion we had about this on #xorg-devel earlier:
< drago01> daniels: anything against merging this patch
           http://rafb.net/p/PD2C8p58.html from mjg59 ? with it my
           volume keys are working
< mjg59> drago01: Daniel described it as making babies cry
< mjg59> drago01: Best might be to punt it to the mailing list and see
         if anyone has any better suggestions
< drago01> mjg59: ok
< daniels> yeah, it's ... yeesh.
< daniels> it might well be necessary though, and kbd is already a
           cesspit, so it's not like it makes it overly worse, just
           less deterministic
< maniac103> is 146 some magic value in key event processing?
< drago01> everything > 146 are not "normal keys"
< daniels> iow, magic value, yes
< mjg59> daniels: I'd guess evdev will show the same behaviour, though
< daniels> right, which is why it would be ideal to have it done by the
           kernel
< mjg59> I'm kind of in favour of the kernel reporting the actual
         hardware behaviour
< mjg59> At least, I don't have any faith in our ability to sell it to
         upstream
< daniels> the point is that we have to do fucked-up hardware-specific
           hacks _somewhere_.  if we're going to do that, why not do it
           as close to the hardware as possible, instead of behind
           abstraction layers that progressively remove our ability to
           determine which hardware we're running on?
< drago01> daniels: what about a way of configuring it for specific
           keys and let hal do it? (ie. add it to the keymap stuff)
< mjg59> Because the kernel response is going to be that this is how
         the hardware behaves, some people might want the functionality
         and consumers should filter as appropriate
< mjg59> What /could/ probably be added to the kernel would be flags to
         control whether a key autorepeats or not
< daniels> mjg59: for the tty reporting, i can see that.  for evdev,
           this goes against every principle of its interface deisgn.
< mjg59> Then we could just bodge stuff in at boot time
< mjg59> Or X startup
< daniels> so what does everyone else using evdev do?
< daniels> bear in mind that evdev was designed to be like x's input (ha
           ha, but seriously).  it should be abstract, it should be
           discoverable, and it should be directly usable by anyone
           without ps/2-like hacks.
< daniels> this falls under the category of ps/2-like hacks.
< mjg59> All I can say is that there's no realistic chance of having a
         default policy for this in the kernel
< daniels> what's the practical difference between having this patch in
           kbd_drv, and its moral equivalent in the kernel?
< mjg59> One is achievable. The other isn't.
< airlied> I think you could push it upstream.
< airlied> the kernel should expose a standard key interface
< airlied> and the keys should all act the same..
< daniels> airlied: evdev, yes
< mjg59> airlied: The kernel /does/ expose a standard key interface. On
         keydown, it reports keydown. On keyup, it reports keyup.
< airlied> mjg59: but on keyup it doesn't .. because the hw doesn't.
< airlied> the key is up
< daniels> mjg59: for the tty layer, you're correct.  for evdev, it's
           more abstract, and isn't supposed to be a 1:1 hw:event
           mapping.
< daniels> as dave says, it's supposed to usefully represent keys, not
           usefully represent the ps/2 wire protocol.
< mjg59> daniels: But you end up with working hardware now reporting
         keydown/keyup/keydown/keyup rather than keydown/keyrepeat/keyup
< daniels> cool.
< daniels> as long as we're putting the patch into x, that's the end
           result, anyway.
< mjg59> Right. But putting it in the kernel breaks any consumers that
         want the latter behaviour.
< daniels> i'm not merging this patch or anything like it into evdev
           until someone admits that the concept of evdev is a complete
           failure.
< mjg59> So it would need to be runtime configurable
< arekm> hehe
< daniels> mjg59: as opposed to just breaking any consumers that want
           keys to be reported.
< mjg59> And if it's runtime configurable, then nobody's going to want
         to put a default policy in the kernel
< daniels> so, don't make it runtime configurable.  life's tough for
           high keys.
< daniels> how many keys act like that, anyway? i thought it was just
           hangul?
< airlied> really can we list the evdev interface consumers?
< mjg59> Volume keys on drag01's machine, eject and hibernate keys on
         Dell laptops
< mjg59> High keys work fine on my HP
< daniels> airlied: if it's an abstract interface, then it's an
           abstract interface.  if it's not, then let me punch through
           and see every detail that was previously hidden.
< mjg59> The behaviour's also PS/2 specific
< daniels> mjg59: so you're saying we need some kind of table listing
           machine-specific quirks.  that's sure to be unpopular with
           the kernel team.
< mjg59> daniels: Ha.
< mjg59> daniels: Well, I can look into the possibility of doing this
         in the ps2 driver.
< daniels> mjg59: that'd be aces, thankyou
< airlied> is usb not bongtastic
< airlied> ?
< mjg59> I haven't heard anyone report this behaviour on any USB devices
< airlied> in that case the kernel shoyuuld abstract it
< airlied> really a ps2 keyb and usb keyb should look the same to
           userspace
< daniels> airlied: right now they do, except that some keys mystically
           autorepeat forever.
< mjg59> Downside to doing it in kernel is that the laoptop users on
         FreeBSD cry
< airlied> mjg59: they all run macosx :-)
< daniels> that's my point, is that if it's abstract enough that i
           can't tell the difference, then it has to be quirked in the
           kernel.  if it's the full brutal wire interface, then i'll
           deal with it.
< daniels> mjg59: hopefully they can convert tears into patches for
           their kernel

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080630/835cef08/attachment.pgp>