Ryan C. Gordon <icculus@icculus.org> [Wed, 06 Jan 2010 06:41:41 +0000] rev 4395
Call SDL_OutOfMemory() if SDL_malloc() fails.
Sam Lantinga <slouken@libsdl.org> [Thu, 17 Dec 2009 14:33:00 +0000] rev 4394
Merged SDL 1.3 revision 5424, fixing a crash in the joystick code on recent kernels.
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Dec 2009 22:41:31 +0000] rev 4393
Fixed bug #901
Tim Angus 2009-12-11 11:45:46 PST
Disable mouse event generation when state is not SDL_APPMOUSEFOCUS
If a Windows SDL application is minimised by using alt-tab, SDL_APPMOUSEFOCUS
is lost as part of the minimisation. Unfortunately, the directx driver doesn't
pay any attention to this state when generating mouse button events, so
clicking on the Desktop can cause mouse clicks in the SDL application, while
it's still minimised. The attached patch fixes this. It looks much more
complicated than it actually is due to indentation; here it is ignoring
whitespace:
tma@abraxas:~/sources/SDL-1.2-svn$ svn diff -x -b
Index: src/video/windx5/SDL_dx5events.c
===================================================================
--- src/video/windx5/SDL_dx5events.c (revision 5376)
+++ src/video/windx5/SDL_dx5events.c (working copy)
@@ -374,10 +374,9 @@
if ( !(SDL_GetAppState() & SDL_APPMOUSEFOCUS) ) {
mouse_lost = 1;
ClipCursor(NULL);
- }
-
+ } else {
/* If the mouse was lost, regain some sense of mouse state */
- if ( mouse_lost && (SDL_GetAppState() & SDL_APPMOUSEFOCUS) ) {
+ if ( mouse_lost ) {
POINT mouse_pos;
Uint8 old_state;
Uint8 new_state;
@@ -548,6 +547,7 @@
if ( xrel || yrel ) {
post_mouse_motion(1, xrel, yrel);
}
+ }
}
/* The main Win32 event handler */
Sam Lantinga <slouken@libsdl.org> [Fri, 11 Dec 2009 15:31:37 +0000] rev 4392
Fixed bug #898
Jeremiah Morris 2009-12-09 16:07:17 PST
No-op GlobalToLocal translations in fullscreen mode
On my MacBook Pro running 10.6, I noticed a small upward bias on mouse movement
in a fullscreen SDL application. The app uses WarpCursor and GetMouseState in a
loop to measure relative movement. I tracked it down to NSWindow's
convertBaseToScreen: routine, which added a 2-pixel offset on the Y coordinate
instead of the expected (+0,+0) translation.
In fullscreen mode, QZ_PrivateWarpCursor() does not translate the desired
position through QZ_PrivateGlobalToLocal() before passing it to the Core
Graphics system. However, QZ_GetMouseLocation() does call the reverse
QZ_PrivateLocalToGlobal() even in fullscreen mode. This asymmetry caused
problems each time the mouse was moved.
Sam Lantinga <slouken@libsdl.org> [Fri, 11 Dec 2009 15:24:53 +0000] rev 4391
Fixed bug #849 some more:
Tim Angus 2009-11-26 14:41:04 PST
Fix to the cursor not being responsive when the app doesn't have
SDL_APPINPUTFOCUS
The problems with the directx driver are similar to the ones I introduced in
the windib driver with r4478. Basically if the application did not have focus,
the mouse position is not updated. It's not really that the mouse cursor was
invisible, it's that it is stuck underneath another window where you can't see
it. This behaviour predates my r4478 changes and is the reason I unwittingly
broke the windib driver as I had been replicating the way the directx driver
deals with focus. Prior to r4478 the directx driver could not be used in
windowed mode, so the broken focusing would not have actually been observable.
Anyway, the attached patch makes the directx driver behaves like the windib
driver in terms of focus.
Time for 1.2.15? ;)
I've added an additional change of moving the calls to WIN_GrabInput that are
made on WM_ACTIVATE messages so that they only occur when the state is
SDL_APPINPUTFOCUS. When a fullscreen application is minimised using alt-tab, it
still receives WM_ACTIVATE messages when other applications are selected. If
WIN_GrabInput is called when the SDL application doesn't have input focus, bad
things happen; it shouldn't be being called at all.
I've also added a line to make sure that SDL_APPMOUSEFOCUS state is dropped
when the application is minimised following an alt-tab.
Sam Lantinga <slouken@libsdl.org> [Fri, 11 Dec 2009 15:14:13 +0000] rev 4390
Fixed bug #895
Markus Rothe 2009-12-07 09:32:46 PST
Check if libspe2 is available
Building on PowerPC64 results in:
[...]
In file included from ./src/video/ps3/SDL_ps3events_c.h:33,
from ./src/video/ps3/SDL_ps3video.c:32:
./src/video/ps3/SDL_ps3video.h:34:21: error: libspe2.h: No such file or
directory
In file included from ./src/video/ps3/SDL_ps3events_c.h:33,
from ./src/video/ps3/SDL_ps3video.c:32:
./src/video/ps3/SDL_ps3video.h:75: error: expected specifier-qualifier-list
before 'spe_context_ptr_t'
./src/video/ps3/SDL_ps3video.c:78: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'fb_writer_spu'
./src/video/ps3/SDL_ps3video.c: In function 'PS3_VideoInit':
./src/video/ps3/SDL_ps3video.c:167: error: 'spu_data_t' has no member named
'program'
./src/video/ps3/SDL_ps3video.c:167: error: 'fb_writer_spu' undeclared (first
use in this function)
[...]
The problem is that the ps3 video driver is being build regardless if libspe2
is installed or not. The attached patch fixes this problem.
[ Note: The other headers that are being checked for are coming from the linux
headers package on powerpc64. As a result these are also available if you're on
a generic powerpc64 machine and not a PS3 only. ]
Sam Lantinga <slouken@libsdl.org> [Fri, 11 Dec 2009 15:11:49 +0000] rev 4389
Fixed bug #899
Jeremiah Morris 2009-12-09 16:23:50 PST
Re-enable mouseLocation workaround on 10.4, 10.5
OS X systems before 10.6 have a bug with [NSEvent mouseLocation] if the screen
resolution changes. SDL_QuartzVideo.m contains a workaround for this bug, but
it was placed inside an #ifdef in revision 4762. The comment reads, "I'm
gambling they fixed this by 10.4."
After seeing this bug on several Tiger and Leopard systems (both PPC and
Intel), I can confirm that it's not fixed until 10.6. The workaround doesn't
compile for x86_64/10.6, so I can understand why it was segregated, but it
needs to remain in place for the i386 and ppc versions. The workaround causes
no problems under 10.6, even though it's not necessary there.
Patch is attached with one method of keeping the workaround active on the
systems that need it.
Sam Lantinga <slouken@libsdl.org> [Fri, 11 Dec 2009 08:00:57 +0000] rev 4388
Fixed bug #896
John Popplewell 2009-12-08 23:05:50 PST
Originally reported by AKFoerster on the mailing list.
Error decoding UTF8 Russian text to UTF-16LE on Windows, but specifically on
platforms without iconv support (the default on Windows).
Valid UTF8 characters are flagged as being overlong and then substituted by the
UNKNOWN_UNICODE character.
After studying the testiconv.c example program, reading the RFCs and putting
some printf statements in SDL_iconv.c the problem is in a test for 'Maximum
overlong sequences', specifically 4.2.1, which is carried out by the following
code:
} else if ( p[0] >= 0xC0 ) {
if ( (p[0] & 0xE0) != 0xC0 ) {
/* Skip illegal sequences
return SDL_ICONV_EILSEQ;
*/
ch = UNKNOWN_UNICODE;
} else {
if ( (p[0] & 0xCE) == 0xC0 ) { <<<<<<<< here
overlong = SDL_TRUE;
}
ch = (Uint32)(p[0] & 0x1F);
left = 1;
}
} else {
Here is the 2-byte encoding of a character in range 00000080 - 000007FF
110xxxxx 10xxxxxx
The line in question is supposed to be checking for an overlong sequence which
would be less than
11000001 10111111
which should be represented as a single byte.
BUT, the mask value (0xCE) is wrong, it isn't checking the top-most bit:
11000001 value
11001110 mask (incorrect)
^
and should be (0xDE):
11000001 value
11011110 mask (correct)
making the above code:
} else if ( p[0] >= 0xC0 ) {
if ( (p[0] & 0xE0) != 0xC0 ) {
/* Skip illegal sequences
return SDL_ICONV_EILSEQ;
*/
ch = UNKNOWN_UNICODE;
} else {
if ( (p[0] & 0xDE) == 0xC0 ) { <<<<<<<< here
overlong = SDL_TRUE;
}
ch = (Uint32)(p[0] & 0x1F);
left = 1;
}
} else {
I can supply a test program and/or a patch if required,
best regards,
John Popplewell
Sam Lantinga <slouken@libsdl.org> [Thu, 03 Dec 2009 04:20:46 +0000] rev 4387
Missing pop over a jump
Sam Lantinga <slouken@libsdl.org> [Wed, 02 Dec 2009 16:24:21 +0000] rev 4386
Fixed crash - need to save and restore rbx around cpuid, since the compiler may be assuming the stack pointer isn't being modified when filling in %0.
I did it around each call to cpuid which isn't strictly necessary, but is definitely future proof. :)