[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GDM, getty and VTs

On Mon, 16 Nov 2009 11:07:52 +0100
Josselin Mouette <joss@debian.org> wrote:

> Le lundi 16 novembre 2009 à 10:33 +0100, Harald Braumann a écrit : 
> > I don't see any real arguments against the set-up as it is now or
> > for a new way to do it. 
> There are no real arguments for keeping the current setup either.
Yes there is: that it has been like this forever. This is a value of
its own, because users expect it to be like this and rely on it.
Changing it will confuse many. It doesn't mean that it is carved in
stone, but there should be good reasons and the gain should outweigh
the cost.

> > Just because GDM is broken doesn't mean we should
> > change a system that is, in your own words, a long-standing
> > tradition. 
> Just because it is a tradition doesn’t mean it’s the correct way.
So far I haven't seen any argument as to why it shouldn't be the correct

> Actually, several people in this thread felt the current way is
> better, while explaining they don’t have *enough* text VTs for their
> personal use in the default setup.
> Let me sum up the situation otherwise: 
>       * Current situation is far from perfect. 

>       * New GDM upstream, as is, is completely broken. 
That seems to be the only reason. But this is clearly a bug in GDM,
that should be fixed there.

> Let me explain what proposal I have in mind after reading the thread,
> now. It might sound a little crazy but I think it would be much better
> than just keeping our current setup.
> We remove entirely the getty respawning from /etc/inittab. Instead, a
> new daemon is started by a regular init script. This daemon does the
> following: 
>       * Opens all /dev/tty1 to tty6 and display a d-i-like “press
> enter to activate this console” in them. 
>       * Provide a very simple interface to reserve a VT, that can be
>         queried by the display manager. 
>       * Whenever you press enter on a VT, reserve it and start a getty
>         process. 
>       * When almost all ttys are allocated, start opening tty7+ and so
>         on. 
>       * If no display manager is started, always run a getty process
> in tty1.
To me, this seems like a solution looking for a problem. What use-case
do you have in mind here?

On my system it currently works like this:
  - start gettys in /etc/inittab
  - define X's tty in /etc/X11/xdm/Xservers

If you want X on another tty, change it in /etc/X11/xdm/Xservers. If you
need more ttys, add gettys to /etc/inittab. This system is so simple and
flexible, that I don't see how you can improve on it.

So the solution is to make GDM configurable by a parameter or a config
file to set the vt it should start on. 

> I don’t see this as rocket science software, and it means: 
>       * No useless getty processes are started. 
I never considered this to be a real problem. 

>       * tty1 is always the first VT you log on, regardless of your
>         setup. 
I don't see this as an improvement. I always want X on the same tty, no
matter in which order I do things. Or did I misunderstand something

>       * You can start an arbitrary number of text or graphical
> consoles, without any configuration.
Is this really a requirement? Where are the wishlist bugs of users
demanding this? And anyway, a simple script that looks for the next
free tty and spawns getty there solves this nice and easy.


Attachment: signature.asc
Description: PGP signature

Reply to: