Re: question about ruby's keyboard.c & keybdev.c

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

On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote:
> On Sun, Jul 07, 2002 at 08:52:43PM +0200, Vojtech Pavlik wrote:
> > On Sat, Jul 06, 2002 at 04:46:12PM +0200, Franz Sirl wrote:
> > > On Dienstag, 2. Juli 2002 14:52, Vojtech Pavlik wrote:
> > > > On Tue, Jul 02, 2002 at 01:03:06PM +0200, Franz Sirl wrote:
> > > > > With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS
> > > > > for maintenance reasons. keybdev.c provides bridge code between input
> > > > > layer and old-style keyboard.c. In ruby this is no longer necessary as
> > > > > the new-style keyboard.c registers itself directly to the input layer.
> > > > >
> > > > > Maybe you should just wait some more days, Vojtech should be merging this
> > > > > to Linus any day now.
> > > >
> > > > That's right, I'm working on the merge right now.
> > > 
> > > And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech!
> > > 
> > > While preparing the PPC part I noticed one thing though, how do you intend to  
> > > handle the platforms (2 PPC embedded boards and MIPS AFAICS) that redefined 
> > > kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far 
> > > (using ioremap/readb/writeb and sometimes special access sequences)?
> > > 
> > > Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers like 
> > > i8042-ppc.[ch]?
> > 
> > Depends on how much the keyboard controller is similar on those archs.
> 
> Well, in the case of the IBM Spruce (one of the two PPC embedded boards
> that changes things) has an Intel 82C42PC (S82C42C) to control the
> keyboard/mouse.  I'm not quite sure how that relates to i8042 however..

It's the chip, yes. i82c42pc is just a later version of the i8042 ...

> > > One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does this 
> > > really make sense?
> > 
> > Depends what CONFIG_ISA means. i8042 certainly resides on ISA (or what
> > remained of it) in PCs. It's not in an ISA slot, though. But it may not
> > be on ISA on other archs, so we might as well remove the #define.
> 
> That's the important part.  On a somewhat related note (I hope) how is
> the _kd_mksound stuff being handled with the new code?  The 'current'
> _kd_mksound (with PC timers 'n whatnot) works on some PPC32 machines

With the new code the keyboard just sends a "EV_SND, SND_BELL" event to
beep. If the keyboard can do it, it will. Otherwise a separate "beep
device" has to be registered that'll do the beep.

This "beep device" will have a very simple driver that'll program the
i8253 PIT on the PC, but can do other stuff elsewhere.

> (which have a SuperIO) but not on others, and I'd like to avoid turning
> on (or asking about) CONFIG_ISA on machines which have a SuperIO but no
> ISA slots.

Ok. Let's then say that CONFIG_ISA is only for ISA *slots* and then we
won't require it for hardware only found on mainboards (superio, etc).

-- 
Vojtech Pavlik
SuSE Labs