[9fans] usb keyboard and mouse?
ISHWAR RATTAN
Got a machine that has usb ports only. Plan 9 iso gets
stuck (as no input can be provided form the kbd). Is there
a solution to this problem?
-ishwar
Francisco J Ballesteros
Things changed later here and we are not using it since a few months.
I think I have a copy in the dump somewhere, but it´s likely it will need
some adjustments for changes in usbd libusb.
BTW, using it requires changing boot to start usbd usbhid or you won´t be
able to type the password.
If you don´t find anything better, drop me a line and I´ll copy our most recent
version to sources.
ge...@collyer.net
"enable USB keyboard" that, if set, will simulate PS2 input from a USB
keyboard or mouse.
Artem Letko
Francisco J Ballesteros
the hid device out of boot protocol (i.e. back to hid).
C H Forsyth
> > "enable USB keyboard" that, if set, will simulate PS2 input from a USB
> > keyboard or mouse.
no, it works without that; it's intercepted at a lower level.
Ronald G Minnich
You just gotta love system management mode.
Fun. There's giant USB stacks in the bios'en nowadays. Sometimes they
work. Sometimes they don't. Well, often they don't, but ... that's
another story.
I had one machine recently that would work fine with the keyboard --
until the OS came up. then it stopped. And another machine that could
boot off USB key -- er, well, not THAT USB key, or that OTHER USB key,
or ... well, it had booted off SOME usb key at some phase of the moon,
in a timezone > 12 hours off ours. Woo hoo!
BIOS and USB -- what a combination! Sure to induce longing for the steppes.
ron
Mike Haertel
even if the OS bypasses the BIOS and directly fiddles with the PS/2
hardware. It uses chipset magic to translate "in" and "out"
operations to ports 0x60 and 0x64 (the PS/2 keyboard ports) into
USB operations.
The implementation is chipset dependent. Often what happens is
that the chipset recognizes an I/O request to port 0x60 or 0x64 and
aborts the request with an SMI (system management interrupt). This
is a *very* non-maskable interrupt (more non-maskable than NMI...)
that causes the processor to save pretty much all its register state
in a special memory area, and jump to a handler in the system BIOS.
The BIOS SMI handler examines the saved register state, figures out
what the OS was trying to do, runs a software model of the PS/2
keyboard controller's state, chats with the USB keyboard, formulates
an appropriate response, emulates the I/O instruction the OS was
trying to do, and resumes execution of the OS at the instruction
following the I/O instruction.
Some chipsets might do it directly in hardware rather than using
the SMI+BIOS strategy.
>From: "Artem Letko" <ale...@gmail.com>
>To: "Fans of the OS Plan 9 from Bell Labs" <9f...@cse.psu.edu>
>
>but that's only if your kernel uses BIOS calls, right?
>
Charles Forsyth
> what the OS was trying to do, runs a software model of the PS/2
> keyboard controller's state, chats with the USB keyboard, formulates
> an appropriate response, emulates the I/O instruction the OS was
> trying to do, and resumes execution of the OS at the instruction
> following the I/O instruction.
yes, it's good fun and worked fine on my plan 9 file server.
i assumed it was all done with interrupts disabled, so that, as
anciently, the console should not indeed be used for chit-chat.
Dan Cross
> The implementation is chipset dependent. Often what happens is
> that the chipset recognizes an I/O request to port 0x60 or 0x64 and
> aborts the request with an SMI (system management interrupt). This
> is a *very* non-maskable interrupt (more non-maskable than NMI...)
> that causes the processor to save pretty much all its register state
> in a special memory area, and jump to a handler in the system BIOS.
> The BIOS SMI handler examines the saved register state, figures out
> what the OS was trying to do, runs a software model of the PS/2
> keyboard controller's state, chats with the USB keyboard, formulates
> an appropriate response, emulates the I/O instruction the OS was
> trying to do, and resumes execution of the OS at the instruction
> following the I/O instruction.
>
> Some chipsets might do it directly in hardware rather than using
> the SMI+BIOS strategy.
Dear Lord! At what point is a chicken sacrificed in this process?
- Dan C.
Ronald G Minnich
> On Wed, Jun 28, 2006 at 10:31:26PM -0700, Mike Haertel wrote:
>
>>that the chipset recognizes an I/O request to port 0x60 or 0x64 and
>>aborts the request with an SMI (system management interrupt). This
>>is a *very* non-maskable interrupt (more non-maskable than NMI...)
>>that causes the processor to save pretty much all its register state
>>in a special memory area, and jump to a handler in the system BIOS.
>>The BIOS SMI handler examines the saved register state, figures out
>>what the OS was trying to do, runs a software model of the PS/2
>>keyboard controller's state, chats with the USB keyboard, formulates
>>an appropriate response, emulates the I/O instruction the OS was
>>trying to do, and resumes execution of the OS at the instruction
>>following the I/O instruction.
>>
>>Some chipsets might do it directly in hardware rather than using
>>the SMI+BIOS strategy.
>
>
>
> - Dan C.
>
well, it does get better. On the GX2, the BIOS is a message-passing
microkernel that lives in SMI. I am not making this up.
ron
Charles Forsyth
as often as possible, as usual.
chickens are cheap; code is costly.