linuxconsole-dev

Re: [Linuxconsole-dev] EvStack - 2.3.x?

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

> I  think this  whole enterprise  was  already dead  as soon  as GGI  and
> EVSTACK were mentioned.  At least as far  as i am concerned  and i guess
> this holds true  for all the major players in  the kernel development as
> well.

Ouch. Okay this isn't a evstack list. Its a console list. We are ALL here
to express ideas. I'm open minded to listen to concepts no matter who
suggest them. I see you attached a patch. I'm going to look at what you
did. I think everyones work and suggestions are important. We all can
agree we want want something more than what we have. I say lets all work
together. I suggest everyone look at Dominik work and we can discuss them
as well. I'm sure we all can come up with a great solution together :)
Thats the power of open source.    
 
> We don't  need a complete  rewrite of the  console code! All  that needs
> to  be done  are  cleanup  and some  carefully  selected and  _OPTIONAL_
> extensions.

Here is my personal tack on the current console system. I personally think
that the kernel is to VT centric. Take for example the fbdev system. Every 
single fbdev driver has console code in it. Their is no reason for that.
So what I have been doing is moving the console code up and out of all the
fbdev drivers and into fbcon.c. This will always a simple api for drivers
and a much much smaller code base. Now I see the same true for things like
the keybaord driver and the mice drivers. Move the console code out and
make the driver api simpler and reduce the code base. Vojtech was going
this way. I like to see it continue this way. As for the console code
itself. Well we need some clean ups. See my other post about the
vt_struct, vc_data, vc

> Here are my thoughts about the current console code:
> 
> 1. The whole  dual-head discussion: leave that to  the framebuffer guys.
> They are already working on it.

Thats me and Geert writing that code :) What is needed to deal with in the
console system is keeping track of what VTs are active. Right now only one
can be active (fg_console) :( 
 
> 2.  Multiple input  devices (mice,  keyboards, etc.):  this needs  tight
> cooperation  with the  USB  folks to  match what  they  do with  non-USB
> drivers (to the extend applicable to the device in question). Only major
> point here is a clean-up of  the various mouse drivers (excluding serial
> mice): there should be only one  mouse protocol be spoken by /dev/mouse.
> Instead of  the different minor  devices we should  have mouse0...mouseN
> with probing  order defined at  compile time  and a kernel  command line
> override.

Vojtechs work :) Screw the /dev/mouse crap. We have /dev/event. It
basically works like /dev/shmiq on IRIX. Its a event queue. A app opens it
and reads the event packets that arrive. It works for ANY input device :)
Raw access to the input hardware.

> 3. Console device  handling: adequate. Leave it as it  is. Carefully add
> code when necessary.

We have to deal with SMP multihead systems. You could have different
processes running on different CPUs using different heads. As you can see
we need locking to ensure data structures are altered by the wrong VT.
Next problem I bet you didn't think about. Printk being called inside a
bottom handler can also cause nasty race conditions. This was something
Mares notices while working with Vojtech. 

P.S
  As you can see I was working before with Vojtech on his work.

> 4. Builtin  terminal emulation:  separate from console  device handling.
> add  missing  DEC VT220  stuff  and  verify compatibility.  NetBSD  pcvt
> might  be helpful  here. Optional  extensions: full(?)  ECMA-48 terminal
> emulation,  dumb  terminal  emulation  (=  no  emulation)  for  embedded
> systems.

I agree. 

> 5. VT font handling: Add VT220 compatibility (that's connected to the VT
> emulation).  Add X11  font  compatibility. (that's  user-mode stuff  for
> sure!) Remove 512 glyph limit  (no longer necessary due to framebuffer).
> Possibly store fonts  deflated in the kernel (the code  is already there
> for  networking  and  other  stuff)  to  save  memory  for  large  fonts
> (unicode). Almost certainly implement sparse font tables for unicode.

I was think about this for things like supporting korean fonts on console. 

> PS: I have put my console-patch up for grabs at:
> 
>     http://www-klinik.uni-mainz.de/staff/kubla/Linux/

Will look.

"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

Re: [Linuxconsole-dev] EvStack - 2.3.x?

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

