nanogui: does framebuffer driver make everything greenish ?
Subject:
RE: [nanogui] does framebuffer driver make everything greenish ?
From:
"Aveek Adhya" ####@####.####
Date:
5 Jul 2008 08:37:14 -0000
Message-Id:
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: ####@####.####
:
:
