linuxconsole-dev

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

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?

[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] 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?

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

On Sat, Mar 04, 2000 at 11:48:05PM -0500, James Simmons wrote:
...
> 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) :( 

IMO console and vc's are different. So let's agree on consistent terminology
right away:

   console = /dev/console    System console device, might be serial terminal
                             or even a teletype/line printer.

   virtual tty's = /dev/tty[0-9]+

                             Virtual tty's with VT102 terminal emulation.
                             Should be called vt's IMHO and we should use
                             something like ptmx/pts to create the devices
                             on demand (what do you think? And PLEASE nobody
                             mention devfs in my presence!)

What i want to do is to separate the two. Keep the console small and clean.
If you are running linux on a PC104 embedded system with serial console,
then there is no need for VC's. Fortunately we can do this already, but the
code is still mixed right now.

Some thing we might want to look into is a network-base console (using UDP
unicast/multicast/broadcast or whatever one uses for these things).

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

The problem i see here is that this becomes too opaque for the casual user.
Might be clean and nice from a design standpoint, but will certainly irritate
some folks.

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

Ouch!  Your pulling my leg, do you?  We don't even have support for partioning
linux systems and you want to build a console framework for this?  But with
the /390 port and thingies like E10k around this is something we have to
think about.  I'll ask a friend of mine about his input: he's the local expert
for the Convex/HP supercomputers... I think they use a seperate HP workstation
as console device.

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

It's the same i posted to linux-kernel last week when this discussion
started.  Unfortunately i have (again!) no network when running >2.3.36
kernels and my laptop just forgot about some essential keys (i wonder
what the DELL support will say about this when i call in tomorrow!) so i
am somewhat hobbled at the moment.

Yours,
  Dominik
-- 
Looking for information about professional american football in Europe? 
Then visit the independant "NFL@Europe Fan Site" at:
            http://www-klinik.uni-mainz.de/staff/kubla/NFLE/

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

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

> IMO console and vc's are different. So let's agree on consistent terminology
> right away:
> 
>    console = /dev/console    System console device, might be serial terminal
>                              or even a teletype/line printer.
> 
>    virtual tty's = /dev/tty[0-9]+
> 
>                              Virtual tty's with VT102 terminal emulation.
>                              Should be called vt's IMHO and we should use
>                              something like ptmx/pts to create the devices
>                              on demand (what do you think? And PLEASE nobody
>                              mention devfs in my presence!)

Agree. In fact when I think VT I prefere to think of it as Video Terminal
instead of virtual terminal. In theory you could have vitrual terminals
even on serial consoles. 

P.S
  I read your page on devfs.   
 
> What i want to do is to separate the two. Keep the console small and clean.
> If you are running linux on a PC104 embedded system with serial console,
> then there is no need for VC's. Fortunately we can do this already, but the
> code is still mixed right now.

Agree. I like to see that as well. 

> Some thing we might want to look into is a network-base console (using UDP
> unicast/multicast/broadcast or whatever one uses for these things).

Wow. That would be powerful. 

> > 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.
> 
> The problem i see here is that this becomes too opaque for the casual user.
> Might be clean and nice from a design standpoint, but will certainly irritate
> some folks.

Well such a system is being used for USB already so I think people are
getting use to it. Especially people with iMacs which have only USB. 

> > 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. 
> 
> Ouch!  Your pulling my leg, do you?  We don't even have support for partioning
> linux systems and you want to build a console framework for this?  But with
> the /390 port and thingies like E10k around this is something we have to
> think about.  I'll ask a friend of mine about his input: he's the local expert
> for the Convex/HP supercomputers... I think they use a seperate HP workstation
> as console device.

Nope I'm not pulling you leg. 


> It's the same i posted to linux-kernel last week when this discussion
> started.  Unfortunately i have (again!) no network when running >2.3.36
> kernels and my laptop just forgot about some essential keys (i wonder
> what the DELL support will say about this when i call in tomorrow!) so i
> am somewhat hobbled at the moment.

I looked over your patch. It nice to see better VT102 emulation. I thought
you where the one that posted about splitting the terminal emulation from
the console code. You could do things like HP console emulation etc. Thats
a possible idea. 

"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 Sun, Mar 05, 2000 at 11:13:00AM -0500, James Simmons wrote:
> 
> I looked over your patch. It nice to see better VT102 emulation. I thought
> you where the one that posted about splitting the terminal emulation from

I mentioned that as my goal in the message posted to lkml.  So you are not
far of the mark. ;-)

> the console code. You could do things like HP console emulation etc. Thats
> a possible idea. 

