| Re: [AD] new_api_branch news |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Elias Pschernig wrote:
I must look at that. My patch is almost ready as well, I just couldn't
get X synchronization to work yet (but inputing Chinese characters in X
works already :) Or does your patch also include support for that
already?
No. I did try your idea of opening two connections to the X server (one
for input, one for output) but I hit a couple of snags so I undid it for
now.
Did you change the way XLOCK/XUNLOCK works in any way? I'd like to
propose getting rid of XInitThreads and XLock/XUnlock, and use two
displays and pthreads locking instead. Using a separate display e.g. for
the events thread apparently makes X11 do its own locking, so the code
should look better (no more need for us caring about it) - and it makes
XIM work, which can't be used together with XInitThreads. For some
cases, like creating the displays and the initial window or maybe things
like position_mouse, I guess pthreads locks are needed to replace XLock.
The signals version is gone in new_api_branch anyway, so no need to care
about that..
Yes, basically I agree.
Here's what I tried. I made an _xwin.input_display connection in
addition to the _xwin.display connection. Instead of the bg_man thread
polling _xwin.display for X-events, I made a new thread that used
select() on the _xwin.input_display connection fd to block until an
event arrived. Two problems came up:
1. DGA has its own event system. AFAIK you cannot initialise the DGA
extension and open the framebuffer using the _xwin.display connection,
then read in DGA events from the _xwin.input_display connection.
2. When you make Xlib requests, e.g. to update the window, the requests
are buffered and not sent until you flush them. This is usually done
with XFlush(), or XSync(), or when you call XNextEvent(). With the new
setup I no longer had a background thread calling XNextEvent() every
10ms or so. I tried flushing the output buffer at the end of
release_screen() -- this had the same performance decreases as when I
tried it before.
The first problem can be solved, I think, by not using an
_xwin.input_display, but rather an _xwin.output_display. That is,
_xwin.display is used for most of the work, including input handling,
and only using the _xwin.output_display for updating graphics in the
XWIN driver. The DGA driver would ignore _xwin.output_display completely.
The second problem may be solvable with a new gfx API. If we have mode
where changes to the screen bitmap are not guaranteed to be visible
until you call some function (like glXSwapBuffers), then we know when to
do the flushing. On the other hand that's basically what
acquire_screen/release_screen is supposed to do so I'm not sure.
For now two input connections was more trouble than not. Once I commit
my changes, we can try it again.
to the pckeys.c module. The other two drivers work the same as they
used to.
That should be changed. Keyboard should behave the same on all
platforms.
I think it should behave how people expect it to behave, _on that
particular platform_. I think that's what you mean.
Especially on windows I'd like to see a more sane behavior.
Using pckeys.c and keyboard.dat, we will never be able to support proper
internationalization. Which is a shame, given how early Allegro cared
about just that, even supporting unicode so early. Right now, you can
use Allegro's keyboard proplerly maybe in 3 or 4 countries. And I see no
reason at all why not to follow the way of the OSX or linux console (or
your new X11 driver I guess).
Unfortunately there is no way to do it using DirectInput. DirectInput
just treats the keyboard like a giant gamepad. You're supposed to use
the usual Windows message system if you want typing input. I don't know
if using both DirectInput and Windows messages at the same time is feasible.
An incomplete solution (that still leaves out complex input systems) is
to supply bunch of keyboard layouts (as we already do) but automatically
pick the right one. The user should not have to edit config files. We
should also encourage more strongly for people to distribute
keyboard.dat alongside the Allegro DLL.
BTW, make install should install keyboard.dat by default on Unix for
4.1.x :-)
I think, we shouldn't touch the keyboard repeat rate. How my X11 patch
would have worked is this (using the current API):
The key[] array has no repeat. That is, generated repeats from the
hardware/OS are detected and ignored. A key is pressed until it is
released again. The KEY_ constants also don't care about their position,
but what is printed on them. Given their limited number, this can only
work for a few keys like latin letters, numbers, cursor keys, but not
e.g. for keys like \ or ~ which don't even exist on my keyboard.
getkey() OTOH will use the keyboard rate as reported from the OS, since
that's what the user has set and wants to use e.g. in inputs boxes in
the grabber. And it will return whatever is printed on the key that is
pressed, using the same Shift/AltGr/dead-keys behavior the user is used
to.
I think I did exactly the same thing (for the new API).
What is "bool"? I thought that is C++ only?
It's C99 (see stdbool.h in your system directories). It's a bit
controversial to use it, but I really hope we can use it. I'm sick of
every library making up its own boolean type.
Peter