OSDev.org

I'm having strange problem with USB keyboard.
When I get IRQ1 iI check port 0x64 to see if data on port 0x60 are really there, and this works fine, but I'm getting strange data from port 0x60.
Examples: For same key I get different scan codes, 0xe0 as a second byte (sometimes)....

USB keyboards aren't connected to that port. They're connected to the USB port. Write a USB port driver and use that instead.

I'm amazed however that you got some reply at all. AFAIK it shouldn't give any reply on the PS/2 controller since you're not using it.

Are you using an USB keyboard through a converter plug?

IIRC, the BIOS is meant to bind a USB Keyboard to the PS/2 keyboard for compatibility (it'd be hard to use the DOS or even the BIOS itself without a keyboard - especially if you get "No keyboard detected, press F1 to continue"). Basically, it'll be running in emulation mode. 0xE0 is a prefix byte, IIRC, it indicates an extended character of some sort.

Yes I think (well I read it) that it should be running in some kind of PS/2 emulated mode, but it seems something went wrong >:(
0xE0 is prefix byte but it should be sent as the first byte not the second byte of scan code.

AR wrote: IIRC, the BIOS is meant to bind a USB Keyboard to the PS/2 keyboard for compatibility (it'd be hard to use the DOS or even the BIOS itself without a keyboard - especially if you get "No keyboard detected, press F1 to continue"). Basically, it'll be running in emulation mode. 0xE0 is a prefix byte, IIRC, it indicates an extended character of some sort.

AFAIK, it's the bios that replicates the information from the keyboard to the BIOS interface of the keyboard. As soon as you start PMode and stop using that interface, the emulation falls away (such as in Windows and Linux, the seconds in which ctrl-alt-del doesn't reboot the computer) and it does nothing. Later on, it connects with the USB connection and then uses it as a normal USB keyboard (at which time your ctrl-alt-del will be interpreted after all).

Hi,

Unfortunately it's a little more complex than that.

The BIOS uses SMM (System Management Mode) to execute code behind your back. To do this, the BIOS typically hides some code and data underneath the video display memory (i.e. from 0x000A0000 to 0x000BFFFF) and uses this as the SMM area.

The SMM code mainly handles power management (ACPI), but it also does the PS/2 emulation (and probably other things). Every time you access I/O ports 0x60 and 0x64 you cause the CPU to trap into SMM mode, where the SMM code emulates the I/O port access. A similar thing happens when you press a key (it causes an SMI which starts the BIOS SMM code to emulate the keypress).

This means that how well your PS/2 device driver works may depend on how good the BIOS's SMM emulation code is. I would assume some BIOSs are better than others...

To disable this emulation there's sometimes a BIOS setting (for my Pentium 4 the BIOS has an "emulate PS/2 keyboard for OSs that don't support USB" option). From software, you can mess with the state of the USB device itself to turn this emulation off (which is what Windows and Linux would hopefully do).

This mess is one of the reasons I don't implement any device drivers until I've done full hardware detection. Otherwise it's possible to detect a PS/2 keyboard, then start a USB driver and detect a "second" USB keyboard. If the USB driver disables the emulation then your original PS/2 driver is suddenly controlling thin air.


Cheers,

Brendan

Brendan wrote: This mess is one of the reasons I don't implement any device drivers until I've done full hardware detection. Otherwise it's possible to detect a PS/2 keyboard, then start a USB driver and detect a "second" USB keyboard. If the USB driver disables the emulation then your original PS/2 driver is suddenly controlling thin air.

I need keyboard in my bootlader because it has boot menu and I need to capture very few keys: enter, esc, up arrow, down... This means that I don't really want to detect all installed hardware, because I'm not even using 10% keys on keyboard at that time

Well I guess I should test my code on few more machines with USB keyboard if it doesn't work... USB drivers here I come

so, why do you mess with direct keyboard access?
You could just use the BIOS Interrupts in your bootloader...

Because I wrote it to work in protected mode

@kataklinger: well, for a bootloader menu, i'd say you can blissfully ignore the fact that the keyboard is PS/2 or USB and use the emulated PS/2 keyboard. Chances that you mess up with SMM or SMI in a bootloader are very thin.

@brendan: what about saying that USB detection should occur _before_ 'PS/2' detection ?

@brendan: what about saying that USB detection should occur _before_ 'PS/2' detection ?

Sounds like a Microsoft solution? ;D

does it? well, saying that PS/2 is a "fallback" thing seemed natural to me, the same way i'd say that PCI scanning should occur before you attempt to do a SoundBlaster detection routine (which is based on probing ports 0x200 .. 0x260 to see if there's something that reacts like a SoundBlaster there)

If you assign all your "bus drivers" a priority and execute scanning in priority order, you'll be able to have a USB scanner saying the legacy scanner there's no PS/2 mouse and yet code the PS/2 "scanner" (well, that basically consist of looking at BDA content) before you do the USB scanner ...

Anyway, if you detect a USB mouse for which you don't have drivers, i'll be running it in PS/2 compatibility mode ... wouldn't you ?

Hi,

@Bubach: Before you can scan the USB bus (or buses), you need to detect the USB host controller/s. This means you'd need to scan AGP/PCI buses, then scan USB buses, then check for PS/2 devices.

Pype.Clicker wrote:Anyway, if you detect a USB mouse for which you don't have drivers, i'll be running it in PS/2 compatibility mode ... wouldn't you ?

If I'd already got that far, I'd be quite tempted to write a USB driver for the mouse instead!


Cheers,

Brendan

Brendan wrote: Before you can scan the USB bus (or buses), you need to detect the USB host controller/s. This means you'd need to scan AGP/PCI buses, then scan USB buses, then check for PS/2 devices.

That is the way i would do it. the USB controller is connected of the PCI. The once the you find the PS/2 device on the bus the USB controler should tell you what resources (i.e ports any memory address IRQs) the device uses.

Brendan wrote:

Pype.Clicker wrote:Anyway, if you detect a USB mouse for which you don't have drivers, i'll be running it in PS/2 compatibility mode ... wouldn't you ?

If I'd already got that far, I'd be quite tempted to write a USB driver for the mouse instead!

There's no such situation. USB Mice have to conform to the USB HID standard, which includes a define-packet-format-and-meaning block you can read, and then you can of course interpret the input. That works for keyboards, joysticks, mice and so on.

The situation that you'd get a USB mouse that doesn't work with the HID standard, but that DOES work with your BIOS is a paradox.