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

Re: GDM, getty and VTs



What I would like to see is something like the following.
I've no idea whether it is achievable technically, but I'd
be interested to know what others thought.

* the display manager gets the first VT. If there is no 
  display manager configured, a TTY is assigned instead.
  (really, in the absence of an [xkg]dm, a TTY is treated
  as a display manager).
* a localized process which prints "press enter to start a
  console" (similar to what is present in d-i) sits on the
  next available VT
* when a user hits enter, a tty is spawned, and another
  instance of the "press enter" process is also spawned, and
  allocated to the next available VT
* when a user logs out of a TTY, a VT switch occurs to the
  previous VT [1]
* for one release cycle, I would statically allocate a
  localized message to VT7, indicating the changed behaviour

The rationale behind this is - broadly - at any time you
have precicely as many TTYs as you have requested, and a
single  "press enter for another TTY" process. Those who
want to use 6 VTs can spawn 6 with just one keystroke more
than the current situation. Those who never use any only
have a single "press enter" process hanging around. Those
that want lots more can create lots more.

[1] I'm not convinced this, as I've detailed it, would work
    too well. What I am aiming for is a situation where you
    have a list of allocated VTs, and VTs in the middle of
    the list are removed when not needed. But just switching
    back one VT won't achieve this, you would still have a
    dead VT sitting between two actives ones if you cycled
    using the arrow keys, for example, so VT "shuffling"
    would need to take place, or VT navigation would need to
    be redesigned around a dynamic list, rather than static
    slots.


-- 
Jon Dowland

Attachment: signature.asc
Description: Digital signature


Reply to: