Fullscreen "toggle" in fbcon

SDL Development
1

Is there any reason we can’t pretend that SDL_WM_ToggleFullScreen()
succeeded in the fbcon driver? I’ve got Candy Cruncher using this API to
toggle fullscreen/window, and falling back on recreating the screen
surface from scratch if it fails, which works well enough, but it’s less
overhead (and prettier to watch) if SDL_WM_ToggleFullScreen() works.

Here is a patch to make the fbcon driver pretend that a fullscreen toggle
worked.

–ryan.

Index: src/video/fbcon/SDL_fbvideo.c===================================================================
RCS file: /home/slouken/libsdl.org/cvs/SDL12/src/video/fbcon/SDL_fbvideo.c,v
retrieving revision 1.7
diff -u -r1.7 SDL_fbvideo.c
— src/video/fbcon/SDL_fbvideo.c 2001/12/14 12:38:14 1.7
+++ src/video/fbcon/SDL_fbvideo.c 2002/02/17 00:42:22
@@ -144,6 +144,7 @@
static void FB_WaitVBL(_THIS);
static void FB_WaitIdle(_THIS);
static int FB_FlipHWSurface(_THIS, SDL_Surface *surface);
+static int FB_ToggleFullScreen(_THIS, int on);

/* Internal palette functions */
static void FB_SavePalette(_THIS, struct fb_fix_screeninfo *finfo,
@@ -221,6 +222,7 @@
this->GetWMInfo = NULL;
this->InitOSKeymap = FB_InitOSKeymap;
this->PumpEvents = FB_PumpEvents;

  • this->ToggleFullScreen = FB_ToggleFullScreen;

    this->free = FB_DeleteDevice;

@@ -1109,6 +1111,11 @@

surface->pixels = flip_address[flip_page];
return(0);

+}
+
+static int FB_ToggleFullScreen(_THIS, int on)
+{

  • return(1); /* pretend this succeeded. */
    }

static void FB_DirectUpdate(_THIS, int numrects, SDL_Rect *rects)

2

Is there any reason we can’t pretend that SDL_WM_ToggleFullScreen()
succeeded in the fbcon driver?

We can actually do it at a higher level so that if a toggle function
doesn’t exist in the driver we can pretend it succeeds…

Can anybody think of any reason not to do this?

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

3

We can actually do it at a higher level so that if a toggle function
doesn’t exist in the driver we can pretend it succeeds…

My thought was that most drivers SHOULD fail…fbcon is always fullscreen,
though, so it made sense there.

–ryan.

4

We can actually do it at a higher level so that if a toggle function
doesn’t exist in the driver we can pretend it succeeds…

My thought was that most drivers SHOULD fail…fbcon is always fullscreen,
though, so it made sense there.

So you’re saying that drivers that can be both windowed and fullscreen
but can’t do a real fullscreen toggle should fail the call, so the app
can set a new video mode, but that drivers that are only fullscreen or
only windowed should always succeed?

Makes sense… Comments?
-Sam Lantinga, Software Engineer, Blizzard Entertainment

5

“Sam Lantinga” wrote in message
news:mailman.1013967303.26758.sdl at libsdl.org…

Is there any reason we can’t pretend that
SDL_WM_ToggleFullScreen()

succeeded in the fbcon driver?

We can actually do it at a higher level so that if a toggle function
doesn’t exist in the driver we can pretend it succeeds…

Can anybody think of any reason not to do this?

It’s somewhat dishonest.

There are three possible situations:

  1. No separate window and full-screen modes available.
  2. Both modes available, switchable by ‘SDL_WM_ToggleFullScreen’.
  3. Both modes available, only switchable by ‘SDL_SetVideoMode’.

All three are logically distinct. For example, if a program includes
a menu option to switch between windowed and full-screen mode, it
should be disabled in situation 1. I think situation 1 can already be
detected through
’SDL_GetVideoInfo()->wm_available’:

if (SDL_GetVideoInfo()->wm_available) {
if (!SDL_WM_ToggleFullScreen()) {
/* need to use SDL_SetVideoMode /
}
} else {
/ no windowed mode, so nothing to toggle */
}

However, I have to admit that it is more convenient to group situation
1 with situation 2 for the return value of ‘SDL_WM_ToggleFullScreen’.
Maybe it would make sense to introduce another return value that means
"I didn’t really do anything, but don’t bother trying
’SDL_SetVideoMode’ either"?–
Rainer Deyke | root at rainerdeyke.com | http://rainerdeyke.com

6

It’s somewhat dishonest.

That’s a good point, actually.

Is there any place where the wm_available flag wouldn’t be reliable for
this sort of thing?

–ryan.