Ok, so I burn the i386 ISO and boot it up on my PC

[bloodline]

Shadowfax wrote:
Yeep, I tried a PS/2 mouse (that little round port next to the keyboard port on the ATX's rear panel) but with no response. I'll poke around in the BIOS and see what I can see.

That's really odd, I've not found a PS/2 mouse that hasn't worked yet...

I expect the BIOS has the "Legacy support" switched off or something.

[bloodline]

Floid wrote:

bloodline wrote:

Shadowfax wrote:
Yeep, I tried a PS/2 mouse (that little round port next to the keyboard port on the ATX's rear panel) but with no response. I'll poke around in the BIOS and see what I can see.

That's really odd, I've not found a PS/2 mouse that hasn't worked yet...

I expect the BIOS has the "Legacy support" switched off or something.

Does AROS use ACPI for any of that?

Nope, but it would be nice it it did...

[bloodline]

Floid wrote:

bloodline wrote:

Does AROS use ACPI for any of that?

Nope, but it would be nice it it did...

Hum, ah well, currently fiddling with DragonFly on a board with a specifically bugged ... whew, whatever it is, the code you compile to tell it how to present one of the tables involved.

I had similar mouse and keyboard issues with QNX6 on certain 486en back when I was trying to get into it, where you'd expect it all to work, and for some reason it doesn't.

[Hm, there's an idea, you guys fit on a floppy... How much hardware detection actually goes on right now?  Would it be possible to cut an image that loads, say, a memory resident version from a FAT floppy, and blows some rough equivalent of a dmesg/detected device tree back into a text file on the FAT-formatted disk?  Might be convenient for newbies and weird troubles?]

Not a great deal of Hardware detection goes on, AFAIK, just what ever the BIOS knows and then a scan of the PCI bus (looking for any supported devices).

We had one developer looking ACPI, but he is busy with Wanderer at the moment.

[bloodline]

Floid wrote:

bloodline wrote:

Not a great deal of Hardware detection goes on, AFAIK, just what ever the BIOS knows and then a scan of the PCI bus (looking for any supported devices).

Ah, okay.  The above was just presented as a general theory for solving the "it'd be nice to know what exact hardware is present to be failing and not everyone can be bothered to crack the case" issue OS developers seem to get into.  (Of course, depending how the software is written, you still have to trust that it guesses right, but that's obvious.)

yeah, that would be nice... the nearest we have is that we can provide the user with a disk that has debug enabled which (just like AmigaOS's Romwack) will dump out full debug info through the serial port which can be captured by another computer.