Re: [RFC] enhancing the kernel's graphics subsystem

[Jon Smirl]

On 5/21/07, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> 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
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/