On 5/21/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
Jon, that's why I'm posting this stuff in the first place! :) Again, if you have specific problems with the proposed interfaces (problems that would preclude your wishlist from being fully implementable), please let me know (preferably with specifics).
A simple place to start is OOPS display while in graphics mode. If we going to tear up the kernel graphics system this is something that needs to be fixed. I don't think it is safe for the OOPS code to attempt a mode change to text mode when the OOPS happens. The OOPS could have happened in a 3D driver and left the GPU messed up. The safest thing to do is to display the OOPS using the mode that is already set. This implies that the kernel driver needs to track the dimensions and location of the framebuffer and whether it is in text/graphics mode (this hasn't been possible before because X never tells the kernel what mode it is setting). You also need to bring in the bitmap copy code and fonts over from fbdev. When the OOPS happens you use this info to paint the OOPS onto the screen. The code from fbdev will let you display text in graphics mode entirely in kernel context. The driver should also attempt to stop the GPU to try and make sure it doesn't erase the OOPS display. Another simple thing that needs to be built is a mechanism to run the VBIOS in x86 mode when the driver is first loaded. This can be achieved by using call_usermode helper to trigger an external app. You also need to get the x86 emulator working so that this will work on non-x86 platforms (benh has already done this). I've aput the hooks into place to give you access to the VBIOS from sysfs. This app is a prime candidate for klibc. This app is strongly coupled to the problem of VGA arbitration. Could we try and work out a solution to these two problems? If we can solve these they will provide a foundation for fixing the harder ones. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/