nanogui: Thread: does framebuffer driver make everything greenish ?

Hi,
 I am running nano-x applications on a ST based target platform, where
nano-x is compiled with frame buffer driver support. But real problem is
everything is displayed with a greenish shade, even white color is displayed
as light green. There is no problem with h/w or any connector. What could be
the possible reason of this?

I don't think I am passing any wrong values for white color. All bits are
set to 1. In fact it is not only with white color, for every color there is
greenish shade.

Even at the time of boot up, kernel message are also displayed with green
text color on the TV/monitor screen. I think the default foreground color
set by frame buffer driver should be white (I am not sure whether fb driver
really set any default foreground color).

Is that frame buffer driver responsible for this greenish effect?

Is there any generic application (like fbset) to query the frame buffer
driver to get graphics h/w information (bpp, no. of graphics planes, alpha
support etc.) of my target system?

Regards,
Aveek

: Is there any generic application (like fbset) to query the frame buffer
: driver to get graphics h/w information (bpp, no. of graphics planes, alpha
: support etc.) of my target system?

fbset won't tell you this.  But look at the code in
microwindows' driver/scr_fb.c, this queries the framebuffer,
as well as deals with palette issues with the kernel.

It would help to know your framebuffer format, its hard
to guess an answer for you with so little information.  For
instance, on palettized displays, your problem is simple,
the master palette is incorrect.

If your kernel is booting and shows a greenish shade, then
its obvious the problem hasn't to do with microwindows, but
instead with your kernel config/fb setup.

Regards,

Greg 

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?
  
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?

How is each graphics plane identified by the fb driver?

Regards,
Aveek

  

-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Tuesday, July 01, 2008 1:33 AM
To: Aveek Adhya; ####@####.####
Subject: Re: [nanogui] does framebuffer driver make everything greenish ?

: Is there any generic application (like fbset) to query the frame buffer
: driver to get graphics h/w information (bpp, no. of graphics planes, alpha
: support etc.) of my target system?

fbset won't tell you this.  But look at the code in
microwindows' driver/scr_fb.c, this queries the framebuffer,
as well as deals with palette issues with the kernel.

It would help to know your framebuffer format, its hard
to guess an answer for you with so little information.  For
instance, on palettized displays, your problem is simple,
the master palette is incorrect.

If your kernel is booting and shows a greenish shade, then
its obvious the problem hasn't to do with microwindows, but
instead with your kernel config/fb setup.

Regards,

Greg 


---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####

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
>
>   
>
>   

: 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?

The fb driver is using one plane of 24 bits per pixel, three bytes
per color.  Simple, really.



:
: 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...

Not likely if you can see the image.  This means that the image is
displayed using the correct byte-order contents.

Like I mentioned earlier, if you boot the system and its
got a green tinge, then your kernel is not configured properly
for the display.


: Is it the limitation of frame buffer driver because of which Microwindows
: can't support more than one graphics plane?
:

If you're using the fb driver in microwindows, then yes it only
supports one plane.  You would have to write a special driver,
this would require a new kernel interface.  Lots of work.

Regards,

Greg



:
: Microwindow supports only one graphics plane. Can I get the control of 
other
: planes somehow? (just to clean other planes.... )
:: How is each graphics plane identified by the fb driver?
:
: Regards,
: Aveek
:
:
:
: -----Original Message-----
: From: Greg Haerr ####@####.####
: Sent: Tuesday, July 01, 2008 1:33 AM
: To: Aveek Adhya; ####@####.####
: Subject: Re: [nanogui] does framebuffer driver make everything greenish ?
:
:: Is there any generic application (like fbset) to query the frame buffer
:: driver to get graphics h/w information (bpp, no. of graphics planes, 
alpha
:: support etc.) of my target system?
:
: fbset won't tell you this.  But look at the code in
: microwindows' driver/scr_fb.c, this queries the framebuffer,
: as well as deals with palette issues with the kernel.
:
: It would help to know your framebuffer format, its hard
: to guess an answer for you with so little information.  For
: instance, on palettized displays, your problem is simple,
: the master palette is incorrect.
:
: If your kernel is booting and shows a greenish shade, then
: its obvious the problem hasn't to do with microwindows, but
: instead with your kernel config/fb setup.
:
: Regards,
:
: Greg
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:
: 

Thanx Greg.
I have discovered that the greenish effect was coming as I had selected YUV
color space while insmoding the frame buffer driver. When I select RGB then
the greenish effect disappear, but now I can see a very light red tinge
instead. So this problem might be due to color space. The parameter I am
passing while inserting the frame buffer module is as below:

modprobe stmfb display0=1280x720-24@60:10M:NTSC:RGB:RGB

Does it mean that now I am telling the FB driver module to fill with RGB
data for each pixel into frame buffer rather than YUV data? 

What can be the reason of red tinge now?

Regards,
Aveek

-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Wednesday, July 02, 2008 6:21 AM
To: Aveek Adhya; ####@####.####
Subject: Re: [nanogui] does framebuffer driver make everything greenish ?

: 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?

The fb driver is using one plane of 24 bits per pixel, three bytes
per color.  Simple, really.



:
: 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...

Not likely if you can see the image.  This means that the image is
displayed using the correct byte-order contents.

Like I mentioned earlier, if you boot the system and its
got a green tinge, then your kernel is not configured properly
for the display.


: Is it the limitation of frame buffer driver because of which Microwindows
: can't support more than one graphics plane?
:

If you're using the fb driver in microwindows, then yes it only
supports one plane.  You would have to write a special driver,
this would require a new kernel interface.  Lots of work.

Regards,

Greg



:
: Microwindow supports only one graphics plane. Can I get the control of 
other
: planes somehow? (just to clean other planes.... )
:: How is each graphics plane identified by the fb driver?
:
: Regards,
: Aveek
:
:
:
: -----Original Message-----
: From: Greg Haerr ####@####.####
: Sent: Tuesday, July 01, 2008 1:33 AM
: To: Aveek Adhya; ####@####.####
: Subject: Re: [nanogui] does framebuffer driver make everything greenish ?
:
:: Is there any generic application (like fbset) to query the frame buffer
:: driver to get graphics h/w information (bpp, no. of graphics planes, 
alpha
:: support etc.) of my target system?
:
: fbset won't tell you this.  But look at the code in
: microwindows' driver/scr_fb.c, this queries the framebuffer,
: as well as deals with palette issues with the kernel.
:
: It would help to know your framebuffer format, its hard
: to guess an answer for you with so little information.  For
: instance, on palettized displays, your problem is simple,
: the master palette is incorrect.
:
: If your kernel is booting and shows a greenish shade, then
: its obvious the problem hasn't to do with microwindows, but
: instead with your kernel config/fb setup.
:
: Regards,
:
: Greg
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:
: 

: Does it mean that now I am telling the FB driver module to fill with RGB
: data for each pixel into frame buffer rather than YUV data? 
:
Unfortunately, I know nothing of this driver, nor its command
line setup parameters.

 
: What can be the reason of red tinge now?

Probably setup issues, since it was green.

Regards,

Greg

Is there a literature to read and understand all about Frame buffer and associated tools - in application perspective.....

The registers, the communication to Device, What happens and when?

Thanks





--- On Sat, 7/5/08, Greg Haerr ####@####.#### wrote:

> From: Greg Haerr ####@####.####
> Subject: Re: [nanogui] does framebuffer driver make everything greenish ?
> To: "Aveek Adhya" ####@####.#### ####@####.####
> Date: Saturday, July 5, 2008, 12:15 PM
> : Does it mean that now I am telling the FB driver module to
> fill with RGB
> : data for each pixel into frame buffer rather than YUV
> data? 
> :
> Unfortunately, I know nothing of this driver, nor its
> command
> line setup parameters.
> 
>  
> : What can be the reason of red tinge now?
> 
> Probably setup issues, since it was green.
> 
> Regards,
> 
> Greg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail:
> ####@####.####


      

: Is there a literature to read and understand all about Frame buffer and 
associated tools - in application perspective.....
:
: The registers, the communication to Device, What happens and when?

Did you take a second to google for it?

http://www.google.com/search?hl=en&q=framebuffer+linux&btnG=Google+Search

Regards,

Greg 

Yes .. There are many and describe several aspects.  It doesnot give a total pitcture I am looking for.

Thank you



--- On Sat, 7/5/08, Greg Haerr ####@####.#### wrote:

> From: Greg Haerr ####@####.####
> Subject: Re: [nanogui] does framebuffer driver make everything greenish ?
> To: ####@####.#### ####@####.####
> Date: Saturday, July 5, 2008, 11:52 PM
> : Is there a literature to read and understand all about
> Frame buffer and 
> associated tools - in application perspective.....
> :
> : The registers, the communication to Device, What happens
> and when?
> 
> Did you take a second to google for it?
> 
> http://www.google.com/search?hl=en&q=framebuffer+linux&btnG=Google+Search
> 
> Regards,
> 
> Greg 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail:
> ####@####.####