So we've been looking in this computer file and the previous one and how when we press a key on a keyboard
What actually happens to from that key press being pressed and the physical hardware?
to the software say Microsoft Word displaying that
On screen and the previous episode if you haven't seen I suggest you click the link here and go and watch now
We saw what happened at the hardware side of things
so we sort of left our story where the hardware and we saw how that
depending on what the things these days said I'll get packaged up into a
Serial message which is sent to a specialist port is
interrupted the cpu
and now we're looking at the sort of the software side of things of what the operating system does to actually make this work just
Like there was many layers in the hardware there's many layers in the software
So the first place we need to look in a modern operating system and I should caveat this
By saying I'm going to talk in general terms
Each operating system with us windows linux macOS, probably even CPM for people. I'm sure we're going to talk in general
So yes, there'll be some organ systems to do something different there were some which merged some steps. That was something that expands some steps
Fight about it in the comments. So the first thing that there will be from this side. Is that the hardware
Interrupted. There'll be a bit of software built into the operating system
which actually handles that interrupt and
probably map it to the right bit of software to handle where the heart what we should have hardware's generated it and eventually
summing of that will handle
This is a keyboard
interrupt mapped through whatever is the USB the Bluetooth the
Direct connection depending on how it works and says, okay. There's been a keyboard interrupt. I know how to handle this sort of thing and
I'm then going to do it. So it'll get the data and it will say okay. This key was pressed
Let's say the letter A was pressed or the letter A was released, but you generally will get messages from the keyboard
So the keys been pressed and this message to say that the keys been
Released so that then we'll get received by the device driver and these
Generally don't actually need to be that complicated
You generally find if you look at the code say in the Linux kernel, it's open source that the keyboard software
For a simple keyboard like on someone on the Atari ST or the Falcon. It just reads from a memory
It's relatively straightforward. Of course if you've got a USB or Bluetooth keyboard
Then you've got to implement the whole USB and bluetooth stacks things are a lot more complicated
But that's the point of the device driver it can handle all that
Abstracts it away from your program as a user. You just say what keys been pressed. Okay, so we've got that data
We're now in software. We know this key has been pressed. What happens then? Well, you generally don't have
Your software say your word processor talked directly to that device driver
partly because
You'd have to write it for every single possible different device driver
You might need do you've got a USB keyboard or a Bluetooth one, whatever it is
And so on you get then you get the point. So what actually happens is inside say a modern operating system
There's a way of handling input devices keyboards mice
buttons on your machine and so on that will handle these things and so when the keyboard device driver detects a key press
it sends that message or is it generally is turned by that point and event to
The relevant input device which has been created for that particular keyboard
The other advantage of this is even having multiple keyboards connecting your computer quite easily and you can read them separately
Don't always have to but you could do that if you want to do so
You'd have some sort of event queue inside your operating system
That will and remember this is inside the operating system kernel so this is not talking about graphical user interface or anything at this point
we're just talking about getting the message from the device driver into the user land where our
Programs are running and when the keys pressed it would send an event
Down like it would place an event into that queue saying this key was pressed. This is what the scan code was
You could at that point convert that to a ski that I probably actually happened later in the stack probably happen in user mode
There's no reason for it to be done there, but it could be done inside the kernel
And so on unless you do inside the kernel the less attack service you got from a security point of view
You probably timestamp it so
you know when that happened and so and you put that into the queue and we imagine this as
a boundary in your software between what we call user mode, which is where our programs are run and
kernel mode which is where the stuff that wants to talk to the hardware and that
Things that keep things in control and somewhere on there
You'll have some sort of transfer port and their event queue before the inputs would come from the device driver
which gets the message from the keyboard and
The software pop it into the event queue and then when the program over here read from that
It would pull the first one off and get the message say this key was pressed or this key was released
So we're now after the kernel we're out of hardware. We've gone through the device driver in the kernel
we've gone through the kernels input queues and we're now in user mode and the software can ask
What key has been pressed
Now if this was a command line process it would actually probably be talking to what's called a pseudo
Tele tie board a teletype type interface in something like Linux or UNIX
Which literally emulate the alter of teletype?
printers and keyboards and so on and the conversion from scan codes to ASCII would be handled at that point in the
Implementation of the teletype terminal for a graphical user interface things tend to have a few more stages in there
So what you'll generally have is some a program
So on something like a Mac, for example, your own called Windows Server, and there's equivalent things X for example on Linux and in Windows
Which handles the whole graphical user interface? So that's sitting there
Producing the displays and not working out which windows active and so on and it will be that point of the software stack
That will get the key presses from the operating system. So that part of it the Windows Server
Let's just use it as a term will get the key presses and then it will look to say okay
I've got this key press aids been pressed. And where do I actually send this to which window is receiving this?
is it the word processor would running on this or is it going into the email client or is it going into a
Signal to send a secure text message or wherever it is
It's going where's it got to go and in those which windows active so it will then say okay
This is going to this this window is active
We need to send this to this program. Now. How does that happen? Well again, it's similar to what happens here every
graphical user interface program
Generally has at its heart an event processing message processing loop and basically the way they work
It's sometimes explicit you sometimes have to code
So if you program Windows around 20 years ago
You would write code which would have things like peak message translate message dispatch message
I'm not remembering the names right functions in a tight loop to handle all those things if you're writing code on a
Acorn archimedes you would call s y Wimpole and soul to do is to get the messages and base
You can call that in a loop and then you get a message and dispatch it these days
it tends to get wrapped up and things so it's actually hidden in library code and things but
Generally, it's still doing the same thing. So
The window server will send an event to your program
Saying a key has been pressed in this window
And so on it'll happen and again that by that point we probably convert it
So still got the scan code there, but we've probably also converted it into the ASCII code or the unicode code as well
that will be handled by the
Window server because it can then
localize it and do whatever it's needed knowing what sort of keyboard you've got connected and so on there's ways that these can be automatically
configured so you'd actually have to physically tell it unless you
want to
So the windows server will package but at this point you won't use the same sort of event format
that the kernel use it could but generally there's probably a
More specific one which is tied in to which windows and things are being used
That's then got into your program
And you say hey, let's say with Microsoft Word these press the a key you then need to do in your program
Whatever you need to do in your program to update your data structures to say that whatever document we had before
We now need to put an A at wherever the current cursor is in that and that depends on what how your program is written
If your game and that you've got WASD for controlling movement when you press a well
Then you want to update where the player or the cameras position is on the screen at that point
Once you're into the user code the user program that we're interacting with what happens is up to how the program works
It may be that it does absolutely nothing because it doesn't respond to that key. That's a simple case
at that point
We don't know what's happening is a black box it's the program
But we said then what happens?
At that point we still haven't updated the screen
We've pressed the kini gun and it may be that there's no visual effect from pressing that key
you could write a pro and where that didn't happen and then
Two hours later it put pops up a picture of Tom and Jerry on the screen to surprise you if you pressed the wrong key
Probably not going to write a program like that, but you could what's going to happen
Well, we still need to redraw the screen. So what will happen inside that say the word presser you press the a key we've updated
the
Data structures to say we can now got an A in our document
We will then finally say we want to redraw the current window. That's
Representing that document and what that'll actually probably probably won't draw it then and there
Well, it'll probably do is tell the window server that this this window needs redrawing and then eventually that will then come and redraw it
and the reason why that happens is actually
The window main redrawing anyway
Because you've moved the screen or whatever it is you brought that to the front and actually you can then combine the redraws and speed
things up a little bit and
That's pretty much the story of what happens when you press a key on a computer. It's quite involved
What's fascinating though is I read an article that actually measured the latency the time it takes from you pressing a key on a keyboard
To it appearing or having an effect on the screen and actually on modern computer systems whether it's Windows Mac or Linux
It's incredibly long compared to what it was like on something like the Apple 2 or the BBC micro
Behind me on the Apple 2 or the BBC micro it effectively. Did it on the next frame read or within 30 milliseconds on a
Modern PC is significantly longer than that are all peas treated equally shift control
ABC are they all the same number one keypad F key. So there's very good question are all keys treated equally
The short answer is yes
And the long answer is no it depends where you get up to so
implementation of the keyboard the shift keys the caps lock key the num lock key all
Handled identically obviously some of them have LEDs associated with them to light up when they're press or not
Generally, the computer will tell the keyboard to light those LEDs or not like those LEDs
So you press a key and the computer sends a message back. Thanks implemented in the keyboard. It depends on the implementation
So at the hardware level they're probably identical in the kernel that probably identical
I think you'd probably be when you get to the point of the Windows Server or
the
Actual command line teletype terminal that it would actually be handled
And again, if you actually look at the implementation of the operating systems, you can find out what modifier keys are pressed
You generally don't get events for those keys
You only get events being passed so that the keys being pressed
But when you get that event, you can say oh ships pressed as well
Or ships not pressed and so you can work out what's going on. So the answer is yes, and no
That time I was playing manic miner and I jump and I hit the key
I had jumped it was the computer that got it wrong, right?
Possibly depends what looking the way it was implemented in things. I'm not going to comment on your game playing ability
Just leaves you had a Commodore 64