linuxconsole-dev

New to the input layer

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

Hi,

I'm currently working on the integration of PMac ADB into the input layer. 
I use the 2.2.16 USB backport for my work and most stuff works well 
already. But I have some generic implementation questions now:

- who will assign a BUS_ADB number? I used 0x17 for now
- why is there no mixer device /dev/input/events similar to 
/dev/input/mice? Should I implement such a device?
- only 32 event devices, looks a bit short sighted?
- the [sg]etkeycode ioctls are not implemented yet, anyone working on this? 
If not, I'll probably give it a shot
- it seems an ioctl to set the key bitmap is needed, cause I have an USB 
keyboard here which reports 0x65 keys, when in reality it has 0x67 :-(
- what key entry in input.h relates to the "Fn" key found on notebooks?

Thanks,
Franz.

Re: New to the input layer

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

On Mon, Jul 03, 2000 at 01:02:08PM +0200, Franz Sirl wrote:
> Hi,
> 
> I'm currently working on the integration of PMac ADB into the input layer. 
> I use the 2.2.16 USB backport for my work and most stuff works well 
> already. But I have some generic implementation questions now:
> 
> - who will assign a BUS_ADB number? I used 0x17 for now

That's ok.

> - why is there no mixer device /dev/input/events similar to 
> /dev/input/mice? Should I implement such a device?

Is it needed for anything?

> - only 32 event devices, looks a bit short sighted?

There's space for up to 196 (64-255).

> - the [sg]etkeycode ioctls are not implemented yet, anyone working on this? 
> If not, I'll probably give it a shot

Please do.

> - it seems an ioctl to set the key bitmap is needed, cause I have an USB 
> keyboard here which reports 0x65 keys, when in reality it has 0x67 :-(

Really? What keyboard is it and what keys it doesn't report to have? I
think this is more likely to be included in a 'blacklist' in the hid
driver.

> - what key entry in input.h relates to the "Fn" key found on notebooks?

None - the Fn key on notebooks usually doesn't generate any scancodes.
Anyway, the "KEY_MACRO" (112) would make sense - it's used for keys like
that (Macro key, Logitech key, Multi key, or the Fn key).

-- 
Vojtech Pavlik
SuSE Labs

Re: New to the input layer

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

At 17:57 03.07.00, Vojtech Pavlik wrote:
>On Mon, Jul 03, 2000 at 01:02:08PM +0200, Franz Sirl wrote:
> > Hi,
> >
> > I'm currently working on the integration of PMac ADB into the input layer.
> > I use the 2.2.16 USB backport for my work and most stuff works well
> > already. But I have some generic implementation questions now:
> >
> > - who will assign a BUS_ADB number? I used 0x17 for now
>
>That's ok.

Fine. Please update input.h then, I'll remove my local definition as soon 
as they collide :-)

> > - why is there no mixer device /dev/input/events similar to
> > /dev/input/mice? Should I implement such a device?
>
>Is it needed for anything?

Well, I have noticed that on unplugging/replugging a device, it won't 
re-use the previous /dev/input/eventX if it is still held open by an 
application. That means applications have to scan the event devices 
continously themselves as soon as the device is removed, to check where it 
reappears. Think about an X user which unplugs his keyboard, plugs in a 
mouse and replugs the keyboard, does X have to scan then on which eventX 
device the keyboard reappears? I think this is overkill for the usual 
single-user single/multi-screen installations which probably make up 99.9% 
of all installations. With a /dev/input/events mixer device X can attach to 
a single device for all events and doesn't have to care what the user does 
with them. Maybe a ioctl to attach/detach event devices from the event 
mixer would be a good idea then.

> > - only 32 event devices, looks a bit short sighted?
>
>There's space for up to 196 (64-255).

Yes, I know. I was searching for a good minor for /dev/input/events. 
Probably 255 then :-).


> > - the [sg]etkeycode ioctls are not implemented yet, anyone working on 
> this?
> > If not, I'll probably give it a shot
>
>Please do.

OK, I will try to come up with a patch this week.

> > - it seems an ioctl to set the key bitmap is needed, cause I have an USB
> > keyboard here which reports 0x65 keys, when in reality it has 0x67 :-(
>
>Really? What keyboard is it and what keys it doesn't report to have? I
>think this is more likely to be included in a 'blacklist' in the hid
>driver.

It's a Lindy USB kbd for Macintosh, german version. It looks similar to the 
MacSense one. It reports itself as ALCOR 9410 (this seems to be the ID of 
the generic Alcor kbd/hub chip, so it's probably hard to distinguish from 
PC keyboards), language ID 409. The missing keys are KEY_POWER (0x66) and 
KEY_KPEQUAL (0x67). I'll try to find out if MacOS uses some initialization 
USB command to switch the keyboard to a different mode.


> > - what key entry in input.h relates to the "Fn" key found on notebooks?
>
>None - the Fn key on notebooks usually doesn't generate any scancodes.
>Anyway, the "KEY_MACRO" (112) would make sense - it's used for keys like
>that (Macro key, Logitech key, Multi key, or the Fn key).

Aha, thanks. Some Powerbooks with ADB keyboards seem to report this key.

Franz.

Re: New to the input layer

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

On Mon, Jul 03, 2000 at 06:57:31PM +0200, Franz Sirl wrote:
> At 17:57 03.07.00, Vojtech Pavlik wrote:
> >On Mon, Jul 03, 2000 at 01:02:08PM +0200, Franz Sirl wrote:
> > > Hi,
> > >
> > > I'm currently working on the integration of PMac ADB into the input layer.
> > > I use the 2.2.16 USB backport for my work and most stuff works well
> > > already. But I have some generic implementation questions now:
> > >
> > > - who will assign a BUS_ADB number? I used 0x17 for now
> >
> >That's ok.
> 
> Fine. Please update input.h then, I'll remove my local definition as soon 
> as they collide :-)

Ok. Added.

> > > - why is there no mixer device /dev/input/events similar to
> > > /dev/input/mice? Should I implement such a device?
> >
> >Is it needed for anything?
> 
> Well, I have noticed that on unplugging/replugging a device, it won't 
> re-use the previous /dev/input/eventX if it is still held open by an 
> application. That means applications have to scan the event devices 
> continously themselves as soon as the device is removed, to check where it 
> reappears. Think about an X user which unplugs his keyboard, plugs in a 
> mouse and replugs the keyboard, does X have to scan then on which eventX 
> device the keyboard reappears? I think this is overkill for the usual 
> single-user single/multi-screen installations which probably make up 99.9% 
> of all installations. With a /dev/input/events mixer device X can attach to 
> a single device for all events and doesn't have to care what the user does 
> with them. Maybe a ioctl to attach/detach event devices from the event 
> mixer would be a good idea then.

Creating /dev/input/events is the wrong approach. Creating a way how to
make an already-open disappearing and appearing again device to appear
back at the same device number.

The device number is currently held busy until it's not referenced
anymore. It doesn't have to be so.

> > > - only 32 event devices, looks a bit short sighted?
> >
> >There's space for up to 196 (64-255).
> 
> Yes, I know. I was searching for a good minor for /dev/input/events. 
> Probably 255 then :-).

I really don't think it's needed. We would have to add some device ID to
struct input_event, because mixing input from a joystick and a tablet
(or two joysticks or whatever) simply wouldn't work.

> > > - the [sg]etkeycode ioctls are not implemented yet, anyone working on 
> > this?
> > > If not, I'll probably give it a shot
> >
> >Please do.
> 
> OK, I will try to come up with a patch this week.

The ioctls should modify the event->keymap structure.

> >Really? What keyboard is it and what keys it doesn't report to have? I
> >think this is more likely to be included in a 'blacklist' in the hid
> >driver.
> 
> It's a Lindy USB kbd for Macintosh, german version. It looks similar to the 
> MacSense one. It reports itself as ALCOR 9410 (this seems to be the ID of 
> the generic Alcor kbd/hub chip, so it's probably hard to distinguish from 
> PC keyboards), language ID 409. The missing keys are KEY_POWER (0x66) and 
> KEY_KPEQUAL (0x67). I'll try to find out if MacOS uses some initialization 
> USB command to switch the keyboard to a different mode.

