3 ms·
On linux, after keyboard has decided that a key has been pressed, and is ready to tell USB about it. 1. Wait for USB to poll. 2. Handle interrupt urb generate
by Skunkleton 9y ago
On linux, after keyboard has decided that a key has been pressed, and is ready to tell USB about it.
1. Wait for USB to poll.
2. Handle interrupt urb generated by keyboard.
3. Propagate the urb to the correct driver for completion
4. Create input events for each key event in this urb. Don't forget to use this to add to your randomness pool!
5. Pass the key event to user space, and wake up readers.
6. Some library reads the input event, and calls some sort of handler.
7. Application logic updates the internal state as a result of a key press.
8. Tells some library to redraw.
9. Library redraws, and writes to the X server using x protocol.
10. Magic occurs. I assume this magic is mostly just compositing windows and copying to a frame buffer, but who knows?
11. The magic pixies run across the wire from your PC to your monitor, and at some future date, your monitor displays it.
Honestly, I am impressed that all of this gets done in less than 100ms.
- nojvek 9y agoComputers are fast. 100ms is eons for things that just run on CPU. With a 2ghz computer, you can count from 1 to almost a billion. That's a billion little steps that can happen in the blank of an eye.
- Skunkleton 9y agoThe issue is that there are a bunch of steps that are polled (usb), or that require many context switches/interactions with the scheduler. All of this adds significant latency, regardless of the throughput of the CPU.
- whipoodle 9y agoOk, but the point is that it used to take even less time than it does now, and ideally things would get faster as technology advances.
- Skunkleton 9y agoYeah, but there used to be only a few steps to draw a new character, and none of those steps were polled, or dependent on a scheduler.