> 	Any other takers? I need at least TWO testers before I'll 
> start this - don't want it to die of lack of feedback like
> last time (And I know James - it was mostly my fault :^( - live
> and learn..)

I suggest you look at Vojtech work on his input suite. It's very very well
devleoped. It does lots of really neat stuff. 

"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

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

Re: [Linuxconsole-dev] Welcome!!!

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

> > I think this shoudl go on the web page. 
> 
> 	There is a lot of stuff that should go on the web page:
> 
> * Links to prevous console work:
> 	* Voitchek(sp?)'s unified input device work
> 	* fbcon/fbdev stuff
> 	* EvStack/GGI Console stuff
> 	* KGI console stuff
> 	* ...other links...
> 
> * Analyses of the current console and its problems (FAQs)
> 
> * Links to info on how other Un*xen handle their console subsystem designs

Very nice? 

> 	That's not nearly enough info IMHO.  This "just go ahead and write
> something and I'll either accept it or not" system causes coders to waste
> a lot of time implementing ideas which are later shot down by Linus. And
> since the console subsystem is one of the more fundamental and critical
> parts of the kernel, I suspect that Linus will in fact have a lot of
> requirements that he'll want met, both in terms of design and coding
> methodology.  All he needs to do to eliminate the bulk of this uncertainty
> is give some simple answers to these questions:

Your right. I will talk to linus about this.

> * Must we "morph" fbcon/fbdev into the new console system, one tiny patch
> at a time, or can we make larger and more radical changes a la devfs?
> The latter would be much easier on the console coders, but might cause
> Linus more hassles.  Or it might not, especially if we take care to see
> that it doesn't.

Morph a small piece at a time. Try not to break any drivers. This is what
I'm doing for fbdev. Its slow and painful but it works. 

> * If we must implement the new console by parts, what is the largest
> acceptable size of the parts, and in what order should these be worked on?

I think some code clean up for the console system. A good example is the
vt_struct, struct vc_data and then struct vc. This really needs to be
cleaned up. If this can be done without breaking the current console
drivers this would be a plus. Merge these into one universal data struct. 

Keep up the input suite started by Vojtech. Do what I have been doing with
fbdev. Move the console dependent code up out of the input devices into
the console system.

> * To what extent, if any, is it acceptable to integrate the new console
> stuff and kernel graphics handling?  Obviously the two topics are closely
> related in some ways, so how do we handle this?

Well the important thing is to ensure the graphics engine is executed only
by a process on the local console. This is required for /dev/graphics on
SGI workstations. 

> 	See above.  We already have a LOT of console, abstract messaging
> and abstract input device code available.  The best thing Linus can do for
> us is to _quickly_ tell us which ideas he will _not_ accept, so we can
> avoid dead-ends and wasted coding effort.

I will talk to him. 

> 	No, and I would not propose such a thing.  Obviously the new
> console system must preserve the current abstractions, probably by
> encapsulation and extension as devfs does.  If Linus wants to preserve the
> concept of a TTY, fine.  All we need to do is define the concept of a
> 'head', and we can use that as our basic unit of binding context for VTs,
> multiheading, etc.

Okay.

"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

Re: [Linuxconsole-dev] EvStack - 2.3.x?

[Dominik K. <dom...@un...>]

On Sat, Mar 04, 2000 at 06:32:50PM -0500, Brad Douglas wrote:
[ regarding Linus' position ]
> I don't think he's going to accept a rewrite, if that's what your intentions
> are.

I  think this  whole enterprise  was  already dead  as soon  as GGI  and
EVSTACK were mentioned.  At least as far  as i am concerned  and i guess
this holds true  for all the major players in  the kernel development as
well.

We don't  need a complete  rewrite of the  console code! All  that needs
to  be done  are  cleanup  and some  carefully  selected and  _OPTIONAL_
extensions.

Here are my thoughts about the current console code:

1. The whole  dual-head discussion: leave that to  the framebuffer guys.
They are already working on it.

2.  Multiple input  devices (mice,  keyboards, etc.):  this needs  tight
cooperation  with the  USB  folks to  match what  they  do with  non-USB
drivers (to the extend applicable to the device in question). Only major
point here is a clean-up of  the various mouse drivers (excluding serial
mice): there should be only one  mouse protocol be spoken by /dev/mouse.
Instead of  the different minor  devices we should  have mouse0...mouseN
with probing  order defined at  compile time  and a kernel  command line
override.

3. Console device  handling: adequate. Leave it as it  is. Carefully add
code when necessary.

4. Builtin  terminal emulation:  separate from console  device handling.
add  missing  DEC VT220  stuff  and  verify compatibility.  NetBSD  pcvt
might  be helpful  here. Optional  extensions: full(?)  ECMA-48 terminal
emulation,  dumb  terminal  emulation  (=  no  emulation)  for  embedded
systems.

5. VT font handling: Add VT220 compatibility (that's connected to the VT
emulation).  Add X11  font  compatibility. (that's  user-mode stuff  for
sure!) Remove 512 glyph limit  (no longer necessary due to framebuffer).
Possibly store fonts  deflated in the kernel (the code  is already there
for  networking  and  other  stuff)  to  save  memory  for  large  fonts
(unicode). Almost certainly implement sparse font tables for unicode.

Yours,
  Dominik Kubla

PS: I have put my console-patch up for grabs at:

    http://www-klinik.uni-mainz.de/staff/kubla/Linux/

RE: [Linuxconsole-dev] Welcome!!!

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

> but I do not see reason why I cannot move VC from one head to another. 

Why?  

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

Withe fbdev in theory you can up to 256 displays. 64 isn't going to cut
it. Also how do we split the 64 VC between 9 fbdev/keyboards. This is a
odd number which we have to write special code for. 

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

Okay. Almost. 

> 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 ...). From what
> I see graphics engines are way too different to put all emulation into
> kernel (in other way, I do not believe in DRI future, unless it is more
> powerfull than I think (I tried to get some info about that company
> and their products after press release from Jan 12 that PI will write
> Matrox drivers for Linux, but I failed... maybe I choosed wrong email)).

Something is wrong. We agree about DRI. Don't feel bad. Most kernel
developers that have sent them email seems to disappear into a black hole.
So far I'm the only one they responded to. That's because they don't like
me since i point out their design flaws.

"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

RE: [Linuxconsole-dev] EvStack - 2.3.x?

[Brad D. <Br...@NE...>]

> -----Original Message-----
> From: jmc...@li... [mailto:jmc...@li...]
> 
> Brad Douglas <Br...@ne...> wrote:
> > What was it about EvStack/GGI that Linus didn't like?
> 
> 	It was a monster patch. Huge. Vast changes. And it broke
> all current graphics applications. Go figure - he was nuts. ;^)