All we need to do is to pull the necessary info out of *BSD's pcvt.  And
there are other interesting variants, like Siemens (for those BS2000 folks)
or even 5250 or 3270 (argh!). I have a VT420 reference manual at hand and
can loan VT340 programmers manual if need should be (imagine: REGIS or
SIXEL graphics on the console).  There is also the TEK4xxx emulation in
xterm (that would scrap the need for svgalib to run gnuplot on the console)

So there are lots of possibilities and if we offer a clean DDI to add
additional emulations besides the standard "linux" brand, we might see
them happen: people code all sorts of odd stuff if left alone with a
computer and some legacy hardware/software ;-)

Dominik
-- 
Looking for information about professional american football in Europe? 
Then visit the independant "NFL@Europe Fan Site" at:
            http://www-klinik.uni-mainz.de/staff/kubla/NFLE/

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

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

> > I looked over your patch. It nice to see better VT102 emulation. I thought
> > you where the one that posted about splitting the terminal emulation from
> 
> I mentioned that as my goal in the message posted to lkml.  So you are not
> far of the mark. ;-)

I thought so. I was going by memory. 

> > the console code. You could do things like HP console emulation etc. Thats
> > a possible idea. 
> 
> All we need to do is to pull the necessary info out of *BSD's pcvt.  And
> there are other interesting variants, like Siemens (for those BS2000 folks)
> or even 5250 or 3270 (argh!). I have a VT420 reference manual at hand and
> can loan VT340 programmers manual if need should be (imagine: REGIS or
> SIXEL graphics on the console).  There is also the TEK4xxx emulation in
> xterm (that would scrap the need for svgalib to run gnuplot on the console)

This would be really nice. I don't have any manuals for various terminals 
so it would be nice if you could send them to me. Or better yet if we get
them on the projects web page. If it's legal.  

> So there are lots of possibilities and if we offer a clean DDI to add
> additional emulations besides the standard "linux" brand, we might see
> them happen: people code all sorts of odd stuff if left alone with a
> computer and some legacy hardware/software ;-)

Yeap. I like to see this too. Eterm for the console :) So a great step
forward would be to move terminal emulation into a seperate file. Write a
common interface for terminal emulation and write a nice HOWTO to create
a terminal type. Either that or provide a way for userland to shape the
terminal to the type it wants. I like to see that also in a seperate
file. Which do we think is better to do? A userland interface to set the
console to some type of emulation or provide a interface so someone could
write their own terminal emulation module. I kind of like the userland
solution. It coudl get bloated really quick.

"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

[Linuxconsole-dev] Splitting console driver and VT emulation

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

On Tue, Mar 07, 2000 at 09:31:06AM -0500, James Simmons wrote:
> 
> This would be really nice. I don't have any manuals for various terminals 
> so it would be nice if you could send them to me. Or better yet if we get
> them on the projects web page. If it's legal.  
> 

Well, i can not send them and i think scanning and putting them on the web
is also a no-no.  So i will act as a document server for these docs... ;-)

I always intended to have the function description in the source right
at the start of the function...

> Yeap. I like to see this too. Eterm for the console :) So a great step
> forward would be to move terminal emulation into a seperate file. Write a
> common interface for terminal emulation and write a nice HOWTO to create
> a terminal type. Either that or provide a way for userland to shape the
> terminal to the type it wants. I like to see that also in a seperate
> file. Which do we think is better to do? A userland interface to set the
> console to some type of emulation or provide a interface so someone could
> write their own terminal emulation module. I kind of like the userland
> solution. It coudl get bloated really quick.

Make the terminal emulation a loadable module.  Have the console driver
look for module "vte" and then you can use the alias mechanismen of
modload to push the appropriate module.  If that fails fall back to dumb
line mode (similiar to the framebuffer initialization).

Does that appear a workable solution?

Dominik

Re: [Linuxconsole-dev] Splitting console driver and VT emulation

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

> Well, i can not send them and i think scanning and putting them on the web
> is also a no-no.  So i will act as a document server for these docs... ;-)
> 
> I always intended to have the function description in the source right
> at the start of the function...

So your in charge of that.

> Make the terminal emulation a loadable module.  Have the console driver
> look for module "vte" and then you can use the alias mechanismen of
> modload to push the appropriate module.  If that fails fall back to dumb
> line mode (similiar to the framebuffer initialization).
> 
> Does that appear a workable solution?

Yes:)

"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] Splitting console driver and VT emulation

[Jim P. <ji...@ag...>]

> > Make the terminal emulation a loadable module.  Have the console driver
> > look for module "vte" and then you can use the alias mechanismen of
> > modload to push the appropriate module.  If that fails fall back to dumb
> > line mode (similiar to the framebuffer initialization).
> > 
> > Does that appear a workable solution?
> 
> Yes:)

