Re: repeating keys problem SOLVED (bug in xfree86) ... new PROSPECT for Sawfish!

Michal Maru¹ka writes:
|So, if at the right time (i.e. when key Release is signalled from
|hardware/kernel), the pointer still points at EnqueueEvent, the timer is not
|cancelled, is (later) run, and generates a pair of Release/Press events, and
|reschedules itself (so it can happen more times).
|
|I've made a quick fix, basically adding into the EnqueueEvent:
|
|    if (xE->u.u.type==KeyRelease)
|       AccessXCancelRepeatKey(xkbi,key);
|
|I'll post to Xfree86 mailing list, too.

cool, that sounds plausible. Thanks for looking into this.

|
|New possibilities for Sawfish:
|===============================
|
|I'm very interested in incorporating (more) commands/functions equipped with
|grab-keyboard into sawfish.
|
|Input focus can be changed during GrabModeSync keyboard grab, and that can be
|exploited in 'making sawfish reliable', i.e. avoid losing key events or having
|them directed to wrong windows.

when does this happen with the existing code?

|
|So, there needs to be direct access from scheme to XSetInputFocus
|(commit_queued_focus_change is not good); XUngrabKeyboard (in
|on_idle() ) and various XAllowEvents should be made conditional. 

The queued focus changing was added for a reason, to avoid various race
conditions. Isn't XAllowEvents already accessible from lisp code?

        John