linuxconsole-dev

backport to 2.4?

[Andreas S. <an...@sc...>]

i would be very interested in a backport to 2.4. (especially
because of the 'Multi-desktop operation'. Is anyone doing this?
URL?

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

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

On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote:
> What do you all think about the appended patch? With the strategy in the patch
> it should be possible to initialize and use i8042 chips on pretty much every
> platform without code duplication.

What about adding asm/i8042.h instead of the ugly ifdef kludges?

Select an application on a HID tablet

[Freeze <fr...@fr...>]

Hi,
   I've a USB Trust tablet. It's an hid device.

   The tablet can work either in absolute, either in relative mode. Under
windows, the driver select which mode we want to select.

   But under linux, the tablet works in relative mode, and I don't know how
to switch the mode. I saw that there was 2 applications, one in relative, one
in absolute.

   So, my question is how can I send somthing to the device to told that I
want to use the absolute mode.

I've attached the description file to this mail. There are also some  keys
named F1 to F8 on the top of the tablet, but if they don't work. It doesn't
mind! I only want to use the tablet in absolute mode!

Cordially,
Freeze

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

[Tom R. <tr...@ke...>]

On Sat, Jul 13, 2002 at 07:12:59PM +0200, Franz Sirl wrote:
> On Samstag, 13. Juli 2002 16:40, Vojtech Pavlik wrote:
> > On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote:
> > > > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out
> > > > > instead of ioremap/readb/writeb, it assumes control and data register
> > > > > are 4 addresses apart and it assumes no special sequences are
> > > > > necessary to access these registers.
> > > >
> > > > Some time ago I thought about this when I looked at the sparc i8042
> > > > driver. I tried a few things but I didn't come up with a solution.
> > >
> > > What do you all think about the appended patch? With the strategy in the
> > > patch it should be possible to initialize and use i8042 chips on pretty
> > > much every platform without code duplication.
> > >
> > > The patch compiles on PPC (and thus should on x86 too), but I can't test
> > > it cause I don't have access to the affected embedded boards.
> > >
> > > If you like the approach, please apply it to the linux-input repo after
> > > testing on x86.
> >
> > A couple thoughs:
> >
> > 1) We could as well go back to using the asm/ include way, that way
> > we'd have less ifdefs, etc.
> 
> I don't think we would have many #ifdefs, hmm. With asm/ we would have 
> duplication of the header all over the place with nearly no difference. I 
> think in this case the maintainence burden is lower with the #ifdefs.

Isn't that what include/asm-generic/foo.h is for?  Or does that just get
abused into doing things like:
include/asm-$(ARCH)/foo.h
/*
 * We don't need anything special.
 */
#include <asm-generic/foo.h>

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

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

On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote:

> On Montag, 8. Juli 2002 19:01, James Simmons wrote:
> > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out
> > > instead of ioremap/readb/writeb, it assumes control and data register are
> > > 4 addresses apart and it assumes no special sequences are necessary to
> > > access these registers.
> >
> > Some time ago I thought about this when I looked at the sparc i8042
> > driver. I tried a few things but I didn't come up with a solution.
> 
> What do you all think about the appended patch? With the strategy in the patch 
> it should be possible to initialize and use i8042 chips on pretty much every 
> platform without code duplication.
> 
> The patch compiles on PPC (and thus should on x86 too), but I can't test it 
> cause I don't have access to the affected embedded boards.
> 
> If you like the approach, please apply it to the linux-input repo after 
> testing on x86.

Ok, pushed, should be there.

-- 
Vojtech Pavlik
SuSE Labs

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

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

On Samstag, 13. Juli 2002 16:40, Vojtech Pavlik wrote:
> On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote:
> > > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out
> > > > instead of ioremap/readb/writeb, it assumes control and data register
> > > > are 4 addresses apart and it assumes no special sequences are
> > > > necessary to access these registers.
> > >
> > > Some time ago I thought about this when I looked at the sparc i8042
> > > driver. I tried a few things but I didn't come up with a solution.
> >
> > What do you all think about the appended patch? With the strategy in the
> > patch it should be possible to initialize and use i8042 chips on pretty
> > much every platform without code duplication.
> >
> > The patch compiles on PPC (and thus should on x86 too), but I can't test
> > it cause I don't have access to the affected embedded boards.
> >
> > If you like the approach, please apply it to the linux-input repo after
> > testing on x86.
>
> A couple thoughs:
>
> 1) We could as well go back to using the asm/ include way, that way
> we'd have less ifdefs, etc.

