Prompted by this earlier question about USB-to-PS2 adapters, in which the answer is that the mouse figures out what it is connected to, the question arises: how do it know?

  • 2
    I didn't believe that the mouse cares - it is on the PC port to figure it out.
    – Jon Custer
    Commented Jan 17 at 17:53
  • 3
    Does this answer - retrocomputing.stackexchange.com/a/28297/332 - work for you?
    – davidbak
    Commented Jan 17 at 17:54
  • 3
    @JonCuster - the PC port can't figure it out, it's just a standard PS2 port, specified before USB was invented.
    – dave
    Commented Jan 17 at 18:04
  • 12
    @JonCuster It is definitely not the job of PC to figure that out. The PC talks USB on USB ports and PS/2 on PS/2 ports and there is nothing that can change that.
    – Justme
    Commented Jan 17 at 18:26
  • 3
    @ecm The electrical interface and bit-level protocol how bytes are transferred is between AT and PS/2 is practically identical. The PS/2 mouse and keyboard just send different bytes to signal different things. So to the microcontroller in a keyboard and/or mouse, the process of determining if it is connected to USB or PS/2 socket is identical.
    – Justme
    Commented Jan 17 at 19:40

1 Answer 1


The chip inside the mouse or a keyboard is a microcontroller that can detect to which interface it is being connected.

Such MCUs are manufactured by for example Holtek and you could at least back in the day buy pre-programmed MCUs so, to the mouse or keyboard manufacturer, it is just an application-specific IC which implements both USB and PS/2 interfaces and can be put into a circuit and it just works.

The detection mechanism is not described in detail in the data sheet because why would they - you are just buying a pre-programmed MCU which you really don't have to know how it works, and it is likely a trade secret with the firmware being unreadable once programmed.

However, the USB and PS/2 interfaces have similarities (5V supply and ground, two pins for bus).

They also have differences that can be used to detect where the mouse/keyboard MCU is connected.

The PS/2 bus has two pins, data and clock, and they are both 5-volt open-collector (or open-drain) pins for bi-directional transfers and pulled up to 5V with resistors of about 4.7 kΩ, so the pins idle at 5V unless the host or device (or both) pulls the wire low to ground (0V). The device side is allowed to have, and usually has, slightly weaker pull-ups to 5V: maybe 10 kΩ.

The USB bus has also two pins, data and inverted data, for (mostly) differential communication, and the pins use 3.3V-level half-duplex communication. The host side pulls both pins low, and the pins stay low until a device is plugged in. A device receives the 5V, and must signal to the host that it is plugged in by pulling one of the data pins high to 3.3V with a 1.5 kΩ resistor. Which data pin it pulls high tells the host to use a speed of either 1.5 Mbps or 12 Mbps when communicating. After the host sees the pull-up, it will try to communicate with the device using the USB protocol and the device must respond using the USB protocol.

Commonly the Holtek examples show that the PS/2 clock line is shared with the positive of the USB data pair (DP) and the PS/2 data line is shared with negative of the USB data pair (DN). DN/Data is pulled up to 3.3V by a 1k5 resistor, meaning it wants a 1.5 Mbps USB connection.

So assuming the mouse/keyboard MCU gets power, it likely starts checking whether both wires are pulled up by the host which will mean it must be a PS/2 host port.

If the MCU has a controllable pin for the 3.3V pull-up, it may keep it off and then having both data wires pulled low means this must be a USB host port and it can pull the DN line high with the IO pin to signal USB connection to the host. If both pins are high then the MCU may choose to keep the USB pull-up off while in PS/2 mode.

If the MCU does not have a controllable USB pull-up resistor, it likely does not matter much. If the other pin is also high, then this must be a PS/2 port. If the host has already detected the USB pull-up, it will be sending USB packets and waiting for responses, retrying maybe a few times. So the MCU can assume it has been connected to a USB port and try receiving USB protocol packets, but if there are none, and especially if both wires are high, this does not seem like a valid USB port so the MCU can go into PS/2 mode and send something like the result of Basic Assurance Test being OK over the PS/2 protocol and see if the PC PS/2 controller acknowledges the byte frame.

  • The (common) MCU internal pull-up resistors are not low enough for reliable operation (was also clear from measuring with an oscilloscope). The pull-up resistors must be on the order of 10 kΩ or lower (and must thus be external). Commented Jan 18 at 22:49
  • @PeterMortensen Which is why these Holtek MCUs are a bit special and have stronger internal pull-up on the specific pins that are shared with PS/2 and USB. PS/2 data has nominally 4.7k internal and PS/2 clock needs the external 1.5k anyway for USB.
    – Justme
    Commented Jan 19 at 5:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .