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

Re: GDM, getty and VTs

On Sat, 14 Nov 2009 15:45:11 +0100
Josselin Mouette <joss@debian.org> wrote:

> Hi,
> it’s been a long-standing tradition on Linux to have 6 started getty
> processes, in tty1 to tty6. However this doesn’t correspond anymore to
> the way we use our machines. 
>       * I don’t think we need more than 2 of these. They are still
>         useful for servers or when some disaster happens in the GUI,
> but who opens 6 console sessions nowadays? 
I do. And if people don't use them, there's still no harm done.

>       * For desktop machines, the display manager starts on tty7,
> which means there is a tty switch to display it. This causes a small
>         latency
I think the latency comes from the switch from text mode to graphical
mode, which should be alleviated by KMS.

>         and can also create some bugs when you’re using a
>         graphical boot splash.
Which bugs?

> To make things worse, the latest GDM upstream version doesn’t include
> a tty manager anymore. Each started X server will simply use the first
> available VT. Red Hat can afford to do that because their gdm is
> started by the inittab (which is really a bad idea, but well), but in
> Debian this means it takes tty1, stomping on the getty that gets
> launched here later.
> So before we start adding hacks on top of the existing, maybe now is
> the time to think about how we want to use our VTs.
> 1/ What should be on tty1? Ideally, we should have the display manager
> here if it is started, 

> 2/ How do we prevent bad interaction between console VTs and graphical
> VTs? (Of course this is closely related to question 1.)
> Given how they are done now, there will always be some race conditions
> in VT allocations without a tty manager. But as long as this code
> stays in GDM (and KDM, for that matter), we will be stuck to static
> allocation of pools of VTs prior to start anything. 
What's the actual problem with that?

> We can do better
> than that, but this requires system-wide allocation of VTs that could
> be queried from the display manager.
What's the use-case for that?

I don't see any real arguments against the set-up as it is now or for a
new way to do it. Just because GDM is broken doesn't mean we should
change a system that is, in your own words, a long-standing
tradition. I see no gain at all in that but instead it seems it would
make the system more complex, harder to understand and confuse users.


Attachment: signature.asc
Description: PGP signature

Reply to: