Re: [AD] XIM patch for Allegro 4.1.x

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2004-10-26 at 07:14 -0700, Chris wrote:
> It could be a problem with XIM, too. And just by the fact that XIM
> crashes with XLock, and doesn't with pthread_lock, indicates that
> XLock does more than just simply lock. And without knowing what, I
> don't think it'd be safe to replace it. And who knows.. it might not
> affect anything now, but could on a future version of XFree86 or Xorg.
> Or worse, one and not the other. Then we'd definitely all be
> scratching our heads.
> 

Yes, I also believe it will be fixed in future X11 versions. But as I
said, I doubt those 4 examples I mentioned are all wrong. And so far, I
see no indication that XLock is better than a simple pthreads mutex.
There's no other way than replacing it anyway, if we want t use XIM. If
there are problems with the locking, then we should wait with including
XIM until they fix the XLock issue of course. But if pthreads locking
works, I see no problem doing like the other mentioned X11 programs.

> > And yeah, there's still a TODO in the patch to add
> > KEY_UNKNOWN_1 KEY_UNKNOWN_2.. up to as much as we can get (my
> > keyboard has about 5 keys which can't be mapped right now, since the
> > allocation runs out of free KEY_* constants :)
> 
> Why not just make all "unknown" keys start at KEY_MAX? And/or you
> could define a macro KEY_UNKNOWN(x), where x is an interger 0 or
> greater.

That was my original idea.. but there's a maximum of 127 keys currently,
so better waste nothing. I'll make a patch to set KEY_MAX to 127, and
fill the free spaces with KEY_UNKNOWN*.

> > Yep. But I tried at last the programs where there was problems with the
> > XLock (which you always could fix :)
> 
> The only problem, per se, is a queue flush/timing issue.. and it seems
> to be popping up in Windows now too. I sent a patch that adds a yield
> to the test program to fix that problem, but we're not totally sure if
> we just want to require programs to yield/rest, or find a solution
> Allegro can do itself. The former gives more control to the
> programmer, but the latter makes it easier for new programmers.

I think it may be connected to the way Allegro flushes the output from
the input thread. I.e. there's a call to XFlush() 100 times / second. A
better approach would be to allow the user to control when XFlush is
called, maybe in release_screen(). Or maybe this is done already - it
needs investigation in any case.

-- 
Elias Pschernig