I want to test my Sharp LQD341 equivalent display that I've interfaced to the Gumstix to make sure I've wired things correctly before I create a custom PCB (e.g., MSB vs. LSB, colors).
I looked at the files and code Holly Gates posted for converting ppm files for filling the Linux framebuffer. I think these will work for B/W only and support only 8 bits per pixel.
Does anyone know of any easy way to fill the framebuffer with color 640x480x16 test patterns? I'm afraid if I write my own code to do this and debug both the hardware and software simultaneously, I won't really be checking the hardware wiring.
Sounds like some of the stuff you posted got lost. That's a bummer--I really appreciate that you took the time to share your work.
If you have a framebuffer load utility for a color LCD, I'd really appreciate it seeing it.
I read a framebuffer tutorial that used three bytes per pixel. Two bytes for color, one byte for "transparency".
I configured the kernel for 640x480x16, since it looked like the PXA255 supported 5 bits per color. One color had 6 pits (green, I think), the other two had five bits for a total of 16 bits. But perhaps the framebuffer abstraction adds a byte for "transparency" so multiple buffers can be overlaid (or something like that). So I'm not even sure I should have configured for a 640x480x16 framebuffer.
The display I'm using (Sharp LQD341/343 compatible) supports 6 bits per color. I'd like to use the nice png files you posted (green, red, blue, fades from right to left) to verify I have the hardware wiring right and consistent with the kernel configuration.
Get latest updates about Open Source Projects, Conferences and News.