Another idea - the terminal emulator can live in user-space (a terminal-
emulator daemon ?), sitting on top of the normal Linux console code, or
fbdev, or GGI, or X, or whatever.  It can use /dev/ttyp? as the tty device.

It doesn't need to go into the kernel.  If we take the GGI approach of only
having hardware-banging stuff in the kernel, then there is no reason to have
the terminal emulator live there as well.  If we can get all the services we
need from the kernel one way or another, then the terminal emulator can live
outside.  This is what xterm does anyway - sits on X, grabs a pseudo-tty.

This may need to be a high-priority process to keep the display up-to-date
in the face of high system loads.  This is a downside, but there is also the
up-side that the application does not block whilst the display is updated
(as with a kernel solution), but only when the pipe buffer is full.  A
daemon updating once every frame or so could cut out a lot of unnecessary
updates when applications have rolling counters or whatever.

Any objections to this idea ?

The other thing to remember is that in the case of a real hardware terminal,
the only link to the main machine is a two-way serial cable.  So a terminal
emulator could live on the end of a couple of pipes, across the network if
necessary.  This is taking the detachment from the kernel to the extreme,
but perhaps you see the point.

Once you've worked out how to do multiple-keyboards, multiple-heads, and so
on in the kernel, the user-space daemon could be configured to pick these
up and make use of them.

The terminal emulator daemon could support many pseudo-ttys on one display,
using hot-keys to switch (just like Alt-Fn), or even two displays at the
same time, moving pseudo-ttys between them.  You can do a lot from
user-space if the kernel can provide the services.

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim@aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk

Re: [Linuxconsole-dev] Splitting console driver and VT emulation

[Eric S. R. <es...@th...>]

Jim Peters <ji...@ag...>:
> Another idea - the terminal emulator can live in user-space (a terminal-
> emulator daemon ?), sitting on top of the normal Linux console code, or
> fbdev, or GGI, or X, or whatever.  It can use /dev/ttyp? as the tty device.
> 
> It doesn't need to go into the kernel.  If we take the GGI approach of only
> having hardware-banging stuff in the kernel, then there is no reason to have
> the terminal emulator live there as well.  If we can get all the services we
> need from the kernel one way or another, then the terminal emulator can live
> outside.  This is what xterm does anyway - sits on X, grabs a pseudo-tty.
> 
> This may need to be a high-priority process to keep the display up-to-date
> in the face of high system loads.  This is a downside, but there is also the
> up-side that the application does not block whilst the display is updated
> (as with a kernel solution), but only when the pipe buffer is full.  A
> daemon updating once every frame or so could cut out a lot of unnecessary
> updates when applications have rolling counters or whatever.
> 
> Any objections to this idea ?

One big one.  I fear some terminal emulation has to be in the kernel,
otherwise the user will lose badly in pathological situations where the
hypothetical daemon doesn't start up.  Never forget the run-level 1 case.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"As to the species of exercise, I advise the gun. While this gives
[only] moderate exercise to the body, it gives boldness, enterprise,
and independence to the mind.  Games played with the ball and others
of that nature, are too violent for the body and stamp no character on
the mind. Let your gun, therefore, be the constant companion to your
walks."
        -- Thomas Jefferson, writing to his teenaged nephew.

Re: [Linuxconsole-dev] Splitting console driver and VT emulation

[Vojtech P. <vo...@su...>]

On Wed, Mar 08, 2000 at 12:30:08PM +0000, Jim Peters wrote:
> > > Make the terminal emulation a loadable module.  Have the console driver
> > > look for module "vte" and then you can use the alias mechanismen of
> > > modload to push the appropriate module.  If that fails fall back to dumb
> > > line mode (similiar to the framebuffer initialization).
> > > 
> > > Does that appear a workable solution?
> > 
> > Yes:)
> 
> Another idea - the terminal emulator can live in user-space (a terminal-
> emulator daemon ?), sitting on top of the normal Linux console code, or
> fbdev, or GGI, or X, or whatever.  It can use /dev/ttyp? as the tty device.
> 
> It doesn't need to go into the kernel.  If we take the GGI approach of only
> having hardware-banging stuff in the kernel, then there is no reason to have
> the terminal emulator live there as well.  If we can get all the services we
> need from the kernel one way or another, then the terminal emulator can live
> outside.  This is what xterm does anyway - sits on X, grabs a pseudo-tty.
> 
> This may need to be a high-priority process to keep the display up-to-date
> in the face of high system loads.  This is a downside, but there is also the
> up-side that the application does not block whilst the display is updated
> (as with a kernel solution), but only when the pipe buffer is full.  A
> daemon updating once every frame or so could cut out a lot of unnecessary
> updates when applications have rolling counters or whatever.
> 
> Any objections to this idea ?

