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, Why? > 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. Cheers, harry
Attachment:
signature.asc
Description: PGP signature