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

["Jon Smirl" <jonsmirl@gmail.com>]

On 5/22/07, Dave Airlie <airlied@gmail.com> wrote:
> On 5/22/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 5/21/07, Jesse Barnes <jbarnes@virtuousgeek.org> 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,

These are not isolated problems. Linux needs a properly designed
graphics subsystem. One way to achieve that is to design it all on
paper first so that we can try and locate the interactions between
modules. For example the current mode setting design is definitely
broken for multi-seat support, that's because you didn't take that
feature into account when writing the code.

Putting a small module into the kernel first with a random API, then
try and build the next module is not a good development path. It is
better to design all of the modules on paper and then work backwards
to the API the first module needs.  Even better would be to get the
whole subsystem working before including it in the kernel. Once these
exposed APIs go it, it is impossible to get them out. We need to try
and make sure that they are correct to begin with.

You need to take into account that you are proposing the replacement
of an existing subsystem, not the initial inclusion of a virgin
system. Putting your code in as is does make the X server happy, but
it is not solving all of the known problems with the existing graphics
subsystem. If you just want to make to X server happy it would be
better to extend the existing fbdev API and not try and replace the
subsystem.

--
Jon Smirl
jonsmirl@gmail.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/