kwm@rainbow-runner.nl 2011-01-30 06:28:27 PST
Created attachment 562 [details]
Build fix with clang.
When building sdl 1.2.14 with the Clang compiler http://clang.llvm.org .
The build fails in src/video/mmx.h with the following error:
--------------------------------------------------
./src/video/SDL_RLEaccel.c:831:5: error: invalid operand for instruction
CHOOSE_BLIT(RLECLIPBLIT, alpha, fmt);
^
./src/video/SDL_RLEaccel.c:831:17: note: instantiated from:
CHOOSE_BLIT(RLECLIPBLIT, alpha, fmt);
^
./src/video/SDL_RLEaccel.c:831:5: note: instantiated from:
CHOOSE_BLIT(RLECLIPBLIT, alpha, fmt);
^
./src/video/SDL_RLEaccel.c:647:23: note: instantiated from:
blitter(2, Uint8, ALPHA_BLIT16_565MMX); \
^
./src/video/SDL_RLEaccel.c:282:4: note: instantiated from:
movq_r2m(mm3, *dstp); \
^
In file included from ./src/video/SDL_RLEaccel.c:99:
./src/video/mmx.h:379:28: note: instantiated from:
#define movq_r2m(reg, var) mmx_r2m(movq, reg, var)
^
<scratch space>:192:1: note: instantiated from:
"movq"
^
<inline asm>:1:2: note: instantiated into assembly here
movq %mm3, %dx
^
--------------------------------------------------
According to the clang developers this is a invalid inline assembly.
Using the attached patch from the last commit in the below bug report fixes the
compile.
More details from: http://llvm.org/bugs/show_bug.cgi?id=6730
Kees Bakker to sdl
The main.c for the template is still targeting SDL1.2. Here
is the patch to make it work for SDL1.3 (I'm hoping
the mailing lists accepts attachments.)
In this patch I have also changed the shell script that
assembles the Template. Since there is now only one lib
target (same name for "device" and "simulator" version)
I copy the simulator library to the destination with
the name libSDLSimulator.a. This is not a satisfactory
solution, because both libraries are included in the project
while only one is needed (depending on the selected
environment). However, I'm not fluent with Xcode to
say what a better solution would be.
Kind regards,
Kees Bakker
Joseba García Echebarria 2010-12-15 01:55:22 PST
I believe the crash is caused by a check not being performed on wether an
SDL_Touch element is NULL before using it in the SDL_SendTouchMotion function
in src/events/SDL_touch.c around line 400.
Judging from the rest of the code, there's a missing
if (!touch) {
return 0;
}
before using "touch" as SDL_GetFinger(), SDL_GetFingerIndexId() use
touch->num_fingers without checking.
I can attach a patch if you like. It seems pretty straightforward, though.
I have yet to discover why touch is being returned as NULL as this error is
only triggered when an actual gesture has been performed, maybe something
related to SDL_AddTouch()?
Common.c now destroys the SDL_Window upon a SDL_WINDOWEVENT_CLOSE event to ensure that all windows get closed properly and the new code to handle the last window closes gets executed.
when .cc files are used due to bad sed substitution on multiple passes:
$(objects)/SDL_BeApp.lo:
$(objects)/SDL_BeApp.lo: ./src/main/beos/SDL_BeApp.c
$(LIBTOOL) --mode=compile $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c $< -o $@c
$(LIBTOOL) --mode=compile $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c $< -o $@
Signed-off-by: François Revol
The new timer model is formalized as using a separate thread to handle timer callbacks. This was the case on almost every platform before, but it's now a requirement, and simplifies the implementation and makes it perform consistently across platforms.
Goals:
* Minimize timer thread blocking
* Dispatch timers as accurately as possible
* SDL_AddTimer() and SDL_RemoveTimer() are completely threadsafe
* SDL_RemoveTimer() doesn't crash with a timer that's expired or removed
the pthread implementation of SDL_SemWaitTimeout() uses busy waiting, while
pthread's sem_timedwait() does work. Attached are patches that make use of it
The SDL_blendmode.h and SDL_scalemode.h headers needed to be added to the Public Headers and all the public headers need to have the "Public" role set.
Markus Rathgeb 2011-01-23 14:34:23 PST
With kernel 2.6.31 the struct input_absinfo defined in linux/input.h changed.
A field "__s32 resolution" was added at the end of the struct.
Because the macro EVIOCGABS(abs) is using the struct input_absinfo, it would be
better (IMHO) to change the declaration of variable values to
"int values[sizeof(struct input_absinfo) / sizeof(int)];" or using "struct
input_absinfo" directly.
Daniel Ellis 2010-06-25 15:20:31 PDT
SDL based applications sometimes display the wrong application name in the
Sound Preferences dialog when using pulseaudio.
I can see from the code that the SDL pulse module is initiating a new pulse
audio context and passing an application name using the function
get_progname().
The get_progname() function returns the name of the current process. However,
the process name is often not a suitable name to use. For example, the OpenShot
video editor is a python application, and so "python" is displayed in the Sound
Preferences window (see Bug #596504), when it should be displaying "OpenShot".
PulseAudio allows applications to specify the application name, either at the
time the context is created (as SDL does currently), or by special environment
variables (see http://www.pulseaudio.org/wiki/ApplicationProperties). If no
name is specified, then pulseaudio will determine the name based on the
process.
If you specify the application name when initiating the pulseaudio context,
then that will override any application name specified using an environment
variable.
As libsdl is a library, I believe the solution is for libsdl to not specify any
application name when initiating a pulseaudio context, which will enable
applications to specify the application name using environment variables. In
the case that the applications do not specify anything, pulseaudio will fall
back to using the process name anyway.
The attached patch removes the get_progname() function and passes NULL as the
application name when creating the pulseaudio context, which fixes the issue.
