nanogui: Thread: Arm device with 4bpp and planes==0

Hi,

I have an ARM device that works with 4bpp.  When I first ran the nano-X I got the message:

Unsupported 16 color (4 bpp) truecolor framebuffer

Cannot initialise screen
I check the code and found out that in ./drivers/scr_fb.c function fb_open, there is a need to deal with case 4.  so I added the lines:

        if(visual == FB_VISUAL_TRUECOLOR || visual == FB_VISUAL_DIRECTCOLOR) {
                switch(psd->bpp) {
                case 4:
                        psd->pixtype = MWPF_PALETTE;
                        break;
After doing that I got the message:

No driver for screen type 1 visual 4 bpp 4

Cannot initialise screen

So I found out that my device has psd->planes == 0 (I do not know what it means), so in ./drivers/fb.c select_fb_subdriver I added:

        if(psd->planes == 1 || psd->planes == 0) {
                switch(psd->bpp) {

After these two changes nano-X runs with no errors.  I ran the sample.c code but I got no output on the display, the log is:

[root@ebr oren]$ ./bin/nano-X & sleep 1 ; ./test/sample
start set cmap !
get cmap option !
0  100  200  300
set cmap ok
start set cmap !
get cmap option !
0  1100  2200  3300
set cmap ok
createfont: (height == 0) found builtin font System (0)
createfont: (height == 0) found builtin font System (0)


My questions are:
1. Are my two changes above correct?  Is there a better way to do that?
2. Can someone see what the problem is that the device display nothing on the screen?

Thanks,
Oren.


________________________________
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the ####@####.#### and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes.
To protect the environment please do not print this e-mail unless necessary.

An NDS Group Limited company. www.nds.com

On Thu, Jul 16, 2009 at 12:15:53PM +0300, Yair, Oren wrote:
> I have an ARM device that works with 4bpp.  When I first ran the
> nano-X I got the message:
> 
> Unsupported 16 color (4 bpp) truecolor framebuffer
> [...]
> So I found out that my device has psd->planes == 0 (I do not know what
> it means), so in ./drivers/fb.c select_fb_subdriver I added:

what OS are you running on your ARM platform?  if your framebuffer
driver is not showing any planes, this may indicate a bug in the
framebuffer device driver.

have you verified the framebuffer driver is working with something other
than nano-X?

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | ####@####.####

: what OS are you running on your ARM platform?  if your framebuffer
: driver is not showing any planes, this may indicate a bug in the
: framebuffer device driver.
: 
: have you verified the framebuffer driver is working with something other
: than nano-X?

It doesn't appear that's the problem...  instead the kernel is
reporting that the framebuffer is 4bpp truecolor, not palette,
which isn't supported by nano-X.  We do support 4bpp
graycolor, which IIRC doesn't use a pallete. I can't remember
what the framebuffer returns in this case, though.  The
greyscale src/drivers/scr_*.c linear drivers may not be
linked in though.

Oren, we need more information on exactly what the hardware
setup and supposed framebuffer setup is for your system.
Also, you need to grep through the scr_*.c drivers and 
find a truecolor grayscale driver, which might work for you.
In other words, what colors are displayed for each
combination of 4 bits in the framebuffer?

Regards,

Greg