Disable auto repeat for non standard keys?
daniel at fooishbar.org
Mon Jun 30 06:25:35 PDT 2008
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
< 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
< mjg59> I'm kind of in favour of the kernel reporting the actual
< mjg59> At least, I don't have any faith in our ability to sell it to
< 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
< 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
< 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
< 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
< daniels> how many keys act like that, anyway? i thought it was just
< airlied> really can we list the evdev interface consumers?
< mjg59> Volume keys on drag01's machine, eject and hibernate keys on
< 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
< daniels> airlied: right now they do, except that some keys mystically
< mjg59> Downside to doing it in kernel is that the laoptop users on
< 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the xorg