I found this post from Linus on LKML:

"And people still wonder why I'm not too impressed with GGI? No, I'm not
very impressed with people who think they have to rewrite the whole
world in order to fix a few small problems."

I don't think he's going to accept a rewrite, if that's what your intentions
are.

> > It appears that EvStacks (or some derivitive) is being used 
> for USB.  I'm
> > not sure why all input devices aren't using it.  Event 
> driven input seems
> > like a good idea (and very readable).
> 
> 	Its just the event packet system that EvStacks used (or one
> similar to it). It won't be too hard to add that code into the
> standard keyboard driver, and I have a serial mouse kernel driver
> also from GGI Console that could use the same interface.

The patch I saw included all input drivers.  It appears that Linus doesn't
believe all input needs to be switched to evstacks, let alone the console
depending on input drivers using it.

From the same LKML post:

"The same goes for input timing that somebody brought up as a thing that
"required" EvStack and kernel changes.  No such thing is required at
all: it is fairly trivial to have a very small thread that works as a
real-time process and has done a mlock() on the buffer it uses for
events.  Or probably hundreds of other solutions."

> > If this is something everyone can agree on, I'm up for testing.
> 
> 	Any other takers? I need at least TWO testers before I'll 
> start this - don't want it to die of lack of feedback like
> last time (And I know James - it was mostly my fault :^( - live
> and learn..)

Where can I grab a recent version of the code to look over?

Thanks,

Brad Douglas
br...@ne...
http://www.linux-fbdev.org

Re: [Linuxconsole-dev] EvStack - 2.3.x?

[<jmc...@li...>]

Brad Douglas <Br...@ne...> wrote:
> What was it about EvStack/GGI that Linus didn't like?

	It was a monster patch. Huge. Vast changes. And it broke
all current graphics applications. Go figure - he was nuts. ;^)

> It appears that EvStacks (or some derivitive) is being used for USB.  I'm
> not sure why all input devices aren't using it.  Event driven input seems
> like a good idea (and very readable).

	Its just the event packet system that EvStacks used (or one
similar to it). It won't be too hard to add that code into the
standard keyboard driver, and I have a serial mouse kernel driver
also from GGI Console that could use the same interface.

