More low hanging fruit.

[Kristian Høgsberg]

On 8/24/07, Jon Nettleton <jon.nettleton at gmail.com> wrote:
> On 8/24/07, Christopher Aillon <caillon at redhat.com> wrote:
> > Arthur Pemberton wrote:
> > > Is there a problem with RHGB? I haven't heard of one in the chatrooms
> > > or mailing list.
> >
> > The main problem is that it starts an X server.  When rhgb ends, its X
> > server shuts down, and then a second X server is spawned for the user to
> > log in with.
>
> I am working on this.  Hopefully we will have only 1 Xserver running from boot
> to desktop.

Hi,

Allow me to give a summary of the graphical boot plans we've been
discussion at Red Hat and what the bigger picture looks like for the
graphical stack.  We have a wiki-page over here:

  http://fedoraproject.org/wiki/Releases/FeatureBetterStartup

that describes the plan, but let me just quickly summarize what we
hope to get done for F9 (optimistic, but realistic):

 - We switch to graphics mode using the DRM drivers, which we add to
the initrd.  This mean we can display a logo as soon as the kernel
finishes initializing and starts the initrd, which is about 5-10
seconds after grub.  Ray has been working on a small application we
can put in the initrd that displays boot progress.  This won't require
X, most likely just libpng, possibly cairo and will run all the way to
GDM.  When GDM start, we start the X server, which won't change the
mode, but inherit the mode and screen contents set by the drm drivers
and the graphical boot application.

Now, getting all this in place takes a few steps:

1) Get DRM memory manager in to kernel.  This is our top priority
right now.  It blocks on the work Dave Airlie is doing with exa
integration, sorting out caching and the super-submit-ioctl.  It
blocks on verifying that the memory manager is usable for redirected
direct rendering and GLX 1.4 (GLXPixmaps and GLXPbuffers), which I
have been working on.  We expect to get these issues worked out at XDS
in a couple of weeks, and if all goes well we may get the memory
manager into 2.6.24.

2) Move DDX modesetting code into the drm drivers.  So far, the idea
has been pretty well received upstream (kernel) and to some extent,
it's just a matter of moving the code, but there is also the issue of
working out the userspace interface.  This work is already happening,
Jesse Barnes and others have been prototyping this and they have a
wiki page here discussion the changes they're planning:

  http://dri.freedesktop.org/wiki/DrmModesetting

3) Make the boot sequence use the DRM drives; includes work in
mkinitrd, RHGB, GDM, X, and likely other packages, and of course the
new graphical boot application it self (Ray has most of the boot
application done).  This is mostly a Fedora integration effort uses
and integrates the new functionality with our boot sequence.

In the meantime ( = Fedora 8 and worst case 9), we're not really looking to:

  - Use fbdev/bootsplash/splashy.  It's actually a long standing
discussion within Red Hat.  It has been suggested many times and
dismissed many times.  DRM can coexist with fbdev,  but it's not
pretty and some people are concerned about the stability of X running
alongside an fbdev driver.  Also, we don't want to rely on and
maintain another modesetting code path.  DRM modesetting will use the
same code base as X drivers and when we have DRM modesetting, X will
use those that for setting modes.

  - Rock the boat with respect to the X startup sequence.  We've had
RHGB for a long time, and shaking up the way RHGB, GDM and X start up
and interact just before we land the new DRM modesetting make little
sense.  It's a delicate and fragile part of the boot process and
there's a lot of tricky issues to get right.  The small benefit we get
from moving these around doesn't match up with the risks, especially
not for Fedora 8 which freezes in two days.

Kristian