linuxconsole-dev

splitting ruby

[Justin C. <jp...@do...>]

Now 2.4.0 is out, whats next?

I think it might be a good idea to split ruby into 2 parts: the input side
(mostly working) and the console parts (still under dev), and try to get
the input side stuff into 2.4.1.

Any thoughts?

justin

Re: splitting ruby

[Franz S. <Fra...@la...>]

At 14:51 2001-01-09, Justin Cormack wrote:
>Now 2.4.0 is out, whats next?
>
>I think it might be a good idea to split ruby into 2 parts: the input side
>(mostly working) and the console parts (still under dev), and try to get
>the input side stuff into 2.4.1.

I'd _love_ to see this happen as it finally unlinks char/keyboard.c from 
char/pc_keyb.c (which is a big win for non-x86 and embedded people), but I 
doubt a bit Linus will accept it for the 2.4 series...

Franz.

Re: splitting ruby

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

> Now 2.4.0 is out, whats next?

A lot more work :-)  

> I think it might be a good idea to split ruby into 2 parts: the input side
> (mostly working) and the console parts (still under dev), and try to get
> the input side stuff into 2.4.1.

I agree except you will not see the rest of the input stuff go into
2.4.X. We will have to wait until 2.5.0. I have talked to Geert about this
as well. I think the best attack plan is:

1) Dump all the input drivers into the console system. 
2) Change all the fbdev drivers too. 
3) Change the console system.

I don't know if linus would be willing to dump all our work in at one
time. If he would be willing to do so then I would dump it all in. This of
course would require that we have partily working functionality on ALL
platforms. I can test the stuff on PPC, sparcs and alpha as well but
haven't yet. Plus I need to get into contact with the other platform
developers for this.

Re: splitting ruby

[Christoph H. <hc...@ns...>]

On Wed, Jan 10, 2001 at 09:10:33AM -0800, James Simmons wrote:
> I agree except you will not see the rest of the input stuff go into
> 2.4.X. We will have to wait until 2.5.0. I have talked to Geert about this
> as well. I think the best attack plan is:
>
> 1) Dump all the input drivers into the console system.
> 2) Change all the fbdev drivers too.
> 3) Change the console system.
>
> I don't know if linus would be willing to dump all our work in at one
> time. If he would be willing to do so then I would dump it all in. This of
> course would require that we have partily working functionality on ALL
> platforms. I can test the stuff on PPC, sparcs and alpha as well but
> haven't yet. Plus I need to get into contact with the other platform
> developers for this.
 
I'd also favor the partially merge.
IMHO the following order is best:

1) move the busmouse code (excluding ps2, because it is more difficult)
   over to input in 2.5.<veryearly> and merge the serial mouse code.
2) move over the other input drivers to new-style input code.  This
   will include Martin's old version of keyboard.c for the input drivers.
3) merge the new console code.  If possible in smaller chunks, because
   Linus likes that.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: splitting ruby

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

> I'd also favor the partially merge.
> IMHO the following order is best:
> 
> 1) move the busmouse code (excluding ps2, because it is more difficult)
>    over to input in 2.5.<veryearly> and merge the serial mouse code.
> 2) move over the other input drivers to new-style input code.  This
>    will include Martin's old version of keyboard.c for the input drivers.

Yeap. That sounds about right.

> 3) merge the new console code.  If possible in smaller chunks, because
>    Linus likes that.

First we need to change the fbdev drivers to the new api. Then we can
change the fbcon layer with ease.

Re: splitting ruby

[Franz S. <Fra...@la...>]

At 18:10 2001-01-10, James Simmons wrote:

> > Now 2.4.0 is out, whats next?
>
>A lot more work :-)
>
> > I think it might be a good idea to split ruby into 2 parts: the input side
> > (mostly working) and the console parts (still under dev), and try to get
> > the input side stuff into 2.4.1.
>
>I agree except you will not see the rest of the input stuff go into
>2.4.X. We will have to wait until 2.5.0. I have talked to Geert about this
>as well. I think the best attack plan is:
>
>1) Dump all the input drivers into the console system.
>2) Change all the fbdev drivers too.
>3) Change the console system.
>
>I don't know if linus would be willing to dump all our work in at one
>time. If he would be willing to do so then I would dump it all in. This of
>course would require that we have partily working functionality on ALL
>platforms. I can test the stuff on PPC, sparcs and alpha as well but
>haven't yet. Plus I need to get into contact with the other platform
>developers for this.

Well, I don't expect problems for PPC, as the adbhid.c driver is already 
part of 2.4.0, (sigh, reminds me to merge PPC code between ruby and 2.4.0) 
including the rest of the input code in 2.5.0 will just simplify the code 
and clarify configuration (especially on HW supporting both ADB and PS2 
keyboards) for us.

My TODO list for the full input code merge on PPC is quite short:
  - drop the emulate_raw() support for ADB keycodes, present in 2.4
  - drop the emulation code for 2nd and 3rd mouse button (maybe not?)
  - eventually write a handler kmmdev.c, that mixes keyboard and mouse 
events onto a single device (similar to /dev/input/mice) running the event 
protocol

Franz.

Re: splitting ruby

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

> Well, I don't expect problems for PPC, as the adbhid.c driver is already 
> part of 2.4.0, (sigh, reminds me to merge PPC code between ruby and 2.4.0)

Does this include a fix for the USB keyboard double repeat problem. I
tried a USB keyboard on a G4 and if you typed to fast it double printed 
each character. The same driver on a ix86 doesn't show thsi problem. I
have never been able to figure out what it was.
 
> including the rest of the input code in 2.5.0 will just simplify the code 
> and clarify configuration (especially on HW supporting both ADB and PS2 
> keyboards) for us.

Yes. The keyboard multiplexer code is very nice :-) Makes life much
easier.

> My TODO list for the full input code merge on PPC is quite short:
>   - drop the emulate_raw() support for ADB keycodes, present in 2.4

How will X work? The way XFree86 works is it places the VT in raw mode and
grabs the keycodes. You have to patch X to use /dev/event instead which at
the rate of XFree86 developement could be years from now. I plan to add a
printk that states using RAW mode is outdated. I hope this annoyes the
hell out of the XFree86 guys so they do fix it.

>   - drop the emulation code for 2nd and 3rd mouse button (maybe not?)

Could the emulation be done in userland? If so they you coudl drop it.

>   - eventually write a handler kmmdev.c, that mixes keyboard and mouse 
> events onto a single device (similar to /dev/input/mice) running the event 
> protocol

Why?