nanogui: does framebuffer driver make everything greenish ?
Subject:
Re: [nanogui] does framebuffer driver make everything greenish ?
From:
Wayne ####@####.####
Date:
1 Jul 2008 19:03:07 -0000
Message-Id: <486A7F60.9060801@zk.com>
Aveek Adhya wrote:
> Thanks Greg.
> I have given some printf within GdOpenScreen() to get those h/w information.
> It says:
>
> GdOpenScreen(): no of colors currently supported = 16777216 [psd->ncolors]
> No. of planes = 1 [psd->planes]
> bpp = 24 [psd->bpp]
> Size of memory allocated = 2764800 [psd->size]
> address of fb memory = 0x29558000 [psd->addr]
> etc....
>
> It also says that true color is used, not any palette.
>
> According to the h/w manufacturer the graphics chip used has 3 graphics
> plane and 1 cursor plane.
>
> Then why GdOpenScreen() is reporting there is only one plane?
> Does 'psd->planes' mean that graphics plane only or something else?
>
This is because you are using the wrong driver.
>
> As here is 3 graphics planes, might be one of the plane is filled with green
> color and causing the greenish effect on final display. Just guessing...
>
> Microwindow supports only one graphics plane. Can I get the control of other
> planes somehow? (just to clean other planes.... )
>
> Is it the limitation of frame buffer driver because of which Microwindows
> can't support more than one graphics plane?
>
I have not looked at it at all but the driver scr_svga.c looks like it
support svga hardware. svga uses multiple planes so you should be able
to use this as a basis to write a driver that supports you hardware.
> How is each graphics plane identified by the fb driver?
>
The fb driver relies on the Linux fb driver installed on your system. If
you Linux distribution includes a driver that properly supports you
hardware then you can go that route. As you can see from the information
you have supplied above your current configuration does not appear to be
correct.
> Regards,
> Aveek
>
>
>
>
