| 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: Mon, 25 Oct 2004 23:30:58 -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=QFQOIu21vV+2aOswWqZWvKO+ijDnHipdA+R28DWhyfC76Fo372CCuAiAO6Otk0x9KNghwbJg0yinYq/pNYn6Thd56NpODi9AzblmNEZHW8zMXn9sd9APYzDsgooZO7jAOFGwqsrd7OWPZ8au6U7tqN/G9eFX3K6u/DNE+/Dt5Pc=
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).
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.
> 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?
> 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.
> 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.
The mouse draw routine wants to (re)set the palette? I'll have to check that.
- Kitty Cat