More low hanging fruit.

[Jon Nettleton]

On 8/26/07, Kristian Høgsberg <krh at bitplanet.net> wrote:
> 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.
>

I am sorry but this is really the perfect example of Fedora's problem.
The community tries to better the project and is slapped down at the
last minute because in some hidden meeting the powers that be
have decided a different roadmap.  I love NetworkManager but I have
been waiting 2+ years for functionality that I wrote into the existing network
init stuff (wireless ap scanning and profiles).

I guess when Fedora X is released we will get all the great functionality
mentioned above.  I am greatly saddened and discouraged by this
sort of response to an exciting and interesting thread.  Maybe the
future really is a CentOS like fork for the desktop, and not just a spin.

Jon