Mon, 20 Feb 2012 23:54:33 -0500 Fixed bug 1423 - Finger touch events don't report pressure
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Feb 2012 23:54:33 -0500] rev 6299
Fixed bug 1423 - Finger touch events don't report pressure Philip Taylor 2012-02-19 08:34:52 PST SDL_touch.c never actually uses the 'pressurein' arguments to SDL_SendFingerDown/SDL_SendTouchMotion, so it doesn't report the real pressure. Also it uses touch->pressureres which is never initialised. Also it fails to initialise some fields of event.tfinger for certain events, so applications might try to use bogus data. The attached patch seems to be enough to produce generally sensible output on Android.
Mon, 20 Feb 2012 23:51:53 -0500 Fixed bug 1426 - SDL_SemWaitTimeout returns -1 and sets error instead of SDL_MUTEX_TIMEDOUT on time out
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Feb 2012 23:51:53 -0500] rev 6298
Fixed bug 1426 - SDL_SemWaitTimeout returns -1 and sets error instead of SDL_MUTEX_TIMEDOUT on time out deraj 2012-02-19 19:01:08 PST Fix to treat ETIMEDOUT as a time out instead of an error (and update the test)
Mon, 20 Feb 2012 23:51:08 -0500 Fixed bug 1426 - SDL_SemWaitTimeout returns -1 and sets error instead of SDL_MUTEX_TIMEDOUT on time out SDL-1.2
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Feb 2012 23:51:08 -0500] rev 6297
Fixed bug 1426 - SDL_SemWaitTimeout returns -1 and sets error instead of SDL_MUTEX_TIMEDOUT on time out deraj 2012-02-19 19:01:08 PST Fix to treat ETIMEDOUT as a time out instead of an error (and update the test)
Mon, 20 Feb 2012 23:37:57 -0500 Add OpenGL 3.X context creation support
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Feb 2012 23:37:57 -0500] rev 6296
Add OpenGL 3.X context creation support Matthias Bentrup 2011-10-30 03:58:24 PDT I've updated the context creation patch to include the bugfixes by Martin Schreiber and also included a profile bit to request a ES2 compatible profile. The wgl context creation may use 2 call to wglChoosePixelFormat if no acceleration attribute is selected, this should work around a bug with buggy AMD drivers (see #1254).
Mon, 20 Feb 2012 20:56:52 -0500 Fixed bug 1424 - Handling of alpha channel in Altivec accelerated blit functions
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Feb 2012 20:56:52 -0500] rev 6295
Fixed bug 1424 - Handling of alpha channel in Altivec accelerated blit functions evilbite 2012-02-19 09:38:21 PST There is only one Altivec accelerated blit function (ConvertAltivec32to32_prefetch() or ConvertAltivec32to32_noprefetch(), depending on the CPU used) that is supposed to handle all alpha combinations. This works as follows for every pixel line: 1. Blit single pixels until an aligned address is reached 2. Accelerated blit as far as possible 3. Blit single remaining pixels Part 2. is set up correctly to handle different combinations of the alpha channels of the participating surfaces. Parts 1. and 3. only do a simple copy of all the pixel's components from souce to destination. But when the source surface has no alpha channel (Amask is 0, e.g. the video surface) the surface's alpha value must be used instead. Otherwise crap (uninitialized data) is being copied to the destiniation's alpha channel. The attached patch is a quick'n'dirty solution to the problem. A more sophisticated solution might require separate functions for different combinations of the alpha channels of the participating surfaces.
Mon, 20 Feb 2012 20:55:23 -0500 Fixed bug 1424 - Handling of alpha channel in Altivec accelerated blit functions SDL-1.2
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Feb 2012 20:55:23 -0500] rev 6294
Fixed bug 1424 - Handling of alpha channel in Altivec accelerated blit functions evilbite 2012-02-19 09:38:21 PST There is only one Altivec accelerated blit function (ConvertAltivec32to32_prefetch() or ConvertAltivec32to32_noprefetch(), depending on the CPU used) that is supposed to handle all alpha combinations. This works as follows for every pixel line: 1. Blit single pixels until an aligned address is reached 2. Accelerated blit as far as possible 3. Blit single remaining pixels Part 2. is set up correctly to handle different combinations of the alpha channels of the participating surfaces. Parts 1. and 3. only do a simple copy of all the pixel's components from souce to destination. But when the source surface has no alpha channel (Amask is 0, e.g. the video surface) the surface's alpha value must be used instead. Otherwise crap (uninitialized data) is being copied to the destiniation's alpha channel. The attached patch is a quick'n'dirty solution to the problem. A more sophisticated solution might require separate functions for different combinations of the alpha channels of the participating surfaces.
Mon, 20 Feb 2012 20:50:38 -0500 Fixed bug 1427 - integer passed to XChangeProperty() causes crash SDL-1.2
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Feb 2012 20:50:38 -0500] rev 6293
Fixed bug 1427 - integer passed to XChangeProperty() causes crash Julian Coleman 2012-02-20 06:51:12 PST In src/video/x11/SDL_x11video.c, the result of getpid(), i.e., a pid_t is passed to: XChangeProperty(..., 32, ...) However, using 32 here means that Xlib treats the value as a long, and pid_t is an int. So, we get a bus error inside Xlib. The fix is to make sure that anything passed to XChangeProperty() is aligned correctly. Note, that the other calls to XChangeProperty() pass long values here. The proposed patch makes a union of the pid_t return type from getpid() and a dummy long. This has been tested to fix the bus error crash on NetBSD/sparc64.
Mon, 20 Feb 2012 20:46:30 -0500 Fix for double free when quitting on iOS
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Feb 2012 20:46:30 -0500] rev 6292
Fix for double free when quitting on iOS Tim Angus 2012-02-20 09:40:35 PST As alluded to in the email thread "SDL2 error on iOS (doublefree)", I believe the original cause of this bug is confusion over the purpose of SDL_VideoDisplay::current_mode. It looks as though it is a weak reference to another mode, albeit with value semantics. The iOS port treated it as a strong reference however and claimed ownership, which is why things blew up. All the patch really does it to stop treating current_mode as a strong reference. To prevent this happening again it might be an idea to change current_mode to be a pointer type rather than a value. This would certainly make its semantics much more obvious. Failing that, a comment in the struct indicating its weak reference properties might be wise.
Wed, 15 Feb 2012 21:11:21 -0500 Fixed bug 1419 - SDL_libgl2D.c breaks ndk-build
Sam Lantinga <slouken@libsdl.org> [Wed, 15 Feb 2012 21:11:21 -0500] rev 6291
Fixed bug 1419 - SDL_libgl2D.c breaks ndk-build Philip Taylor 2012-02-15 10:43:47 PST render/nds/SDL_libgl2D.c unconditionally includes NDS-only code. SDL's Android.mk compiles source files matching $(wildcard $(LOCAL_PATH)/src/render/*/*.c) which includes that file, causing build errors when running ndk-build.
Wed, 15 Feb 2012 21:06:45 -0500 FreeBSD compile fix
Sam Lantinga <slouken@libsdl.org> [Wed, 15 Feb 2012 21:06:45 -0500] rev 6290
FreeBSD compile fix Robert Millan src/joystick/bsd/SDL_sysjoystick.c makes the invalid assumption that __FreeBSD_kernel__ implies presence of "ucr_data" struct member. This breaks recent versions of FreeBSD 10-CURRENT, FreeBSD 9-STABLE and Debian GNU/kFreeBSD "wheezy/sid".
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip