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