> If this is something everyone can agree on, I'm up for testing.

	Any other takers? I need at least TWO testers before I'll 
start this - don't want it to die of lack of feedback like
last time (And I know James - it was mostly my fault :^( - live
and learn..)


-- 
Jason McMullan, Senior Linux Consultant, Linuxcare, Inc.
412.422.8077 tel, 415.701.0792 fax
jmc...@li..., http://www.linuxcare.com/
Linuxcare. Support for the revolution.

RE: [Linuxconsole-dev] EvStack - 2.3.x?

[Brad D. <Br...@NE...>]

> -----Original Message-----
> From: jmc...@li... [mailto:jmc...@li...]
> 
>   Hey there. As I currently ``maintain'' (ha!) the EvStack/GGI Console
> system, is there any call for a reimplementation of GGI Console
> to 2.3.x, using the fbdev drivers instead of KGI? (not that
> KGI backend support can't be added..)

What was it about EvStack/GGI that Linus didn't like?

>   A functional port of the output side of GGI Console to the 
> 2.3.x kernel will proably give us a good base to work on
> multihead issues, and I can use the 2.3.x /dev/event system for 
> input.

It appears that EvStacks (or some derivitive) is being used for USB.  I'm
not sure why all input devices aren't using it.  Event driven input seems
like a good idea (and very readable).

>   Shouldn't take more that two weeks by myself to port it to
> the ix86 arch. Any takers on testing this project?

If this is something everyone can agree on, I'm up for testing.

Brad Douglas
br...@ne...
http://www.linux-fbdev.org

[Linuxconsole-dev] EvStack - 2.3.x?

[<jmc...@li...>]

  Hey there. As I currently ``maintain'' (ha!) the EvStack/GGI Console
system, is there any call for a reimplementation of GGI Console
to 2.3.x, using the fbdev drivers instead of KGI? (not that
KGI backend support can't be added..)

  A functional port of the output side of GGI Console to the 
2.3.x kernel will proably give us a good base to work on
multihead issues, and I can use the 2.3.x /dev/event system for 
input.

  Shouldn't take more that two weeks by myself to port it to
the ix86 arch. Any takers on testing this project?

-- 
Jason McMullan, Senior Linux Consultant, Linuxcare, Inc.
412.422.8077 tel, 415.701.0792 fax
jmc...@li..., http://www.linuxcare.com/
Linuxcare. Support for the revolution.

RE: [Linuxconsole-dev] Welcome!!!

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

On Thu, 2 Mar 2000, James A Simmons wrote:

> > 	Careful, a "head" is really just the set of all input and output
> > devices, and their associated event handling 'map', which are being used
> > by one person.  A binding, basically.  A "console" in the traditional UNIX
> > sense is a keyboard and a TTY.  A head could consist of a VT102 terminal,
> > or a standard PC keyboard + mouse + monitor + joystick, or even extreme
> > cases like two monitors, a braille touchpad on a serial port, a USB
> > joystick and keyboard, and no /dev/tty at all.  Heads and consoles are
> > often the same thing, but sometimes they will be quite different.
> 
> Very true. Consider a workstation with several sound cards. Each employee
> wants to listen to his own stuff. You have to make sure it goes to the
> right person. This has to be done. 

	Right, and this is easy if you decide not to treat any particular
I/O hardware or abstraction any differently from any other.  You have
event and data sources from input devices (keyboard, mouse, joystick,
remote network event sources, dummy devices, etc) and output devices
(framebuffer, TTY console, /dev/dsp, remote network event sinks, etc).
Event "packets" are generated by event sources, flow to event sinks
according to simple rulesets, and are handled by the event sinks.  As with
TCP networking, the kernel is basically a traffic cop.

	If you do this, suddenly the kernel does not have to deal with a
lot of issues that it does now.  The kernel does not need to care about
anything but the proper routing of abstract events according to internal
tables, just as it now does not have to care about what is inside the TCP
packets (well sort of, you know what I mean).  It just handles them
properly and lets the userspace applications figure out what they _mean_.  
Likewise, if you define a "head" as a binding of input devices and output
devices with some rules about where the events are routed, the kernel does
not have to care about the nature of the individual devices which are
bound into the head.  Whether the head is a VT102 terminal on a serial
port or a very complex multihead+remote setup as has been described before
does not matter _at all_ to the kernel.
 
> > 	Yes, this could be an issue.  Right now I advocate head == VT, but
> > for multi-monitor and such things this could get real ugly real fast |->.
> > Watch the kernel remap a dozen different widely varying types of input and
> > output devices back and forth every time you switch VCs!  Drown in races!
> > Throw spinlocks all over the place!  Get into remote event handling and
> > watch your network latency become your user interface latency!  Etc etc
> > etc.  Of course we will probably want to be able to do most or all of this
> > type of stuff, but Linus may balk at adding such complexity to the kernel,
> > at least all in one go |->.  IMHO, this is an issue for Linus to decide.
> 
> KISS. See my other post about what a tty is to linus.

	Well, if Linus were to allow an abstracted system like the one
outlined above, it would certainly be _different_ from what we have now.
But would it be more complex?  I say no!  I think it would be quite a bit
simpler conceptually, actually.  But we'll see what Linus is willing to
accept, I guess.
 
> > > How does this fit in with DRI (I'm unable to find decent documentation)?
> > > Are gfx and DRI trying to do the same thing?
> > 
> > 	More or less.  It would be very cool if we could design this new
> > console system such that it could easily support and plug into /dev/gfx,
> > DRI, KGI, fbdev, or any other potential kernel graphics (and input device)
> > driver framework(s). 
> 
> Removing the consoel system from hardware drivers is the way to go IMHO.

	Yes.

Jon

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

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

Re: [Linuxconsole-dev] Welcome!!!

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

On Thu, 2 Mar 2000, James A Simmons wrote:

> > 	I think that we have three major areas of concern which will drive
> > the design of this project:
> > 
> > 1: What do we need?
> > 	* Better multiheading, 
> > 	* Cleaner and more abstract [virtual] console representation,
> > 	* fbcon backwards compatibility,
> > 	* /dev/gfx integration,
> > 	* Abstract input devices and event flow graphing,
> > 	* ...others...
> 
> I think this shoudl go on the web page. 

	There is a lot of stuff that should go on the web page:

* Links to prevous console work:
	* Voitchek(sp?)'s unified input device work
	* fbcon/fbdev stuff
	* EvStack/GGI Console stuff
	* KGI console stuff
	* ...other links...

* Analyses of the current console and its problems (FAQs)

* Links to info on how other Un*xen handle their console subsystem designs

> > 2: What does Linus want?
> 
> Something that works. 

	That's not nearly enough info IMHO.  This "just go ahead and write
something and I'll either accept it or not" system causes coders to waste
a lot of time implementing ideas which are later shot down by Linus. And
since the console subsystem is one of the more fundamental and critical
parts of the kernel, I suspect that Linus will in fact have a lot of
requirements that he'll want met, both in terms of design and coding
methodology.  All he needs to do to eliminate the bulk of this uncertainty
is give some simple answers to these questions:

* Must we "morph" fbcon/fbdev into the new console system, one tiny patch
at a time, or can we make larger and more radical changes a la devfs?
The latter would be much easier on the console coders, but might cause
Linus more hassles.  Or it might not, especially if we take care to see
that it doesn't.

* If we must implement the new console by parts, what is the largest
acceptable size of the parts, and in what order should these be worked on?

* To what extent, if any, is it acceptable to integrate the new console
stuff and kernel graphics handling?  Obviously the two topics are closely
related in some ways, so how do we handle this?


> Show me the code is his mato. 

	"If you are the boss, and you want something done, give me at
least a little direction here please so I have a better chance of doing it
right for you" is my motto |->.  I mean, Linus must have _some_ opinions
on this issue, or he would not have rejected the original EvStack concept.  
EvStack/GGI Console is far and away the most complete new console code
around, AFAIK.  If Linus genuinely wants us to just start throwing code at
him to accept or reject, maybe that would be a good place to start...?

> Once coding begins I
> suggest we send him some patches to look at. He will then add his
> comments. Some good, some bad.

	See above.  We already have a LOT of console, abstract messaging
and abstract input device code available.  The best thing Linus can do for
us is to _quickly_ tell us which ideas he will _not_ accept, so we can
avoid dead-ends and wasted coding effort.
  
> > 3: What will Linus accept into 2.5.x?
> > 
> > 	EvStacks was a _really_ good design, but I guss it was too complex
> > and ambitious for Linus.  Therefore, we really need to know where Linus
> > stands on the issues before we do any significant amount of design work
> > this time around.
> 
> One thing I can guarantee is his position on what a console is. I had the
> discussion with him on private mappings and bending the rules for the
> linux-SGI GFX port. We wouldn't go for it. The reason why is the concept.
> To him a thread process is and will always be a lightweight process. As he
> stated it is what it is. If not then rules don't mean much and you might
> as well allow people to break the basic definations that define UNIX for
> their own gain. To him a tty will always be a keyboard and a display.
> Thats it. Breaking what the meaning of a tty is will not go over with
> him.   

	No, and I would not propose such a thing.  Obviously the new
console system must preserve the current abstractions, probably by
encapsulation and extension as devfs does.  If Linus wants to preserve the
concept of a TTY, fine.  All we need to do is define the concept of a
'head', and we can use that as our basic unit of binding context for VTs,
multiheading, etc.

Jon

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

RE: [Linuxconsole-dev] Welcome!!!

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

> 	Yes.  EvStacks maps a "scroller" (/dev/tty) onto a VT, connects
> some event sources/sinks to the VT, and presto you have a console.  James
> and the other console developers appear to be thinking along similar
> lines.

Yes. The move is to have each fbdev driver unaware of the console system.
Fbcon is the interface from fbdev to the console system.

> 	Careful, a "head" is really just the set of all input and output
> devices, and their associated event handling 'map', which are being used
> by one person.  A binding, basically.  A "console" in the traditional UNIX
> sense is a keyboard and a TTY.  A head could consist of a VT102 terminal,
> or a standard PC keyboard + mouse + monitor + joystick, or even extreme
> cases like two monitors, a braille touchpad on a serial port, a USB
> joystick and keyboard, and no /dev/tty at all.  Heads and consoles are
> often the same thing, but sometimes they will be quite different.

Very true. Consider a workstation with several sound cards. Each employee
wants to listen to his own stuff. You have to make sure it goes to the
right person. This has to be done. 

> 	Yes, this could be an issue.  Right now I advocate head == VT, but
> for multi-monitor and such things this could get real ugly real fast |->.
> Watch the kernel remap a dozen different widely varying types of input and
> output devices back and forth every time you switch VCs!  Drown in races!
> Throw spinlocks all over the place!  Get into remote event handling and
> watch your network latency become your user interface latency!  Etc etc
> etc.  Of course we will probably want to be able to do most or all of this
> type of stuff, but Linus may balk at adding such complexity to the kernel,
> at least all in one go |->.  IMHO, this is an issue for Linus to decide.

KISS. See my other post about what a tty is to linus.

> > How does this fit in with DRI (I'm unable to find decent documentation)?
> > Are gfx and DRI trying to do the same thing?
> 
> 	More or less.  It would be very cool if we could design this new
> console system such that it could easily support and plug into /dev/gfx,
> DRI, KGI, fbdev, or any other potential kernel graphics (and input device)
> driver framework(s). 

Removing the consoel system from hardware drivers is the way to go IMHO.

RE: [Linuxconsole-dev] Welcome!!!

[Petr V. <VAN...@vc...>]

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. 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...
> > 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.
> > >     * fbcon backwards compatibility,
> I'm working on that now with the new fbdev API.
'New fbdev API' does not look like backward compatibility stuff.
> > >     * 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 ...). From what
I see graphics engines are way too different to put all emulation into
kernel (in other way, I do not believe in DRI future, unless it is more
powerfull than I think (I tried to get some info about that company
and their products after press release from Jan 12 that PI will write
Matrox drivers for Linux, but I failed... maybe I choosed wrong email)).
                                                Best regards,
                                                    Petr Vandrovec
                                                    van...@vc...
                                                    

Re: [Linuxconsole-dev] multihead

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

> Here's a link to a page that discusses the issues with multihead under
> Linux.  Some of the diagrams are probably out of date.

> http://web1.turbolinux.com/%7Ebrad/patches/mhead/

Pretty good link. I sent him email to let him know whats going on.

RE: [Linuxconsole-dev] Welcome!!!

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

> > 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
a x amount to one fbdev head. Then a Y amount to another fbdev head etc.
If you insmod a fbdev driver you can use con2fb to map a console or group
of consoles to this new fbdev driver.

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

> > 	* fbcon backwards compatibility,

I'm working on that now with the new fbdev API.

> > 	* /dev/gfx integration,
> > 	* 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?

The input stuff as already been tempted by Vojtech. GFX and DRI should
have nothing to do with the console system. They should only make sure the
person is on the local console to allow access. No remote rendering. As a
side note DRI is aimed at lower end hardware. GFX is aimed at more modern
and higher level hardware. DRI is far to limited in design to work on SGI
hardware. SGI hardware isn't like PC hardware where you program a few
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.

> > 2: What does Linus want?
> 
> Beer?

Ha Ha!

Codito, ergo sum - "I code, therefore I am"
James Simmons                                                      (o_
fbdev/gfx developer                                      (o_  (o_ //\
http://www.linux-fbdev.org                              (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net

Re: [Linuxconsole-dev] Welcome!!!

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

> 	Well, I don't think that I can help with this too much - my web
> design skills are pretty bad.  Looka t http://libggi3d.sourceforge.net to
> see what I am capable of |->.

I see. Mine such too!

> 	I think that we have three major areas of concern which will drive
> the design of this project:
> 
> 1: What do we need?
> 	* Better multiheading, 
> 	* Cleaner and more abstract [virtual] console representation,
> 	* fbcon backwards compatibility,
> 	* /dev/gfx integration,
> 	* Abstract input devices and event flow graphing,
> 	* ...others...

I think this shoudl go on the web page. The accel handling issues is the
only point I don't agree. I will post the reason why in another post. 

> 2: What does Linus want?

Something that works. Show me the code is his mato. Once coding begins I
suggest we send him some patches to look at. He will then add his
comments. Some good, some bad.
 
> 3: What will Linus accept into 2.5.x?
> 
> 	EvStacks was a _really_ good design, but I guss it was too complex
> and ambitious for Linus.  Therefore, we really need to know where Linus
> stands on the issues before we do any significant amount of design work
> this time around.

One thing I can guarantee is his position on what a console is. I had the
discussion with him on private mappings and bending the rules for the
linux-SGI GFX port. We wouldn't go for it. The reason why is the concept.
To him a thread process is and will always be a lightweight process. As he
stated it is what it is. If not then rules don't mean much and you might
as well allow people to break the basic definations that define UNIX for
their own gain. To him a tty will always be a keyboard and a display.
Thats it. Breaking what the meaning of a tty is will not go over with
him.   

Codito, ergo sum - "I code, therefore I am"
James Simmons                                                      (o_
fbdev/gfx developer                                      (o_  (o_ //\
http://www.linux-fbdev.org                              (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net

RE: [Linuxconsole-dev] Welcome!!!

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

On Wed, 1 Mar 2000, Brad Douglas wrote:

> > -----Original Message-----
> > From: Jon M. Taylor [mailto:ta...@ec...]
> > 
> > 	I think that we have three major areas of concern which 
> > will drive
> > the design of this project:
> > 
> > 1: What do we need?
> > 	* Better multiheading,
> 
> Each head should have it's own console.  Is this already being worked on
> now?

	Yes.  EvStacks maps a "scroller" (/dev/tty) onto a VT, connects
some event sources/sinks to the VT, and presto you have a console.  James
and the other console developers appear to be thinking along similar
lines.
 
> > 	* 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.  

	Careful, a "head" is really just the set of all input and output
devices, and their associated event handling 'map', whcih are being used
by one person.  A binding, basically.  A "console" in the traditional UNIX
sense is a keyboard and a TTY.  A head could consist of a VT102 terminal,
or a standard PC keyboard + mouse + monitor + joystick, or even extreme
cases like two monitors, a braille touchpad on a serial port, a USB
joystick and keyboard, and no /dev/tty at all.  Heads and consoles are
often the same thing, but sometimes they will be quite different.

> I don't think this will be easily backward compatible
> and are there possible race conditions with each head having it's own VTs?

	Yes, this could be an issue.  Right now I advocate head == VT, but
for multi-monitor and such things this could get real ugly real fast |->.
Watch the kernel remap a dozen different widely varying types of input and
output devices back and forth every time you switch VCs!  Drown in races!
Throw spinlocks all over the place!  Get into remote event handling and
watch your network latency become your user interface latency!  Etc etc
etc.  Of course we will probably want to be able to do most or all of this
type of stuff, but Linus may balk at adding such complexity to the kernel,
at least all in one go |->.  IMHO, this is an issue for Linus to decide.
 
> > 	* fbcon backwards compatibility,
> > 	* /dev/gfx integration,
> > 	* 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?

	More or less.  It would be very cool if we could design this new
console system such that it could easily support and plug into /dev/gfx,
DRI, KGI, fbdev, or any other potential kernel graphics (and input device)
driver framework(s). That way we have a lot fewer issues to have religious
wars over |->.

Jon 

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

[Linuxconsole-dev] multihead

[Brad D. <Br...@NE...>]

Here's a link to a page that discusses the issues with multihead under
Linux.  Some of the diagrams are probably out of date.

http://web1.turbolinux.com/%7Ebrad/patches/mhead/

Thanks,

Brad Douglas
br...@ne...
http://www.linux-fbdev.org
 

RE: [Linuxconsole-dev] Welcome!!!

[Brad D. <Br...@NE...>]

> -----Original Message-----
> From: Jon M. Taylor [mailto:ta...@ec...]
> 
> 	Well, I don't think that I can help with this too much - my web
> design skills are pretty bad.  Looka t 
> http://libggi3d.sourceforge.net to
> see what I am capable of 
> |->.

Rockin! :)

> 	I think that we have three major areas of concern which 
> will drive
> the design of this project:
> 
> 1: What do we need?
> 	* Better multiheading,

Each head should have it's own console.  Is this already being worked on
now?

> 	* 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 don't think this will be easily backward compatible
and are there possible race conditions with each head having it's own VTs?

> 	* fbcon backwards compatibility,
> 	* /dev/gfx integration,
> 	* 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?

> 2: What does Linus want?

Beer?

> 3: What will Linus accept into 2.5.x?
> 
> 	EvStacks was a _really_ good design, but I guss it was 
> too complex
> and ambitious for Linus.  Therefore, we really need to know 
> where Linus
> stands on the issues before we do any significant amount of 
> design work
> this time around.

I'm slowly still looking over EvStacks...  No opinions, yet.

Thanks,

Brad Douglas
br...@ne...
http://www.linux-fbdev.org

Re: [Linuxconsole-dev] Welcome!!!

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

On Wed, 1 Mar 2000, James A Simmons wrote:

> 
> Welcome to the linux console project!!!!
> 
>     I see we have a quite a few people interested. I know some of the
> people on this list have attempted to design a new console system. The
> purpose of this project to unite the different workes people have done and
> to learn from each other experiences at trying to design a new console
> system. 
>    First things first. I need someone to work on the basic web pages.
> Even a link from http://linuxconsole.sourceforge.net to
> http://sourceforge.net/mail/?group_id=3063 will do. Also long as we have
> something that makes it easy for people to remember to get to.

	Well, I don't think that I can help with this too much - my web
design skills are pretty bad.  Looka t http://libggi3d.sourceforge.net to
see what I am capable of |->.

> The second
> one is a little hard to remember. The next step to come up with a common
> design goal. I have seen quite a few different designs with different
> goals in mind. 

	I think that we have three major areas of concern which will drive
the design of this project:

1: What do we need?
	* Better multiheading, 
	* Cleaner and more abstract [virtual] console representation,
	* fbcon backwards compatibility,
	* /dev/gfx integration,
	* Abstract input devices and event flow graphing,
	* ...others...

2: What does Linus want?

3: What will Linus accept into 2.5.x?

	EvStacks was a _really_ good design, but I guss it was too complex
and ambitious for Linus.  Therefore, we really need to know where Linus
stands on the issues before we do any significant amount of design work
this time around.

Jon

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

[Linuxconsole-dev] Welcome!!!

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

Welcome to the linux console project!!!!

    I see we have a quite a few people interested. I know some of the
people on this list have attempted to design a new console system. The
purpose of this project to unite the different workes people have done and
to learn from each other experiences at trying to design a new console
system. 
   First things first. I need someone to work on the basic web pages.
Even a link from http://linuxconsole.sourceforge.net to
http://sourceforge.net/mail/?group_id=3063 will do. Also long as we have
something that makes it easy for people to remember to get to. The second
one is a little hard to remember. The next step to come up with a common
design goal. I have seen quite a few different designs with different
goals in mind. The final step will be actually coding. I hope to work
this together with the 2.4.0 release. To keep up with 2.3.X will be
difficult so it would be easier to use a stable release. Since 2.4.X
is so close to release playing with 2.2.x would require us to port it
to 2.4.x in the near future. 

Codito, ergo sum - "I code, therefore I am"
James Simmons                                                      (o_
fbdev/gfx developer                                      (o_  (o_ //\
http://www.linux-fbdev.org                              (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net