How OS handle input operations?

Question

I learn how an OS system works and know that peripheral devices can send interrupts that OS handles then. But I don't have a vision of how actually it handles it.

What happens when I move the mouse around? Does it send interrupts every millisecond? How OS can handle the execution of a process and mouse positioning especially if there is one CPU? How can OS perform context switch in this case effectively?

Or for example, there are 3 launched processes. Process 1 is active, process 2 and process 3 are ready to go but in the pending state. The user inputs something with the keyboard in process 1. As I understand OS scheduler can launch process 2 or process 3 while awaiting input. I assume that the trick is in timings. Like the processor so fast that it's able to launched processes 2 and 3 between user's presses.

Also, I will appreciate any literature references where I could get familiar with how io stuff works especially in terms of timings and scheduling.

Answer 1

Let's assume it's some kind of USB device. For USB you have 2 layers of device drivers - the USB controller driver and the USB peripheral (keyboard, mouse, joystick, touchpad, ...) driver. The USB peripheral driver asks the USB controller driver to poll the device regularly (e.g. maybe every 8 milliseconds) and the USB controller driver sets that up and the USB controller hardware does this polling (not software/driver), and if it receives something from the USB peripheral it'll send an IRQ back to the USB controller driver.

When the USB controller sends an IRQ it causes the CPU to interrupt whatever it was doing and execute the USB controller driver's IRQ handler. The USB controller driver's IRQ handler examines the state of the USB controller and figures out why it sent an IRQ; and notices that the USB controller received data from a USB peripheral; so it determines which USB peripheral driver is responsible and forwards the received data to that USB peripheral's device driver.

Note: Because it's bad to spend too much time handling an IRQ (because it can cause the handling of other more important IRQs to be postponed) often there will be some kind separation between the IRQ handler and higher level logic at some point; which is almost always some variation of a queue where the IRQ handler puts a notification on a queue and then returns from the IRQ handler, and the notification on the queue causes something else to be executed run later. This might happen in the middle of the USB controller driver (e.g. USB controller driver's IRQ handler does a little bit of work, then creates a notification that causes the rest of the USB controller driver to do the rest of the work). There's multiple ways to implement this "queue of notifications" (deferred procedure calls, message passing, some other form of communication, etc) and different operating systems use different approaches.

The USB peripheral's device driver (e.g. keyboard driver, mouse driver, ...) receives the data sent by the USB controller's driver (that came from the USB controller that got it from polling the USB peripheral); and examines that data. Depending on what the data contains the USB peripheral's device driver will probably construct some kind of event describing what happened in a "standard for that OS" way. This can be complicated (e.g. involve tracking past state of the device and lookup tables for keyboard layout, etc). In any case the resulting event will be forwarded to something else (often a user-space process) using some form of "queue of notifications". This might be the same kind of "queue of notifications" that was used before; but might be something very different (designed to suit user-space instead of being designed for kernel/device drivers only).

Note: In general every OS that supports multi-tasking provides one or more ways that normal processes can use to communicate with each other; called "inter-process communication". There are multiple possibilities - pipes, sockets, message passing, etc. All of them interact with scheduling. E.g. a process might need to wait until it receives data and call a function (e.g. to read from a pipe, or read from a socket, or wait for a message, or ..) that (if there's no data in the queue to receive) will cause the scheduler to be told to put the task into a "blocked" state (where the task won't be given any CPU time); and when data arrives the scheduler is told to bump the task out of the "blocked" state (so it can/will be given CPU time again). Often (for good operating systems), whenever a task is bumped out of the "blocked" state the scheduler will decide if the task should preempt the currently running task immediately, or not; based on some kind of task/thread priorities. In other words; if a lower priority task is currently running and a higher priority task is waiting to receive data, then when the higher priority task receives the data it was waiting for the scheduler may immediately do a task switch (from lower priority task to higher priority task) so that the higher priority task can examine the data it received extremely quickly (without waiting for ages while the CPU is doing less important work).

In any case; the event (from the USB peripheral's device driver) is received by something (likely a process in user-space, likely causing that process to be unblocked and given CPU time immediately by the scheduler). This is the top of a "hierarchy/tree of stuff" in user-space; where each thing in the tree might look at the data it receives and may forward it to something else in the tree (using the same inter-process communication to forward the data to something else). For example; that "hierarchy/tree of stuff" might have a "session manager" at the top of the tree, then "GUI" under that, then several application windows under that. Sometimes an event will be consumed and not forwarded to something else (e.g. if you press "alt+tab" then the GUI might handle that itself, and the GUI won't forward it to the application window that currently has keyboard focus).

Eventually most events will end up at a normal application. Normal applications often have a language run-time that will abstract the operating systems details to make the application more portable (so that the programmer doesn't have to care which OS their application is running on). For example, for Java, the Java virtual machine might convert the operating system's event (that arrived in an "OS specific" format via. an "OS specific" communication mechanism) into a generic "KeyEvent" (and notify any "KeyListener").

The entire path (from drivers to a function/method inside an application) could involve many thousands of lines of code written by hundreds of people spread across many separate layers; where the programmers responsible for one piece (e.g. GUI) don't have to worry much about what the programmers working on other pieces (e.g. drivers) do. For this reason; you probably won't find a single source of information that covers everything (at all layers). Instead, you'll find information for device driver developers only, or information for C++ application developers only, or ...

This is also why nobody will be able to provide more than a generic overview (without any OS specific or "layer specific" details) - they'd have to write 12 entire books to provide an extremely detailed answer.