Emergency situations. Cases when the daemon is not started. Cases of
system crashing and kernel oopsing and writing data to the screen. While
a full vt100 isn't needed for these cases, *some* terminal is needed,
right in the kernel.

-- 
Vojtech Pavlik
SuSE Labs

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

[<kim...@at...>]

> 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.
  The USB code uses a trimmed down version of Vojtech Pavlik's event 
interface for HID devices. That includes keyboards, mice, tablets, um, ups's 
I think, and pretty much anything that has a button on it.  The rest of his
complete input patch handles most mice, and joystickts(oh yeah, USB ones
too).  In the USB code the input interface is allready tagged as an option.
You need to enable keyboard compatibility and mouse emulation. If you don't
enable those options, then the only way to get input from those devices is
through his event interface device.
  I'm currently attempting to slap together an XFree4 driver for Vojtech's
interface in my spare time.  I'm hoping that with it you'll be able to have
X use a different keyboard than the kernel. Or, have two different X's use
different keyboards, for multiseat purposes.  
  As a matter of terminology, I think multiseat is a much better term for a
system where multiple people can sit down and have independant sessions. 
Were as multihead could also be just somebody with a 3840x1024 desktop. 
Both have their uses, and are /really/ neat, but we do need to tell the
ideas apart.
  Back to the existing code. From what I can tell of the internal kernel
interface, all handlers can get a shot at all input, if they feel like it.
Which is consistant with me being able to type and read from the keyboard
evdev at the same time.  So, if the console interface were able to handle
this style of input events the whole mess could be handled from either
userland or in the kernel, perhaps with some sort of fallover.
  userland: "cat /dev/evdev0 > /dev/consoledev0" effectivly attaches evdev0
to console0. Ugly, but functional.
  kernel: input_register_handler(&console_handler); - the same event parser
would be used, so we could get both interfaces for the price of one.
  As for that fallover, what I meant by that is, maybe, any device(s) not
explicitly claimed by anything else(any console) would just fall through to
a default. That way no configuration would need to be done in the
default/simplest case.  ei: you let the smoke out of your AT/PS2 keyboard
port. No problem, just plug in a USB keyboard and everything is happy.
  Then, of course, there is the biggest reason for considering Vojtech's
interface: It's allready in the kernel, via the USB code.
  
  -- Nick Lopez
     kim...@at...

Re: EvStack - 2.3.x?

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

>   I'm currently attempting to slap together an XFree4 driver for Vojtech's
> interface in my spare time.  I'm hoping that with it you'll be able to have
> X use a different keyboard than the kernel. Or, have two different X's use
> different keyboards, for multiseat purposes.  

This would be really nice.

>   As a matter of terminology, I think multiseat is a much better term for a
> system where multiple people can sit down and have independant sessions. 
> Were as multihead could also be just somebody with a 3840x1024 desktop. 
> Both have their uses, and are /really/ neat, but we do need to tell the
> ideas apart.
 
Alright. 

> So, if the console interface were able to handle
> this style of input events the whole mess could be handled from either
> userland or in the kernel, perhaps with some sort of fallover.

Right. 

>   userland: "cat /dev/evdev0 > /dev/consoledev0" effectivly attaches evdev0
> to console0. Ugly, but functional.

It should already be attached to the first console. I never liked the
idea of mapping devices from one head to another. Fbdev does this and it
has it problems. 

>   As for that fallover, what I meant by that is, maybe, any device(s) not
> explicitly claimed by anything else(any console) would just fall through to
> a default. That way no configuration would need to be done in the
> default/simplest case.  ei: you let the smoke out of your AT/PS2 keyboard
> port. No problem, just plug in a USB keyboard and everything is happy.

Hot pluggable devices will be fun to deal with. For a fully functional
console you want it to search for the one lacking that part and fill it
in.

>   Then, of course, there is the biggest reason for considering Vojtech's
> interface: It's allready in the kernel, via the USB code.

Yep.

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

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

[Firstname L. <ms...@ho...>]

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

Yes!  I have 2 matrox cards running fbdev, hooked to 2 monitors, a ps/2 
keyboard, and a USB keyboard working as /dev/InputX (acutally i have a ATI 
card and a 3rd monitor, but not enough PCI slots... had to take out to get 
the USB card in :)

I currently also have GGI running and use "tile" to tile across the 2 
monitors.

If you port evstack to the ix86, i'll test it on a recent 2.3.x

and if it works, i can start tossing all those old 386's i've been keeping 
around to use as dumb Xterms/clients. :)

Corey

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

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?

[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] EvStack - 2.3.x?

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

Forgot to post where the EvStack (ancient) code resides:

	http://zhrodague.net/~jmcc/ggi/EvStack/

Pull down the entrie CVS repository.

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