We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 280 - Problems with the ggi output driver under linux fbdev
Summary: Problems with the ggi output driver under linux fbdev
Status: RESOLVED WONTFIX
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 1.2
Hardware: x86 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-14 15:06 UTC by Sean d'Epagnier
Modified: 2006-09-23 21:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sean d'Epagnier 2006-07-14 15:06:32 UTC
Hi, I have been taking a look at SDL lately, and I have tested the latest
SDL with the latest GGI and have found a few problems.

All my tests use linux fbdev, I have an
 amd64 system.
I have not done extensive research into the code, but I have found that it

initializes the graphics twice, once in SDL_Init, and again in
 CreateScreen.
I believe this is a mistake, as it uses GGI_AUTO for all values the first time,
and the second time the values are based on the first run.  The result is,
the program does not switch bit depth when it
could.  Perhaps there is a
reason for this?  with SDL_VIDEODRIVER=fbdev
the test program test/graywin
switches bit depth, but with ggi it does
not.  It uses the current bit depth
and it displays a black screen if my initial bit depth is 8.
 Right now the
only bit depth that works correctly is 16.  My cards do not support 24bpp,
and with 32 I think the program obviously is writing 24bpp data to 32bpp memory.
This is because exactly the left 3/4ths of the
 screen displays a somewhat
grayscaled image (but it is clear there is
color) This is true as well
when using mplayer with -vo sdl and
 SDL_VIDEODRIVER=ggi

 Another major problem I have run into is when running on a linux terminal,
ggiOpen attempts to use linux-kbd to read input instead of stdin.  The

issue here is it locks up the program and it does not continue to
function.
I do not know SDL well enough, but I believe SDL tries to open the same
device and blocks.  The only way around this I have found is to set
the environment variable GGI_DISPLAY=fbdev:-noinput or to run the

program from within screen (ggi in this case uses stdin since it can't
 open linux-kbd) This is not a problem for ggi programs that are not using SDL.
I think this means there is a bug in the input drivers when using ggi somewhere,
it should get all it's input from ggi.

libggi uses FRAMEBUFFER to determine the framebuffer device to use and
defaults to /dev/fb0 if not set.  libSDL uses SDL_FBDEV, I think the

environment variable should be forwarded from the SDL variable to the ggi
variable.


SDL crashes in SDL_Quit when using ggi, this isn't the worst problem,
but it does cause the program to shutdown unclean, and does not restore the

video mode or terminal settings.  If I run the test program test/graywin:

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaaf9f746 in free () from /lib/libc.so.6
(gdb) bt
#0  0x00002aaaaaf9f746 in free () from /lib/libc.so.6
#1  0x00002aaaaac080b3 in SDL_FreeSurface (surface=0x50b640)

     at SDL_surface.c:935
#2  0x00002aaaaac0b227 in SDL_VideoQuit () at SDL_video.c:1353
#3  0x00002aaaaabd39ce in SDL_QuitSubSystem (flags=65535) at SDL.c:200
#4  0x00002aaaaabd3a04 in SDL_Quit () at SDL.c:220
#5  0x0000000000401695 in main (argc=1, argv=0x7ffffff4f698) at graywin.c:259


I would like to find someone else who is willing to work on these problems,
and at first any of the errors they can produce as well we can try to fix.

Thanks,
Sean D'Epagnier
Comment 1 Sam Lantinga 2006-09-23 21:17:08 UTC
The GGI driver is no longer supported, but you're welcome to submit a patch for it.