>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. I get 0x80 for white. >look at the >code in engine/devopen.c::GdFindColor(), where an >MWCOLORVAL (white == 0xFFFFFFFF) is converted >to a pixel value (0xFFFF).
In devopen.c::GdFindColor(), I get this for white: case MWPF_TRUECOLOR565 c = 0x3F1F1F COLOR2PIXEL565(c) = 0x18E7 for black: case MWPF_TRUECOLOR565 c = 0x0 COLOR2PIXEL565(c) = 0x0 On one screen I got this once: case MWPF_TRUECOLOR565 c = 0xFFFFFFFF COLOR2PIXEL565(c) = 0xFFFF and ocassionally this: case MWPF_TRUECOLOR565 c = 0xFF000000 COLOR2PIXEL565(c) = 0x0 one of these is blue: case MWPF_TRUECOLOR565 c = 0x301818 COLOR2PIXEL565(c) = 0x18C6 psd->pixtype = 5 case MWPF_TRUECOLOR565 c = 0x10 COLOR2PIXEL565(c) = 0x1000 White is a dim grey-bue, blue is dull red, red is a green. j. lopes ________________________________ From: Greg Haerr [mailto:g...@censoft.com] Sent: Thu 6/2/2011 12:22 PM To: Joseph Lopes; nanogui@linuxhacker.org Subject: Re: [nanogui] mw-0.91 to current tarball, white is blue? > 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 [mailto:g...@censoft.com] Sent: Thu 5/26/2011 12:54 PM To: Joseph Lopes; nanogui@linuxhacker.org 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: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org ************************************************************************************ 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. ************************************************************************************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org
