| Re: [AD] XIM patch for Allegro 4.1.x |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] XIM patch for Allegro 4.1.x
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Tue, 26 Oct 2004 07:14:41 -0700
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=U1xBHoNxOKkTLpRmpysnJ6OFWFAKwHM7JayVrlmiDXhAFaEUREgdKxHmkSp275oENJQjfVbOovEPZe76t2BoS5HhcSmb0lVeeHbG0urZaNV1840f4tTh4n8Mqwh218GCN3jidQF4ucLGGOYhwQilrbg4FU8Vp8Adt3dA+/v4UZw=
On Tue, 26 Oct 2004 12:46:19 +0200, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> Yes, the mutex ensures that never two X11 functions are called from
> different threads. gdb shows that XLock at least internally also uses a
> pthreads lock (at least the X11 I have here). Not sure what else it
> does, but I have some indication that it is quite broken: XIM simply
> crashes with it.
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.
> No, the problems is simply this: We have a set of X11 keysyms, and a set
> of Allegro KEY_* constants. With positional mapping, you map them so the
> position is the same. E.g. the "A" key on a French keyboard is mappe to
> KEY_Q. But we agreed that it's better to follow the model of e.g. the
> OSX driver, and just map the "A" key to KEY_A.
Oh, okay. Yeah, it should behave that way.
> 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.
> 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.
- Kitty Cat