I'm working on a framebuffer driver for a high-definition tuner
card's OSD, and I have two equally bad options for pixel format.
I can choose 24-bit pixels, with every FOUR bytes in reverse
order (even though pixels are three bytes long - that makes for
some interesting pictures when it's not set up right), or 32-bit
pixels, with mandatory transparency.
When I try the 24-bit route, I get video, but it looks kind of like
someone took the color columns of an LCD screen and mixed
them up, so the red of one pixel will be before the green of the
pixel to its left or something.
When I do 32-bit, it seems that no programs pay attention to
the transparency field of fb_var_screeninfo. fbi, for example,
clears the screen to 0x00000000 before drawing its image
data, leaving the screen black. If I manually set all of the
alpha bytes to 0x7f (full opacity), the fbi image is displayed,
but as soon as fbi updates the display everything's black
again.
Is it possible, without modifying userland software, to either
1. byte-swap every four bytes with three-byte wide pixels
or
2. force the transparency byte of all 32-bit pixels to 0x7f
??
I have a modified version of libfbx (u4x.sf.net/projects/libfbx)
that sets the transparency value correctly, which I used to
test the framebuffer driver, but I'd really prefer to have this
work without too much work in userspace. My main goal is
to get X to display on the framebuffer.
Any help or suggestions would be greatly appreciated.
My framebuffer driver uses the following driver as a backend:
http://myhd.sf.net/
Mike Bourgeous
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
|