I don't think we would have many #ifdefs, hmm. With asm/ we would have 
duplication of the header all over the place with nearly no difference. I 
think in this case the maintainence burden is lower with the #ifdefs.

We could do it like that in i8042.c though:

#include "i8042.h"
#ifdef CONFIG_PPC
#include "i8042-ppc.h"
#endif
#ifndef I8042_HAVE_PLATFORM_INLINES
static inline ....
#endif

That would avoid the generic i8042-io.h header.

Or what about a local i8042.h and a i8042-arch.h in asm/?

Anyway, just massage the patch as you would like it (or tell me exactly what 
solution you want) and push it, I'll send you any missing PPC parts then.

> 2) Do we really want to do all the nasty probing needed on x86 to detect
> the presence of the AUX port, on every arch out there? Well, maybe it
> doesn't hurt ...

It didn't hurt so far with the pc_keyb.c driver, so I guess it's OK. But on 
the other hand it would be no problem to put the AUX probing into another 
inline routine that platforms can override.

Franz.

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

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

On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote:

> > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out
> > > instead of ioremap/readb/writeb, it assumes control and data register are
> > > 4 addresses apart and it assumes no special sequences are necessary to
> > > access these registers.
> >
> > Some time ago I thought about this when I looked at the sparc i8042
> > driver. I tried a few things but I didn't come up with a solution.
> 
> What do you all think about the appended patch? With the strategy in the patch 
> it should be possible to initialize and use i8042 chips on pretty much every 
> platform without code duplication.
> 
> The patch compiles on PPC (and thus should on x86 too), but I can't test it 
> cause I don't have access to the affected embedded boards.
> 
> If you like the approach, please apply it to the linux-input repo after 
> testing on x86.

A couple thoughs:

1) We could as well go back to using the asm/ include way, that way
we'd have less ifdefs, etc.

2) Do we really want to do all the nasty probing needed on x86 to detect
the presence of the AUX port, on every arch out there? Well, maybe it
doesn't hurt ...

-- 
Vojtech Pavlik
SuSE Labs

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

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

On Montag, 8. Juli 2002 19:01, James Simmons wrote:
> > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out
> > instead of ioremap/readb/writeb, it assumes control and data register are
> > 4 addresses apart and it assumes no special sequences are necessary to
> > access these registers.
>
> Some time ago I thought about this when I looked at the sparc i8042
> driver. I tried a few things but I didn't come up with a solution.

What do you all think about the appended patch? With the strategy in the patch 
it should be possible to initialize and use i8042 chips on pretty much every 
platform without code duplication.

The patch compiles on PPC (and thus should on x86 too), but I can't test it 
cause I don't have access to the affected embedded boards.

If you like the approach, please apply it to the linux-input repo after 
testing on x86.

Franz.

[PATCH] New VT console system patch

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

Here is the patch I posted some time ago for the new console system. It
has been tested and has been in the Dave Jones tree for so time now.
The changes are:

The removal of struct kbd_struct from being passed around in sysrq.
Cleanup of keyboard.c in preperations for migrating to the input api.

 arch/i386/kernel/apm.c         |    2
 arch/ppc/xmon/start.c          |    2
 arch/ppc64/xmon/start.c        |    2
 drivers/acpi/system.c          |    2
 drivers/char/console.c         |   82 ++--
 drivers/char/keyboard.c        |  781 +++++++++++++++++++++--------------------
 drivers/char/sysrq.c           |   46 +-
 drivers/char/tty_io.c          |   15
 include/linux/console_struct.h |    1
 include/linux/sysrq.h          |   13
 10 files changed, 487 insertions(+), 459 deletions(-)

BK tree:

   http://linuxconsole.bkbits.net:8080/dev

diff:

    http://www.transvirtual.com/~jsimmons/console.diff.gz


Thank you.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

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

[Tom R. <tr...@ke...>]

