On Fri, Oct 31, 2008 at 1:20 PM, Bill Nottingham <notting@xxxxxxxxxx> wrote: > Dan Nicholson (dbn.lists@xxxxxxxxx) said: >> Oh, very good point. Let's try again. In the attached patch, all the >> logic is handled in event.d/prefdm. In particular, when we want to >> spawn a getty on tty1, we use initctl to emit a new event >> "tty1-getty". This also includes some logic to try to make sure that >> the display manager is gdm before assuming that it will be able to >> start on tty1. >> >> What do you think? > > It's still problematic in that whichever vt you run telinit from will > get gdm, which may not be tty1. (Also, it's just getting a little complex > overall.) I think this case is handled. Once you run telinit, runlevel will not return "N" as the first setting and the force-vt logic is skipped. gdm will start X on a new vt. And `telinit 5' from runlevel 5 is a no-op, I believe. It is certainly getting complex, but the current setup is not robust. Even if you take away the "I always want getty on tty1" pref, how do you handle the case when the display manager is not gdm? Just have nothing running on tty1? Because, init currently will not start a getty on tty1 in runlevel 5 in any situation. > There's still the issue of what to do with respect to stopping sometihng > on a current tty that GDM is using, if there is something there. You mean the `telinit 3' from runlevel 5 case? I'm not following exactly. -- Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list