[AD] XIM patch for Allegro 4.1.x

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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? :)

The patch now does two things. First, it replaces X locking with
pthreads locking. Second, it adds a new keyboard driver, which works the
same as the one in new_api_branch - just it has support for XIM. There's
no more need for keyboard.dat or language specification with it - simply
whatever unicode you get for a keypress/sequence of keypresses in any
X11/Gnome/KDE app also is seen by Allegro, and be it Chinese symbols.

<Some more details following:>

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 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.

About new_api_branch, it should be easy to merge.. just copying over the
XIM part, and using pthreads instead of X locks should be enough. And it
has time for after 4.2.0.

I also had to fix a small bug in xdga2.c where the mode fetching called
X11 functions without proper locking. And vsync would deadlock with the
pthreads locking: The timer wants to draw the mouse, so waits for the
mutex of vsync (called by e.g. set_palette). But vsync waits for the
timer value to change :P Not sure why it caused no problems with X
locking.

-- 
Elias Pschernig

Attachment: xim.diff.gz
Description: GNU Zip compressed data



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/