On Mon, Jul 08, 2002 at 06:33:37PM +0200, Vojtech Pavlik wrote:
> On Mon, Jul 08, 2002 at 09:21:49AM -0700, Tom Rini wrote:
> > On Mon, Jul 08, 2002 at 05:59:24PM +0200, Vojtech Pavlik wrote:
> > > On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote:
> > > > 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 ...
> > 
> > Okay, that's good.  Will the current code remove the need for what
> > spruce_read_keyb_{data,status} (arch/ppc/platforms/spruce_setup.c) or
> > allow for overides like it is now?
> 
> Wow, the chip must be connected in some pretty non-simple way then.
> You'll most likely need a separate driver for spruce there.
> 
> By the way, is there a way to *write* to the keyboard controller on that
> machine?

Oh, and as Franz just pointed out to me on IRC, writing it much simpiler
(in arch/ppc/platforms/spruce.h) :)

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

[Tom R. <tr...@ke...>]

On Mon, Jul 08, 2002 at 06:33:37PM +0200, Vojtech Pavlik wrote:
> On Mon, Jul 08, 2002 at 09:21:49AM -0700, Tom Rini wrote:
> > On Mon, Jul 08, 2002 at 05:59:24PM +0200, Vojtech Pavlik wrote:
> > > On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote:
> > > > 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 ...
> > 
> > Okay, that's good.  Will the current code remove the need for what
> > spruce_read_keyb_{data,status} (arch/ppc/platforms/spruce_setup.c) or
> > allow for overides like it is now?
> 
> Wow, the chip must be connected in some pretty non-simple way then.
> You'll most likely need a separate driver for spruce there.
> 
> By the way, is there a way to *write* to the keyboard controller on that
> machine?

Well, from what I can tell of the documents
(http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/39BD3DAA6349C75F87256A0E0046344A)
about it all, I think it might be possible to get at the keyboard in a
different way, but the way we're doing it now is the suggested way to do
it by IBM on that particular memory map.  But I'm not entirely sure.
And it might be possible to write to the controller in a similar fashion
to how we read from it.  I need to go track down my coworker who did all
of this and ask him more..

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

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

> > Just a few more steps to go. I submited the console patches to Linus. Now
> > to wait for them to go in.
>
> Well, what are a few weeks more, I'm waiting for 2 years now for this code to
> go in.

Well it is a matter of convincing Linus to take the code. I sent him the
BK link for the console code some time ago. He hasn't applied it.


> > layer is if you want to change the api you need to change the upper
> > layer first and break every driver. Its the only way it will work.
>
> No complaint here, just searching for a solution :-).

Its the only way. BT Wprepare for major breakage for teh fbdev layer. Only
a few drivers will work very soon.

> Exactly. i8042.c has quite a few assumptions in it. It uses inb/out instead of
> ioremap/readb/writeb, it assumes control and data register are 4 addresses
> apart and it assumes no special sequences are necessary to access these
> registers.

Some time ago I thought about this when I looked at the sparc i8042
driver. I tried a few things but I didn't come up with a solution.

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

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

On Mon, Jul 08, 2002 at 09:21:49AM -0700, Tom Rini wrote:
> On Mon, Jul 08, 2002 at 05:59:24PM +0200, Vojtech Pavlik wrote:
> > On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote:
> > > 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 ...
> 
> Okay, that's good.  Will the current code remove the need for what
> spruce_read_keyb_{data,status} (arch/ppc/platforms/spruce_setup.c) or
> allow for overides like it is now?

Wow, the chip must be connected in some pretty non-simple way then.
You'll most likely need a separate driver for spruce there.

By the way, is there a way to *write* to the keyboard controller on that
machine?

> > > (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).
> 
> Sounds good to me..

-- 
Vojtech Pavlik
SuSE Labs

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

[Tom R. <tr...@ke...>]

On Mon, Jul 08, 2002 at 05:59:24PM +0200, Vojtech Pavlik wrote:
> On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote:
> > 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 ...

Okay, that's good.  Will the current code remove the need for what
spruce_read_keyb_{data,status} (arch/ppc/platforms/spruce_setup.c) or
allow for overides like it is now?

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

Sounds good to me..

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

[Benjamin H. <be...@ke...>]

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

Sounds good...

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

