nanogui: Thread: 4bpp OK, 1bpp Not So Good

Hello,

I have been using Nano-X version 0.91 compiled for an ARM processor 
successfully for some time now.  I've been using it in framebuffer mode 
with a 4 bit-per-pixel monochrome display and it's been just fine. 
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!

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?  Does 
Nano-X use the Linux framebuffer primitives, i.e. those for drawing 
rectangles, etc., or does Nano-X draw directly to framebuffer space?  If 
this is the case, are we looking at modifying Nano-X?

Finally, I'm currently using SCREEN_PIXTYPE = MWPF_PALETTE in my config 
file.  Is this correct?

Cheers,
Gil Glass
Telecom Field Services
JDSU
Germantown, MD, USA
+1-240-404-2551
Please note new e-mail address:  ####@####.####  While the Acterna 
address will continue to work for a while, please begin using the JDSU 
address instead.

: 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

Thanks for the reply, Greg,

> 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.

This is correct if I understand what you're saying.  Basically, the 
controller writes 4 adjacent pixels at a time to the physical display. The 
controller in the ARM processor already supports this, we just need to 
make sure that the pixels are in place when it goes to write then to the 
display hardware.
 
> 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.

I believe so but how would I know for sure?  If, using fbset for example, 
I set the depth to 1bpp, then am I inherently using fblin1.c?

> 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.

My coworker, who has looked at the fblin1.c code, seems to think that 
modifications to fblin1.c could be in order and would likely be relatively 
minor.

Cheers,
Gil
 

: I believe so but how would I know for sure?  If, using fbset for example,
: I set the depth to 1bpp, then am I inherently using fblin1.c?

Yes, the code in scr_fb.c selects the driver from the returned
fb info


:
: > 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.
:
: My coworker, who has looked at the fblin1.c code, seems to think that
: modifications to fblin1.c could be in order and would likely be relatively
: minor.

Yes, as long as you can somehow get the adjacent three pixels from
the controller.  Otherwise, you'll have to store everything in an
internal ram buffer as well.

Regards,

Greg