Thread (2 messages) 2 messages, 2 authors, 2008-02-10

framebuffer questions

flat view

From: Scott D. Davilla <hidden>
Date: 2008-02-09 21:13:38

I'm tracking a X11 hang/video corruption problem. I'm not a Linux 
framebuffer expert so I'm asking for input.

Hardware is an AppleTV (yes, an AppleTV). This is an EFI based 
pentium-m with intel 945GM chipset with nvidia 7300.

Linux boots and I get console output. X11 works but when displaying 
720p or 1080i MPEG2 content using xvmc, I get random application 
hangs (requiring a kill to the app) and random green macro block 
video corruption.  A similar BIOS based ITX system  configured with 
identical kernel/rootfile system never hangs or has video corruption.

The differences are EFI vs BIOS and imacfb vs vesafb.

EFI does not have any dynamic interaction with the kernel or app 
level. The only time EFI comes into play is mapping memory and 
acpi/smbios address structures. And with these EFI is not doing 
anything, the kernel  EFI routines are using the passed EFI memory 
structures. All timing/runtime EFI services are disabled/remapped to 
non-EFI routines. I've even remapped the EFI structures into e820 
structures in an experimental bootloader that boots the kernel is a 
similar fashion as ELILO does for the 2.6.24 kernels and still get 
hangs/video corrution. So I don't think it's related to EFI booting.


Going over the imacfb source, I've noticed a few issues that might be 
causing hidden problems.

1) "info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev)" is used to 
allocate memory for the framebuffer info structure (struct fb_info 
*info).

struct fb_info is greater than 16 * sizeof(u32) so it seems this 
should be "info = framebuffer_alloc(sizeof(struct fb_info), 
&dev->dev)" or imacfb is going to be read/writing beyond what was 
allocated. Side note efifb.c has this same code as it was derived 
from imacfb.


2) "request_mem_region(imacfb_fix.smem_start, size_total, "imacfb")" 
uses size_total and "ioremap(imacfb_fix.smem_start, 
imacfb_fix.smem_len)" uses imacfb_fix.smem_len. I guess the intent 
here is request memory for the largest video buffer size supported 
but only map the current video buffer size. There's a complicated 
logic sequence above the request_mem_region call that uses magic 
numbers to try to compute and pad the various sizes.

This seems in error. The current video buffer size is 
"imacfb_defined.yres * imacfb_fix.line_length", and the max size is 
screen_info.lfb_size. Should these not be used directly and all the 
sizing logic voodoo removed.

3) imacfb (and efifb) do not any removal routines for unloading the 
module. So what happens when X11 takes over? Should there be an 
removal routine for unloading? The console video buffer is still 
mapped (screen_base). How does X11 know not to use this area? What 
does X11 do regarding the console framebuffer when it runs and it is 
does not unlaod the console module, how does it avoid using the 
console mapped video memory?

Thanks
Scott


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help