From: Mike B. <i_a...@ho...> - 2006-02-24 10:26:38
|
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/ |
From: Torgeir V. <to...@po...> - 2006-02-25 03:13:55
|
On Fri, 2006-02-24 at 02:26 -0800, Mike Bourgeous wrote: > My main goal is to get X to display on the framebuffer. Isn't it too slow for X? I'd be thinking going the dvb driver route would be the way, since the card is similar in function to full features dvb-s cards? -- Torgeir Veimo <to...@po...> |
From: Geert U. <ge...@li...> - 2006-02-25 08:46:56
|
On Fri, 24 Feb 2006, Mike Bourgeous wrote: > 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. [...] > work without too much work in userspace. My main goal is > to get X to display on the framebuffer. Getting tinyX to work is not that difficult. Using its shadow screen feature, you let it draw to a `normal' 24 bit image of the screen in RAM, and convert all modified rectangular areas to the hardware's format. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |