*sigh* man is X an overengineered POS. X(
Thanks for the pointers, you've saved me a lot of time and pain!
I've been looking into what other 'platform abstraction' libs do. SDL
uses essentially the same trick I described, with a tolerance of 2 ms:
/* Check to see if this is a repeated key.
(idea shamelessly lifted from GII -- thanks guys! :)
*/
static int X11_KeyRepeat(Display *display, XEvent *event)
{
XEvent peekevent;
int repeated;
repeated = 0;
if ( XPending(display) ) {
XPeekEvent(display, &peekevent);
if ( (peekevent.type == KeyPress) &&
(peekevent.xkey.keycode == event->xkey.keycode) &&
((peekevent.xkey.time-event->xkey.time) < 2) ) {
repeated = 1;
XNextEvent(display, &peekevent);
}
}
return(repeated);
}
I don't think the combination of XPending/XPeekEvent/XNextEvent adds
anything over XCheckIfEvent. In theory there is a semantic difference:
if there are other events between the KeyRelease and the KeyPress, the
SDL version will call this a genuine KeyRelease without ever looking
at the KeyPress. If anything, this relying on autorepeat KeyPress
events always immediately following the corresponding KeyRelease ones
should only make this check less robust. Whatever it might add is lost
in the general case where no non-keyboard events happen while you
type?
Richard, do you remember having tried this particular tolerance?
More interestingly, freeglut uses XQueryKeymap:
if (event.type==KeyRelease)
{
/*
* Look at X11 keystate to detect repeat mode.
* While X11 says the key is actually held down,
we'll ignore KeyRelease/KeyPress pairs.
*/
char keys[32];
XQueryKeymap( fgDisplay.Display, keys ); /* Look
at X11 keystate to detect repeat mode */
if ( event.xkey.keycode<256 ) /*
XQueryKeymap is limited to 256 keycodes */
{
if ( keys[event.xkey.keycode>>3] &
(1<<(event.xkey.keycode%8)) )
window->State.KeyRepeating = GL_TRUE;
else
window->State.KeyRepeating = GL_FALSE;
}
}
I tried this one and it works for me in sane conditions, but I was
skeptical to adopt it because I thought this was doing a check for the
asynchronous keyboard state and it would err under lag conditions.
Checking the Xlib spec, I read
"The XQueryKeymap function returns a bit vector for the logical
state of the keyboard [...]. Note that the logical state of a device
(as seen by client applications) may lag the physical state if device
event processing is frozen."
But now I realise I was taking this warning backwards. I think
XQueryKeymap gives me exactly the state I need in order to check
autorepeat at my leisure. The only problem I see with it is the 256
keycode limit. Maybe this is a problem for international keyboards?
Have you considered this method, and if so, could you please share why
you discarded it?
Esteban.
[BTW, Please let me know if you think this kind of discussion is
abusing the list.]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
