This version contains a number of framebuffer console driver improvements:
1.0.2: Added GPM repeater support (gpm -R) to fbcon driver
1.0.2: Implemented console switching in fbcon driver
1.0.2: Implemented graphics mode detection in fbcon driver
If you have a non PS/2 mouse, you can now use it with the SDL framebuffer
console driver by running GPM with the -R option.
The latest framebuffer console driver also allows console switching using the
standard Alt-FN keys. This probably doesn’t work properly with multithreaded
programs, as only the event handling thread blocks while the console is switched
away. Solutions are welcome.
Also, if you have a framebuffer console driver that support dynamic video
mode switching (e.g. Matrox, etc.) then SDL now makes those modes available
and switches to them when requested. This has only been tested on a Matrox
Millenium I, so I’m interested in feedback on other cards.
The problem with the screen contents not being refreshed on exit is still there.
I’ve tries explicitly calling the hacks in the kernel console driver to refresh
the screen, but that doesn’t work either. Switching to another console and back
fixes the text display, but I suspect there is a bug in the vt/console driver.
Thanks to the Clanlib and GGI code, I’ll probably have hardware acceleration for
the Matrox video card on the framebuffer console soon.
Also, if you have a framebuffer console driver that support dynamic video
mode switching (e.g. Matrox, etc.) then SDL now makes those modes available
and switches to them when requested. This has only been tested on a Matrox
Millenium I, so I’m interested in feedback on other cards.
yes, video mode switching works on the G200, too … sort of
Requesting a 640x480 and 1024x768 worked ok.
But when requesting 800x600 the picture looked cut on the side.
Why? The monitor pic was not centered!
My request is a
screen = SDL_SetVideoMode(w, h, 0, SDL_SWSURFACE|SDL_ANYFORMAT);
My console runs default 800x600 @ 100Hz.
Requesting 800x600 from SDL initiates a mode switch to 800x600 @ 72 Hz.
Why switch videomode when the one requested is already in use ?
(and losing precious 100Hz…)
Follow up question:
How do I find the current running video mode size? My app likes whatever
is running now. Looking in the docs, SDL_GetVideoInfo only returns a vmt
with the pixel format. Giving vmt to SDL_ListModes returns all possible
modes, … but how do I determine the currently running one?
(My idea: When running unter fbcon take running video mode and utilize
full screen. When started from X take current pixel format and make
window size half/third/whatever of full screen size.)
Follow up question:
How do I find the current running video mode size? My app likes whatever
is running now. Looking in the docs, SDL_GetVideoInfo only returns a vmt
with the pixel format. Giving vmt to SDL_ListModes returns all possible
modes, … but how do I determine the currently running one?
The video mode for FBCON is whatever your FB console is currently set
to. It cannot switch, so the driver simply asks for the current
resolution and creates a clipping region centered in the screen.
(My idea: When running unter fbcon take running video mode and utilize
full screen.
That’s what it currently does. You can ask the kernel what size the
current framebuffer is the same way the FBCON driver does; I don’t have
the code in front of me at the moment. If you want to check whether a
particular screen size is currently in use (“I requested 1024x768, is
that what I got?”) you can call SDL_VideoModeOK().
When started from X take current pixel format and make
window size half/third/whatever of full screen size.)
That would sort of break the whole idea. The X driver uses DGA if
available to utilize fullscreen mode. If not, it simply allocates a
window of the size requested (up to the current server resolution).
That’s what it currently does. You can ask the kernel what size the
current framebuffer is the same way the FBCON driver does; I don’t have
the code in front of me at the moment. If you want to check whether a
particular screen size is currently in use (“I requested 1024x768, is
that what I got?”) you can call SDL_VideoModeOK().
I don’t want to mess with the kernel. I want to know that from SDL.
I want to know the current size before calling SetVideoMode.
I don’t want to check what I got afterwards.
(Remember, I don’t care about bpp)
error: bad english, too many "want"s …
When started from X take current pixel format and make
window size half/third/whatever of full screen size.)
That would sort of break the whole idea. The X driver uses DGA if
available to utilize fullscreen mode. If not, it simply allocates a
window of the size requested (up to the current server resolution).
DGA would be raw access to the framebuffer ?
I thought that’s a HWSURFACE, I’m requesting a SWSURFACE, so I’ll
always get a window in X ?
Also, if you have a framebuffer console driver that support dynamic video
mode switching (e.g. Matrox, etc.) then SDL now makes those modes available
and switches to them when requested. This has only been tested on a Matrox
Millenium I, so I’m interested in feedback on other cards.
yes, video mode switching works on the G200, too … sort of
Requesting a 640x480 and 1024x768 worked ok.
But when requesting 800x600 the picture looked cut on the side.
Why? The monitor pic was not centered!
This is because your monitor is already set to the 100 Hz mode, and the
timings for the 800x600 mode slide it over. You can use your monitor
controls to slide it back over. I’ll check the current mode in future
releases.
Eventually, I’ll add code to parse /etc/fb.modes and load timing information
from that. I’m currently using the default mode timings that come with the
matrox video driver.
Follow up question:
How do I find the current running video mode size? My app likes whatever
is running now. Looking in the docs, SDL_GetVideoInfo only returns a vmt
with the pixel format. Giving vmt to SDL_ListModes returns all possible
modes, … but how do I determine the currently running one?
Well, this isn’t usually meaningful information, so I haven’t made it available.
You should choose your favorite from the available modes, and if you
choose the current one, it will not switch modes.
This is because your monitor is already set to the 100 Hz mode, and the
timings for the 800x600 mode slide it over. You can use your monitor
controls to slide it back over. I’ll check the current mode in future
releases.
yeah, sure, but I was already pondering at what point my prog. calculates
the offset wrong, I just didn’t think about the easy bugs
Follow up question:
How do I find the current running video mode size? My app likes whatever
is running now. Looking in the docs, SDL_GetVideoInfo only returns a vmt
with the pixel format. Giving vmt to SDL_ListModes returns all possible
modes, … but how do I determine the currently running one?
Well, this isn’t usually meaningful information, so I haven’t made it available.
You should choose your favorite from the available modes, and if you
choose the current one, it will not switch modes.
Well, usually, yes.
But any video mode switch is not 100% safe.
Therefor I prefer the mode already running, machine surely was setup that
this mode looks perfect.
Switching video mode resulting in a wrong picture not every user is able to
figure out what’s wrong.
IMHO.
