On Tue, Sep 21, 2010 at 07:07:30PM +0000, Wolf Tivy wrote: > That would suck. Good to know it can be done tho. I have heard of > a way to turn off repeats, and I'll look into that before I do any > nasty race-condition hacks.
The only mechanism I know of is what "xset r off" does, i.e. it is not a per-application thing. I think you'd find disabling it to be annoying in many applications. You may want to check this yourself, but years ago I dissected the issue and I remember it not being a race condition. That is, when the X server decides to repeat a key, it simultaneously (i.e. atomically wrt anything looking at the X event queue) places both Release and Press events on the queue. I just checked in xev, here you can see how these pairs of events appear: KeyRelease event, serial 28, synthetic NO, window 0x2e00001, root 0x119, subw 0x0, time 1926272019, (75,141), root:(76,142), state 0x0, keycode 39 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (73) "s" XFilterEvent returns: False KeyPress event, serial 28, synthetic NO, window 0x2e00001, root 0x119, subw 0x0, time 1926272019, (75,141), root:(76,142), state 0x0, keycode 39 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (73) "s" XmbLookupString gives 1 bytes: (73) "s" XFilterEvent returns: False As you can see, I misspoke earlier: the events have *exactly* the same time field. Combining this with what I said about the queuing (the "atomic" insertion), I think you'll agree that doing XPeekEvent inside the KeyRelease handler, and discarding the pair of events if the time, keycode, etc fields match, is a sufficiently robust test. Also, though this may seem nasty, it is nice in the sense that all programs reacting to KeyPress events get key the same key repeat behavior 'for free'.