Ok. Implementing setkeycode with USB keyboards won't be easy, since
hid.c has a quite complicated structure for this. If you won't be able
to find any such initialization (and even if you will) I think an
exception in the hid.c driver for this keyboard will be needed.

> >None - the Fn key on notebooks usually doesn't generate any scancodes.
> >Anyway, the "KEY_MACRO" (112) would make sense - it's used for keys like
> >that (Macro key, Logitech key, Multi key, or the Fn key).
> 
> Aha, thanks. Some Powerbooks with ADB keyboards seem to report this key.

Ok.

-- 
Vojtech Pavlik
SuSE Labs

Re: New to the input layer

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

At 23:36 03.07.00, Vojtech Pavlik wrote:
> > > > - why is there no mixer device /dev/input/events similar to
> > > > /dev/input/mice? Should I implement such a device?
> > >
> > >Is it needed for anything?
> >
> > Well, I have noticed that on unplugging/replugging a device, it won't
> > re-use the previous /dev/input/eventX if it is still held open by an
> > application. That means applications have to scan the event devices
> > continously themselves as soon as the device is removed, to check where it
> > reappears. Think about an X user which unplugs his keyboard, plugs in a
> > mouse and replugs the keyboard, does X have to scan then on which eventX
> > device the keyboard reappears? I think this is overkill for the usual
> > single-user single/multi-screen installations which probably make up 99.9%
> > of all installations. With a /dev/input/events mixer device X can 
> attach to
> > a single device for all events and doesn't have to care what the user does
> > with them. Maybe a ioctl to attach/detach event devices from the event
> > mixer would be a good idea then.
>
>Creating /dev/input/events is the wrong approach. Creating a way how to
>make an already-open disappearing and appearing again device to appear
>back at the same device number.

Seems like a quite difficult task to me...


>The device number is currently held busy until it's not referenced
>anymore. It doesn't have to be so.

Hmm. Let me think about that... What will the application see? I don't see 
a type  like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED?

> > > > - only 32 event devices, looks a bit short sighted?
> > >
> > >There's space for up to 196 (64-255).
> >
> > Yes, I know. I was searching for a good minor for /dev/input/events.
> > Probably 255 then :-).
>
>I really don't think it's needed. We would have to add some device ID to
>struct input_event, because mixing input from a joystick and a tablet
>(or two joysticks or whatever) simply wouldn't work.

I see. Actually, what I'm looking for is a reasonable simple way to port 
some legacy (but unfortunately still needed) applications to the input 
layer... Hmm, I can live with mice and keyboards being separate, so would 
you accept if I added a keyboard mixer device to keybdev.c?


> > > > - the [sg]etkeycode ioctls are not implemented yet, anyone working on
> > > this?
> > > > If not, I'll probably give it a shot
> > >
> > >Please do.
> >
> > OK, I will try to come up with a patch this week.
>
>The ioctls should modify the event->keymap structure.

Sure. But you mean event->keycode, or?


> > >Really? What keyboard is it and what keys it doesn't report to have? I
> > >think this is more likely to be included in a 'blacklist' in the hid
> > >driver.
> >
> > It's a Lindy USB kbd for Macintosh, german version. It looks similar to 
> the
> > MacSense one. It reports itself as ALCOR 9410 (this seems to be the ID of
> > the generic Alcor kbd/hub chip, so it's probably hard to distinguish from
> > PC keyboards), language ID 409. The missing keys are KEY_POWER (0x66) and
> > KEY_KPEQUAL (0x67). I'll try to find out if MacOS uses some initialization
> > USB command to switch the keyboard to a different mode.
>
>Ok. Implementing setkeycode with USB keyboards won't be easy, since
>hid.c has a quite complicated structure for this. If you won't be able
>to find any such initialization (and even if you will) I think an
>exception in the hid.c driver for this keyboard will be needed.

I'll try to find out more.

BTW, are there any known problems with the current backport and console 
switching? It seems to lock down some of the modifier keys from time to 
time, then you have to press all of them to get them back in a known state.
And it seems the LED status sent to USB keyboards is inverted.

Franz.

Re: New to the input layer

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

On Tue, Jul 04, 2000 at 12:25:17PM +0200, Franz Sirl wrote:

> >Creating /dev/input/events is the wrong approach. Creating a way how to
> >make an already-open disappearing and appearing again device to appear
> >back at the same device number.
> 
> Seems like a quite difficult task to me...

But something like that will be badly needed for other parts of the
system as well. For example the USB Storage driver already does it. So
it's possible.

> Hmm. Let me think about that... What will the application see? I don't see 
> a type like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED?

Right now, the events from the device will just stop coming in.

> I see. Actually, what I'm looking for is a reasonable simple way to port 
> some legacy (but unfortunately still needed) applications to the input 
> layer... Hmm, I can live with mice and keyboards being separate, so would 
> you accept if I added a keyboard mixer device to keybdev.c?

Keybdev.c already does that, and keyboard.c (in the complete input
drivers) is doing it as well.

> >The ioctls should modify the event->keymap structure.
> 
> Sure. But you mean event->keycode, or?

Sorry, I meant struct input_dev->keycode. I should have checked the
sources first.

> >Ok. Implementing setkeycode with USB keyboards won't be easy, since
> >hid.c has a quite complicated structure for this. If you won't be able
> >to find any such initialization (and even if you will) I think an
> >exception in the hid.c driver for this keyboard will be needed.
> 
> I'll try to find out more.
> 
> BTW, are there any known problems with the current backport and console 
> switching? It seems to lock down some of the modifier keys from time to 
> time, then you have to press all of them to get them back in a known state.
> And it seems the LED status sent to USB keyboards is inverted.

There seems to be a problem with some keys not getting released
correctly. I wasn't able to find the cause yet.

-- 
Vojtech Pavlik
SuSE Labs

Re: New to the input layer

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

At 13:19 04.07.00, Vojtech Pavlik wrote:
>But something like that will be badly needed for other parts of the
>system as well. For example the USB Storage driver already does it. So
>it's possible.

I'll check that out.


> > Hmm. Let me think about that... What will the application see? I don't see
> > a type like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED?
>
>Right now, the events from the device will just stop coming in.

Hmm, this means even input layer aware applications will have no chance to 
react? Is anything planned in this area?

> > I see. Actually, what I'm looking for is a reasonable simple way to port
> > some legacy (but unfortunately still needed) applications to the input
> > layer... Hmm, I can live with mice and keyboards being separate, so would
> > you accept if I added a keyboard mixer device to keybdev.c?
>
>Keybdev.c already does that, and keyboard.c (in the complete input
>drivers) is doing it as well.

Heh, but they mix to "legacy" console devices (or do I miss something 
here?), I want an event protocol device :-). Remember, on PPC we used ADB 
scancodes so far. I don't wan't to change to AT scancodes now and then 
again to events, when the input layer is 100% ready. That's why I want a 
/dev/input/keyboards, running the event protocol. I'll make it CONFIG_PPC 
specific if you want.

> > BTW, are there any known problems with the current backport and console
> > switching? It seems to lock down some of the modifier keys from time to
> > time, then you have to press all of them to get them back in a known state.
> > And it seems the LED status sent to USB keyboards is inverted.
>
>There seems to be a problem with some keys not getting released
>correctly. I wasn't able to find the cause yet.

I have a feeling that this might be related to key repeat. What happens to 
the repeat timers on console switch?

Also do you know if the LED's on USB keyboards work correctly on a PC? 
Benjamin is working with the USB analyzer today and will look at this.

Benjamin Herrenschmidt wrote a few minutes ago on IRC/#mklinux/EFnet:
<BenH> Also, I have the HID specs, I'll be able to look at those LEDs 
problems. I'd like to know if they work on PC however
<BenH> Looks like apple leaves KBDs in boot protocol on MacOS 9
<BenH> They do a SetProtocol(0), a SetIdle, a few SetReport and that's all

Franz.

Re: New to the input layer

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

On Tue, Jul 04, 2000 at 02:12:28PM +0200, Franz Sirl wrote:

