[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/ |