Menu
▾
▴
linuxconsole-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(235) |
Apr
(30) |
May
(32) |
Jun
(86) |
Jul
(81) |
Aug
(108) |
Sep
(27) |
Oct
(22) |
Nov
(34) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(78) |
Feb
(10) |
Mar
(81) |
Apr
(27) |
May
(13) |
Jun
(105) |
Jul
(78) |
Aug
(52) |
Sep
(59) |
Oct
(90) |
Nov
(127) |
Dec
(49) |
| 2002 |
Jan
(102) |
Feb
(72) |
Mar
(54) |
Apr
(98) |
May
(25) |
Jun
(23) |
Jul
(123) |
Aug
(14) |
Sep
(52) |
Oct
(65) |
Nov
(48) |
Dec
(48) |
| 2003 |
Jan
(22) |
Feb
(25) |
Mar
(29) |
Apr
(12) |
May
(16) |
Jun
(11) |
Jul
(20) |
Aug
(20) |
Sep
(43) |
Oct
(84) |
Nov
(98) |
Dec
(56) |
| 2004 |
Jan
(28) |
Feb
(39) |
Mar
(41) |
Apr
(28) |
May
(88) |
Jun
(17) |
Jul
(43) |
Aug
(57) |
Sep
(54) |
Oct
(42) |
Nov
(32) |
Dec
(58) |
| 2005 |
Jan
(80) |
Feb
(31) |
Mar
(65) |
Apr
(41) |
May
(20) |
Jun
(34) |
Jul
(62) |
Aug
(73) |
Sep
(81) |
Oct
(48) |
Nov
(57) |
Dec
(57) |
| 2006 |
Jan
(63) |
Feb
(24) |
Mar
(18) |
Apr
(9) |
May
(22) |
Jun
(29) |
Jul
(47) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Pavel M. <pa...@su...> - 2000-07-11 22:00:52
|
Hi! > > How about (found somewhere in net): > > > > btw: is someone to do hi-resolution(80x43) for hercules (hga not mda - > > cards) ? > > Thanks for the info. I will look it over. As for hi resolution for > hercules. I like to see this too :-) If someone will make a pacth for me I > will gladly accept it. fbcon support for hercules is already in kernel! It can happily do higher resolutions. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. |
|
From: James S. <jsi...@ac...> - 2000-07-10 12:18:16
|
> > I'm going to give it a try now. Thanks. If this works really well we can > > see if it will be applied to the standard kernel. > > The results I have with this (changing test_mda_b and uncommenting the > rextra tests): > with a noname mda card in the system - still recognised. > only SiS 6326 (no mda) - not recognised both with extra tests and without. > only Banshee (no mda) mdacon finds an MDA card without the extra tests, > but does not find without it. > > So it does seem to help It helped here too :-) Lets post that patch to the kernel mailing list for people to test out. > > Yeah. This might be one of those oplease only compile in if you really > > have a MDA card thing. Thank for the info below. > > It is better to have a boot command line option, I think. Lets wait to see more resulst with your patch. This patch might work with all VGA cards. 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 |
|
From: Matan Ziv-Av <ma...@sv...> - 2000-07-10 11:02:38
|
On Sun, 9 Jul 2000, James Simmons wrote: > > > > > The mdacon driver detects a mda card only by checking if memory at > > > > 0xb0000 is accessible (for write and read). If your vga card does decode > > > > those addressess, I can think of the following options: > > > > * enable the commented out tests in mda_detect. > > > > > > Short term solution. > > > > It might be a good solution. It seems to me that test_mda_b is wrong. It > > does not restore the register value to what it was, which might be the > > reason. Try replacing the function with > > I'mgoing to give it a try now. Thanks. If this works really well we can > see if it will be applied to the standard kernel. The results I have with this (changing test_mda_b and uncommenting the rextra tests): with a noname mda card in the system - still recognised. only SiS 6326 (no mda) - not recognised both with extra tests and without. only Banshee (no mda) mdacon finds an MDA card without the extra tests, but does not find without it. So it does seem to help > > > Actually, I am not sure that there is such a test. the 6845 is very > > simple, and if a vga card emulates it it might emulate it completely. > > Yeah. This might be one of those oplease only compile in if you really > have a MDA card thing. Thank for the info below. It is better to have a boot command line option, I think. -- Matan Ziv-Av. ma...@sv... |
|
From: Matan Ziv-Av <ma...@sv...> - 2000-07-10 11:02:37
|
> > btw: is someone to do hi-resolution(80x43) for hercules (hga not mda - > > cards) ? > > Thanks for the info. I will look it over. As for hi resolution for > hercules. I like to see this too :-) If someone will make a pacth for me I > will gladly accept it. This is fbdev stuff, and is already done. Look at hgafb bt Ferenc Bakonyi at http://drama.obuda.kando.hu/~fero/cgi-bin/hgafb.shtml -- Matan Ziv-Av. ma...@sv... |
|
From: James S. <jsi...@ac...> - 2000-07-10 00:48:43
|
> > The system has both vga card and mda card, so the vga test will not > > fail. The light pen ports are not available on mda cards, but only on > > hercules and compatibles. > > If you are trying to detect the primary adapter the check is correct the VGA > is the primary Right now I have one vga card in my system. I wanted to test to see if mdacon initialization would failed if the system lacked a mda card. For my system it didn;t fail but seen my vga card as a mda card :-( I also wanted to test this so if I do have vga and mda card that the mdacon driver doesn't go for the wrong card. 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 |
|
From: James S. <jsi...@ac...> - 2000-07-10 00:43:42
|
> > > The mdacon driver detects a mda card only by checking if memory at > > > 0xb0000 is accessible (for write and read). If your vga card does decode > > > those addressess, I can think of the following options: > > > * enable the commented out tests in mda_detect. > > > > Short term solution. > > It might be a good solution. It seems to me that test_mda_b is wrong. It > does not restore the register value to what it was, which might be the > reason. Try replacing the function with I'm going to give it a try now. Thanks. If this works really well we can see if it will be applied to the standard kernel. > Actually, I am not sure that there is such a test. the 6845 is very > simple, and if a vga card emulates it it might emulate it completely. Yeah. This might be one of those oplease only compile in if you really have a MDA card thing. Thank for the info below. 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 |
|
From: James S. <jsi...@ac...> - 2000-07-10 00:39:24
|
On Sun, 9 Jul 2000, Soeren Sonnenburg wrote: > How about (found somewhere in net): > > btw: is someone to do hi-resolution(80x43) for hercules (hga not mda - > cards) ? Thanks for the info. I will look it over. As for hi resolution for hercules. I like to see this too :-) If someone will make a pacth for me I will gladly accept it. 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 |
|
From: Matan Ziv-Av <ma...@sv...> - 2000-07-09 15:11:54
|
On Sat, 8 Jul 2000, James Simmons wrote:
> > The mdacon driver detects a mda card only by checking if memory at
> > 0xb0000 is accessible (for write and read). If your vga card does decode
> > those addressess, I can think of the following options:
> > * enable the commented out tests in mda_detect.
>
> Short term solution.
It might be a good solution. It seems to me that test_mda_b is wrong. It
does not restore the register value to what it was, which might be the
reason. Try replacing the function with
static int test_mda_b(unsigned char val, unsigned char reg)
{
unsigned long flags;
unsigned char save;
save_flags(flags); cli();
outb_p(reg, mda_index_port);
udelay(20);
save=inb_p(mda_value_port);
udelay(20);
outb (val, mda_value_port);
udelay(20); val = (inb_p(mda_value_port) == val);
udelay(20);
outb_p(save,mda_value_port);
restore_flags(flags);
return val;
}
This works on my mda without the reported cursor problems. Please check
if it indeed Does not recognise your vga card.
> > * make the mda driver disable all pci vga cards, before probing for mda.
> > * don't insmod mdacon.c on a system without a mda driver.
> > * find a better way to detect an mda card.
>
> Long term solution. Just have to find info on MDA. Anyone know where docs
> are for MDA ?
Actually, I am not sure that there is such a test. the 6845 is very
simple, and if a vga card emulates it it might emulate it completely.
From PC Intern and vgadoc4b:
port 0x3b8 Control:
bit 0 - must be 1
bit 3 - enable screen
bit 5 - bit 7 of attribute is 0-bold 1-blinking
port 0x3ba Status (RO):
bit 0 - Horiz sync
bit 3 - pixel status (current pixel sent to monitor)
All other bits are 1.
port 0x3b4, 0x3b5 CRTC:
index
0 Horizontal Total Register (-1)
1 Horizontal Displayed Register (-1)
2 Horizontal Sync Position Register
3 Horizontal Sync Width Register
4 Vertical Total Register
5 Vertical Total Adjust Register
6 Vertical Displayed Register
7 Vertical SyncPosition Register
8 Interlace Mode Register
9 Maximum Scan Line Register (-1)
a Cursor Start Register (bits 0-4 cursor start,
bits 5-6 cursor attributes)
b Cursor End Register
c Start Address High Register
d Start Address Low Register
e Cursor Location High Register
f Cursor Location Low Register
--
Matan Ziv-Av. ma...@sv...
|
|
From: James S. <jsi...@ac...> - 2000-07-09 13:14:26
|
I couldn't wait. I added multiple keyboard support to the console system. Give it a try. Vgacon, mdacon and the NVIDIA non fbdev driver are now updated to this new api. So in theory you can now support a true multihead console system with more than one keyboard and the above consoel vidoe drivers. Give it a try and let me know the results. The fbdev code has not been updated yet. 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 |
|
From: James S. <jsi...@ac...> - 2000-07-08 23:54:52
|
> The mdacon driver detects a mda card only by checking if memory at > 0xb0000 is accessible (for write and read). If your vga card does decode > those addressess, I can think of the following options: > * enable the commented out tests in mda_detect. Short term solution. > * make the mda driver disable all pci vga cards, before probing for mda. > * don't insmod mdacon.c on a system without a mda driver. > * find a better way to detect an mda card. Long term solution. Just have to find info on MDA. Anyone know where docs are for MDA ? 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 |
|
From: Matan Ziv-Av <ma...@sv...> - 2000-07-08 18:48:26
|
> I just tested the code and everything should be safe. The only thing is > one keybaord still will be used by both the MDA and VGA displays. The only > funny thing is for some reason MDA detects a mda card when all I have is a > matrox millenium in my system. This of course interferes with vga and > hangs my system. Any idea anyone? The mdacon driver detects a mda card only by checking if memory at 0xb0000 is accessible (for write and read). If your vga card does decode those addressess, I can think of the following options: * enable the commented out tests in mda_detect. * make the mda driver disable all pci vga cards, before probing for mda. * don't insmod mdacon.c on a system without a mda driver. * find a better way to detect an mda card. -- Matan Ziv-Av. ma...@sv... |
|
From: James S. <jsi...@ac...> - 2000-07-08 16:39:42
|
I just tested the code and everything should be safe. The only thing is one keybaord still will be used by both the MDA and VGA displays. The only funny thing is for some reason MDA detects a mda card when all I have is a matrox millenium in my system. This of course interferes with vga and hangs my system. Any idea anyone? 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 |
|
From: Matan Ziv-Av <ma...@sv...> - 2000-07-08 07:33:40
|
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... |
|
From: James S. <jsi...@ac...> - 2000-07-08 00:50:19
|
Hi! I just commited some more code. Multihead with vgacon and mdacon might work. Give it a try and tell me the results. The keyboard driver for the console system still doesn't work manage multiple keyboards with multiple VTs just yet. I'm just curious what the results will be. It might hang your system. Thank you. 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 |
|
From: James S. <jsi...@ac...> - 2000-07-08 00:41:59
|
> 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 |
|
From: Franz S. <Fra...@la...> - 2000-07-07 15:01:26
|
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
|
|
From: Matan Ziv-Av <ma...@sv...> - 2000-07-06 18:58:42
|
> > 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... |
|
From: James S. <jsi...@ac...> - 2000-07-06 14:17:13
|
Hi! Vojtech its time to make keyboard.c mutlikeyboard aware. I nearly got mdacon working with vgacon. It hangs when mdacon is initialized so I have hunt down this bug today. Last time we where talking about having vt_struct in input_handle->private when kbd_connect is called. I just want to make sure doing this doesn't blow away any previous data the keyboard driver might need so I will need your help their. Then we can extract vt_struct when kbd_keycode is called. From that we can grab the visiable VC. 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 |
|
From: James S. <jsi...@ac...> - 2000-07-06 14:07:56
|
While working on console system I noticed this redundent code. In con_init after vc_init the palette is initialized. If you look at vc_init the palette is initialized there. So this patch removes setting the palette twice. 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 --- console.c.orig Thu Jul 6 10:00:10 2000 +++ console.c Thu Jul 6 10:03:06 2000 @@ -2439,11 +2439,6 @@ kmalloced = 0; vc_init(currcons, video_num_lines, video_num_columns, currcons || !sw->con_save_screen); - for (j=k=0; j<16; j++) { - vc_cons[currcons].d->vc_palette[k++] = default_red[j] ; - vc_cons[currcons].d->vc_palette[k++] = default_grn[j] ; - vc_cons[currcons].d->vc_palette[k++] = default_blu[j] ; - } } currcons = fg_console = 0; master_display_fg = vc_cons[currcons].d; |
|
From: James S. <jsi...@ac...> - 2000-07-06 14:01:03
|
This patches fixes a problem several fbdev drivers where having. The patch works great with vgacon as well. I have tested it with vgacon and fbdev for several weeks and it works fine. Other people have tried the patch and it worked for them. On calling sw->con_switch for fbdev drivers this could change the video mode. For many types of video hardware the way the palette is set depends on the video mode. In redraw_screen the palette was being set before the video mode was changed. This was producing errors on several drivers. This patch fixed this problem by setting the palette after sw->con_switch was called. Thank you. 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 --- console.c.orig Thu Jul 6 09:43:31 2000 +++ console.c Thu Jul 6 09:44:40 2000 @@ -581,10 +581,11 @@ if (redraw) { set_origin(currcons); - set_palette(currcons); - if (sw->con_switch(vc_cons[currcons].d) && vcmode != KD_GRAPHICS) + if (sw->con_switch(vc_cons[currcons].d) && vcmode != KD_GRAPHICS) { /* Update the screen contents */ + set_palette(currcons); do_update_region(currcons, origin, screenbuf_size/2); + } } set_cursor(currcons); if (is_switch) { |
|
From: James S. <jsi...@ac...> - 2000-07-06 13:14:35
|
> 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 |
|
From: James S. <jsi...@ac...> - 2000-07-06 13:09:16
|
> 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 |
|
From: James S. <jsi...@ac...> - 2000-07-06 12:53:57
|
> > 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 |
|
From: Matan Ziv-Av <ma...@sv...> - 2000-07-04 15:43:56
|
> > > > - 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... |
|
From: Vojtech P. <vo...@su...> - 2000-07-04 12:46:52
|
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 |
1998 messages has been excluded from this view by a project administrator.
