RE: [Linuxconsole-dev] Welcome!!!

[James S. <jsi...@ac...>]

> 	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).

I have no problem of creatings a VT per head. But this moving a VT around
from head to head is a nightmare. If a app wants to use a VT thats on
anoteh head just look to see if its in use then grab it. 

> > 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.  

And it is. The console code is being moved up and out to fbcon.c which
really is apart of the console system. I hope to see the same from
Vojtechs input system. 

> 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.

Thats right. This can be seen in the new fbdev coming up over the horizon.

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U