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.
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.
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?
I just did a yum list 'allegro*' and we don't have allegrogl.
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
Created attachment 125630 [details] Patch fixing the described problems using the 3 window solution
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.