> Ok, so we have ttye0 for the custom chip text console, ttye1
> for Retina Z2, ttye2 for Z3 and ttye3 for cirrus based boards.
> Now what if someone produces a Cybervision or Piccolo SD64
> driver, then we'll have ttye4, and so on. Now imagine a user that's
> trying to boot a generic kernel with all those drivers enabled,
> so that the one that fits his hardware is selected. Now are you
> sure there is a line in /etc/ttys for his ttyeX? Isn't this
> getting a bit confusing?

Yes.

> Wouldn't it be wiser if the default console would be always
> configured as ttye0 (and it doesn't matter if the default console
> is cc, rt, rh, cl or whatever).

What _is_ the default console (as you've asked)?


I'm running into a similar problem on the Alpha, and the following is
more-or-less the way i'm dealing with it:

(1) early on in the boot sequence, pick a primary console.  This has
    to happen, and if things work out, it should be the same as the one
    the native OS (in my case, OSF/1) uses for console/boot messages.

(2) if there is a primary console, note that fact, for later.

(3) have the notion of a 'workstation console' device, a combination
    of one video output device and one input device (i.e. keyboard)

(4) attach instances of the 'workstation console' device to video
    devices, similarly to how audio devices are attached.  make sure
    that the 'primary' console is attached to unit zero.  other
    displays can be numbered however, probably starting at '1',
    increasing as they're found, etc.  if done right, this also could
    allow the person configuring the kernel to map displays to
    'console numbers', but that's not particularly necessary, and
    might make things much harder.

(5) attach the keyboard (i assume that there's only one; there can
    only be one on the systems i'm hacking on) to the zero-th
    'console'. 


In the workstation world, if you're not running X, you can only use
the keyboard with the 'primary' screen.  That's find be me.

Also, in my opinion, there's little place for virtual consoles on
'real workstations'.

however, if one really wanted to implement them, all one would have to
do is:
	(1) attach multiple 'workstation console' devices per physical
	    device -- note that that means including the ability to
	    run X on virtual consoles.  if you can't run a seperate
	    X server on your secondary virtual console, your VC
	    implementation is less than optimal...
	(2) provide a way to set which device is receiving input
	    from the input device.


in some places above, i way "should," "might," etc.  I'm only about
half done implementing this on the Alpha.  (head colds cut
productivity to nil, ya know?  *sigh*)


<soapbox>
One of the big problems encouraged by 'PC's is the notion of an X
server which understands exactly one type of display hardware.

That's wrong, broken, and stupid.

If I've got N display cards in my machine, i want to be able to set up
N monitors side by side, and be able to mouse across all of them with
one fell swoop.  In other words, multiple displays should be treated
as one single logical desktop, not N seperate ones.  unfortunately,
you can't do this (easily; i suppose one can do most anything with X,
if one puts enough effor into it... 8-) if each different display
adapter has its own seperate X server.

I'm _not_ particularly concerned with X server size, because it's huge
to begin with.  however, some people undoubtedly are, and there are
lots of methods that can be used to get around size problems,
including dynamic loading of server support code.
</soapbox>




chris