On 5/22/07, Jon Smirl <[email protected]> wrote:
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.
What does this have to do with Jesse's patches? this is a totally
orthogonal issue..
We will fix this once we have the basic modesetting code working,
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.
Again orthogonal problem, VGA arbitration isn't going to matter for
this stuff, and we can have initramfs sw do vbetool post on
non-initialised cards at startup even now (it may not always work as
some cards may not have BIOSes in the right place s and we need the
VGA arb to work to do it properly...)
These are nothing to do with the work we are doing, and I think a big
part of your problem with working on this previously is you have
linked together a group of orthogonal problems into one big problem,
when really there are 5-10 problems all of which can be solved
separately...
Dave.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
