From: jayakumar l. <jay...@gm...> - 2005-04-29 12:40:46
|
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=3D0, 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 |