AW: Multiple text consoles

[Unger R. <ric...@te...>]

Hi!=20

On the whole, I agree with you. What you say seems to make very good
sense.
Support for dumb consoles and a framebuffer terminal application would
work well.

I suppose fbcon would be a sort of 'in-kernel' version of this
framebuffer terminal app.
However, fbcon has the advantage of being able to show the system
console as well. (System console useful for boot-time interaction).
Also, on non-intel architectures there often is no VGA console (eg Mac),
only a framebuffer console. Such systems need fbcon in order to show
boot messages. So there is still justification for an in-kernel
framebuffer console layer.

Multiple VGA text consoles seems difficult (Avilis pointed out that only
one VGA device per PCI domain is allowed) - I really know too little
about it, but it seems to me that one runs into BIOS/Hardware issues
that make more than one VGA device impossible.

Basically, I think it is also difficult because the semantics for
multiple consoles are poorly defined:
-> Which console gets the boot console?
-> Which console gets which keyboard/mouse device?
Perhaps some work needs to be done to define standards for how all this
should all work.

In my eyes it isn't a matter of adjusting the kernel for multiple VGA
kernels - I think the aim should be something like the following:

0 or 1 VGA consoles
X serial consoles
Y framebuffer consoles
Z dumb consoles
(where X,Y and Z are non-negative integers)

Each of these consoles should have one or more virtual terminals
assigned.=20

If at least one console exists, one should be assigned to the system
console. This could be controlled via a kernel boot param. If none is
supplied I would say the VGA console would be a good first choice,
followed by the first framebuffer console if available.

Each of the consoles should be assigned a keyboard. Again, the
assignment could be controlled by a boot param, or perhaps, if it could
be changed without too much trouble later, there could be an initial
assignment of all keyboards to the system console at boot time, and this
would then be changed by a suitable rc-script.

In my imagination, this is how things should work :)

Regards,
Richard Unger



> In my opinion, we shouldn't try to adjust the kernel to=20
> accomplish multiple text consoles. Someone should create a=20
> VT102-compatible terminal emulation program for framebuffer.=20
> The ruby kernel has support allready for multiple dumb=20
> consoles, so these terminal emulation programs just have to=20
> be started on the right console for multiple text console=20
> support to work.
>=20
> IMHO, true multiple console text mode is trying to push your=20
> luck. I don't think the hardware is able to pull this, afaik=20
> the linux kernel uses very simple calls to get it's text=20
> console to the screen.
> Framebuffer is the way to go for multiple text consoles, but=20
> why use framebuffer when you can use X?
>=20
> IIRC, some time ago somebody had the idea of creating a=20
> userspace terminal emulation program with an fbdev video output.
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web. =20
> DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&
> dat=3D121642
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>=20