OSDev.org

Posted: **Fri May 20, 2005 7:04 pm**

My mouse is not completely working. My kernel is currently in 3 stages.
1st: Bootstrap; enables A20; PMODE; loads 2nd.
2nd: IDT written to 0x8700; floppy driver loads 3rd; Init mouse; Paging; ect.
3rd: Rewrites IDT to 0x90000; GUI.

Now, we have two issues on our hands:
1. The mouse init routine only works right when I boot the second stage. Meaning, that it won't initialize the mouse if I put the same exact code much later in my program. Apparently the mouse expects the be initialized early in the boot process. BTW, it takes ~20 seconds from the time of the 2nd stage starting to the 3rd stage actually running. In summary: can the mouse only be initialized early in the boot?

2. IF I DO ENABLE the mouse in the 2nd stage, my mouse barfs after I rewrite my IDT. It doesn't send any more packets over the same exact interrupt. BTW, the interrupt, PIC, ect is working fine in all the stages AND the cascade, keyboard, mouse are unmasked AND the keyboard SHOULDN'T have sent any commands to be read.. I catch every byte sent from the keyboard.

So, how does this work? Is there some way I can turn off the mouse for my rewrite of the IDT? Could I simply 'Reset' the mouse after I start the 3rd stage?
And if I was to talk to the mouse, documentation is not very helpful and rather sparse. It's fairly hard to get a lot of info on this device.
Questions? Comments? Smart remarks?

Thanks,
Brett

Posted: **Fri Jun 03, 2005 1:41 pm**

I had the same problem. when I initialize Mouse after initialising Keyboard, it dint work. so i do one thing:
1. setting up IDT
2. Eanble Mouse (See 1st I initialize mice)
3. Initilize Keyboard
and so on....
Surprizingly It works..........

Posted: **Sun Jun 05, 2005 3:36 am**

just out of curiosity, how do you "initialize the keyboard" ??

Posted: **Mon Jun 06, 2005 3:22 pm**

You initialize the keyboard by telling it that you definitely DON'T want the default scancode set, and that it's default repeat rate is totally too slow to be of any use whatsoever.

Posted: **Mon Jun 06, 2005 7:11 pm**

Hi,

I guess a more direct line of questioning may be:

a) How do you initialize the keyboard?
b) How do you initialize the mouse?
c) How do you initialize the PS/2 controller?

In my experience the PS/2 controller can take a relatively large amount of work to initialize correctly - especially if you auto-detect which devices are connected, prevent the rare case of received data messing up initialization, and/or handle incompatibilities between different PS/2 controller chips.

Cheers,

Brendan

Posted: **Tue Jun 07, 2005 2:37 am**

well, there are
http://www.mega-tokyo.com/forum/index.p ... eadid=3888
and http://www.mega-tokyo.com/forum/index.p ... eadid=7336 giving info about the PS2 mouse initialization already, and i know the mouse should be given some commands before it starts delivering events to the PC, but i never heard of something similar for keyboard.

Now okay, if you mean setting suitable typematic rate and things alike ...

Posted: **Tue Jun 07, 2005 2:59 am**

To get it further, I for one fetch the first scancode after doing all the init stuff (setting the LED's to a known state, choosing repeat rate & scan code set, initializing the circular scancode buffer and registering the Interrupt handler) to avoid mixing up in the buffer. Unwanted characters might be read.

Posted: **Tue Jun 07, 2005 5:15 am**

Hi,

My current PS/2 controller initialization sequence goes like this:

Code: Select all

a) Do a couple dummy reads from the data port.
b) Get the current controller configuration byte (controller command 0x20).
c) Do another dummy read from the data port.
d) Set a new configuration byte (controller command 0x60).
     Note: This step disbles IRQs, enables clock signals to any devices
           and disables the scan code translation for the first PS/2 port
e) Do another dummy read from the data port.
f) Send "disable device B" command to the controller (controller command 0xA7).
g) Get the current controller configuration (controller command 0x20).
h) If clock signal to device B is still enabled, then assume the PS/2
     controller is an older "single device" controller rather than
     a "dual device" controller, and mark device B as unusable.
i) If it is a "dual device" controller, send the controller configuration
     byte again to re-enable device B (controller command 0x60).
j) Create a new node for the PS/2 controller in my "device tree" (mark the
     IO ports and IRQ/s as used, etc).
k) Disable scanning for device A by sending command 0xF5 to it.
l) If device B is still usable, disable scanning for device B by
     sending command 0xF5 to it.
m) Perform device A interface test (send command 0xAB to device).
n) If device B is still usable, perform device B interface test (send
     command 0xAB to device).
o) Reset device A (device command 0xFF) - if it doesn't return 0xFA then
     0xAA (ACK then BAT test passed) mark device A as unusable, otherwise
     disable device A scanning again (device command 0xF5).
p) If device A is still usable, send the "identify" device command to
     it and store anything returned for later.
q) If device B is still usable, reset device B (device command 0xFF) - if
     it doesn't return 0xFA then 0xAA mark device B as unusable, otherwise
     disable device A scanning again (device command 0xF5).
r) If device B is still usable, send the "identify" device command to
     it and store anything returned for later.
s) Add any usable devices to the the "device tree" ready to load device drivers

There's a few notes that go with all this..

It's designed to support any combination of devices (a mouse where the keyboard normally goes, a pair of keyboards and no mouse, etc).

I deliberately try to disable the default scan code translation (which is meant to convert "scancode set 2" sent by the keyboard into "scancode set 1"). This translation is only possible for device A, and messes up mouse data when a mouse is plugged in as device A. Unfortunately, for some older PS/2 controllers it can't be disabled (~80486 and Bochs), and for some new computers if the BIOS has the "emulate PS/2 for USB keyboard/mouse for crappy OSs" option enabled. In this case it's difficult to have a mouse as PS/2 device A (I still need to do some research on how hard it is to reverse this translation if it can't be disabled).

All of the steps above rely on little helper routines to get data, send commands, etc. These helpers can all return a time-out error. During the early parts of initialization any time-out results in a "controller not found" condition. Later stages may result in device A or device B being marked unusable or a "controller not found" condition (if the time-out shouldn't be possible when a device isn't present).

Possible "device types" returned from step P and step R are:

Code: Select all

  0xFA               AT keyboard with translation (not possible for device B)
  0xFA, 0xAB, 0x41   MF2 keyboard with translation (not possible for device B)
  0xFA, 0xAB, 0xC1   MF2 keyboard with translation (not possible for device B)
  0xFA, 0xAB, 0x83   MF2 keyboard without translation
  0xFA, 0x00         Standard mouse
  0xFA, 0x03         Mouse with a scroll wheel
  0xFA, 0x04         5 button mouse with a scroll wheel

There's probably device types that I haven't seen yet, but the list covers everything I've been able to test so far.

After initialization, the IRQs for any usable devices are left disabled and so is device scanning. These are enabled when a PS/2 keyboard or mouse driver does it's initialization. Leaving "device scanning" disabled prevents the device from sending any data to the controller unless they've been asked to.

Device specific configuration is left to an appropriate device driver (there's no setting the LED's, typematic rate, mouse scaling, etc). The idea is to configure the PS/2 controller only - it could be a bar code scanner or something attached for all I know.

The method above works on everything I've tested it on, but I haven't tested it on everything in the world so there's no guarantees

.

Cheers,

Brendan

OSDev.org

Meese

Meese

Re:Meese

Re:Meese

Re:Meese

Re:Meese

Re:Meese

Re:Meese

Re:Meese