More low hanging fruit.

[Kristian Høgsberg]

On 8/27/07, Steven Garrity <stevelist at silverorange.com> wrote:
> Kristian Høgsberg wrote:
> > It's not kernel rendered graphics, the kernel just sets the graphics
> > mode and then a small userspace application can provide a simple
> > progress bar.  The userspace application will start very early in the
> > boot process and replace RHGB, so we still avoid starting 2 X servers
> > with this approach.  The transition from the userspace application to
> > the X server will be smooth, for example, a cross fade, and in
> > particular, no mode switches.
>
> Isn't the small userspace app you're describing here very similar to
> Splashy [1]?

It may well make more sense to go with that, but we need to take a
closer look.  A few things that we need that I don't think splashy
does:

 - we're going to use the drm fbdev or maybe drm ioctls to set and
control the graphics as opposed the the current fbdev system.  The drm
drivers and the current fbdev arbitrate access to the underlying in
graphics device in a pretty hacky way that we want to avoid.

 - we want to make sure that the drm driver sets the right mode right
from the start so that we can do a nice transition effect into the X
server without changing mode.  This requires some hand-off protocol
between splasy and the X server so the X server wont clear the
framebuffer contents on startup.

That said, I can't see why these features wouldn't be accepted by the
splashy project, once the drm modesetting is in place.

Kristian