> > > Hmm. Let me think about that... What will the application see? I don't see
> > > a type like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED?
> >
> >Right now, the events from the device will just stop coming in.
> 
> Hmm, this means even input layer aware applications will have no chance to 
> react? Is anything planned in this area?

This has to be solved. I'm open to suggestions, here go two that could
work:

1) Have a /proc/bus/input/devices file (or some elseplace a similar
node) that'd list currently existant input devices. select() on it would
tell the app that the list has changed and should be reread. Nothing
needs to be changed in evdev.c behaviour.

2) Like 1 but also return -ENODEV on read to non-existing devices
(instead blocking / returning -EAGAIN forever).

3) As you suggest, EV_STATUS or something like that telling the app the
device is gone and/or reconnected.

> Heh, but they mix to "legacy" console devices (or do I miss something 
> here?), I want an event protocol device :-). Remember, on PPC we used ADB 
> scancodes so far. I don't wan't to change to AT scancodes now and then 
> again to events, when the input layer is 100% ready. That's why I want a 
> /dev/input/keyboards, running the event protocol. I'll make it CONFIG_PPC 
> specific if you want.

I think it'd be better to solve the connect/disconnect issue once and
forever and mix the data in userland. You'd need to add a lot of stuff
to evdev.c (usecounting ala mousedev.c which is plain ugly) to implement
the keyboards device.

> I have a feeling that this might be related to key repeat. What happens to 
> the repeat timers on console switch?

The repeat is handled in input.c. It doesn't know of console switches.

> Also do you know if the LED's on USB keyboards work correctly on a PC? 

Yes, both with plain 2.4 kernels and 2.4+ruby.

> Benjamin is working with the USB analyzer today and will look at this.
> Benjamin Herrenschmidt wrote a few minutes ago on IRC/#mklinux/EFnet:
> <BenH> Also, I have the HID specs, I'll be able to look at those LEDs 
> problems. I'd like to know if they work on PC however

They do.

> <BenH> Looks like apple leaves KBDs in boot protocol on MacOS 9

We'll have to switch it to full HID then. But I think we're already
doing that in hid.c

> <BenH> They do a SetProtocol(0), a SetIdle, a few SetReport and that's all

Makes sense.

-- 
Vojtech Pavlik
SuSE Labs

Re: New to the input layer

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

> 3) As you suggest, EV_STATUS or something like that telling the app the
> device is gone and/or reconnected.

I like this approach but instead of expensive ioctl calls we send
EV_STATUS events.

> > Heh, but they mix to "legacy" console devices (or do I miss something 
> > here?), I want an event protocol device :-). Remember, on PPC we used ADB 
> > scancodes so far. I don't wan't to change to AT scancodes now and then 
> > again to events, when the input layer is 100% ready. That's why I want a 
> > /dev/input/keyboards, running the event protocol. I'll make it CONFIG_PPC 
> > specific if you want.

Legacy devices. The way ruby works for keyboards is:

"native keyboard" -> event -> input -> /dev/event
 PS/2 or ADB etc	   |
			   |
			   ------- keyboard.c -> console system.

So a /dev/input/event should be created and the ADB input driver
translates it to a event packet. The console system works with these event
packets. This allows for a universal interface for the console with
keyboards. At the same time it allows for /dev/input/eventX to be used for
any type of keyboard. 
		 	
Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: New to the input layer

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

> > Hmm. Let me think about that... What will the application see? I don't see 
> > a type like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED?
> 
> Right now, the events from the device will just stop coming in.

What if we create a CONNECT, DISCONNECT event to send to the userland
application ? This way the userland app can decided on what to do.

> Keybdev.c already does that, and keyboard.c (in the complete input
> drivers) is doing it as well.

Ruby doesn't use keybdev.c still right?

> > BTW, are there any known problems with the current backport and console 
> > switching? It seems to lock down some of the modifier keys from time to 
> > time, then you have to press all of them to get them back in a known state.
> > And it seems the LED status sent to USB keyboards is inverted.
> 
> There seems to be a problem with some keys not getting released
> correctly. I wasn't able to find the cause yet.

Console switching is independent of the modifier key handling. I have no
trouble with PC PS/2 keyboards. Sounds like the problem is USB keyboard
specific. What I do see is when I press F1 I get A, F2 I get B etc. I
think this is just a strange keymaping going on. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: New to the input layer

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

At 13:19 04.07.00, Vojtech Pavlik wrote:
>On Tue, Jul 04, 2000 at 12:25:17PM +0200, Franz Sirl wrote:
> > BTW, are there any known problems with the current backport and console
> > switching? It seems to lock down some of the modifier keys from time to
> > time, then you have to press all of them to get them back in a known state.
> > And it seems the LED status sent to USB keyboards is inverted.
>
>There seems to be a problem with some keys not getting released
>correctly. I wasn't able to find the cause yet.

Hi Vojtech,

the modifier keys work fine for me now, that was caused by a 
misinterpretation on my side on how the global key_maps variable works, 
also char/keyboard.c in 2.2 at least contains a small uncleanliness, it 
accesses plain_map[i] directly instead of key_maps[0][i] to compute the 
shift state.

Now that we have binary kernels with the current backport and ADB converted 
to the input layer around, we get the first reports flowing in :-). Could 
you please assign numbers for the KEY_UNKNOWN in the message I have 
appended? Ignore the underscore/KEY_JPN stuff, that one just misses 
conversion to the ADB keycodes, I'll fix that on my side. It might be a 
good idea to report the KEY_UNKNOWN's without the user having to enable 
DEBUG and DEBUG_DATA in hid.c.

But in general we've got very few problem reports so far, so you'll get 
input layer aware ADB drivers for ruby in a few days, after we did our 
internal merges into our 2.2 and 2.4 trees.

Franz.

------ Forwarded Message -------
From: Hollis Blanchard <ho...@am...>
To: Fra...@la...
Subject: Japanese USB kbd stuff

Here you are.

