Frame buffer issues

I’ve been recently developing a library mostly intended to target frame buffer devices. I’ve found several issues in the frame buffer driver code.

My frame buffer is configured at 1600x1200. My application is requestion a display sized 800x600. Vesa frame buffer does not support resizing. SDL results in a window cenetered in the middle of the screen. When switching away from said virtual console, it saves the current image, and then switches the console, and later restores the image. The image buffer it allocates is 600 lines long (the size of the mode I requested) at the pitch of the screen (1600) so it ends up saving the top half of my screen (and the top half of what I drew) and restores that half when it exits. I went browsing for wheter the actual video size is anywhere, didn’t find it but came across screen->offset.

Proposed fix :
src/video/fbcon/SDL_fbevents.c switch_vt()

if( screen_contents ) {
// here is added "screen->offset"
memcpy( screen_contents, screen->pixels + screen->offset, screen_arealen );
}

and later when restored…

memcpy( scren->pixels + screen->offset, screen_contents, screen_arealen );

This was the easy issue to discuss…

My default, SDL does not detect which mouse I’m using correctly, if one specifies SDL_MOUSEDEV in their environemnt, then loads a program using SDL and fbcon - the open mouse code (at the end, default case) will open the device, and assign it as a Microsoft mouse. It does not check to see what (if any) SDL_MOUSEDRV was specified.

My proposed fix for this
(same file, FB_OpenMouse - at the end there is a fprintf…
fprintf( stderr, “Using Microsoft mouse on %s\n”, mousedev );

Replace that line with something like…
if( !strcmp( mousedrv, “PS2” ) )
{
mouse_drv=MOUSE_PS2;
#if DEBUG_MOUSE
fprintf( stderr, “Using (user specified) PS2 mouse on %s\n”, mousedev );
#endif
}
else
{
mouse_drv= MOUSE_MS;
#if DEBUG_MOUSE
fprintf( stderr, “Using Microsoft mouse on %s\n”, mousedev );}
#endif
}

Third, the modeline for 1600 by 1200 in Vesa mode has a 0 for timing information, thereby disabling that from being a valid mode.

I’m not sure how or why this timing is used… but here are some parameters from my nVidia geforce 4 1600x1200x16bit
(SDL_fbvideo.c)

  1600, 1200, 6208, 200, 32, 16, 4, 200, 4, 0, 0

Would appreciate if somehow these changes could wander into the next release.

Jim

www.d3x0r.org

Proposed fix :
src/video/fbcon/SDL_fbevents.c switch_vt()

if( screen_contents ) {
// here is added "screen->offset"
memcpy( screen_contents, screen->pixels + screen->offset,
screen_arealen );
}

and later when restored…

memcpy( scren->pixels + screen->offset, screen_contents,
screen_arealen );

Actually I would suggest that the restore be replaced with

SDL_UpdateRect( SDL_GetVideoSurface(), 0, 0, 0, 0 );

Then the surface doesn’t have to be imaged into memory, and the current
drawn state can be directly output…

but maybe that only works with the particular frame buffer modes I’m working
with… but since all drawing operations end up working anyhow, they’re
already somewhere - (tried tracking that place down to use that directly in
the Update there - but failed… )

A while ago I sent two messages about frame buffer issues - mouse problems, and locks - never heard any feedback… are these reasonable changes? Or am I to maintain my own tree?----- Original Message -----
From: Jim
To: sdl at libsdl.org
Sent: Friday, February 07, 2003 3:21 PM
Subject: [SDL] Frame buffer issues

I’ve been recently developing a library mostly intended to target frame buffer devices. I’ve found several issues in the frame buffer driver code.

My frame buffer is configured at 1600x1200. My application is requestion a display sized 800x600. Vesa frame buffer does not support resizing. SDL results in a window cenetered in the middle of the screen. When switching away from said virtual console, it saves the current image, and then switches the console, and later restores the image. The image buffer it allocates is 600 lines long (the size of the mode I requested) at the pitch of the screen (1600) so it ends up saving the top half of my screen (and the top half of what I drew) and restores that half when it exits. I went browsing for wheter the actual video size is anywhere, didn’t find it but came across screen->offset.

Proposed fix :
src/video/fbcon/SDL_fbevents.c switch_vt()

if( screen_contents ) {
// here is added "screen->offset"
memcpy( screen_contents, screen->pixels + screen->offset, screen_arealen );
}

and later when restored…

memcpy( scren->pixels + screen->offset, screen_contents, screen_arealen );

This was the easy issue to discuss…

My default, SDL does not detect which mouse I’m using correctly, if one specifies SDL_MOUSEDEV in their environemnt, then loads a program using SDL and fbcon - the open mouse code (at the end, default case) will open the device, and assign it as a Microsoft mouse. It does not check to see what (if any) SDL_MOUSEDRV was specified.

My proposed fix for this
(same file, FB_OpenMouse - at the end there is a fprintf…
fprintf( stderr, “Using Microsoft mouse on %s\n”, mousedev );

Replace that line with something like…
if( !strcmp( mousedrv, “PS2” ) )
{
mouse_drv=MOUSE_PS2;
#if DEBUG_MOUSE
fprintf( stderr, “Using (user specified) PS2 mouse on %s\n”, mousedev );
#endif
}
else
{
mouse_drv= MOUSE_MS;
#if DEBUG_MOUSE
fprintf( stderr, “Using Microsoft mouse on %s\n”, mousedev );}
#endif
}

Third, the modeline for 1600 by 1200 in Vesa mode has a 0 for timing information, thereby disabling that from being a valid mode.

I’m not sure how or why this timing is used… but here are some parameters from my nVidia geforce 4 1600x1200x16bit
(SDL_fbvideo.c)

    1600, 1200, 6208, 200, 32, 16, 4, 200, 4, 0, 0

Would appreciate if somehow these changes could wander into the next release.

Jim

www.d3x0r.org

A while ago I sent two messages about frame buffer issues - mouse problems, and locks - never heard any feedback… are these reasonable changes? Or am I to maintain my own tree?

Go ahead and submit a patch. They looked good, but I’ll have to review them
before adding them to CVS.

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