PS/2 Mouse: Difference between revisions
[unchecked revision] | [unchecked revision] |
(added more detailed examples on reading the generic ps/2 mouse packet) |
m (fixed section title (had duplicate)) |
||
Line 35: | Line 35: | ||
So, overall the hardware exposing the PS/2 interface may be light weight or heavy and it all depends on the system board (not the processor). |
So, overall the hardware exposing the PS/2 interface may be light weight or heavy and it all depends on the system board (not the processor). |
||
===== Mouse |
===== Mouse Device Over PS/2 ===== |
||
: $linuxsrc/drivers/input/mouse/psmouse-base.c |
: $linuxsrc/drivers/input/mouse/psmouse-base.c |
||
: http://www.computer-engineering.org/ps2mouse/ |
: http://www.computer-engineering.org/ps2mouse/ |
Revision as of 19:57, 24 March 2012
PS/2 Protocol
Also to avoid your confusion. A PS/2 bus (interface) by standard is limited to only one device. Although, you may hear it is limited to two devices. Do not become confused because your system hosting the interface is considered one of the two, and the keyboard or mouse for instance is actually considered the master (drives the clock line) and the computer (host) the slave.
You may wish to see the PS2 Keyboard page from here. As it stems from the PS/2 protocol.
Implementation Of The PS/2 Protocol
This greatly depends on your board. So for starters your going to need specific code to deal with this hardware that implements the PS/2 protocol or exposes it, then you are going to need to deal with the mouse hardware.
For example taking a look at:
- $linuxsrc/drivers/input/serio/i8042.c
We can see an actual driver for the I8042 PS2 implementation/hardware. Now, on top of this Linux creates an serial abstraction type layer. This allows all sorts of different implementation of the PS/2 interface to exist but become exposed to for instance the mouse driver as no different than any other device (such s the I8042 or the PL050). I will explain about the PL050 in the next few paragraphs. Otherwise, each mouse driver would have to specifically support each implementation (I8042, PL050, ...) of a PS2 bus interface.
By taking note of how Linux separated the hardware will allow you to see the programming paradigm that is taking place. But, this is not required for you to fully understand in order to implement your mouse driver.
If your writing an operating system you always have time to go back and rewrite or expand a part of it. So at first you will be okay just writing a single driver to handle the hardware exposing the PS/2 and the mouse driver in one package. And, in other cases it may actually make more sense to create a single driver for instance for an embedded system.
Another example is the ARM Integrator/CP board which implements the PS/2 interface encapsulated in the PL050 (where the PL050 is analogous to the I8042) except you communicate with the PL050 differently than the I8042. But, after the PL050 is configured you then proceed with the PS/2 mouse protocol. For example:
KMI_MMIO volatile *mmio; uint32 tmp; mmio = (KMI_MMIO*)KMI_MS_BASE; mmio->cr = 0x4; /* talk to the PS2 controller and enable it */ mmio->data = 0xF4; /* keyboard sends back ACK */ while(!KMI_TXFULL(mmio->stat)); tmp = mmio->data;
The above uses memory mapped input/output (MMIO), but other architectures may use I/O ports instead or a combination of I/O ports and MMIO for example the X84/64. So understanding your platform is very important to understand how to proceed in talking to the devices.
Above, the PL050 is also called the KMI (Keyboard And Mouse Interface). So first we have to configure the PL050 by enabling it. Now, it provides a interface to the PS2 interface which then interfaces with the mouse. So, the next thing I have to do is write the value 0xF4 which you can find in the table above to enable the mouse.
So, overall the hardware exposing the PS/2 interface may be light weight or heavy and it all depends on the system board (not the processor).
Mouse Device Over PS/2
- $linuxsrc/drivers/input/mouse/psmouse-base.c
- http://www.computer-engineering.org/ps2mouse/
Here is the table of command a generic PS/2 compatible mouse understands:
Standard PS/2 Mouse Commands | |
---|---|
Byte | Description |
0xFF | Reset |
0xFE | Resend |
0xF6 | Set Defaults |
0xF5 | Disable Data Reporting |
0xF4 | Enable Data Reporting |
0xF3 | Set Sample Rate |
0xF2 | Get Device ID |
0xF0 | Set Remote Mode |
0xEE | Set Wrap Mode |
0xEC | Reset Wrap Mode |
0xEB | Read Data |
0xEA | Set Stream Mode |
0xE9 | Status Request |
The most command reply is 0xFA from the master (mouse), which means acknowledge. You may then get a variable number of bytes afterwards depending on the command. You may also receive other command replies which may state that the master (mouse) has encountered an error decoding your command. For a more detailed list check out some of the links above or look through the Linux source tree.
First, you have to enable the mouse on the PS/2 bus. This requires sending one byte which is clocked over the PS/2 interface. You will then get a response regarding the result. By sending 0xF4 (Enable Data Reporting) the mouse should reply back with a 0xFA which means acknowledgement. Then afterwards as the mouse pointer is moved it will send back the generic packet format like below. Unless, you enable an enhanced mode for the mouse (non-standard) this is what you will get when ever the mouse is moved.
Generic PS/2 Mouse Packet Bits | ||||||||
---|---|---|---|---|---|---|---|---|
BYTE | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
0 | yo | xo | ys | xs | ao | bm | br | bl |
1 | xm | |||||||
2 | ym |
Code | Description |
---|---|
yo | Y-Axis Overflow |
xo | X-Axis Overflow |
ys | Y-Axis Sign Bit (9-Bit Y-Axis Relative Offset) |
xs | X-Axis Sign Bit (9-Bit X-Axis Relative Offset) |
ao | Always One |
bm | Button Middle (Normally Off = 0) |
br | Button Right (Normally Off = 0) |
bl | Button Left (Normally Off = 0) |
xm | X-Axis Movement Value |
ym | Y-Axis Movement Value |
Each X and Y axis value is relative. The mouse device does not track it's location in absolute coordinates. This should also be apparent by the 9-bit values. Instead, it sends back saying I moved this far to the left, to the right, down, or up. To keep track of a mouse position you need to accumulate these relative offsets into a absolute position offset in your code:
mouse_x = mouse_x + mouse_packet_rel_x mouse_y = mouse_y + mouse_packet_rel_y
Being these 9-bit values are signed the above pseudo would work.
Also, if you simply read the xm or ym fields you will get an 8-bit unsigned value. Which, if used as unsigned will yield incorrect behavior. If you convert it into a signed 8-bit value you will get behavior that is similar to correct, but strange artifacts will appear when the mouse is moved fast. The correct way to produce a 9-bit or greater signed value is as follows:
state = first_byte d = second_byte rel_x = d - ((state << 4) & 0x100) d = third_byte rel_y = d - ((state << 3) & 0x100)
The pseudo code above will cause ((state << 4) & 0x100) to equal 0x100 only if the signed bit (9'th bit stored in the first byte) is set. If the 9'th bit is set then the value is deemed negative, but the value in second_byte is not stored in one or two's complement form. It is instead stored as a positive 8-bit value. So, if second_byte is say a 2 then it will become 2 minus 0 since the negative (9'th bit) is off. But, if it is on then it will become 2 minus 0x100 which will produce the twos complement, or -2. It will also cause the register to be correctly sign extended no matter it's size.
Mouse Extensions
Here, an example of mouse that supports extensions. To maintain backwards compatibility you should have to activate these features through the PS/2 bus. Various mouse devices use different ways. Linux mouse drivers for example sometimes handle multiple different devices which all share the same standard packet format above, or at least support the compatibility mode described above.
IntelliMouse Explorer | ||||||||
---|---|---|---|---|---|---|---|---|
BYTE | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
3 | vs | hs |