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