nanogui: mw-0.91 to current tarball, white is blue?


Previous by date: 2 Jun 2011 16:22:37 -0000 Re: New to Nano-X: Font problems, Franco Benedetti
Next by date: 2 Jun 2011 16:22:37 -0000 Re: mw-0.91 to current tarball, white is blue?, Joseph Lopes
Previous in thread: 2 Jun 2011 16:22:37 -0000 Re: mw-0.91 to current tarball, white is blue?, Joseph Lopes
Next in thread: 2 Jun 2011 16:22:37 -0000 Re: mw-0.91 to current tarball, white is blue?, Joseph Lopes

Subject: Re: [nanogui] mw-0.91 to current tarball, white is blue?
From: "Greg Haerr" ####@####.####
Date: 2 Jun 2011 16:22:37 -0000
Message-Id: <0db801cc2141$4627b520$6964a8c0@winXP>

> GrFillRect(win, gc, x, y, w, (h));
> all have the same collor problem as GrCopyArea.

Joseph -

Not sure how to start on this.  It seems you're saying that all
drawing is incorrect, using the wrong colors for certain colors.
Lets take the most simple program, one that draws white
square using GrFillRect on a portion of a window who's
background is black.  You're saying the white will appear
blue.

We need to see what the pixel value is for the color used
in this instance.  You can put a debug printf() statement in the
fblin16.c  driver, at the linear16_drawhorzline entry point, print
the MWPIXELVAL c value.  It will be 0 for the black
line draws, and should be 0xff (all bits on) for the white
values.  If drawing 0xff results in blue, then it's a hardware
issue.  If the value isn't 0xff, then we need to look at the
code in engine/devopen.c::GdFindColor(), where an
MWCOLORVAL (white == 0xFFFFFFFF) is converted
to a pixel value (0xFFFF).

Another option would be to see whether this problem
persists in 0.92.  I'm thinking there could be a color
macro error in 0.93pre, the above would help find it.

Regards,

Greg





> pix_map = GrNewPixmap(LCD_WIDTH_V(), LCD_HEIGHT_V(), NULL);
> GrText(win, gc, x, y, text, strlen(text), GR_TFTOP);
> GrCopyArea(lcd_win, pix_gc, x, y, w, h, pix_map, x, y, MWROP_COPY);
> GrFillRect(win, gc, x, y, w, (h));
> to mainly draw white text in black rectangles,  with popup rectangles of
> blue boarders, white centers,
> black text.
> the screen name is a red rectangle with white text.
> Yes background and foreground fills work, as does drawing text, it is only
> the color which is off, red is "a green",blue is light blue is pink, white
> is dim and grey-blueish.

Joseph - I'm thinking that this bug is relating to drawing
on the offscreen pixmap, pix_map, above, and then the
following GrCopyArea.  In v0.93, there are new
routines that implement the GrCopyArea blit which
could be copying bad values.

So, I'm interested in knowing whether only the colors
transferred using GrCopyArea are incorrect, or whether
other colors drawn directly to the window are also incorrect.

Regards,

Greg







>What is the exact layout of your truecolor framebuffer, for each 16 bit
>word?

fbset gives:
mode "240x320-0"
    # D: 0.000 MHz, H: 0.001 kHz, V: 0.003 Hz
    geometry 240 320 240 320 16
    timings -1 -1 -1 -1 -1 -1 -1
    rgba 5/11,6/5,5/0,0/0
endmode

the driver is set with:

/*  IPU Pixel format definitions */
/*  Four-character-code (FOURCC) */
#define fourcc(a, b, c, d)\
        (((__u32)(a)<<0)|((__u32)(b)<<8)|((__u32)(c)<<16)|((__u32)(d)<<24))


#define IPU_PIX_FMT_RGB565  fourcc('R', 'G', 'B', 'P') /*!< 1 6  RGB-5-6-5
*/


static void mxcfb_init_panel (struct fb_info *fbi)
{
uint32_t pix_fmt = IPU_PIX_FMT_RGB565;


And all of this remains the same when I load the old 0.91 nano-X binary, and
it will be OK.

(to be clear I can rebuild the 0.91 code in the same toolchain and it is
fine, not a build tool issue)

Thanks,

j. lopes


-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Thu 5/26/2011 12:54 PM
To: Joseph Lopes; ####@####.####
Subject: Re: [nanogui] mw-0.91 to current tarball, white is blue?

> define MWPIXEL_FORMAT  MWPF_TRUECOLOR565 in mwtypes.h

What did you set MWPF_PIXELFORMAT to in the config file?
The above is supposed to be set in config only, not mwtypes.h.



> #if MWPIXEL_FORMAT == MWPF_PALETTE
                        colorval = GETPALENTRY(gr_palette, pixelval);
#else
                        colorval = PIXEL565TOCOLORVAL(pixelval);
#endif

and

> #if MWPIXEL_FORMAT == MWPF_PALETTE
                        *(MWPIXELVALHW *)outbuf =
GdFindNearestColor(gr_palette,
                                        gr_palsize, colorval);
#else
                        *(MWPIXELVALHW *)outbuf = COLOR2PIXEL565(colorval);
#endif
> in devdraw.c

These mods are in GdTranslateArea, which IIRC isn't actually
called or used.

> Building went OK, no problems.  But when I run nano-X the whites are light
> blue, red is a greenish
> grey, and the display is dim.

What exactly is drawing those colors?  Are you drawing images, or text,
or pure background colors?  I'm trying to understand the engine routines
called, image, fillrect, or text.

I'm not sure what the problem is yet.  It would be interesting to know
whether solid background fills work, (many demos do this), as well
as text or line draw colors, or whether the problem is just when
drawing images.  The image drawing routines have changed greatly,
and use convblit functions which may need changing.  Older
point-by-point drawing can be done by setting convblit = NULL
in GdDrawImage for instance, which will force the older slow methods.

What is the exact layout of your truecolor framebuffer, for each 16 bit
word?

Regards,

Greg





Simply reload my 0.91 build will correct the color problem.

I have hunted around but I seem alone on this one,  the PSD struct members
appear to be the same settings on each build, as they should be:

92b

psd->xres, psd->yres, psd->ncolors, psd->data_format, type, visual,
psd->bpp);
240x           320x        65536          x80000        0      2       16


psd->xres, psd->yres, (psd->pixtype == MWPF_TRUECOLOR555)? 15: psd->bpp,
psd->pitch, type, visual, psd->ncolors, psd->pixtype);
240x            320x                                           16
480       0      2       65536           5



91

psd->xres, psd->yres, psd->ncolors, psd->linelen, type, visual, psd->bpp);
240x           320x        65536        480          0      2      16


psd->xres, psd->yres, (psd->pixtype == MWPF_TRUECOLOR555)? 15: psd->bpp,
psd->pitch, type, visual, psd->ncolors, psd->pixtype);
240x          320x                                                16bpp
0     2          65536           5

Any clues?

j.lopes

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





************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************








************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.
************************************************************************************







Previous by date: 2 Jun 2011 16:22:37 -0000 Re: New to Nano-X: Font problems, Franco Benedetti
Next by date: 2 Jun 2011 16:22:37 -0000 Re: mw-0.91 to current tarball, white is blue?, Joseph Lopes
Previous in thread: 2 Jun 2011 16:22:37 -0000 Re: mw-0.91 to current tarball, white is blue?, Joseph Lopes
Next in thread: 2 Jun 2011 16:22:37 -0000 Re: mw-0.91 to current tarball, white is blue?, Joseph Lopes


Powered by ezmlm-browse 0.20.