The whole point of detecting ISA-like (superio or whatever else) devices
has been discussed a bit at OLS & kernel summit. One idea that popped up
would be to have:

 - Arch fills the device tree whith informations about known
    ISA-like devices in the system
 - Drivers for those rely on the device-tree and stop mucking
    around possibly non-existent HW
 - In order to deal with the problem of legacy stuff for which
   we don't know really if the device is here before "probing" for
   it at various known ports & IRQs, the solution is to have the arch
   put that info in the device-tree as well (some kind of "need probe"
   flag instead of a resource).

That way, existing legacy x86 would just populate the device-tree with
default entries for legacy serial, kbd, ... stuffs with a "need probe"
flag. Newer x86 could use whatever (ACPI ?) tables are passed by the
BIOS to populate the device-tree.
Non-x86 can do the right thing ;)

Ben.

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

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

[Tom R. <tr...@ke...>]

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

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

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

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

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.

I'd prefer separate files if the driver on those arch (for example Sun)
where the separate driver wouldn't need to handle all the quirky PC
historic cruft, and thus be just a very simple driver. Also, if probing
is different (if for example firmware can tell you the thing is there),
it's worth a separate driver.

The code duplication won't be that bad.

But for Alpha for example, #defines for just the i/o and irqs will be
enough.

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

-- 
Vojtech Pavlik
SuSE Labs

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

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

On Sun, Jul 07, 2002 at 03:29:53PM +0200, Franz Sirl wrote:
> On Samstag, 6. Juli 2002 23:59, James Simmons wrote:
> > > > > 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.
> >
> > You still need keybdev.c with 2.5.25. It will be a few weeks before we
> > will migrate the console system to the input api.
> 
> No problem. The main problem isn't keybdev.c but pc_keyb.c. On PPC I just 
> disabled most of pc_keyb.c by adding this to asm/keyboard.h:
> 
> static inline void kbd_init_hw(void)
> {
> }
> 
> and removing the corresponding #define. Then atkbd.c and i8042.c can be used 
> without problems.
> 
> > > > That's right, I'm working on the merge right now.
> > >
> > > And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech!
> >
> > Just a few more steps to go. I submited the console patches to Linus. Now
> > to wait for them to go in.
> 
> Well, what are a few weeks more, I'm waiting for 2 years now for this code to 
> go in.

I'll be pushing a lot this week, and possibly manage to switch away from
keybdev.c this week also. There might not be a complete switch to
James's console code , just a hacked keyboard.c, but that'll work for
the time being.

-- 
Vojtech Pavlik
SuSE Labs

Re: iforce compilation fixes for 2.5.25

[Johann D. <joh...@la...>]

Brad Hards wrote:
> On Sun, 7 Jul 2002 19:10, Johann Deneux wrote:
> 
>>>>Those symbols were both used as "enums" for bus types and as
>>>>configuration options. Now IFORCE_{232,USB} is used for the bus type
>>>>only, and CONFIG_JOYSTICK_IFORCE_{232,USB}.
>>>>
>>>This sentence looks incomplete - I'm not following it.
>>>
>>It is indeed incomplete. The missing part is "for
>>configuration-dependent code".
>>
> So you used a construct like:
> 
>         case IFORCE_USB:
> 
> #ifdef CONFIG_JOYSTICK_IFORCE_USB
>                 iforce->cr.bRequest = packet[0];
> <random snippage>
> #else
>                 printk(KERN_ERR "iforce_get_id_packet: iforce->bus = USB!\n");
> #endif
>                 break;
> 
> 
> 

Yep
-- 
Johann

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

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

On Samstag, 6. Juli 2002 23:59, James Simmons wrote:
> > > > 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.
>
> You still need keybdev.c with 2.5.25. It will be a few weeks before we
> will migrate the console system to the input api.

No problem. The main problem isn't keybdev.c but pc_keyb.c. On PPC I just 
disabled most of pc_keyb.c by adding this to asm/keyboard.h:

static inline void kbd_init_hw(void)
{
}

and removing the corresponding #define. Then atkbd.c and i8042.c can be used 
without problems.

> > > That's right, I'm working on the merge right now.
> >
> > And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech!
>
> Just a few more steps to go. I submited the console patches to Linus. Now
> to wait for them to go in.

Well, what are a few weeks more, I'm waiting for 2 years now for this code to 
go in.

> > 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)?
>
> Why we break them. One thing I learned the hard way with the fbdev layer
> is if you want to change the api you need to change the upper layer first
> and break every driver. Its the only way it will work.

