The API specifies that SDL_OpenAudio() will fill out the 'desired' audio spec
with the correct samples and size set by the driver. This value is important
since it may be used by applications that size audio buffers, etc.
However, we want to allow advanced applications to call SDL_OpenAudioDevice()
which gets passed a const 'desired' parameter, and have the correct data filled
into the 'obtained' parameter, possibly allowing or not allowing format changes.
So... 'obtained' becomes the audio format the user callback is expected to use,
and we add flags to allow the application to specify which format changes are
allowed.
Note: We really need to add a way to query the 'obtained' audio spec.
From: Couriersud
Subject: SDL: Mouse last_x, last_y into SDL_Mouse
the attached diff moves the static vars last_x and last_y into
SDL_Mouse. These, as far as I understand it, should be tied to the
individual mouse.
The patch also makes the code check for out of window conditions of
mouse->x,y when relative movements are passed to MouseSendMotion.
Also attached is the latest DirectFB code (dfb20081208) supporting
multiple mice and keyboards. This works quite well with sdlmame now. It
however needs more testing with different directfb configurations.
correct value for YUV textures. Yay!
I'm still cheering for Ryan's pixel shader instead, since once it works
different shaders can handle all the YUV formats.
From: Couriersud
Subject: SDL: Relative mouse movements
The patch below will reenable processing of relative mouse movements.
The DirectFB drivers generates those in "grabbed" mode. These ensure,
that even in fullscreen mode relative movements are reported. SDLMAME
depends on this for games with trackballs.
Looking at the code I ask myself whether relative movements should be
handled in the drivers (x11, directfb). Both x11 and directfb are able
to report relative movements. This would leave it to the driver to use
the most appropriate method for relative movements when at the border of
a fullscreen window or being "grabbed".
