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

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2004-10-25 at 23:30 -0700, Chris wrote:
> On Tue, 26 Oct 2004 00:47:54 +0200, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> > After finally realizing that two displays won't easily work with
> > Allegro, I just took the simple approach of using a pthreads lock
> > instead of XLock. Why didn't anyone tell me earlier? :)
> 
> I'm not sure I like this. If it was just this simple of replacing
> XLock with pthreads lock, why create the XLock in the first place? For
> all we know, the XLock can (and probably does) do more than just a
> thread lock, since Xlib isn't allowed to even have two calls from
> seperate contexts in the same thread. XLock probably does some queue
> flushing when needed (as shown by the blit test problem in the test
> program).

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. SDL, Qt, GTK, wine (according to mailing list posts I
found when googling for XInitThreads) all stay clear of it. And the two
solutions: Use 2 displays (SDL), or manual locking (my patch) - or a
third method would be to combine them, e.g. have the input threads live
in its own display which may not be used by any other thread, and only
use pthreads locking for the other display.. but that turned out to be
complicated.

> 
> I think something like this really needs to be investigated deeply..
> to find out what the expected behavior of XLock and XUnlock are, how
> they deal on different systems (multi-cpu, non-x86, etc), and so on.
> We wouldn't want to do this now and all of a sudden notice problems in
> 4.2 and not know why.
> 

Yes, of course this needs lots of testing. 4.2 still may be far enough
though, given the big advantages this has for users. Currently, half of
the keys aren't useable without requiring the user to run setup and
xkeymap. But of course, if lots of problems start popping up - it
shouldn't be used. But there's also the possibility that this patch will
make 4.2 more stable, given all the problems XInitThreads seems to
cause.

> > The mapping to KEY_* keys initially just uses a list of known keys,
> > which should contain all keys on a US keyboard, so the standard behavior
> > won't change. After that, the remaining keys are just randomly placed to
> > free KEY_* values.
> 
> I don't think I understand this. Are you saying that if some KEY_*
> values are pre-defined, you leave them as-is, and set the rest to
> other values? Can you gaurantee that any pre-defined KEY_* values will
> be less than KEY_MAX?

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. This works well for the
following keys: A-Z, 0-9, F1-F12, cursors, enter, and a few others. And
hopefully for keys like Shift, Ctrl, Alt. The remaining keys then just
are mapped to the remaining KEY_* constants which only exist on English
keyboards, like KEY_TILDE. So e.g. XF86VolumeMute is mapped to
KEY_TILDE. 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 :)

> 
> > I tried with DGA and with signals, and didn't get a single X11 async
> > reply or deadlock so far.. so there should be no fundamental problems
> > with it.
> 
> As I mentioned before, I think this requires more extensive testing.
> Single- and multi-processor machines with the software mouse being the
> main ones.
> 

Yep. But I tried at last the programs where there was problems with the
XLock (which you always could fix :) - and they simply wotk with the
pthreads mutex, without any problems so far. But yes, this should be
tested thouroughly.

-- 
Elias Pschernig