PS/2 mouse initializing

[Thunder]

I'm confused with PS2 mouse:
What I must to do to inialize mouse (PS2)?

I think:
to initialize mouse interface 0xA8 to 0x64 port,
then before sending each command to aux I need to send 0xD4 to 0x64 port,
so I send 0xF6 - this sets mouse defaults, enters Stream mode and disables data reporting. So I enable data reporting after sending 0xD4 to 0x64 port with byte 0xF4. And, in my opinion thats the end of initialization.

Then I get back 3 bytes from IRQ12

Am I right?
Thanks. Bye...

[Pype.Clicker]

all i know about PS2 mice has been posted here

[Thunder]

Pype,
you were not right, when we enable PS/2 mouse, on IRQ12 we get all 3 bytes .

My problem was, that I was doing inportb too fast.
The initialization of PS/2 mouse was good.
Bye

[Pype.Clicker]

well, i guess the real amount of bytes you'll receive per interrupt will depend on hardware timings, i don't remember very well where i read this from ...
but i still think you should not *assume* that the 3 bytes will be here (unless you tell me you tried on several distinct hardware and virtual platform or find something in the 8042 docs that tells "one IRQ12 interrupt when the whole mouse packet has been received) when you're called. If there are more than one byte, that's just fine: pick them all ... if there are less, you should be able to handle it aswell ...

For instance, brandon on BOCHS has one interrupt for 2 bytes and then a second one with only 1 byte ...

i'll check the linux source to be sure ... (drivers/char/pc_keyb.c)

[bkilgore]

I based my mouse code on the loosely on the linux code, which does support a variable number of bytes per interrupt.

If you take a look at the function handle_kbd_event in pc_char.c you can see that the function iterates on a

Code: Select all

 while (status & KBD_STAT_OBF) 

and each scancode read this way is passed off to handle_mouse_event if the mouse buffer flag was set (indicating it was a mouse byte being read, as opposed to a keyboard scancode)

So as long as the keyboard refills the buffer in the time it takes the function to handle the scancode, it will keep reading the scancodes. If at any point it takes longer than this, the interrupt will return, and then will fire again when the next scancode is ready. So although you could just read one per interrupt, it makes more sense to keep reading as long as you can, to eliminate some of the overhead of switching contexts for the interrupt.

Just remember to add the scancodes to a buffer and keep track of how many you've received, and only parse them in multiples of three.


Another thing to watch for is mouse acknowledgment scancodes, which come in the form of 0xFA bytes that look exactly like other movement scancodes, but have to be ignored if you sent a command to the mouse that sends back acknowledgment.

FYI - I'm planning on writing a PS/2 mouse tutorialover the next week or so in my free time. If anyone is interested let me know, and I'll post a link when it's done.

[Pype.Clicker]

i would be interrested. You can post the link to your tutor on the board.

[Slasher]

the ps/2 mouse only sends 1 byte per interrupt. I spent days trying all sorts to see if the 3 byte packet is sent in one interrupt and it is not.
In your mouse isr you should count the number of bytes recieved until you get three. you store each byte and acknowledge the int after each byte. Only after you get the 3 bytes do you modify your mouse variables. A tutorial is in the making, will post it when next i log on

[bkilgore]

the ps/2 mouse only sends 1 byte per interrupt. I spent days trying all sorts to see if the 3 byte packet is sent in one interrupt and it is not.
In your mouse isr you should count the number of bytes recieved until you get three. you store each byte and acknowledge the int after each byte. Only after you get the 3 bytes do you modify your mouse variables.

As was mentioned above, the actual number of values sent per interrupt varies by the hardware or the emulator. For optimization purposes, it is worthwhile to continue reading as many values as are ready while the isr is active, to prevent unnecessary context switches.

A tutorial is in the making, will post it when next i log on

Mine is also almost done. It will be posted on my sourceforge site when it is ready (as will all future tutorials)

- Brandon