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/