These are all unknown ("keyboard.c: can't emulate rawmode for keycode
180"):

kanji conversion key: 0091
kana conversion key: 0090
keypad comma: 0085
underscore (KEY_JPN I think?): 0087
\ (aka yen, shifted to |) key: 0089

Both of these produce a "ctrl urb status = -32" message on every
keypress:

keypad numlock: 0053
caps lock: 0039

-HollisJul  7 22:34:24 localhost kernel: klogd 1.3-3, log source = 
/proc/kmsg started.
Jul  7 22:34:24 localhost kernel: Inspecting /boot/System.map
Jul  7 22:34:24 localhost kernel: Symbol table has incorrect version number.
Jul  7 22:34:24 localhost kernel: Cannot find map file.
Jul  7 22:34:24 localhost kernel: No module symbols loaded.
Jul  7 22:34:24 localhost kernel: device tree used 34608 bytes
Jul  7 22:34:24 localhost kernel: Total memory = 256MB; using 1024kB for 
hash table (at c0400000)
Jul  7 22:34:24 localhost kernel: Linux version 2.2.17pre10-ben1 (root@g4) 
(gcc version 2.95.2 19991024 (release/franzo)) #2 Fri Jul 7 20:56:25 JST 2000
Jul  7 22:34:24 localhost kernel: PCI bus 0 controlled by pci at f0000000
Jul  7 22:34:24 localhost kernel: PCI bus 0 controlled by pci at f2000000
Jul  7 22:34:24 localhost kernel: PCI bus 0 controlled by pci at f4000000
Jul  7 22:34:24 localhost kernel: Uni-N revision: 3, KeyLargo revision: 2
Jul  7 22:34:24 localhost kernel: Registered 1 feature controller(s)
Jul  7 22:34:24 localhost kernel: PMU driver initialized for Core99
Jul  7 22:34:24 localhost kernel: pmac nvram is core99: 1
Jul  7 22:34:24 localhost kernel: PowerMac using OpenPIC irq controller
Jul  7 22:34:24 localhost kernel: OpenPIC Version 1.2 (4 CPUs and 64 IRQ 
sources) at 80040000
Jul  7 22:34:24 localhost kernel: GMT Delta read from XPRAM: 540 minutes, 
DST: off
Jul  7 22:34:24 localhost kernel: via_calibrate_decr: decrementer_count = 
249672 (1498032 ticks)
Jul  7 22:34:24 localhost kernel: Console: colour dummy device 80x25
Jul  7 22:34:24 localhost kernel: Calibrating delay loop... 897.84 BogoMIPS
Jul  7 22:34:24 localhost kernel: Memory: 255636k available (1608k kernel 
code, 4740k data, 160k init) [c0000000,d0000000]
Jul  7 22:34:24 localhost kernel: Dentry hash table entries: 32768 (order 
6, 256k)
Jul  7 22:34:24 localhost kernel: Buffer cache hash table entries: 262144 
(order 8, 1024k)
Jul  7 22:34:24 localhost kernel: Page cache hash table entries: 65536 
(order 6, 256k)
Jul  7 22:34:24 localhost kernel: POSIX conformance testing by UNIFIX
Jul  7 22:34:24 localhost kernel: PCI: Probing PCI hardware
Jul  7 22:34:24 localhost kernel: Linux NET4.0 for Linux 2.2
Jul  7 22:34:24 localhost kernel: Based upon Swansea University Computer 
Society NET3.039
Jul  7 22:34:24 localhost kernel: NET4: Unix domain sockets 1.0 for Linux 
NET4.0.
Jul  7 22:34:24 localhost kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Jul  7 22:34:24 localhost kernel: IP Protocols: ICMP, UDP, TCP, IGMP
Jul  7 22:34:24 localhost kernel: TCP: Hash tables configured (ehash 262144 
bhash 65536)
Jul  7 22:34:24 localhost kernel: NET4: AppleTalk 0.18 for Linux NET4.0
Jul  7 22:34:24 localhost kernel: Starting kswapd v 1.5
Jul  7 22:34:24 localhost kernel: usb.c: registered new driver usbdevfs
Jul  7 22:34:24 localhost kernel: usb.c: registered new driver hub
Jul  7 22:34:24 localhost kernel: usb.c: registered new driver hid
Jul  7 22:34:24 localhost kernel: mice: PS/2 mouse device common for all mice
Jul  7 22:34:24 localhost kernel: PCI: Enabling bus mastering for device 00:c0
Jul  7 22:34:24 localhost kernel: usb-ohci.c: USB OHCI at membase 
0x80082000, IRQ 27
Jul  7 22:34:24 localhost kernel: usb.c: new USB bus registered, assigned 
bus number 1
Jul  7 22:34:24 localhost kernel: usb.c: USB new device connect, assigned 
device number 1
Jul  7 22:34:24 localhost kernel: hid.c: HID probe called for ifnum 0
Jul  7 22:34:24 localhost kernel: hub.c: USB hub found
Jul  7 22:34:24 localhost kernel: hub.c: 2 ports detected
Jul  7 22:34:24 localhost kernel: PCI: Enabling bus mastering for device 00:c8
Jul  7 22:34:24 localhost kernel: usb-ohci.c: USB OHCI at membase 
0x80081000, IRQ 28
Jul  7 22:34:24 localhost kernel: usb.c: new USB bus registered, assigned 
bus number 2
Jul  7 22:34:24 localhost kernel: usb.c: USB new device connect, assigned 
device number 1
Jul  7 22:34:24 localhost kernel: hid.c: HID probe called for ifnum 0
Jul  7 22:34:24 localhost kernel: hub.c: USB hub found
Jul  7 22:34:24 localhost kernel: hub.c: 2 ports detected
Jul  7 22:34:24 localhost kernel: aty128fb: detected XCLK=0x1392, ref_div=0x1a
Jul  7 22:34:24 localhost kernel: aty128fb: Rage128 RL (AGP) [chip rev 0x2] 
8M 64-bit SDR SGRAM (2:1)
Jul  7 22:34:24 localhost kernel: Console: switching to colour frame buffer 
device 128x48
Jul  7 22:34:24 localhost kernel: fb0: ATY Rage128 frame buffer device on 
/pci@f0000000/ATY,Rage128k@10
Jul  7 22:34:24 localhost kernel: mouse0: PS/2 mouse device for input0
Jul  7 22:34:24 localhost kernel: event0: Event device for input0
Jul  7 22:34:24 localhost kernel: input0: Macintosh mouse button emulation
Jul  7 22:34:24 localhost kernel: PowerMac Z8530 serial driver version 2.0
Jul  7 22:34:24 localhost kernel: tty00 at 0x80013020 (irq = 22) is a Z8530 
ESCC (cobalt modem)
Jul  7 22:34:24 localhost kernel: tty01 at 0x80013000 (irq = 50) is a Z8530 
ESCC
Jul  7 22:34:24 localhost kernel: pty: 256 Unix98 ptys configured
Jul  7 22:34:24 localhost kernel: Macintosh ADB mouse driver installed.
Jul  7 22:34:24 localhost kernel: Macintosh non-volatile memory driver v1.0
Jul  7 22:34:24 localhost kernel: DMA sound driver installed, using 4 
buffers of 32k.
Jul  7 22:34:24 localhost kernel: RAM disk driver initialized:  16 RAM 
disks of 4096K size
Jul  7 22:34:24 localhost kernel: loop: registered device at major 7
Jul  7 22:34:24 localhost kernel: pmac_ide: enabling IDE bus ID 2
Jul  7 22:34:24 localhost kernel: pmac_ide: enabling IDE bus ID 0
Jul  7 22:34:24 localhost kernel: pmac_ide: enabling IDE bus ID 1
Jul  7 22:34:24 localhost kernel: hda: IBM-DPTA-373420, ATA DISK drive
Jul  7 22:34:24 localhost kernel: hdb: MATSHITADVD-ROM SR-8184, ATAPI CDROM 
drive
Jul  7 22:34:24 localhost kernel: ide0 at 0x8e01f000-0x8e01f007,0x8e01f160 
on irq 19
Jul  7 22:34:25 localhost kernel: hda: Enabling Ultra DMA 4
Jul  7 22:34:25 localhost kernel: hda: IBM-DPTA-373420, 32634MB w/1961kB 
Cache, CHS=4160/255/63, (U)DMA
Jul  7 22:34:25 localhost kernel: hdb: Enabling MultiWord DMA 2
Jul  7 22:34:25 localhost kernel: hdb: ATAPI 24X DVD-ROM drive, 512kB Cache
Jul  7 22:34:25 localhost kernel: Uniform CD-ROM driver Revision: 3.11
Jul  7 22:34:25 localhost kernel: scsi : 0 hosts.
Jul  7 22:34:25 localhost kernel: scsi : detected total.
Jul  7 22:34:25 localhost kernel: PPP: version 2.3.7 (demand dialling)
Jul  7 22:34:25 localhost kernel: TCP compression code copyright 1989 
Regents of the University of California
Jul  7 22:34:25 localhost kernel: PPP line discipline registered.
Jul  7 22:34:25 localhost kernel: eth0: DC21143 at 0x0400 (PCI bus 0, 
device 19), h/w address 00:0a:27:82:e3:9a,
Jul  7 22:34:25 localhost kernel: eth0: Using generic MII device control. 
If the board doesn't operate,
Jul  7 22:34:25 localhost kernel: please mail the following dump to the 
author:
Jul  7 22:34:25 localhost kernel:
Jul  7 22:34:25 localhost kernel: MII device address: 0
Jul  7 22:34:25 localhost kernel: MII CR:  3000
Jul  7 22:34:25 localhost kernel: MII SR:  7809
Jul  7 22:34:25 localhost kernel: MII ID0: 40
Jul  7 22:34:25 localhost kernel: MII ID1: 6212
Jul  7 22:34:25 localhost kernel: MII ANA: 1e1
Jul  7 22:34:25 localhost kernel: MII ANC: 0
Jul  7 22:34:25 localhost kernel: MII 16:  1000
Jul  7 22:34:25 localhost kernel: MII 17:  1
Jul  7 22:34:25 localhost kernel: MII 18:  0
Jul  7 22:34:25 localhost kernel:
Jul  7 22:34:25 localhost kernel:       and requires IRQ53 (provided by PCI 
BIOS).
Jul  7 22:34:25 localhost kernel: de4x5.c:V0.544 1999/5/8 
da...@ma...
Jul  7 22:34:25 localhost kernel: Partition check:
Jul  7 22:34:25 localhost kernel:  hda: hda1 hda2 hda3 hda4 hda5 hda6 hda7 
hda8 hda9 hda10 hda11 hda12 hda13 hda14 (root on 9)
Jul  7 22:34:25 localhost kernel: VFS: Mounted root (ext2 filesystem) 
readonly.
Jul  7 22:34:25 localhost kernel: Freeing unused kernel memory: 160k init 
32k prep
Jul  7 22:34:25 localhost kernel: usb.c: USB new device connect, assigned 
device number 2
Jul  7 22:34:25 localhost kernel: hid.c: HID probe called for ifnum 0
Jul  7 22:34:25 localhost kernel: hub.c: USB hub found
Jul  7 22:34:25 localhost kernel: hub.c: 3 ports detected
Jul  7 22:34:25 localhost kernel: usb.c: USB new device connect, assigned 
device number 3
Jul  7 22:34:25 localhost kernel: hid.c: HID probe called for ifnum 0
Jul  7 22:34:25 localhost kernel: hid.c: report (size 64, read 64) =  05 01 
09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 75 01 95 08 81 02 95 01 75 08 81 
01 95 05 75 01 05 08 19 01 29 03 91 02 95 01 75 03 91 01 95 06 75 08 15 00 
26 ff 00 05 07 19 00 29 ff 81 00 c0
Jul  7 22:34:25 localhost kernel: Application(GenericDesktop.Keyboard)
Jul  7 22:34:25 localhost kernel:   INPUT[INPUT]
Jul  7 22:34:25 localhost kernel:     Field(0)
Jul  7 22:34:25 localhost kernel:       Usage(8)
Jul  7 22:34:25 localhost kernel:         Keyboard.00e0
Jul  7 22:34:25 localhost kernel:         Keyboard.00e1
Jul  7 22:34:25 localhost kernel:         Keyboard.00e2
Jul  7 22:34:25 localhost kernel:         Keyboard.00e3
Jul  7 22:34:25 localhost kernel:         Keyboard.00e4
Jul  7 22:34:25 localhost kernel:         Keyboard.00e5
Jul  7 22:34:25 localhost kernel:         Keyboard.00e6
Jul  7 22:34:25 localhost kernel:         Keyboard.00e7
Jul  7 22:34:25 localhost kernel:       Logical Minimum(0)
Jul  7 22:34:25 localhost kernel:       Logical Maximum(1)
Jul  7 22:34:25 localhost kernel:       Report Size(1)
Jul  7 22:34:25 localhost kernel:       Report Count(8)
Jul  7 22:34:25 localhost kernel:       Report Offset(0)
Jul  7 22:34:25 localhost kernel:       Flags( Variable Absolute )
Jul  7 22:34:25 localhost kernel:     Field(1)
Jul  7 22:34:25 localhost kernel:       Usage(256)
Jul  7 22:34:25 localhost kernel:         Keyboard.0000
Jul  7 22:34:25 localhost kernel:         Keyboard.0001
Jul  7 22:34:25 localhost kernel:         Keyboard.0002
Jul  7 22:34:25 localhost kernel:         Keyboard.0003
Jul  7 22:34:25 localhost kernel:         Keyboard.0004
Jul  7 22:34:25 localhost kernel:         Keyboard.0005
Jul  7 22:34:25 localhost kernel:         Keyboard.0006
Jul  7 22:34:25 localhost kernel:         Keyboard.0007
Jul  7 22:34:25 localhost kernel:         Keyboard.0008
Jul  7 22:34:25 localhost kernel:         Keyboard.0009
Jul  7 22:34:25 localhost kernel:         Keyboard.000a
Jul  7 22:34:25 localhost kernel:         Keyboard.000b
Jul  7 22:34:25 localhost kernel:         Keyboard.000c
Jul  7 22:34:25 localhost kernel:         Keyboard.000d
Jul  7 22:34:25 localhost kernel:         Keyboard.000e
Jul  7 22:34:25 localhost kernel:         Keyboard.000f
Jul  7 22:34:25 localhost kernel:         Keyboard.0010
Jul  7 22:34:25 localhost kernel:         Keyboard.0011
Jul  7 22:34:25 localhost kernel:         Keyboard.0012
Jul  7 22:34:25 localhost kernel:         Keyboard.0013
Jul  7 22:34:25 localhost kernel:         Keyboard.0014
Jul  7 22:34:25 localhost kernel:         Keyboard.0015
Jul  7 22:34:25 localhost kernel:         Keyboard.0016
Jul  7 22:34:25 localhost kernel:         Keyboard.0017
Jul  7 22:34:25 localhost kernel:         Keyboard.0018
Jul  7 22:34:25 localhost kernel:         Keyboard.0019
Jul  7 22:34:25 localhost kernel:         Keyboard.001a
Jul  7 22:34:25 localhost kernel:         Keyboard.001b
Jul  7 22:34:25 localhost kernel:         Keyboard.001c
Jul  7 22:34:25 localhost kernel:         Keyboard.001d
Jul  7 22:34:25 localhost kernel:         Keyboard.001e
Jul  7 22:34:25 localhost kernel:         Keyboard.001f
Jul  7 22:34:25 localhost kernel:         Keyboard.0020
Jul  7 22:34:25 localhost kernel:         Keyboard.0021
Jul  7 22:34:25 localhost kernel:         Keyboard.0022
Jul  7 22:34:25 localhost kernel:         Keyboard.0023
Jul  7 22:34:25 localhost kernel:         Keyboard.0024
Jul  7 22:34:25 localhost kernel:         Keyboard.0025
Jul  7 22:34:25 localhost kernel:         Keyboard.0026
Jul  7 22:34:25 localhost kernel:         Keyboard.0027
Jul  7 22:34:25 localhost kernel:         Keyboard.0028
Jul  7 22:34:25 localhost kernel:         Keyboard.0029
Jul  7 22:34:25 localhost kernel:         Keyboard.002a
Jul  7 22:34:25 localhost kernel:         Keyboard.002b
Jul  7 22:34:25 localhost kernel:         Keyboard.002c
Jul  7 22:34:25 localhost kernel:         Keyboard.002d
Jul  7 22:34:25 localhost kernel:         Keyboard.002e
Jul  7 22:34:25 localhost kernel:         Keyboard.002f
Jul  7 22:34:25 localhost kernel:         Keyboard.0030
Jul  7 22:34:25 localhost kernel:         Keyboard.0031
Jul  7 22:34:25 localhost kernel:         Keyboard.0032
Jul  7 22:34:25 localhost kernel:         Keyboard.0033
Jul  7 22:34:25 localhost kernel:         Keyboard.0034
Jul  7 22:34:25 localhost kernel:         Keyboard.0035
Jul  7 22:34:25 localhost kernel:         Keyboard.0036
Jul  7 22:34:25 localhost kernel:         Keyboard.0037
Jul  7 22:34:25 localhost kernel:         Keyboard.0038
Jul  7 22:34:25 localhost kernel:         Keyboard.0039
Jul  7 22:34:25 localhost kernel:         Keyboard.003a
Jul  7 22:34:25 localhost kernel:         Keyboard.003b
Jul  7 22:34:25 localhost kernel:         Keyboard.003c
Jul  7 22:34:25 localhost kernel:         Keyboard.003d
Jul  7 22:34:25 localhost kernel:         Keyboard.003e
Jul  7 22:34:25 localhost kernel:         Keyboard.003f
Jul  7 22:34:25 localhost kernel:         Keyboard.0040
Jul  7 22:34:25 localhost kernel:         Keyboard.0041
Jul  7 22:34:25 localhost kernel:         Keyboard.0042
Jul  7 22:34:25 localhost kernel:         Keyboard.0043
Jul  7 22:34:25 localhost kernel:         Keyboard.0044
Jul  7 22:34:25 localhost kernel:         Keyboard.0045
Jul  7 22:34:25 localhost kernel:         Keyboard.0046
Jul  7 22:34:25 localhost kernel:         Keyboard.0047
Jul  7 22:34:25 localhost kernel:         Keyboard.0048
Jul  7 22:34:25 localhost kernel:         Keyboard.0049
Jul  7 22:34:25 localhost kernel:         Keyboard.004a
Jul  7 22:34:25 localhost kernel:         Keyboard.004b
Jul  7 22:34:25 localhost kernel:         Keyboard.004c
Jul  7 22:34:25 localhost kernel:         Keyboard.004d
Jul  7 22:34:25 localhost kernel:         Keyboard.004e
Jul  7 22:34:25 localhost kernel:         Keyboard.004f
Jul  7 22:34:25 localhost kernel:         Keyboard.0050
Jul  7 22:34:25 localhost kernel:         Keyboard.0051
Jul  7 22:34:25 localhost kernel:         Keyboard.0052
Jul  7 22:34:25 localhost kernel:         Keyboard.0053
Jul  7 22:34:25 localhost kernel:         Keyboard.0054
Jul  7 22:34:25 localhost kernel:         Keyboard.0055
Jul  7 22:34:25 localhost kernel:         Keyboard.0056
Jul  7 22:34:25 localhost kernel:         Keyboard.0057
Jul  7 22:34:25 localhost kernel:         Keyboard.0058
Jul  7 22:34:25 localhost kernel:         Keyboard.0059
Jul  7 22:34:25 localhost kernel:         Keyboard.005a
Jul  7 22:34:25 localhost kernel:         Keyboard.005b
Jul  7 22:34:25 localhost kernel:         Keyboard.005c
Jul  7 22:34:25 localhost kernel:         Keyboard.005d
Jul  7 22:34:25 localhost kernel:         Keyboard.005e
Jul  7 22:34:25 localhost kernel:         Keyboard.005f
Jul  7 22:34:25 localhost kernel:         Keyboard.0060
Jul  7 22:34:25 localhost kernel:         Keyboard.0061
Jul  7 22:34:25 localhost kernel:         Keyboard.0062
Jul  7 22:34:25 localhost kernel:         Keyboard.0063
Jul  7 22:34:25 localhost kernel:         Keyboard.0064
Jul  7 22:34:25 localhost kernel:         Keyboard.0065
Jul  7 22:34:25 localhost kernel:         Keyboard.0066
Jul  7 22:34:25 localhost kernel:         Keyboard.0067
Jul  7 22:34:25 localhost kernel:         Keyboard.0068
Jul  7 22:34:25 localhost kernel:         Keyboard.0069
Jul  7 22:34:25 localhost kernel:         Keyboard.006a
Jul  7 22:34:25 localhost kernel:         Keyboard.006b
Jul  7 22:34:25 localhost kernel:         Keyboard.006c
Jul  7 22:34:25 localhost kernel:         Keyboard.006d
Jul  7 22:34:25 localhost kernel:         Keyboard.006e
Jul  7 22:34:25 localhost kernel:         Keyboard.006f
Jul  7 22:34:25 localhost kernel:         Keyboard.0070
Jul  7 22:34:25 localhost kernel:         Keyboard.0071
Jul  7 22:34:25 localhost kernel:         Keyboard.0072
Jul  7 22:34:25 localhost kernel:         Keyboard.0073
Jul  7 22:34:25 localhost kernel:         Keyboard.0074
Jul  7 22:34:25 localhost kernel:         Keyboard.0075
Jul  7 22:34:25 localhost kernel:         Keyboard.0076
Jul  7 22:34:25 localhost kernel:         Keyboard.0077
Jul  7 22:34:25 localhost kernel:         Keyboard.0078
Jul  7 22:34:25 localhost kernel:         Keyboard.0079
Jul  7 22:34:25 localhost kernel:         Keyboard.007a
Jul  7 22:34:25 localhost kernel:         Keyboard.007b
Jul  7 22:34:25 localhost kernel:         Keyboard.007c
Jul  7 22:34:25 localhost kernel:         Keyboard.007d
Jul  7 22:34:25 localhost kernel:         Keyboard.007e
Jul  7 22:34:25 localhost kernel:         Keyboard.007f
Jul  7 22:34:25 localhost kernel:         Keyboard.0080
Jul  7 22:34:25 localhost kernel:         Keyboard.0081
Jul  7 22:34:25 localhost kernel:         Keyboard.0082
Jul  7 22:34:25 localhost kernel:         Keyboard.0083
Jul  7 22:34:25 localhost kernel:         Keyboard.0084
Jul  7 22:34:25 localhost kernel:         Keyboard.0085
Jul  7 22:34:25 localhost kernel:         Keyboard.0086
Jul  7 22:34:25 localhost kernel:         Keyboard.0087
Jul  7 22:34:25 localhost kernel:         Keyboard.0088
Jul  7 22:34:25 localhost kernel:         Keyboard.0089
Jul  7 22:34:25 localhost kernel:         Keyboard.008a
Jul  7 22:34:25 localhost kernel:         Keyboard.008b
Jul  7 22:34:25 localhost kernel:         Keyboard.008c
Jul  7 22:34:25 localhost kernel:         Keyboard.008d
Jul  7 22:34:25 localhost kernel:         Keyboard.008e
Jul  7 22:34:25 localhost kernel:         Keyboard.008f
Jul  7 22:34:25 localhost kernel:         Keyboard.0090
Jul  7 22:34:25 localhost kernel:         Keyboard.0091
Jul  7 22:34:25 localhost kernel:         Keyboard.0092
Jul  7 22:34:25 localhost kernel:         Keyboard.0093
Jul  7 22:34:25 localhost kernel:         Keyboard.0094
Jul  7 22:34:25 localhost kernel:         Keyboard.0095
Jul  7 22:34:25 localhost kernel:         Keyboard.0096
Jul  7 22:34:25 localhost kernel:         Keyboard.0097
Jul  7 22:34:25 localhost kernel:         Keyboard.0098
Jul  7 22:34:25 localhost kernel:         Keyboard.0099
Jul  7 22:34:25 localhost kernel:         Keyboard.009a
Jul  7 22:34:25 localhost kernel:         Keyboard.009b
Jul  7 22:34:25 localhost kernel:         Keyboard.009c
Jul  7 22:34:25 localhost kernel:         Keyboard.009d
Jul  7 22:34:25 localhost kernel:         Keyboard.009e
Jul  7 22:34:25 localhost kernel:         Keyboard.009f
Jul  7 22:34:25 localhost kernel:         Keyboard.00a0
Jul  7 22:34:25 localhost kernel:         Keyboard.00a1
Jul  7 22:34:25 localhost kernel:         Keyboard.00a2
Jul  7 22:34:25 localhost kernel:         Keyboard.00a3
Jul  7 22:34:25 localhost kernel:         Keyboard.00a4
Jul  7 22:34:25 localhost kernel:         Keyboard.00a5
Jul  7 22:34:25 localhost kernel:         Keyboard.00a6
Jul  7 22:34:25 localhost kernel:         Keyboard.00a7
Jul  7 22:34:25 localhost kernel:         Keyboard.00a8
Jul  7 22:34:25 localhost kernel:         Keyboard.00a9
Jul  7 22:34:25 localhost kernel:         Keyboard.00aa
Jul  7 22:34:25 localhost kernel:         Keyboard.00ab
Jul  7 22:34:25 localhost kernel:         Keyboard.00ac
Jul  7 22:34:25 localhost kernel:         Keyboard.00ad
Jul  7 22:34:25 localhost kernel:         Keyboard.00ae
Jul  7 22:34:25 localhost kernel:         Keyboard.00af
Jul  7 22:34:25 localhost kernel:         Keyboard.00b0
Jul  7 22:34:25 localhost kernel:         Keyboard.00b1
Jul  7 22:34:25 localhost kernel:         Keyboard.00b2
Jul  7 22:34:25 localhost kernel:         Keyboard.00b3
Jul  7 22:34:25 localhost kernel:         Keyboard.00b4
Jul  7 22:34:25 localhost kernel:         Keyboard.00b5
Jul  7 22:34:25 localhost kernel:         Keyboard.00b6
Jul  7 22:34:25 localhost kernel:         Keyboard.00b7
Jul  7 22:34:25 localhost kernel:         Keyboard.00b8
Jul  7 22:34:25 localhost kernel:         Keyboard.00b9
Jul  7 22:34:25 localhost kernel:         Keyboard.00ba
Jul  7 22:34:25 localhost kernel:         Keyboard.00bb
Jul  7 22:34:25 localhost kernel:         Keyboard.00bc
Jul  7 22:34:25 localhost kernel:         Keyboard.00bd
Jul  7 22:34:25 localhost kernel:         Keyboard.00be
Jul  7 22:34:25 localhost kernel:         Keyboard.00bf
Jul  7 22:34:25 localhost kernel:         Keyboard.00c0
Jul  7 22:34:25 localhost kernel:         Keyboard.00c1
Jul  7 22:34:25 localhost kernel:         Keyboard.00c2
Jul  7 22:34:25 localhost kernel:         Keyboard.00c3
Jul  7 22:34:25 localhost kernel:         Keyboard.00c4
Jul  7 22:34:25 localhost kernel:         Keyboard.00c5
Jul  7 22:34:25 localhost kernel:         Keyboard.00c6
Jul  7 22:34:25 localhost kernel:         Keyboard.00c7
Jul  7 22:34:25 localhost kernel:         Keyboard.00c8
Jul  7 22:34:25 localhost kernel:         Keyboard.00c9
Jul  7 22:34:25 localhost kernel:         Keyboard.00ca
Jul  7 22:34:25 localhost kernel:         Keyboard.00cb
Jul  7 22:34:25 localhost kernel:         Keyboard.00cc
Jul  7 22:34:25 localhost kernel:         Keyboard.00cd
Jul  7 22:34:25 localhost kernel:         Keyboard.00ce
Jul  7 22:34:25 localhost kernel:         Keyboard.00cf
Jul  7 22:34:25 localhost kernel:         Keyboard.00d0
Jul  7 22:34:25 localhost kernel:         Keyboard.00d1
Jul  7 22:34:25 localhost kernel:         Keyboard.00d2
Jul  7 22:34:25 localhost kernel:         Keyboard.00d3
Jul  7 22:34:25 localhost kernel:         Keyboard.00d4
Jul  7 22:34:25 localhost kernel:         Keyboard.00d5
Jul  7 22:34:25 localhost kernel:         Keyboard.00d6
Jul  7 22:34:25 localhost kernel:         Keyboard.00d7
Jul  7 22:34:25 localhost kernel:         Keyboard.00d8
Jul  7 22:34:25 localhost kernel:         Keyboard.00d9
Jul  7 22:34:25 localhost kernel:         Keyboard.00da
Jul  7 22:34:25 localhost kernel:         Keyboard.00db
Jul  7 22:34:25 localhost kernel:         Keyboard.00dc
Jul  7 22:34:25 localhost kernel:         Keyboard.00dd
Jul  7 22:34:25 localhost kernel:         Keyboard.00de
Jul  7 22:34:25 localhost kernel:         Keyboard.00df
Jul  7 22:34:25 localhost kernel:         Keyboard.00e0
Jul  7 22:34:25 localhost kernel:         Keyboard.00e1
Jul  7 22:34:25 localhost kernel:         Keyboard.00e2
Jul  7 22:34:25 localhost kernel:         Keyboard.00e3
Jul  7 22:34:25 localhost kernel:         Keyboard.00e4
Jul  7 22:34:25 localhost kernel:         Keyboard.00e5
Jul  7 22:34:25 localhost kernel:         Keyboard.00e6
Jul  7 22:34:25 localhost kernel:         Keyboard.00e7
Jul  7 22:34:25 localhost kernel:         Keyboard.00e8
Jul  7 22:34:25 localhost kernel:         Keyboard.00e9
Jul  7 22:34:25 localhost kernel:         Keyboard.00ea
Jul  7 22:34:25 localhost kernel:         Keyboard.00eb
Jul  7 22:34:25 localhost kernel:         Keyboard.00ec
Jul  7 22:34:25 localhost kernel:         Keyboard.00ed
Jul  7 22:34:25 localhost kernel:         Keyboard.00ee
Jul  7 22:34:25 localhost kernel:         Keyboard.00ef
Jul  7 22:34:25 localhost kernel:         Keyboard.00f0
Jul  7 22:34:25 localhost kernel:         Keyboard.00f1
Jul  7 22:34:25 localhost kernel:         Keyboard.00f2
Jul  7 22:34:25 localhost kernel:         Keyboard.00f3
Jul  7 22:34:25 localhost kernel:         Keyboard.00f4
Jul  7 22:34:25 localhost kernel:         Keyboard.00f5
Jul  7 22:34:25 localhost kernel:         Keyboard.00f6
Jul  7 22:34:25 localhost kernel:         Keyboard.00f7
Jul  7 22:34:25 localhost kernel:         Keyboard.00f8
Jul  7 22:34:25 localhost kernel:         Keyboard.00f9
Jul  7 22:34:25 localhost kernel:         Keyboard.00fa
Jul  7 22:34:25 localhost kernel:         Keyboard.00fb
Jul  7 22:34:25 localhost kernel:         Keyboard.00fc
Jul  7 22:34:25 localhost kernel:         Keyboard.00fd
Jul  7 22:34:25 localhost kernel:         Keyboard.00fe
Jul  7 22:34:25 localhost kernel:         Keyboard.00ff
Jul  7 22:34:25 localhost kernel:       Logical Minimum(0)
Jul  7 22:34:25 localhost kernel:       Logical Maximum(255)
Jul  7 22:34:25 localhost kernel:       Report Size(8)
Jul  7 22:34:25 localhost kernel:       Report Count(6)
Jul  7 22:34:25 localhost kernel:       Report Offset(16)
Jul  7 22:34:25 localhost kernel:       Flags( Array Absolute )
Jul  7 22:34:25 localhost kernel:   OUTPUT[OUTPUT]
Jul  7 22:34:25 localhost kernel:     Field(0)
Jul  7 22:34:25 localhost kernel:       Usage(5)
Jul  7 22:34:25 localhost kernel:         LED.0001
Jul  7 22:34:25 localhost kernel:         LED.0002
Jul  7 22:34:25 localhost kernel:         LED.0003
Jul  7 22:34:25 localhost kernel:         Pointer.0000
Jul  7 22:34:25 localhost kernel:         Pointer.0000
Jul  7 22:34:25 localhost kernel:       Logical Minimum(0)
Jul  7 22:34:25 localhost kernel:       Logical Maximum(1)
Jul  7 22:34:25 localhost kernel:       Report Size(1)
Jul  7 22:34:25 localhost kernel:       Report Count(5)
Jul  7 22:34:25 localhost kernel:       Report Offset(0)
Jul  7 22:34:25 localhost kernel:       Flags( Variable Absolute )
Jul  7 22:34:25 localhost kernel: keybdev.c: Adding keyboard: input1
Jul  7 22:34:25 localhost kernel: event1: Event device for input1
Jul  7 22:34:25 localhost kernel: input1: USB HID v0.01 Keyboard [Mitsumi 
Electric Apple USB Keyboard] on usb2:3.0
Jul  7 22:34:25 localhost kernel: Adding Swap: 51196k swap-space (priority -1)
Jul  7 22:34:25 localhost kernel: usb.c: USB new device connect, assigned 
device number 4
Jul  7 22:34:25 localhost kernel: hid.c: HID probe called for ifnum 0
Jul  7 22:34:25 localhost kernel: hid.c: report (size 50, read 50) =  05 01 
09 02 a1 01 05 09 19 01 29 01 15 00 25 01 95 01 75 01 81 02 95 01 75 07 81 
03 05 01 09 01 a1 00 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0
Jul  7 22:34:25 localhost kernel: Application(GenericDesktop.Mouse)
Jul  7 22:34:25 localhost kernel:   INPUT[INPUT]
Jul  7 22:34:25 localhost kernel:     Field(0)
Jul  7 22:34:25 localhost kernel:       Usage(1)
Jul  7 22:34:25 localhost kernel:         Button.0001
Jul  7 22:34:25 localhost kernel:       Logical Minimum(0)
Jul  7 22:34:25 localhost kernel:       Logical Maximum(1)
Jul  7 22:34:25 localhost kernel:       Report Size(1)
Jul  7 22:34:25 localhost kernel:       Report Count(1)
Jul  7 22:34:25 localhost kernel:       Report Offset(0)
Jul  7 22:34:25 localhost kernel:       Flags( Variable Absolute )
Jul  7 22:34:25 localhost kernel:     Field(1)
Jul  7 22:34:25 localhost kernel:       Usage(1)
Jul  7 22:34:25 localhost kernel:         Pointer.0000
Jul  7 22:34:25 localhost kernel:       Logical Minimum(0)
Jul  7 22:34:25 localhost kernel:       Logical Maximum(1)
Jul  7 22:34:25 localhost kernel:       Report Size(7)
Jul  7 22:34:25 localhost kernel:       Report Count(1)
Jul  7 22:34:25 localhost kernel:       Report Offset(1)
Jul  7 22:34:25 localhost kernel:       Flags( Constant Variable Absolute )
Jul  7 22:34:25 localhost kernel:     Field(2)
Jul  7 22:34:25 localhost kernel:       Physical(GenericDesktop.Pointer)
Jul  7 22:34:25 localhost kernel:       Usage(2)
Jul  7 22:34:25 localhost kernel:         GenericDesktop.X
Jul  7 22:34:25 localhost kernel:         GenericDesktop.Y
Jul  7 22:34:25 localhost kernel:       Logical Minimum(-127)
Jul  7 22:34:25 localhost kernel:       Logical Maximum(127)
Jul  7 22:34:25 localhost kernel:       Report Size(8)
Jul  7 22:34:25 localhost kernel:       Report Count(2)
Jul  7 22:34:25 localhost kernel:       Report Offset(8)
Jul  7 22:34:25 localhost kernel:       Flags( Variable Relative )
Jul  7 22:34:25 localhost kernel: mouse1: PS/2 mouse device for input2
Jul  7 22:34:25 localhost kernel: event2: Event device for input2
Jul  7 22:34:25 localhost kernel: input2: USB HID v0.01 Mouse [Mitsumi 
Apple USB Mouse] on usb2:4.0
Jul  7 22:34:25 localhost kernel: eth0: media is 100Mb/s.
T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB OHCI Root Hub
S:  SerialNumber=80081000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 3
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=05ac ProdID=1001 Rev= 2.11
S:  Manufacturer=Mitsumi Electric
S:  Product=Hub in Apple USB Keyboard
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=255ms
T:  Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=1.5 MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=05ac ProdID=0203 Rev= 1.03
S:  Manufacturer=Mitsumi Electric
S:  Product=Apple USB Keyboard
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl= 10ms
T:  Bus=02 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#=  4 Spd=1.5 MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=05ac ProdID=0301 Rev= 5.05
S:  Manufacturer=Mitsumi
S:  Product=Apple USB Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 28mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=   3 Ivl= 10ms
T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB OHCI Root Hub
S:  SerialNumber=80082000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

Re: New to the input layer

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

> But in general we've got very few problem reports so far, so you'll get 
> input layer aware ADB drivers for ruby in a few days, after we did our 
> internal merges into our 2.2 and 2.4 trees.

Thank you very much. I will leave keyboard.c in CVS alone until you have
the changes merged. I just did a commit a few minutes ago. As for having
Japanese keyboard support is really really good. By the Vojtech how does
different languages fit with /dev/event? As for the console system we will
need to add support for 16 bit characters in the future as well as
different directions to typing. In some languages you write right to left
instead of left to right as many european languages do. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: New to the input layer

[Matan Ziv-Av <ma...@sv...>]

On Fri, 7 Jul 2000, James Simmons wrote:

> different languages fit with /dev/event? As for the console system we will
> need to add support for 16 bit characters in the future as well as
> different directions to typing. In some languages you write right to left
> instead of left to right as many european languages do.

Hebrew is one of those right to left languages, but this is an output
only concern. The input system still needs to give the events in
chronological order.  Again, for hebrew, even the output support needs
to be done at the application level. Putting it in the console is hack
that works a little, and might be useful in a few occasions, but it is
not the solution for BiDirectional functionality.


-- 
Matan Ziv-Av.                         ma...@sv...

Re: New to the input layer

[Matan Ziv-Av <ma...@sv...>]

> > > > - why is there no mixer device /dev/input/events similar to
> > > > /dev/input/mice? Should I implement such a device?
> > >
> > >Is it needed for anything?
> >
> > Well, I have noticed that on unplugging/replugging a device, it won't
> > re-use the previous /dev/input/eventX if it is still held open by an
> > application. That means applications have to scan the event devices
> > continously themselves as soon as the device is removed, to check where it
> > reappears. Think about an X user which unplugs his keyboard, plugs in a
> > mouse and replugs the keyboard, does X have to scan then on which eventX
> > device the keyboard reappears? I think this is overkill for the usual
> > single-user single/multi-screen installations which probably make up 99.9%
> > of all installations. With a /dev/input/events mixer device X can attach to
> > a single device for all events and doesn't have to care what the user does
> > with them. Maybe a ioctl to attach/detach event devices from the event
> > mixer would be a good idea then.
> 
> Creating /dev/input/events is the wrong approach. Creating a way how to
> make an already-open disappearing and appearing again device to appear
> back at the same device number.
> 
> The device number is currently held busy until it's not referenced
> anymore. It doesn't have to be so.
> 
> > > > - only 32 event devices, looks a bit short sighted?
> > >
> > >There's space for upto 196 (64-255).
> >
> > Yes, I know. I was searching for a good minor for /dev/input/events.
> > Probably 255 then :-).
> 
> I really don't think it's needed. We would have to add some device ID to
> struct input_event, because mixing input from a joystick and a tablet
> (or two joysticks or whatever) simply wouldn't work.

