On 8/27/07, Jon Nettleton <jon.nettleton(a)gmail.com> wrote:
On 8/27/07, Arthur Pemberton <pemboa(a)gmail.com> wrote:
> On 8/26/07, Jon Nettleton <jon.nettleton(a)gmail.com> wrote:
> > 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.
> This seems to have been developed and publicized on the Fedora wiki
> page since 2007-05-08. I'm not sure how that is last minute or hidden.
So we are going to hold back our desktop user community a better boot
process for 10 better seconds of kernel rendered graphics? What is the
next thing we have to wait for?
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.
As far as I know all our first boot and admin
utilities are written to use X or ncurses. Booting to an X server as fast as
possible allows us to embed X admin utilites already written.
Otherwise we are stuck using ncurses and text to set the time
server and change the root password. Or are we going to rewrite these
No, that was not part of what I wrote. All those tools are still
going to require an X server, and we're not going to move away from X.
I understand that people feel the future is in DDX but is that
replacing X on the desktop?
DDX is the part of X that drives the hardware, Driver Dependent X.
When X hackers talk about DDX drivers, they're really just talking
about the 2D driver part of the X server. The DRM modesetting effort
is about moving the modesetting part of the DDX driver into the
kernel, so that the kernel can set the mode on boot or in the initrd
(the earliest userspace). This has a number of other benefits, for
example, the kernel can then restore a garbled display if your X
server crashes, or if the kernel crashes it can print an oops on
screen even if you're in X.
If it isn't then shouldn't the future of a DESKTOP
version of fedora be to get to X ASAP and stay in X?
If the question is no then I will gladly unsubscribe from this list and not
be part of the problem any longer.
The most important part is to boot into a desktop session as fast as
possible. Where in the boot sequence we start X is less important,
but as soon as we can set the graphics mode a provide graphical
feedback the better. The earliest time where we can do this is the