No complaint here, just searching for a solution :-).

> > Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers
> > like i8042-ppc.[ch]?
> >
> :-(

Exactly. i8042.c has quite a few assumptions in it. It uses inb/out instead of 
ioremap/readb/writeb, it assumes control and data register are 4 addresses 
apart and it assumes no special sequences are necessary to access these 
registers.

> > One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does
> > this really make sense?
>
> ??

On PPC quite a lot of embedded boards exist that have PS2 HW which is remapped 
to the standard IO addresses and thus i8042.c is useable out of the box. 
Nevertheless none of these boards have ISA slots (shudder!) and thus 
CONFIG_ISA isn't defined, preventing enabling of CONFIG_SERIO_I8042.

Franz.

Re: iforce compilation fixes for 2.5.25

[Brad H. <bh...@bi...>]

On Sun, 7 Jul 2002 19:10, Johann Deneux wrote:
> >>Those symbols were both used as "enums" for bus types and as
> >> configuration options. Now IFORCE_{232,USB} is used for the bus type
> >> only, and CONFIG_JOYSTICK_IFORCE_{232,USB}.
> >
> > This sentence looks incomplete - I'm not following it.
>
> It is indeed incomplete. The missing part is "for
> configuration-dependent code".
So you used a construct like:

        case IFORCE_USB:

#ifdef CONFIG_JOYSTICK_IFORCE_USB
                iforce->cr.bRequest = packet[0];
<random snippage>
#else
                printk(KERN_ERR "iforce_get_id_packet: iforce->bus = USB!\n");
#endif
                break;


-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: iforce compilation fixes for 2.5.25

[Johann D. <joh...@la...>]

Johann Deneux wrote:
> Brad Hards wrote:
> 
>> On Sun, 7 Jul 2002 19:15, Johann Deneux wrote:
>>
>>> On Sun, 7 Jul 2002, Brad Hards wrote:
>>>
>>>> The iforce code in 2.5.25 won't compile unless both USB and RS232
>>>> versions are built into the kernel.
>>>>
>>> Indeed. A user reported that bug this week, and I fixed it in the 
>>> version
>>> for 2.4.18. I have yet to include the fix in linuxconsole CVS.
>>>
>> Can you send to Linus for 2.5.25?
>>
> 
> Ok, I will.
> 
>>
>>>> This patch fixes the two issues:
>>>> 1. IFORCE_232 and IFORCE_USB are used in iforce-packet.c without 
>>>> testing
>>>> if they exist.
>>>>
>>> Those symbols were both used as "enums" for bus types and as 
>>> configuration
>>> options. Now IFORCE_{232,USB} is used for the bus type only, and
>>> CONFIG_JOYSTICK_IFORCE_{232,USB}.
>>>
>> This sentence looks incomplete - I'm not following it.
> 
> 
> It is indeed incomplete. The missing part is "for 
> configuration-dependent code".
> 
>>
>>>> 2. IFORCE_232 needs to be defined when the Config.in option is set as a
>>>> module or when built into the kernel. Same for IFORCE_USB.
>>>>
>>> The Config.in option can only be set to "y" or "n". iforce.o is a
>>> multi-part driver, and the choice for RS232 in Config.in just tells if
>>> iforce-serio.o should be included in iforce.o. Another option decides
>>> whether iforce.o should be a module or not.
>>>
>> That is _not_ how the Config.in looks in 2.5.25.
>>
> 
> Indeed. I obviously forgot to update the CVS. Working on it.
> 

No, I did not. drivers/input/joystick/Config.in differs in 2.5.25 and 
linuxconsole CVS. These lines should be replaced by
include iforce/config.in

Is that intentional ?

>> dep_tristate '  I-Force USB joysticks and wheels' 
>> CONFIG_JOYSTICK_IFORCE_USB $CONFIG_INPUT $CONFIG_INPUT_JOYSTICK 
>> $CONFIG_USB
>> dep_tristate '  I-Force Serial joysticks and wheels' 
>> CONFIG_JOYSTICK_IFORCE_232 $CONFIG_INPUT $CONFIG_INPUT_JOYSTICK 
>> $CONFIG_SERIO
>>
>> Brad
>>

-- 
Johann Deneux

Re: iforce compilation fixes for 2.5.25

[Johann D. <joh...@la...>]

Brad Hards wrote:
> On Sun, 7 Jul 2002 19:15, Johann Deneux wrote:
> 
>>On Sun, 7 Jul 2002, Brad Hards wrote:
>>
>>>The iforce code in 2.5.25 won't compile unless both USB and RS232
>>>versions are built into the kernel.
>>>
>>Indeed. A user reported that bug this week, and I fixed it in the version
>>for 2.4.18. I have yet to include the fix in linuxconsole CVS.
>>
> Can you send to Linus for 2.5.25?
> 

Ok, I will.

> 
>>>This patch fixes the two issues:
>>>1. IFORCE_232 and IFORCE_USB are used in iforce-packet.c without testing
>>>if they exist.
>>>
>>Those symbols were both used as "enums" for bus types and as configuration
>>options. Now IFORCE_{232,USB} is used for the bus type only, and
>>CONFIG_JOYSTICK_IFORCE_{232,USB}.
>>
> This sentence looks incomplete - I'm not following it. 
> 

It is indeed incomplete. The missing part is "for 
configuration-dependent code".

> 
>>>2. IFORCE_232 needs to be defined when the Config.in option is set as a
>>>module or when built into the kernel. Same for IFORCE_USB.
>>>
>>The Config.in option can only be set to "y" or "n". iforce.o is a
>>multi-part driver, and the choice for RS232 in Config.in just tells if
>>iforce-serio.o should be included in iforce.o. Another option decides
>>whether iforce.o should be a module or not.
>>
> That is _not_ how the Config.in looks in 2.5.25.
> 

Indeed. I obviously forgot to update the CVS. Working on it.

> dep_tristate '  I-Force USB joysticks and wheels' CONFIG_JOYSTICK_IFORCE_USB 
> $CONFIG_INPUT $CONFIG_INPUT_JOYSTICK $CONFIG_USB
> dep_tristate '  I-Force Serial joysticks and wheels' 
> CONFIG_JOYSTICK_IFORCE_232 $CONFIG_INPUT $CONFIG_INPUT_JOYSTICK $CONFIG_SERIO
> 
> Brad
> 
> BTW: Your email address is bouncing me, again.
> 

Again ??? Well you can use joh...@it... (this address does not 
have the somewhat strict spam filter). I will tell my sysadmins anyway.

> 

-- 
Johann Deneux

Re: iforce compilation fixes for 2.5.25

[Brad H. <bh...@bi...>]

On Sun, 7 Jul 2002 19:15, Johann Deneux wrote:
> On Sun, 7 Jul 2002, Brad Hards wrote:
> > The iforce code in 2.5.25 won't compile unless both USB and RS232
> > versions are built into the kernel.
>
> Indeed. A user reported that bug this week, and I fixed it in the version
> for 2.4.18. I have yet to include the fix in linuxconsole CVS.
Can you send to Linus for 2.5.25?

> > This patch fixes the two issues:
> > 1. IFORCE_232 and IFORCE_USB are used in iforce-packet.c without testing
> > if they exist.
>
> Those symbols were both used as "enums" for bus types and as configuration
> options. Now IFORCE_{232,USB} is used for the bus type only, and
> CONFIG_JOYSTICK_IFORCE_{232,USB}.
This sentence looks incomplete - I'm not following it. 

> > 2. IFORCE_232 needs to be defined when the Config.in option is set as a
> > module or when built into the kernel. Same for IFORCE_USB.
>
> The Config.in option can only be set to "y" or "n". iforce.o is a
> multi-part driver, and the choice for RS232 in Config.in just tells if
> iforce-serio.o should be included in iforce.o. Another option decides
> whether iforce.o should be a module or not.
That is _not_ how the Config.in looks in 2.5.25.

dep_tristate '  I-Force USB joysticks and wheels' CONFIG_JOYSTICK_IFORCE_USB 
$CONFIG_INPUT $CONFIG_INPUT_JOYSTICK $CONFIG_USB
dep_tristate '  I-Force Serial joysticks and wheels' 
CONFIG_JOYSTICK_IFORCE_232 $CONFIG_INPUT $CONFIG_INPUT_JOYSTICK $CONFIG_SERIO

Brad

BTW: Your email address is bouncing me, again.

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.