Should the desktop release have X run on vt1 and a text console on vt2? I also don't see much reason to have more than that either. I probably wouldn't remove them from inittab just disable them in run level 5.
Jon
Hi, On Fri, 2007-08-24 at 11:19 -0400, Jon Nettleton wrote:
Should the desktop release have X run on vt1 and a text console on vt2? I also don't see much reason to have more than that either. I probably wouldn't remove them from inittab just disable them in run level 5.
Seems like a good idea to me. At a minimum we should get rid of the getty on tty1 so we don't have the brief "Login: " flash when the screen jumps from rhgb to gdm.
--Ray
Ray Strode escribió:
Seems like a good idea to me. At a minimum we should get rid of the getty on tty1 so we don't have the brief "Login: " flash when the screen jumps from rhgb to gdm.
--Ray
When will Fedora drop RHGB once and for all? Seems all that's needed is already into the kernel or easily configured into it... Albeit the current mode setting is rather manual, but we could simply go with something standard such as 1024x768@32bpp, or is this value going to directly feed X resolution information? For in that case, why not make X and VT configuration part of either: boot loader (LiveCD) or Anaconda (DVD) for installation, just "like in the old days", I don't see why both resolution values have to be tied together or identical in any way...
On 8/24/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
For in that case, why not make X and VT configuration part of either: boot loader (LiveCD) or Anaconda (DVD) for installation, just "like in the old days",
NO! we have the autodetection in xorg which works just well .. why go back and ask the users useless questions?
On 8/24/07, dragoran drago01@gmail.com wrote:
On 8/24/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
For in that case, why not make X and VT configuration part of either: boot loader (LiveCD) or Anaconda (DVD) for installation, just "like in the old days",
NO! we have the autodetection in xorg which works just well .. why go back and ask the users useless questions?
Since this autodetection has been put in place, I have had to manually set my Mode every Fedora install. It has never guessed correctly on any machine I have installed it on. I don't complain about it since I can only assume it works well for someone out there. But it doesn't work "just well"
On 8/24/07, Arthur Pemberton pemboa@gmail.com wrote:
On 8/24/07, dragoran drago01@gmail.com wrote:
On 8/24/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
For in that case, why not make X and VT configuration part of either: boot loader (LiveCD) or Anaconda (DVD) for installation, just "like in the old days",
NO! we have the autodetection in xorg which works just well .. why go back and ask the users useless questions?
Since this autodetection has been put in place, I have had to manually set my Mode every Fedora install. It has never guessed correctly on any machine I have installed it on. I don't complain about it since I can only assume it works well for someone out there. But it doesn't work "just well"
Do you have a bugzilla to point us to? Are these all using the same hardware? I know I have one LCD panel that no matter what chipset I plug it into it doesn't work. I have dumped the info and the EDID data is junk.
Jon
On 8/25/07, Arthur Pemberton pemboa@gmail.com wrote:
On 8/24/07, dragoran drago01@gmail.com wrote:
On 8/24/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
For in that case, why not make X and VT configuration part of either: boot loader (LiveCD) or Anaconda (DVD) for installation, just "like in the old days",
NO! we have the autodetection in xorg which works just well .. why go back
and
ask the users useless questions?
Since this autodetection has been put in place, I have had to manually set my Mode every Fedora install. It has never guessed correctly on any machine I have installed it on. I don't complain about it since I can only assume it works well for someone out there. But it doesn't work "just well"
ok let me correct myself : "it works well aslong as your display does not return crap (dcc/edid info)"
Hi,
When will Fedora drop RHGB once and for all?
Not sure, Fedora 9, I think?
Seems all that's needed is already into the kernel or easily configured into it... Albeit the current mode setting is rather manual, but we could simply go with something standard such as 1024x768@32bpp, or is this value going to directly feed X resolution information?
We're waiting on drm modesetting, which is more in line with what we need. (See the earlier low hanging fruit thread)
--Ray
On 8/24/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
Ray Strode escribió:
Seems like a good idea to me. At a minimum we should get rid of the getty on tty1 so we don't have the brief "Login: " flash when the screen jumps from rhgb to gdm.
--Ray
When will Fedora drop RHGB once and for all? Seems all that's needed is already into the kernel or easily configured into it... Albeit the current mode setting is rather manual, but we could simply go with something standard such as 1024x768@32bpp, or is this value going to directly feed X resolution information? For in that case, why not make X and VT configuration part of either: boot loader (LiveCD) or Anaconda (DVD) for installation, just "like in the old days", I don't see why both resolution values have to be tied together or identical in any way...
I almost have a working configuration that allows rhgb to use the gdm xserver. This means that once X starts ( even earlier than with rhgb now ) it is a seamless X transition all the way to login. I also have it doing cool things like instead of bouncing back to a VT for manual fsck it all happens right there in the rhgb vte screen.
It isn't perfect yet but I am trying to get it usable enough to make it into Fedora 8 feature set.
Jon
On 8/24/07, Jon Nettleton jon.nettleton@gmail.com wrote:
On 8/24/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
Ray Strode escribió:
Seems like a good idea to me. At a minimum we should get rid of the getty on tty1 so we don't have the brief "Login: " flash when the
screen
jumps from rhgb to gdm.
--Ray
When will Fedora drop RHGB once and for all? Seems all that's needed is already into the kernel or easily configured into it... Albeit the current mode setting is rather manual, but we could simply go with something standard such as 1024x768@32bpp, or is this value going to directly feed X resolution information? For in that case, why not make X and VT configuration part of either: boot loader (LiveCD) or Anaconda (DVD) for installation, just "like in the old days", I don't see why both resolution values have to be tied together or identical in any
way...
I almost have a working configuration that allows rhgb to use the gdm xserver. This means that once X starts ( even earlier than with rhgb now ) it is a seamless X transition all the way to login. I also have it doing cool things like instead of bouncing back to a VT for manual fsck it all happens right there in the rhgb vte screen.
It isn't perfect yet but I am trying to get it usable enough to make it into Fedora 8 feature set.
ok but feature freeze is in 4 days... will it be ready by then?
On 8/24/07, dragoran drago01@gmail.com wrote:
On 8/24/07, Jon Nettleton jon.nettleton@gmail.com wrote:
On 8/24/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
Ray Strode escribió:
Seems like a good idea to me. At a minimum we should get rid of the getty on tty1 so we don't have the brief "Login: " flash when the
screen
jumps from rhgb to gdm.
--Ray
When will Fedora drop RHGB once and for all? Seems all that's needed is already into the kernel or easily configured into it... Albeit the current mode setting is rather manual, but we could simply go with something standard such as 1024x768@32bpp, or is this value going to directly feed X resolution information? For in that case, why not make X and VT configuration part of either: boot loader (LiveCD) or Anaconda (DVD) for installation, just "like in the old days", I don't see why both resolution values have to be tied together or identical in any
way...
I almost have a working configuration that allows rhgb to use the gdm xserver. This means that once X starts ( even earlier than with rhgb now ) it is a seamless X transition all the way to login. I also have it doing cool things like instead of bouncing back to a VT for manual fsck it all happens right there in the rhgb vte screen.
It isn't perfect yet but I am trying to get it usable enough to make it into Fedora 8 feature set.
ok but feature freeze is in 4 days... will it be ready by then?
I think I got over the last major hurdle this morning so hopefully.
On 8/24/07, Jon Nettleton jon.nettleton@gmail.com wrote:
I almost have a working configuration that allows rhgb to use the gdm xserver. This means that once X starts ( even earlier than with rhgb now ) it is a seamless X transition all the way to login. I also have it doing cool things like instead of bouncing back to a VT for manual fsck it all happens right there in the rhgb vte screen.
It isn't perfect yet but I am trying to get it usable enough to make it into Fedora 8 feature set.
That sounds awesome! I'm curious do you have a place where you're putting patches for your work?
On 8/24/07, Colin Walters walters@redhat.com wrote:
On 8/24/07, Jon Nettleton jon.nettleton@gmail.com wrote:
I almost have a working configuration that allows rhgb to use the gdm xserver. This means that once X starts ( even earlier than with rhgb now ) it is a seamless X transition all the way to login. I also have it doing cool things like instead of bouncing back to a VT for manual fsck it all happens right there in the rhgb vte screen.
It isn't perfect yet but I am trying to get it usable enough to make it into Fedora 8 feature set.
That sounds awesome! I'm curious do you have a place where you're putting patches for your work?
I haven't released any official patches. I hope to finish the last bits tonight to make it publicly digestable, and enough to get it in for feature freeze. Then it will still need some debugging and such. It will be close, but I have high hopes right now.
Jon
On 8/24/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
Ray Strode escribió:
Seems like a good idea to me. At a minimum we should get rid of the getty on tty1 so we don't have the brief "Login: " flash when the screen jumps from rhgb to gdm.
--Ray
When will Fedora drop RHGB once and for all?
Is there a problem with RHGB? I haven't heard of one in the chatrooms or mailing list.
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.
That, and rhgb was designed to hide all the spew you get when you start up, but it doesn't because of all the spew that pops up before rhgb ever loads. Oh and then there's the "can't start eth0, network start failed" issue which makes you see most of the spew anyway on laptops. It's pretty much useless.
On 8/24/07, Christopher Aillon caillon@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.
That, and rhgb was designed to hide all the spew you get when you start up, but it doesn't because of all the spew that pops up before rhgb ever loads. Oh and then there's the "can't start eth0, network start failed" issue which makes you see most of the spew anyway on laptops. It's pretty much useless.
If you don't want to see this message why don't you disable eth0 from coming up on boot? This problem really has nothing to do with rhgb.
Instead of complaining why not suggest what you would like to see.
Jon
On Sex, 2007-08-24 at 20:29 -0400, Jon Nettleton wrote:
If you don't want to see this message why don't you disable eth0 from coming up on boot? This problem really has nothing to do with rhgb.
Instead of complaining why not suggest what you would like to see.
Personally I'd prefer to not have time to see nothing. Boot should be as fast as possible:
Power On -> BIOS output -> Nice image/color/gradient/whatever -> GDM ^ ^ Inevitable on x86 Realistically shouldn't take more than 20s.
The point is, for a desktop spin there is nothing to show until GDM. Network management should be done by NM and pretty much everything else should be started on demand by D-Bus.
*Reality check*: I know this won't happen for F8 but let's try for F9 :-)
Rui
On 8/24/07, Rui Tiago Cação Matos tiagomatos@gmail.com wrote:
On Sex, 2007-08-24 at 20:29 -0400, Jon Nettleton wrote:
If you don't want to see this message why don't you disable eth0 from coming up on boot? This problem really has nothing to do with rhgb.
Instead of complaining why not suggest what you would like to see.
Personally I'd prefer to not have time to see nothing. Boot should be as fast as possible:
Power On -> BIOS output -> Nice image/color/gradient/whatever -> GDM ^ ^ Inevitable on x86 Realistically shouldn't take more than 20s.
The point is, for a desktop spin there is nothing to show until GDM. Network management should be done by NM and pretty much everything else should be started on demand by D-Bus.
*Reality check*: I know this won't happen for F8 but let's try for F9 :-)
Well with a vesa framebuffer I have.
Power On -> BIOS output -> TUX vesa fb and 3 lines of text -> rhgb starts and runs -> GDM
The whole process takes 40 seconds with BIOS and hitting enter at the grub screen.
Your reality check is really spoiled by the fact that bios -> nash -> udev is 25 seconds. That is with high IO also. The work I have done has broken start_udev into two parts that the first creating static devices that Xorg needs to detect basic devices. Then the automatic detection of devices comes later. start_udev is about 5.5 secs by itself, when I break it up it is about 1.3 seconds and 4.5 seconds. The overhead of the second detection is hidden by the fact the gui is running instead of just sitting there.
We will keep plugging away. If you truly want 20 seconds you should get on the ACPI mailing list and get suspend and hibernate working on your machine.
Jon
Jon Nettleton wrote:
If you don't want to see this message why don't you disable eth0 from coming up on boot? This problem really has nothing to do with rhgb.
Or I could just stop booting the machine to not see debug messages at bootup!
Seriously, do you really expect the average user to do that just because of a bug[1] in rhgb?
[1] The bug is that as soon as anything goes wrong, regardless of how critical it is, it starts dumping stuff out. See how e.g. MacOSX handles this: it just doesn't show the user anything if it's not critical, but it does log to /var/log/messages. Can't get wired because we're a laptop? NOT CARE.
On 8/24/07, Christopher Aillon caillon@redhat.com wrote:
Jon Nettleton wrote:
If you don't want to see this message why don't you disable eth0 from coming up on boot? This problem really has nothing to do with rhgb.
Or I could just stop booting the machine to not see debug messages at bootup!
Seriously, do you really expect the average user to do that just because of a bug[1] in rhgb?
[1] The bug is that as soon as anything goes wrong, regardless of how critical it is, it starts dumping stuff out. See how e.g. MacOSX handles this: it just doesn't show the user anything if it's not critical, but it does log to /var/log/messages. Can't get wired because we're a laptop? NOT CARE.
Much better. So instead of dropping open the terminal you would rather have the spinner icon turn to a spinning yield icon or something. I can't say that will happen for Fedora 8 but I can see where for a desktop spin that could be doable.
Thanks Jon
On 8/24/07, Jon Nettleton jon.nettleton@gmail.com wrote:
On 8/24/07, Christopher Aillon caillon@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
On 8/26/07, Kristian Høgsberg krh@bitplanet.net wrote:
On 8/24/07, Jon Nettleton jon.nettleton@gmail.com wrote:
On 8/24/07, Christopher Aillon caillon@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:
- 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.
- 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
- 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
On 8/26/07, Jon Nettleton jon.nettleton@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.
On 8/27/07, Arthur Pemberton pemboa@gmail.com wrote:
On 8/26/07, Jon Nettleton jon.nettleton@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? 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 utilties also? I understand that people feel the future is in DDX but is that replacing X on the desktop? 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.
Jon
On 8/26/07, Jon Nettleton jon.nettleton@gmail.com wrote:
On 8/27/07, Arthur Pemberton pemboa@gmail.com wrote:
On 8/26/07, Jon Nettleton jon.nettleton@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? 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 utilties also? I understand that people feel the future is in DDX but is that replacing X on the desktop? 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.
You need to calm down. I only quoted and replied to a small portion your post. I am not the person to answer all these questions, so there's no point to replying to my message with these question. You mentioned 'hidden' and 'last minute' and I only disagreed with that. I am not prepared to argue against/for the merits of an early Xorg etc.
I only originally asked a question since you seemed to be aware of a problem with RHGB that I was not aware of, and wanted to be informed.
On 8/27/07, Jon Nettleton jon.nettleton@gmail.com wrote:
On 8/27/07, Arthur Pemberton pemboa@gmail.com wrote:
On 8/26/07, Jon Nettleton jon.nettleton@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 utilties also?
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 initrd.
Kristian
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]?
Cheers, Steven Garrity (who admittedly knows very little about this topic)
On 8/27/07, Steven Garrity stevelist@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
On 8/26/07, Jon Nettleton jon.nettleton@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.
Have you posted your patches? Maybe they turn out to be simple enough?
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.
What the Desktop SIG/spin is about is to do the small tweaks to Fedora to make it a better desktop. If we get blocked on some larger changes to the underlying OS (like this bootup sequence), the answer isn't to fork. Let's be honest, there are a bazillion other Linux distributions out there, I think few people here have the desire to add to the pool. Keep in mind what makes Fedora Fedora (among other things, but in this context...) is that we try to get everything upstream and we try to have a unified code base.
Colin Walters wrote:
On 8/26/07, Jon Nettleton jon.nettleton@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.
Have you posted your patches? Maybe they turn out to be simple enough?
+1
And just because they might not make it into the default boot sequence, doesn't mean there might not be plenty of people who would like a simple installable package which made those changes to their systems.
-dmc
Hello all,
I'm the main developer (and project admin) of the Splashy project. Somebody mentioned this threat on the #splashy channel (irc.freenode.net) and I decided to join the list and follow it closely.
We are very interested in getting Splashy on Fedora. We have worked with a few Fedora developers before in order to get a .spec file that's generic enough for most RPM-based systems. Now that Splashy depends on less debian-specific libraries, I think it's time to start supporting Fedora in full.
As you might already know, Xandros, SuSE and Mandriva are already considering or using Splashy on their projects. And so are other vendors (small integrators and other people who customize Linux distributions). I believe that this will be easier for all of them if there was a src.rpmofficially released from the Splashy project page.
If anybody is interested in helping us, please join us on IRC to discuss about it.
Regards,
Luis Mondesi wrote:
We are very interested in getting Splashy on Fedora. We have worked with a few Fedora developers before in order to get a .spec file that's generic enough for most RPM-based systems. Now that Splashy depends on less debian-specific libraries, I think it's time to start supporting Fedora in full.
As you might already know, Xandros, SuSE and Mandriva are already considering or using Splashy on their projects. And so are other vendors (small integrators and other people who customize Linux distributions). I believe that this will be easier for all of them if there was a src.rpm officially released from the Splashy project page.
It might be a good start to get Splashy into the Fedora repo so we can easily "yum install" it to try it out.
Cheers, Steven Garrity
Jon Nettleton escribió:
Should the desktop release have X run on vt1 and a text console on vt2? I also don't see much reason to have more than that either. I probably wouldn't remove them from inittab just disable them in run level 5.
Jon
I don't think that's a good idea... Like me, I know a bunch of users who do actually make use of the other VTs, making the default graphics VT VT1 seems like a good idea, but be done with the six text VTs doesn't, IMO look like such a good idea.
Gian Paolo Mureddu wrote:
Jon Nettleton escribió:
Should the desktop release have X run on vt1 and a text console on vt2? I also don't see much reason to have more than that either. I probably wouldn't remove them from inittab just disable them in run level 5.
Jon
I don't think that's a good idea... Like me, I know a bunch of users who do actually make use of the other VTs, making the default graphics VT VT1 seems like a good idea, but be done with the six text VTs doesn't, IMO look like such a good idea.
Bear in mind the scope. This is for a specialized Desktop spin, which is not the main Fedora distro.
Hi,
I don't think that's a good idea... Like me, I know a bunch of users who do actually make use of the other VTs, making the default graphics VT VT1 seems like a good idea, but be done with the six text VTs doesn't, IMO look like such a good idea.
Remember that this change is proposed for an experimental desktop specific spin. It doesn't seem unreasonable to me to target users who don't use multiple VTs.
Keep in mind this is just configuration / default policy. If you want to try the experimental desktop spin, but would rather have more VTs, you can change /etc/inittab after the system is installed.
On the other hand, you can also just use the normal Fedora spin, since we aren't talking about changing it.
--Ray
desktop@lists.stg.fedoraproject.org
-
Arthur Pemberton -
Christopher Aillon -
Colin Walters -
Douglas McClendon -
drago01 -
Gain Paolo Mureddu -
Jon Nettleton -
Kristian Høgsberg -
Luis -
Ray Strode -
Rui Tiago Cação Matos -
Steven Garrity