Jan Engelhardt 2010-09-23 17:02:37 PDT
Problem:
SDL-1.2.14.
When SDL switches to fullscreen 640x480 - for example, because the game is
configured to run in such resolution - or back, it changes the desktop size too
by means of xrandr or something along the lines of that.
Actual results:
Windows on my desktop are reordered, which is usually a result of the WM being
forced to do so because the desktop size (virtualsize) changed.
Resolution switching also takes significantly longer than it did before — this
is another sign that it switches desktop size (too), not just resolution.
First the screen goes black-with-backlight and after roughly 500ms, the TFT
screen finally gets the new 640x480 mode signal (I use VGA), which is evidenced
by the backlight going briefly off.
Expected results:
Previous behavior. In other worsd, leave desktop size as-is (and subsequently
keep my windows where they are) and _only_ change the resolution. The old
switching style is also way faster in that there is no black-with-backlight
delay.
Additional information:
Overriding the system SDL 1.2.14 libraries and using LD_LIBRARY_PATH to point
to SDL-1.2.13 libraries brings back the desired behavior.
hg bisecting...
The first bad revision is:
changeset: 4313:8ec3036098df
branch: SDL-1.2
user: Sam Lantinga <slouken@libsdl.org>
date: Sat Oct 10 10:14:01 2009 +0000
summary: Adapted from Debian patch: 320_activate_xrandr_on_default.diff
I am aware of the existence of the SDL_VIDEO_X11_XRANDR environment variable,
but that only looks like a temporary workaround to me.
--HG--
branch : SDL-1.2
Carlo Bramini 2010-01-27 10:06:17 PST
When building third party software powered by libtool (like xine-lib and
several others) under Mingw+MSys, libSDL fails to link.
I got this message when building SDL video out component of xine-lib:
*** Warning: linker path does not have real file for library -lmingw32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libmingw32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libmingw32.a
Apparently there is no need to manually add -lmingw32 for making libSDL
working.
If this flag is removed, everything is built without troubles.
If it has been added for fixing a cross-compiler, perhaps if would be a better
idea to adjust its SPECS file in the same manner it has been done in the true
one used by mingw on Windows (I'm just guessing why it exists here).
There is also another message received on the console:
*** Warning: linker path does not have real file for library -lSDLmain.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libSDLmain and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libSDLmain.a
This message, like previous one, is caused by -no-undefined flag sent to
libtool when building shared libraries.
Actually adding an .la file with its dependencies solves the troubles, so I
believe it would be better to create it too in the build process of libSDL.
--HG--
branch : SDL-1.2
yrizoud@gmail.com 2010-12-01 07:34:48 PST
Run a SDL program with "" as one of the command-line arguments: crash on
startup.
Program received signal SIGSEGV, Segmentation fault.
0x0047b2ea in ParseCommandLine (cmdline=<value optimized out>, argv=0x0)
at ./src/main/win32/SDL_win32_main.c:100
100 while ( *bufp && ( *bufp != '"' || *lastp == '\\' ) ) {
(gdb) bt
#0 0x0047b2ea in ParseCommandLine (cmdline=<value optimized out>, argv=0x0)
at ./src/main/win32/SDL_win32_main.c:100
#1 0x0047b5bb in WinMain@16 (hInst=0x400000, hPrev=0x0,
szCmdLine=0x81c530e0 "a \"\" b", sw=10)
at ./src/main/win32/SDL_win32_main.c:374
#2 0x0047af28 in main ()
---
The problem is that on Windows when you make a shortcut, and want it to accept
drag-and-dropped files, the good way to make it work work with files that have
spaces in their names or paths is make this argument "%1" (with the surrounding
quotes). But then when you run it without dropping a file into it, it's
resolved as "", and triggers this bug.
--HG--
branch : SDL-1.2
burkheart@yahoo.com 2011-09-24 07:42:49 PDT
When reparenting the SDL Window in a Win32 window (using SetParent) then
stealing the focus during resizing from the parent window is causing problems.
Assume you are dragging a corner of the parent window and consequently the
parent window is sending resize events to the SDL child window. The SDL child
window will eventually call DIB_ResizeWindow which has a call to
SetForegroundWindow and is stealing the focus from the parent window. The
switch in focus stops the resizing dragging process in the parent window.
Basically making it nearly impossible to resize the parent window by dragging
along the edges and corners.
Solution, add a condition to avoid this when reparenting:
if (GetParent(SDL_Window) == NULL) SetForegroundWindow(SDL_Window);
--HG--
branch : SDL-1.2
Gabriel Gambetta 2009-11-04 04:51:46 PST
If you change the video mode while holding the mouse button down, and then
click on the window, you can't move the mouse pointer over the title bar or the
close window button.
It turns out WinMessage in SDL_Sysevents.c is using a static int mouse_pressed
to keep track of whether it should call SetCapture() and ReleaseCapture().
Since it's static and initialized only once, it isn't cleared when the video
mode changed, so there's a kind of one-off error and SetCapture() and
ReleaseCapture() aren't being called when they should.
Here's a patch - I just made that int accessible from the outside and reset it
to 0 in SDL_SetVideoMode, wrapped in #ifdef WIN32. Suggestions on how to make
this more elegant are welcome.
--HG--
branch : SDL-1.2
cjj_009@yahoo.com 2009-12-14 20:32:35 PST
I've been working on an SDL/OpenGL program, that among other things, must deal
with resizing events in order to adjust the aspect ratio.
It doesn't always seem to get the SDL_VIDEORESIZE event when it should, causing
the aspect ratio to not be adjusted as needed.
I've run it in debug mode and made these observations:
*When it initially starts up, if I maximize the window, it receives the
SDL_VIDEORESIZE event as needed.
*If, after starting up the the application and maximizing the window, I then
restore the window by double clicking the title bar, it does NOT receive the
SDL_VIDEORESIZE event.
*I can repeat the last two steps, and it will get continue to get the
SDL_VIDEORESIZE on the maximize but not get one on the restore.
*If I then do a slight adjustment to the width or height of the window, it will
get the SDL_VIDEORESIZE event.
*From then on, if I do restore operations to the window, the SDL_VIDEORESIZE
event will be caught properly.
See http://forums.libsdl.org/viewtopic.php?t=5291 for additional information.
vgvgf 2010-03-28 15:15:16 PDT
Proposed patch for SDL_resize.c
The width and height values stored in SDL_VideoSurface are the sizes of the
video surface when it was created. So, when the window is rezised back to its
creation size, the following condition will make the SDL_PrivateResize function
stop, and the video resize msg won't be queued.
if ( ! SDL_VideoSurface ||
((w == SDL_VideoSurface->w) && (h == SDL_VideoSurface->h)) ) {
return(0);
}
Sam Lantinga 2011-12-30 02:59:51 PST
I'm okay with applying this patch, but be aware that the expected response to a
resize message is that you call SDL_SetVideoMode() again with the new mode.
This signals SDL that you're expecting the new size, and there may be other
problems if you don't do this.
--HG--
branch : SDL-1.2
This fixes a logic error, and allows setting the cursor from off the main
thread, which isn't strictly a good idea, but previous versions of SDL on
Mac OS X apparently allowed it, so we'll make the effort here.
Fixes Bugzilla #1355.
Thanks to Alexei Svitkine for the patch!
--HG--
branch : SDL-1.2
alarantalara@gmail.com 2011-12-19 20:43:13 PST
On little endian systems using the Quartz code, an unusual set of RBGA masks is
used when using the windowed video mode.
This set is not taken into account in SDL_DisplayFormatAlpha and so it converts
the supplied surface to a format that does not match the video surface,
preventing fast blitting.
This was observed in recent builds of Battle for Wesnoth when SDL was updated
to cover the problem when switching to full screen in Lion
(https://gna.org/bugs/?18319).
You can observe the performance issue if you download Wesnoth 1.9.13 for OS X
at
http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.9.13/Wesnoth_1.9.13.dmg/download
and replace the included SDL library with any build of SDL 1.2.14 or later. (I
have already patched the included version, so the problem is not observable
without replacement.)
A patch resolving the issue is attached.
--HG--
branch : SDL-1.2
zicodxx@gmx.de 2010-07-28 12:59:27 PDT
Again another bug I encountered on Windows 7:
Assuming I hide my mouse cusor with SDL_ShowCursor(SDL_DISABLE).
Now if my app runs on Fullscreen, I tend to "get out" of it using ALT+TAB. This
will minimize the app. However SDL_GetAppState will STILL report SDL_APPACTIVE,
SDL_APPINPUTFOCUS and SDL_APPMOUSEFOCUS.
Also if I check event.active.gain, this *seems* (as much as I could find out)
to be set twice (first 0 then 1 again) while going out of the app with ALT+TAB.
I am not perfectly sure here but even if the app is minimized because of
ALT+TAB (or also CTRL+ESC), event.active.gain is 1.
Alex Volkov 2011-04-28 17:19:26 PDT
This happens with the windib driver. Windows posts the WM_ACTIVATE WA_INACTIVE
event with minimized==false when you Alt+Tab out of a fullscreen app.
Responding to this event, wincommon/SDL_sysevents.c:WinMessage() calls
ShowWindow(,SW_MINIMIZE) via SDL_RestoreDesktopMode, but another WM_ACTIVATE
event is not posted in response to that.
Whatever the case may be, WinMessage() should just treat a fullscreen app
receiving WA_INACTIVE the same as a minimized app. Additionally, it's probably
a good idea to clear SDL_APPMOUSEFOCUS at the same time, and that should take
care of bug #1035.
--HG--
branch : SDL-1.2
Matthias Hawran 2010-07-28 03:00:49 PDT
Hi,
I simply want to "forward" this post
(http://forums.libsdl.org/viewtopic.php?t=4123) about absolute mouse events not
being monitored by SDL 1.2 as directfb / tslib generates them.
It's fixed in 1.3 and IMHO it should be backported to 1.2
Included the patch from the post (thanks to Guillaume Chereau)
Cheers,
Matthias
--HG--
branch : SDL-1.2
In X11_CreateYUVOverlay hwdata->image will be accessed after it has been
freed, causing undefined behavior. Exchanging two lines as shown in this
patch will fix that problem:
Regards, Bodo
--HG--
branch : SDL-1.2
Don't ever leave it to the OS to decide, because older ATI drivers apparently
break in this case, and generally apps want FULL by default anyhow.
--HG--
branch : SDL-1.2
