Bug 183645 - window <-> fullscreen switching sometimes failed
Summary: window <-> fullscreen switching sometimes failed
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: allegro
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-02 14:30 UTC by Hans de Goede
Modified: 2013-07-02 23:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-02 14:35:14 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch working around the described problems (7.40 KB, patch)
2006-03-02 15:31 UTC, Hans de Goede
no flags Details | Diff
Patch fixing the described problems using the 3 window solution (25.28 KB, patch)
2006-03-03 23:18 UTC, Hans de Goede
no flags Details | Diff

Description Hans de Goede 2006-03-02 14:30:58 UTC
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.

Other unix users have also been able to reproduce this,
sofat the common factor seems to be the metacity
(gnome) window manager.

The problem is in src/x/xwin.c around line 734:
if (fullscreen) {
AL_CONST char *fc;
char tmp1[64], tmp2[128];
int i;

/* Switch video mode. */
if (!_xvidmode_private_set_fullscreen(w, h)) {
ustrzcpy(allegro_error, ALLEGRO_ERROR_SIZE,
get_config_text("C
return 0;
}

/* Hack: make the window fully visible and center
cursor. */
XMoveWindow(_xwin.display, _xwin.window, 0, 0);
XF86VidModeSetViewPort(_xwin.display,
_xwin.screen, 0, 0);

/* This chunk is disabled by default because of
problems on KDE
fc = get_config_string(uconvert_ascii("graphics",
tmp1),

uconvert_ascii("force_centering", tmp2),
NULL);

if ((fc) && ((i = ugetc(fc)) != 0) && ((i == 'y')
|| (i == 'Y') ||
XWarpPointer(_xwin.display, None,
_xwin.window, 0, 0, 0, 0, 0,
XWarpPointer(_xwin.display, None,
_xwin.window, 0, 0, 0, 0, w -
XWarpPointer(_xwin.display, None,
_xwin.window, 0, 0, 0, 0, 0,
XWarpPointer(_xwin.display, None,
_xwin.window, 0, 0, 0, 0, w -
}

XWarpPointer(_xwin.display, None, _xwin.window,
0, 0, 0, 0, w / 2,
XSync(_xwin.display, False);

/* Grab the keyboard and mouse. */
if (XGrabKeyboard(_xwin.display,
XDefaultRootWindow(_xwin.display)
GrabModeAsync, GrabModeAsync,
CurrentTime) != Gr
ustrzcpy(allegro_error, ALLEGRO_ERROR_SIZE,
get_config_text("C
return 0;
}
_xwin.keyboard_grabbed = 1;
if (XGrabPointer(_xwin.display, _xwin.window, False,
PointerMotionMask |
ButtonPressMask |
GrabModeAsync, GrabModeAsync,
_xwin.window, None,
ustrzcpy(allegro_error, ALLEGRO_ERROR_SIZE,
get_config_text("Ca
return 0;
}
_xwin.mouse_grabbed = 1;
}


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.

I've attached a very much minimized version of the
program causing this problem upstream.

I'm discussing this with / tracking this upstream. I've already added a
workaround patch with explanation to the upstream bugreport:
http://sourceforge.net/tracker/index.php?func=detail&aid=1441740&group_id=5665&atid=105665

Jindrich, I don't want to push this patch as I'm not 100% sure its correct, can
you take a look.

It would be great if you could see if you can reproduce the problem:
Use gnom/metacity, start lacewing, goto options press enter on fullscreen
option, repeat pressing enter, 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.

If you can reproduce it can you also test the workaround? And see if it helps
for you too my previous workaround didn't help other allegro developers (who
could reproduce this), but that was no surprise. I've more hope for this one.

Comment 1 Jindrich Novy 2006-03-02 14:58:01 UTC
Hans, could you please attach the patch here as well? I'm getting "500 -
Internal Server Error" from sourceforge when trying to review the patch.

Thanks.

Comment 2 Hans de Goede 2006-03-02 15:31:45 UTC
Created attachment 125542 [details]
Patch working around the described problems

As requested, the workaround patch, upstream has confirmed that this fixes it
on other machines then mine too (unlike a previous attempt).

Quoting upstream:

"I can confirm this seems to fix the problem. Do you think it's possible
to simply unmap the window though, instead of destroying it?

For 4.3, it would be nice to have a way to simply switch a window
between fullscreen/windowed, preserving things like an OpenGL context
attached to it. Also, with the resizeable windows we will have there,
this might be independent of a resolution change. So, sooner or later we
will need a better solution.

For now, I think the patch should be applied though, because it is an
improvement.

Of course, there's again the ABI issue with the changed struct - but
since the xwin struct already has variable members depending on
the ./confugure results, it shouldn't matter."

The ABI issue is probably a moot one, the xwin struct really should not be used
by other apps, as its platform specific.

And as said the struct even changes when changing ./configure flags. I could
put the problematic variable somewhere else then in the struct though, that
would fix it for sure.

Now the opengl stuff is more serious, I didn't think about that one. Do we have
allegrogl in extras?

So what do we do?

Comment 3 Hans de Goede 2006-03-02 15:47:28 UTC
I just did a yum list 'allegro*' and we don't have allegrogl.


Comment 4 Hans de Goede 2006-03-03 23:16:34 UTC
I've been discussing this with upstream and I've come up with a patch I'll wait
with applying it for a reaction from upstream, here is my latest entry in the
upstream bug tracker:

As discussed on the list I've been working on a solution using 3 windows:
-fs_window (for fullscreen)
-wm_window (window managed)
-window    (the real window)
2 of which will be created in _xiwn_create_window: wm_window and window. The
fullscreen window gets (re)created when needed, because reusing it causes the
same trouble again.
The real window uses wm_window as parent initially and will be reparened to the
(freshly created) fullscreen window when requested and reparented back again in
screen_destroy.

Idea / concept of 3 windows borrowed from SDL. But somehow SDL manages to reuse
the fullscreen window too.

This patch also adds:
-support for fullscreen without the XF86VM extension
(I believe xgfxdrv.c needs updating for this too, untested)
-support for not available resolutions in fullscreen, it
 chooses the smallest bigger mode and centers the graphics
-gets completly rid of the center window patch that was disabled because of
WindowMaker trouble this should no longer be needed, see comments in the patch.
-integrates xwin_resize_window into xwin_create_window the code was wrong for
seperate resize and it wasn't use anywhere else. Resizing a toplevel window will
only send a resize request to the window manager, since our hints say we're not
resizable the window manager will ignore this request, resulting in nothing
happening. The unmap might have helped here but we were mapping the window again
before changing the hints. when testing resizing code for xmame I've even been
able to resize a window by just setting the hints, the way which always works
which I found for xmame is:
*set hints to resizable
*XResizeWindow
*set hints to fixed new size


Comment 5 Hans de Goede 2006-03-03 23:18:30 UTC
Created attachment 125630 [details]
Patch fixing the described problems using the 3 window solution

Comment 6 Hans de Goede 2006-03-08 22:00:54 UTC
Upstream likes my second fix and will apply it to their tree, I'm applying it to
our tree, together with a fix for the i386 assembler on processors with NX
protection.



Note You need to log in before you can comment on or make changes to this bug.