Re: [dev] [dwm] tagging interface

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'.
Received on Wed Sep 22 2010 - 02:06:34 CEST