LCD Controller with vertical packing

LCD Controller with vertical packing

[jayakumar lkml]

Hi all,

I have a LCD board with a physical resolution of 384x128 which is made
up of a 3x2 grid of 128x64 monochrome black/white lcds. The interface
is 8bit data with a few other lines for handshaking and control. I'm
thinking of writing an fbdev driver for this device so that userspace
apps can do stuff like open /dev/fb0,write,close or maybe even
open,mmap,dostuff,cleanup or even use Xfbdev on it. But I think there
is a problem. The controller has an unusual pixel packing. It's packed
8-vertical pixels per byte. Meaning, that if you wanted to write a
single pixel high horizontal line 384 pixels wide at y=0, you'd have
to output 0x1 to the datalines 384 times. And say you wanted a
vertical stipple, it'd be 0xA to the datalines 384 times. Whereas if
you wanted to draw a black box 8 pixels high and 5 pixels wide, you'd
just write 0xF five times. I hope that explaination is clear. One
could also use the control lines to tell the controller an x and y
coordinate address to get to any individual 8 pixel vertical block.

I suspect this packing is not one that is easily supported in fbdev
given it's packing. Is this suspicion valid? I mean, I guess i could
use fb_ops->fb_write hooks and then repack any writes to the
framebuffer. Would that work for stuff like Xfbdev? I'm guessing
anything that depended on being able to mmap the fb would not work.
Maybe there's some way to make all mmaped writes to the fb cause some
kind of page fault and then have a handler that repacked it.

All advice and feedback is welcome.

Thanks,
jaya


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 

LCD controller with vertical packing

[jayakumar lkml]

Hi all,

I have a LCD board with a physical resolution of 384x128 which is made
up of a 3x2 grid of 128x64 monochrome black/white lcds. The interface
is 8bit data with a few other lines for handshaking and control. I'm
thinking of writing an fbdev driver for this device so that userspace
apps can do stuff like open /dev/fb0,write,close or maybe even
open,mmap,dostuff,cleanup or even use Xfbdev on it. But I think there
is a problem. The controller has an unusual pixel packing. It's packed
8-vertical pixels per byte. Meaning, that if you wanted to write a
single pixel high horizontal line 384 pixels wide at y=0, you'd have
to output 0x1 to the datalines 384 times. And say you wanted a
vertical stipple, it'd be 0xA to the datalines 384 times. Whereas if
you wanted to draw a black box 8 pixels high and 5 pixels wide, you'd
just write 0xF five times. I hope that explaination is clear. One
could also use the control lines to tell the controller an x and y
coordinate address to get to any individual 8 pixel vertical block.

I suspect this packing is not one that is easily supported in fbdev
given it's packing. Is this suspicion valid? I mean, I guess i could
use fb_ops->fb_write hooks and then repack any writes to the
framebuffer. Would that work for stuff like Xfbdev? I'm guessing
anything that depended on being able to mmap the fb would not work.
Maybe there's some way to make all mmaped writes to the fb cause some
kind of page fault and then have a handler that repacked it.

All advice and feedback is welcome.

Thanks,
jaya


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix