nanogui: 4bpp OK, 1bpp Not So Good
Subject:
Re: [nanogui] 4bpp OK, 1bpp Not So Good
From:
"Greg Haerr" ####@####.####
Date:
25 Jan 2006 00:27:15 +0000
Message-Id: <1f3801c62146$0f651d30$0300a8c0@RDP>
: However, the real-deal hardware that my product is going to use is one
: bit-per-pixel and, wouldn't you know it, the display hardware expects 4
: pixels in each data word sent to it!
If you mean that the display is actually 1bpp, but the controller
requires the nearest other 3 pixels to be written when writing 1
bit, then you're going to likely have to keep an internal framebuffer,
which is used to come up with the four bits. If not, see below.
:
: Now we have modified the Linux framebuffer primitives to correctly handle
: the 4-pixel-nybble structure (2.6.11 does it wrong) and we can write to
: the display via /dev/tty0. However, when I try to run Nano-X, as it is
: currently built, on the 1-bpp display, I see the expected image but with
: narrow vertical stripes across the entire display. It's hard to tell, but
: the stripes are probably about 4 pixels wide. Any idea what's up?
Hard to say, are you running with the 1bpp (fblin1.c) or the 4bpp
(fblin4*.c) driver? Only fblin1.c is the actual monochrome driver.
: Does
: Nano-X use the Linux framebuffer primitives, i.e. those for drawing
: rectangles, etc., or does Nano-X draw directly to framebuffer space?
We never use framebuffer primitives, all drawing is direct, when
running the fblin*.c drivers. Of course, a custom driver can do
anything, which could be what you need.
: If
: this is the case, are we looking at modifying Nano-X?
If you want to run nano-X in 1bpp, but write the the screen/fb
differently, then you'll hack a modified fblin1.c.
:
: Finally, I'm currently using SCREEN_PIXTYPE = MWPF_PALETTE in my config
: file. Is this correct?
Yes, this is used for 1, 4 and 8bpp in "palette" mode, where a internal
RGB<->pixel translation table is used (engine/devpalX.c)
Regards,
Greg
