[9fans] usb keyboard and mouse?

[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

Re: [9fans] usb keyboard and mouse?

[Francisco J Ballesteros]

Time ago I implemented a usbhid, w/ keyboard/mouse combo drivers.
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.

On 6/26/06, ISHWAR RATTAN <rattan@cps.cmich.edu> wrote:
>
> 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
>
>
>

Re: [9fans] usb keyboard and mouse?

[geoff]

Some BIOSes have an option with a name like "enable legacy USB" or
"enable USB keyboard" that, if set, will simulate PS2 input from a USB
keyboard or mouse.

Re: [9fans] usb keyboard and mouse?

[Artem Letko]

but that's only if your kernel uses BIOS calls, right?

On 6/26/06, geoff@collyer.net <geoff@collyer.net> wrote:
> Some BIOSes have an option with a name like "enable legacy USB" or
> "enable USB keyboard" that, if set, will simulate PS2 input from a USB
> keyboard or mouse.
>
>

Re: [9fans] usb keyboard and mouse?

[Francisco J Ballesteros]

Also, I found that in several cases, setting up usb suffices to get
the hid device out of boot protocol (i.e. back to hid).

On 6/28/06, Artem Letko <aletko@gmail.com> wrote:
> but that's only if your kernel uses BIOS calls, right?
>
> On 6/26/06, geoff@collyer.net <geoff@collyer.net> wrote:
> > Some BIOSes have an option with a name like "enable legacy USB" or
> > "enable USB keyboard" that, if set, will simulate PS2 input from a USB
> > keyboard or mouse.
> >
> >
>
>

Re: [9fans] usb keyboard and mouse?

[C H Forsyth]

> > Some BIOSes have an option with a name like "enable legacy USB" or
> > "enable USB keyboard" that, if set, will simulate PS2 input from a USB
> > keyboard or mouse.
> but that's only if your kernel uses BIOS calls, right?

no, it works without that; it's intercepted at a lower level.

Re: [9fans] usb keyboard and mouse?

[Ronald G Minnich]

C H Forsyth wrote:
>>>Some BIOSes have an option with a name like "enable legacy USB" or
>>>"enable USB keyboard" that, if set, will simulate PS2 input from a USB
>>>keyboard or mouse.
>>
>>but that's only if your kernel uses BIOS calls, right?
> 
> 
> no, it works without that; it's intercepted at a lower level.

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

Re: [9fans] usb keyboard and mouse?

[Mike Haertel]

Er, no.  Legacy keyboard emulation is intended to work with any OS,
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" <aletko@gmail.com>
>To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
>
>but that's only if your kernel uses BIOS calls, right?
>
>On 6/26/06, geoff@collyer.net <geoff@collyer.net> wrote:
>> Some BIOSes have an option with a name like "enable legacy USB" or
>> "enable USB keyboard" that, if set, will simulate PS2 input from a USB
>> keyboard or mouse.

Re: [9fans] usb keyboard and mouse?

[Charles Forsyth]

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

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.

Re: [9fans] usb keyboard and mouse?

[Dan Cross]

On Wed, Jun 28, 2006 at 10:31:26PM -0700, Mike Haertel wrote:
> 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.

Re: [9fans] usb keyboard and mouse?

[Ronald G Minnich]

Dan Cross wrote:
> On Wed, Jun 28, 2006 at 10:31:26PM -0700, Mike Haertel wrote:
> 
>>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.
> 

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

Re: [9fans] usb keyboard and mouse?

[Charles Forsyth]

>Dear Lord!  At what point is a chicken sacrificed in this process?

as often as possible, as usual.
chickens are cheap; code is costly.