When we move the mouse, we can see the cursor moving on the monitor. I know that mouse can send signals according to its movements. Which component of a computer is receiving those signals in the first place? Is this whole process happening only between device controllers and device drivers? Is there any involvement of the OS in this?
$\begingroup$
$\endgroup$
3
-
$\begingroup$ The mouse talks to a USB controller (previously a Serial controller), and the latter to the CPU via the device driver. $\endgroup$– user16034Dec 2, 2022 at 12:43
-
$\begingroup$ Ofcourse the OS is involved, even the device drivers need to be executed on the cpu, and that is one of its responsibilies. $\endgroup$– Rinkesh PDec 2, 2022 at 12:50
-
$\begingroup$ @RinkeshP, it might work like that, but it doesn't have to. The device controller could keep track of the position itself, send an interrupt to the OS when something changes, and the OS can query it when it wants the information. $\endgroup$– Ray ButterworthDec 2, 2022 at 13:20
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
Your mouse is plugged into a USB port, yes? And you're using a pretty normal PC?
First off, USB devices never send signals by themselves. They're only allowed to respond to questions they get from the computer (formally, the "host"). The computer is asking the mouse, typically 125 times per second, whether it's moved. Some expensive mice get polled 1000 times per second, but it uses more bandwidth on the USB bus. So let's answer the opposite question first: how do these requests get from the operating system to the mouse? and then the answers go back the opposite way to that.
If you were to trace the wire (don't bother, it's tiny and probably goes underneath other wires) you'll find it goes - past some circuits to defend against static electricity zaps - back to a component called a USB host controller. The host controller can be a separate chip, or it can be inside the CPU chip or the Platform Controller Hub. You can (and probably do) have more than one. To keep things simple let's assume it's a separate chip.
The USB host controller's job is to control the USB bus. The host controller is fully in charge of the USB bus (at least the one it's connected to - you have several), but is itself a slave to the rest of the system. It sends out these polling requests 125 times per second, all by itself, because it was told to.
Who told it? Well, the host controller, being a kind of adapter, has two sides. One side is the USB bus where you plug in your mouse. The other side points towards the CPU. There are many different host controllers that connect to CPUs in different ways, but since you have a PC, your one is probably connected to a PCI Express bus. The PCIe bus passes through a chip called the Platform Controller Hub (whose job isn't important here) and then on to the CPU. Actually, since the CPU is in charge of everything, I should say it goes from the CPU, through the PCH and on to the USB host controller.
The CPU can send PCIe transactions or "packets" to the USB host controller, more-or-less directly. The CPU redirects certain memory addresses to the PCIe bus, and PCIe packets are sent using the memory read and write instructions.
That covers the hardware side. How does the software look?
On the software side, you have a driver for the USB host controller, which knows what PCIe packets to send it to make it send these polling requests 125 times per second. That driver acts on behalf of the mouse driver, which knows that it has to send polling requests 125 times per second. And when it gets a response back (saying the mouse was moved) it passes that response to the mouse driver to interpret the mouse movement.
A USB bus can have several things plugged into it (via hubs) so the one host controller can interface with several USB devices at the same time, and therefore the one host controller driver can interface with several USB device drivers at the same time.
The USB mouse protocol is standardized, so you don't need to install a special driver for your mouse - the built-in one for "any USB mouse" will do.
It's quite typical that the software looks like the opposite of the hardware. You have a mouse driver that wants to talk to the mouse. But it can't talk directly, so it enlists the USB host controller driver to send the needed USB packets to the mouse. Some CPU designs (not yours) don't speak PCIe directly, so they might even need a PCIe driver to send the PCIe packets to the host controller. And we can go upwards, too: if you plug in a hard drive with a USB-to-SATA adapter, the SATA hard drive driver has to call on the USB-to-SATA chip driver to send SATA commands, which calls on the USB controller driver to send the USB commands telling the adapter chip to send the SATA commands.
The involvement of the operating system is that it's the framework within which all the drivers sit. You'd expect the operating system to mostly stay out of the way, apart from loading the necessary drivers depending on which hardware is plugged in.
The OS will scan the PCIe bus to see what devices are attached. It will see the USB host controller, and load the USB host controller driver, which will scan the USB bus to see what devices are attached. It will see the SATA adapter and the mouse, and get the OS to load the SATA adapter driver and the mouse driver... you get the idea.