I think that can be useful. There are many more scenarios of device
numbers changing:
* My usb hub causes a complete rescan when a device is inserted/removed.
* If some of the input device drivers are modules that are periodically
  inserted/removed by kmod. 

If you make the ID unique (use 32 bits, and no reuse should be good
enough), and add in the device info also serial number and some kind of
geometry (where applicable). Then it would be easy to change the X
server (and other application) to take the following instructions:
use only the btc keyboard or
use only the keyboard with a given serial number or
use only the keyboard connected to the ps/2 auxiliary port or
use only the keyboard connected directly to the usb host

The former two are useful to make sure X uses the same keyboard, no
matter how/where we connect it. The latter are useful for making X use
the keyboard which is in the same location, no matter which it is.

I don't see how can this be achieved in the current scheme, since the
application cannot know when a new device is connected, and can't use
select/poll on non existing devices.



-- 
Matan Ziv-Av.                         ma...@sv...

Re: New to the input layer

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

> If you make the ID unique (use 32 bits, and no reuse should be good
> enough), and add in the device info also serial number and some kind of
> geometry (where applicable). Then it would be easy to change the X
> server (and other application) to take the following instructions:
> use only the btc keyboard or
> use only the keyboard with a given serial number or
> use only the keyboard connected to the ps/2 auxiliary port or
> use only the keyboard connected directly to the usb host

I believe their is ioctl call for /dev/input/eventX that retrieves info on
a device. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: New to the input layer

[Matan Ziv-Av <ma...@sv...>]

> > If you make the ID unique (use 32 bits, and no reuse should be good
> > enough), and add in the device info also serial number and some kind of
> > geometry (where applicable). Then it would be easy to change the X
> > server (and other application) to take the following instructions:
> > use only the btc keyboard or
> > use only the keyboard with a given serial number or
> > use only the keyboard connected to the ps/2 auxiliary port or
> > use only the keyboard connected directly to the usb host
> 
> I believe their is ioctl call for /dev/input/eventX that retrieves info on
> a device.

I know. I suggested adding more info (which should identify the
individual device) such as serial number and geometry of the connection.

-- 
Matan Ziv-Av.                         ma...@sv...