| Re: [AD] Real weird unix bug, help wanted |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Elias Pschernig wrote:
On Wed, 2006-03-01 at 22:08 +0100, Hans de Goede wrote:
There is a problem (under unix using the X11-system driver) when calling
set_gfx_mode(GFX_AUTODETECT_FULLSCREEN, ... when changing from a
windowed display to a fullscreen display.
I'm not at all sure that this is allegro's fault it might very well be
the brand spanking new modular Xorg 7.0 release I'm using. While we're
on the topic, I'm using (and you might need an exact copy to reproduce):
-athlon64 2800+
-radeon 9250 / 9200pro with 256 mb ram
-latest x86_64 (64 bits) version of Fedora (FC5test3 + updates)
-using gnome with the (default) metacity window manager.
-allegro-4.2.0-8 as packaged by Fedora-Extras
[..]
Only similarity i see here is, i'm also using Gnome+Metacity
Good, then we can rule out the newer Xorg and 64bit.
This should create an unmanaged window with its left top at position 0.0
of the root window. Now the problem is that with one allegro using
program, sometimes it is as if the XMoveWindow call and the XGrabPointer
call fail silently. In this case the window is at its last position
(before the set_gfx_mode call) and the mouse is ungrabbed, thus I can
pan around the rest of my desktop. It is as if both the move and the
mousegrab never happened. Strange enough the keyboardgrab has happened.
Yeah, I've been seeing this problem for some time here, on both the old
XFree86 and now on X.org. The attached program is how far I got with
tracking this further.. but my conclusions was, X11 really is weired
(e.g. removing one of the XSync in that program makes it not work, and I
have no idea why I would need to set the type to DOCK to get fullscreen,
not do I know why I need the XGrabKeyboard, but oh well..)
Well X11 isn't that weird but when you want fullscreen and you want it
to work with many window managers then things indeed can get weird. I've
had similar problems with xmame for which I've (re)written most of the
(native / no other library involved) X11 code. But xmame doesn't use
xvidmode extension, it just creates a screenfilling window and uses
opengl or Xv hw-scaling to scale the picture.
But back to the topic, yes when using window managers things can get
weird, but that should not be an issue here as the code in xwin.c first
does:
setattr.override_redirect = True;
XChangeWindowAttributes(_xwin.display, _xwin.window,
CWOverrideRedirect, &setattr);
_xwin.override_redirected = 1;
Which tells the window manager to leave the window alone.
I've attached a very much minimized version of the program causing this
problem and I've also found a workaround. There is a define called
workaround in the top of the file, comment this to get the buggy
behaviour. Once you have the file compiled with the workaround define
commented press any key todo the fullscreen<->window toggle. Within say
10 toggle you should see the unwanted behaviour of the window not being
at 0.0 (the viewport will be there) and then you can also freely cause
the mouse to move outside the window and thus the viewport to scroll.
The workaround consists of waiting for the key which was pressed to be
released before doing the switch. Don't ask me why but this fixes it (it
took me ages (hours) to find this, looking at how other programs without
the problem did it).
Unfortunately, it makes no difference here :/
Thats indeed unfortunatly, it seems to fix it 100% for me.
Yes, it's a good test case, it reproduces it for me like each other
time, or maybe even 2/3 of time and only works correctly sometimes.
Anyway, now that you mention this, we should try to fix it. The first
thing I can think of is to try it outside of Gnome.
Any maybe should investigate more my attached test code? I was to
eventually get back to it myself, but not sure when.
You're code is vastly different from what allegro does, whats the idea
behind you're code?
Or it could be an actual bug in the Allegro code - but I don't know
where to start looking.
It might be a race condition, I don't think Xlib is threadsafe if we
screw up the locking we could be confusing Xlib, resulting in all kinda
funnies as said it is almost as if the XmoveWindow call never gets made.
Regards,
Hans