nanogui: 4bpp OK, 1bpp Not So Good
Subject:
Re: [nanogui] 4bpp OK, 1bpp Not So Good
From:
Gil Glass ####@####.####
Date:
25 Jan 2006 14:38:54 +0000
Message-Id: <OFAE02E073.1223547D-ON85257101.004FE6DE-85257101.00505B39@acterna.com>
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
