OSDev.org

fixed

fixed

The mouse tells you how far it moved. The mouse does not tell you where it moved to.

fixed

octacone wrote:Okay, it only tells me the direction, up down left right. How do I get its real location (x, y)?

You start somewhere (e.g. in the center), then you add the movements to the position.
So if the mouse starts at X = Y = 100, and then the mouse tells you it moved +10 on the X-axis and -20 on the Y-axis the new position becomes X = 110, Y = 80.
You just remember where the mouse is and keep track of how far it moved away from that place (and in which direction).

fixed

No, like this: Call it everytime the mouse moves.
deltaX and deltaY come from the mouse packet, the wiki tells you which byte is what and where the sign bits are.

octacone wrote:

Octocontrabass wrote:The mouse tells you how far it moved. The mouse does not tell you where it moved to.

Okay, it only tells me the direction, up down left right. How do I get its real location (x, y)?

The mouse tells you its direction AND how much it moved in that direction.
Bit 4 of the data (byte 0 of the packet) tells you the X direction. When it is clear, the mouse is being moved right, and X is a positive value. In this case, do: mouse_x += mouse_packet.x; When it is set, the mouse is being moved left, and X is a negative value. In this case, do: mouse_x -= (~mouse_packet.x+1);
Bit 5 of the data packet is mostly the same idea, but for the Y direction. When it is clear, Y is a positive value and the mouse is being moved down (towards the user). When it is set, the Y packet is a negative value in the mouse is being moved away from the user.

Also remember that there are different packet formats for different mice.

Most PS/2 mice will start sending a certain packet format no matter the mouse type. Then using the SetSampleRate() command, you send a sequence of three rates and the mouse will change to a different format, as long as it is capable of that format. For example, the initial packet will have the X and Y coordinates, and two or three buttons. When you send the three special SetSampleRate() commands, you can instruct the mouse to send the Z delta also, four buttons, or many more formats.

When you initialize the mouse by sending the Reset() command, the mouse will send you an ID byte. This byte will tell you what packet to expect. Most of the time the value will be zero, initially. After you send the SetSampleRate() sequence, send the GetIDByte() command and the mouse may or may not send you a different ID, indicating that it now supports a different packet, that packet format you requested by the sequence of SetSampleRate() commands.

Ben
http://www.fysnet.net/input_and_output_devices.htm

fixed

A few things right off the bat. Yourwill instantly return if there is no input ready rather than waiting for input to be ready. However, since the controller fired the interrupt, that means there is a byte ready to be read. No need to check.

Also, and this is what catches most people, the controller will fire an interrupt once for each byte sent to the single-byte output buffer. You must only read one byte per interrupt. Therefore, you must maintain a running buffer of your own and keep track of the start of the packet, which you have done with your mouseCycle member.

Please note that you must exit your interrupt handler as soon as you have stored that byte and updated your mouseCycle member, allowing the controller to fire the next interrupt so that you can come back and do it again.

I believe that all you need to do is re-write your handler to be called once for each byte, handling only a single byte per call, and you will get the result you are looking for. Also, no need to check to see if a byte is available, the interrupt fired, so a byte is available.

Ben

fixed

fixed

fixed

fixed