I was finally able to play full-screen MPEG video with SDL…
Cool!
Yay! 
How can I determine if the hardware supports buffer flipping ?
Use SDL 0.9.x, and call SDL_GetVideoInfo() and look for both hw_available
caps and enough video memory. Alternatively, put SDL_HWSURFACE and
SDL_DOUBLEBUF in the video mode flags and if they are both set when
you return, then you have page flipping. This is the most reliable
method because setting up page flipping may fail transparently for
other reasons.
Now, assuming I know that my hardware does not support
buffer flipping, is there a way to write directly in the
frame buffer ?
Yes, use the SDL_HWSURFACE flag when setting the video mode.
I don’t recommend this because each video memory access has to go
out over the PCI bus, at much slower than RAM speeds. In almost
every case with newer video hardware, it’s much faster to generate
the image in RAM and then blit it to the video memory at once.
SDL takes advantage of hardware acceleration in this case, as well.
(The Matrox Millennium supports RAM -> VRAM acceleration, as well
as most other bus-mastering video cards, I think)
I could not find it. It seems that if I do not flip or
update the screen, the display is not updated, i.e. my
screen surface is not the actual display. Is there a way
to avoid that copy to the display ?
Yup, use SDL_HWSURFACE. If that flag is set in the screen surface
that is returned, you are updating the visible display area directly.
You’ll still need to lock the surface however.
Does SDL_SetVideoMode() allocate any memory ?
Yes.
If yes, how can I “UnsetVideoMode” i.e. release any memory
that was allocated by SDL_SetVideoMode() and return to the
same state as immediately after calling SDL_Init() ?
Either call SDL_Quit(), or set another video mode.
There’s currently no way to say “go to initial state”
Our application is relyingheavily on “select()” to listen to several
pipes/fd for events/messages. Somehow I will have to listen
to the SDL events with select()…
Will it work if I create a new thread that reads SDL events
(and notify the application by writing something in a pipe
that will be listen to by the select) ?
Yes. You’ll need to define “THREADED_EVENTS” when building SDL to
make the event queue thread-safe, but this should work okay.
Hum, actually, after looking at the code, it looks like I need to
do a little bit of tweaking to make it work exactly the way you want.
I’ll work on it.
In other words, is it OK to call the SDL event routines in
a separate thread from the thread that calls the video routines ?
I am affraid I cannot do any other way…
Yup.
You’ll experience scheduling delay in the events (~10-50 ms), but
as long as you don’t need real-time event delivery, you should be
okay.