RE: [Linuxconsole-dev] Welcome!!!

[Jon M. T. <ta...@ec...>]

On Thu, 2 Mar 2000, Petr Vandrovec wrote:

> On  2 Mar 00 at 10:49, James A Simmons wrote:
> > > > 1: What do we need?
> > > >     * Better multiheading,
> > > Each head should have it's own console.  Is this already being worked on
> > > now?
> > Note really. The current implementation is we have 32 consoles and we map
>                                                      64...
> > a x amount to one fbdev head. Then a Y amount to another fbdev head etc.
> > > >     * Cleaner and more abstract [virtual] console representation,
> > > I like the idea of moving /dev/fbx to /dev/fb/fbx/,fbx+1/... and each head
> > > having it's own VTs.  
> > I do like the idea of having VT pools to each head. This way these VTs
> > keep out of each others way. It should be (using devfs) 
> > /dev/head0/vc/1
> > /dev/head0/vc/2
> > ...
> > /dev/head1/vc/1
> > /dev/head1/vc/2
> > The only thing is figureing out which head we are on. Thus we need a
> > /dev/vc/0 that tells us that. 
>
> I do not see, what this bring to normal user or to kernel code. I can
> understand that we may want to have per-keyboard mapping from
> 1..24 -> global VC number, but I do not see reason why I cannot move
> VC from one head to another. 

	Right, that should definitely be possible.  A console is just
another type of possible output device, which should be mappable/bindable
to a head context just like any other output device (framebuffer, serial
port, network pipe, etc).

> Do not forget that only minority of users
> will run boxes in dangerous environment where you want strictly splitted
> head0 user/resources/... from head1 user/resources. In most applications
> you just have two keyboards and two monitors. And you want to
> select two of your 64 VCs to be visible/controllable at one time...

	Well, I do not think that designing the console system only to
handle the simplest cases is very wise.  If we design a flexible enough
system, we will not have to go back and redesign it when someone wants to
run e.g. three braille readers and no monitors |->.

> > > I don't think this will be easily backward compatible
> > > and are there possible race conditions with each head having it's own VTs?
> > No. Even less since we don't have to locks for two different heads trying
> > to execute the same code. With each VT pool only one VT is active at a
> > time. 
>
> You should not lock VT pool, but one VT. And for console switch, you must
> obtain lock on current VT, future VT and, - if we'll write it that way -
> on framebuffer. But locking current VT can lock fb implicitly.

	The special association between framebuffer devices and consoles
should be removed IMHO.  Both TTYs and framebuffer devices should be
treated as just some types of input and output devices, and the only thing
special about them is that they can be bound together to produce this type
of device we call a console, along with a keyboard or serial port devices.
I think that this would simplify things a lot.

> > > >     * fbcon backwards compatibility,
> > I'm working on that now with the new fbdev API.
> 'New fbdev API' does not look like backward compatibility stuff.

	devfs isn't backwards compatible either, unless you use devfsd. We
could provide 'consoled' if we needed to, which would allow us to keep
~100% backwards compatibility and also give us much more design freedom.
These are the type of issues I would really like Linus' opinion on....

> > > >     * Abstract input devices and event flow graphing,
> > > >     * ...others...
> > > How does this fit in with DRI (I'm unable to find decent documentation)?
> > > Are gfx and DRI trying to do the same thing?
> > register and draw a triangle. Its composed of ~50 APIC which allow it to
> > have a very deep parrallel graphics pipeline. You can't even just mmap the
> > MMIO regions on a SGI workstation. Some of memory space is cached and some
> > is uncacheable. SGI graphics hardware often uses both types of memory.
> > Thus you need to use a ioctl call to mmap a region. Enough on that.
>
> More I think about this, more I believe that we should split problems
> on per-driver basis to userspace and kernel, and create userspace library
> providing an industry interface (OpenGL(, DirectX) or ...). 

	This is exactly what GGI has been preaching for years now, and the
design of KGI and LibGGI is build around this concept.  It doesn't make
sense for the kernel to have to know all the little details of different
types of graphics hardware, or input devices, or all of the possible
interactions between them.  It is just too complex and changes too
rapidly.  The kernel should define some quite abstract systems for
defining input devices, output devices, messaging systems, and binding
systems for pulling it all together.  This keeps the complexity out of the
kernel core, allows maximum flexibility of driver design and user
interface structure, and actually makes things _simpler_ for the kernel
coders since everything in the non-driver kernel code is kept nice and
abstract.

> From what
> I see graphics engines are way too different to put all emulation into
> kernel 

	Yes.  The drivers must be able to talk to and listen from
userspace in very finely-tuned and hardware-specific ways, in order to
keep down kernel bloat and allow for maximum optimization potential.  
There is no way to do this properly if the kernel APIs have to care about
the little details of the hardware capabilities and interfaces.  This is
why input devices must be abstracted as EvStacks and Voichek's unified
input devices work have done, and why display hardware must be virtualized
at a quite abstract level (buffermap/command FIFO/resource lock) as KGI
does.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed