I’m working with an SDL app that runs on the STPC Atlas under Linux
using the framebuffer driver provided by stpc.
stpcfb has the wonderfull quality that it actually tries to set the
video mode when you do a mode check. So when SDL scans the video modes
for resolution and color depth support the screen goes crazy until my
requested video mode is set. In some cases it can crash the GPU.
Obviously this is a driver flaw but until I get the driver fixed is
there a non-hack-the-source method of disableing the color depth and
resolution searching that SDL does when you init the screen?
For example I want SDL to only attempt to set 1024x768x24 and thats it.–
Richard A. Smith
@Richard_Smith
I’m working with an SDL app that runs on the STPC Atlas under Linux
using the framebuffer driver provided by stpc.
stpcfb has the wonderfull quality that it actually tries to set the
video mode when you do a mode check. So when SDL scans the video modes
for resolution and color depth support the screen goes crazy until my
requested video mode is set. In some cases it can crash the GPU.
Obviously this is a driver flaw but until I get the driver fixed is
there a non-hack-the-source method of disableing the color depth and
resolution searching that SDL does when you init the screen?
For example I want SDL to only attempt to set 1024x768x24 and thats it.
You might want to fill an fb.modes file (with only one video mode) and try my fb.modes parser patch :
http://twomix.devolution.com/pipermail/sdl/2004-May/062176.html
Stephane
Stephane Marchesin wrote:
there a non-hack-the-source method of disableing the color depth and
resolution searching that SDL does when you init the screen?
You might want to fill an fb.modes file (with only one video mode) and try my fb.modes parser patch :
http://twomix.devolution.com/pipermail/sdl/2004-May/062176.html
That falls into the hack-the-source catagory. Will source changes be
the only way?
I’d like to be able to use stock (debian) packages if possible.
I guess if the patch works you can roll it into mainstream.
I’ll give it a whirl in the next few days or so.
Richard Smith wrote:
Stephane Marchesin wrote:
there a non-hack-the-source method of disableing the color depth and
resolution searching that SDL does when you init the screen?
You might want to fill an fb.modes file (with only one video mode)
and try my fb.modes parser patch :
http://twomix.devolution.com/pipermail/sdl/2004-May/062176.html
Hmmm… On second though, it seems that it won’t work.
That falls into the hack-the-source catagory. Will source changes be
the only way?
I’m quite sure there’s no way without hacking the source.
Stephane
I’m quite sure there’s no way without hacking the source.
Also, I should add that a quick way to get the desired effect is to
#define BROKEN_MODES on top of the SDL_fbvideo.c file.
Stephane
Stephane Marchesin wrote:
and try my fb.modes parser patch :
http://twomix.devolution.com/pipermail/sdl/2004-May/062176.html
Hmmm… On second though, it seems that it won’t work.
Ok well then I won’t bother testing it. 
Stephane Marchesin wrote:
I’m quite sure there’s no way without hacking the source.
Also, I should add that a quick way to get the desired effect is to
#define BROKEN_MODES on top of the SDL_fbvideo.c file.
Ah yes, I see that looks like that will do what I need. Curious as to
why this is a #define and not an enviroment variable like the other
settings.
I would think that finding cards (or chips) with broken modes would be
the norm rather than the execption.
Also, I should add that a quick way to get the desired effect is to
#define BROKEN_MODES on top of the SDL_fbvideo.c file.
Ah yes, I see that looks like that will do what I need. Curious as to
why this is a #define and not an enviroment variable like the other
settings.
I would think that finding cards (or chips) with broken modes would be
the norm rather than the execption.
Good point. It’ll be the environment variable "SDL_FB_BROKEN_MODES"
in the next release.
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment