How does a USB keyboard work?

the old ps2 style keyboard interface is pretty simple only four of the pins are actually used two of them are for ground and five volts to provide power to the keyboard and then once the keyboard is powered up the other two pins provide two signals that are used to communicate and each time we press or release a key the keyboard will send one or more of these bursts of data on those two signals and so each of these bursts includes 11 clock pulses and the corresponding data a start bit 8 bits of data a parity bit and a stop bit it really couldn't be a less complicated protocol and in fact over on patreon emily says i've heard anecdotally that ps2 accessories are better for gaming because the latency is lower than usb seeing how simple the protocol is i could probably believe that now maybe someday you'll hook your oscilloscope up to some usb gadgets and we can see how complex that is well that day has arrived i've got a usb keyboard here and the standard usb 2 connection also uses just four pins there's ground five volt power and then two data signals here that we can look at on the oscilloscope if we look at the spec we see red is bus voltage black is ground and then green or white are d plus and d minus so rather than having separate clock and data pins we've got a differential pair so more on that in a minute this by the way is from page 89 of the usb or the 650 page usb spec but anyway if we connect the keyboard you'll see that d plus stays low and d minus goes high when we connect the keyboard but if we try typing anything on the keyboard nothing happens so what's going on well if we look at the usb spec for signaling levels there's this table and as is all too common with specs it's got a lot of precision but not a ton of clarity but if we break down the two signals we've got the d plus and d minus and basically there's really only four scenarios we can have here either d plus can be high and d minus can be low d plus can be low and d minus can be high they could both be low or they could both be high and that's basically what these first four things are indicating here so there's a differential one where d plus is is high there's a differential zero where d minus is high and then there's the single ended zero single ended one where they're both low or both high so the state we're in right now when we connect the keyboard d plus is low and d minus is high so that's a differential zero but that also corresponds to this idle state right d minus is high d plus is low but notice that that's the idle state for low speed there's also an idle state for full speed which is the opposite where d plus is high and d minus is low and that's because usb operates at different speeds depending on the particular device that's connected there's a low speed which is 1.5 megabits per second and full speed which is 12 megabits per second and then actually after connecting at full speed a device can even switch to high speed which is 480 megabits per second and then of course you know usb 3 you can go up to 10 gigabits but that's a whole different interface and so what we're seeing here is that by pulling the d minus high like that when we plug the keyboard in the the keyboard is really signaling two things one it's you know signaling that it's connected but two by pulling d minus high it's signaling that it is a low speed device i've got another keyboard here that is uh i guess maybe i don't know a little fancier certainly costs more but if we plug it in what you'll see is that it pulls d plus high so that means that this keyboard is saying that it's a full speed device rather than a low speed device but just like before when we press keys it doesn't actually do anything and that's because with usb all of the communication is initiated by the computer the the keyboard doesn't ever volunteer anything on its own other than just saying what speed it wants to communicate at so low speed in this case but actually get the keyboard to do anything we need to connect a usb to a computer so the computer can initiate communication the other end of that usb i've got hooked up to this cable here where i've broken out the d plus d minus signals as well as ground and of course i don't need to break out the bus voltage because the cube the computer is going to be providing power to the to the keyboard but anyway we can hook up the d plus and d minus here to our oscilloscope and then i've got the ground here so we can get a signal ground for the oscilloscope leads and then when we plug the keyboard in we actually start to see a signal of some sort and we can zoom in on what we're capturing here and we've got some kind of you know data communication going on here so let's uh take a single shot of that and we can zoom in and actually see kind of what's going on here and actually what i'll do is i'll connect this little thumb drive then i'll zoom in and and um you know to better analyze this what i can do is just basically take screenshots of this and kind of scroll through and try to get screenshots of the entire waveform that i can then piece together into one sort of giant image that we can use to to sort of analyze this better and so i'll piece all these bits together and take the the entire waveform that we captured and then i'll invert the color so i can print it out and we'll be able to use a printed copy to kind of take a closer look at what's going on here and here it is this is the signal that we captured and maybe it's kind of silly to print it out like this but i think it'll be interesting to to dig in and really understand what's going on here you can see for the most part the signal is differential so the d plus and d minus are pretty much the opposite of each other and that corresponds to the differential one and differential zero states that we saw before but there are a couple places where we see the single ended zero where both d plus and d minus are low so for example here as well as out here and then finally at the end and that single ended zero for approximately two bit times corresponds with an end of packet and so that suggests that we might have you know one two three packets perhaps but anyway it says the end of packet is a single ended zero for approximately two bit times followed by j for one bit time and j is this data j state for low speed it's going to be a differential zero and if we were running at full speed it would be a differential one and so they've got this j state they've also got a k state which is basically the opposite so you know we're running low speed here so if the j is is a differential zero the k is the same as differential one and if we were running full speed it would just be the opposite but basically in either case the idle state is is this j state and then when we start a packet the data lines switch from that idle to the k state so in this case it'll be a differential one so j state is this period in here where we're basically sitting at this uh you know this idle state where we where we were before where the the d plus is low the d minus is high you know if we're a low speed device that's going to be our idle state and then that end of packet is a differential or is a single ended zero followed by the j state and so that's what we have here and then a starter packet is switching from that idle state to a k state and that's what happens here so this switch is now to k-state for one bit time and so that's uh that's basically the beginning of a packet and then the way we're going to interpret what's in that packet or really what all of this stuff is is by you know first decoding this into whether it's a j or k state and that's also going to mean recovering some sort of clock from this because for the most part this data is sent as a differential pair it's not sent like the the ps2 keyboard where we had a separate clock line that just was a clock and then we had data that we could read against that clock we don't have that here we have this differential data and we have to infer the clock based on well a couple things one we know that this is low speed because of the idle state and so we know that the clock should be about 1.5 megabits per second but then as far as exactly what it is because of course it's not going to be perfect we have to just look at where these transitions are and figure out for ourselves so we can kind of look at something like this and see well those transitions are happening at this interval and so if we want to know well how many bits exactly are there well we can infer from these other transitions that you know in this period there's probably going to be let's see that looks like three bits and you know somewhere over here for example you know this is going to be four bits and so you might be wondering you know why send this differential pair and then you know force the receiver to figure out what the clock is by by inferring it from when the transitions are occurring and the reason is there's actually a lot of advantages to using a differential pair like this a big one is avoiding susceptibility to interference because if there's some sort of electromagnetic interference that happens with this the interference will presumably affect both signals the same because both of these wires are run right next to each other and they're the same length so any interference that affects one is going to affect the other and with a differential pair like this what the receiver can do is it can just subtract one signal from the other and any interference that affected one of them will then will have affected the other the same way when you subtract them it'll subtract out that difference and you'll just be left with the original signal the other advantage of a differential pair like this is reducing emissions because once you're sending data really fast like this in this case you know our frequency our data rate is a 1.5 megabits per second so if we've got what is effectively a one and a half megahertz ac signal going through here um that wire could start to look a lot like an antenna with a one and a half megahertz radio transmission emanating from it and that you know one and a half megahertz radio transmission could cause quite a bit of a problem for some other electronics but by using a differential pair like this you're going to have two things presumably emitting but they're going to be 180 degrees out of phase and effectively whatever radio interference emissions they emit will destructively interfere with each other and effectively cancel each other out so another advantage of using a differential signal like this is reducing emissions and since all of the remaining signal is differential i'll go through and fill in whether each bit is a j or a k that way we'll have all the bits accounted for and then we'll be able to go through and actually figure out what it means okay and so that's everything and so we've got our single single-ended zeros here and then we've got our j and k now the single-ended zeros like i mentioned before those kind of delineate these packet boundaries and so what we're seeing here is we're seeing three distinct packets being sent as part of this burst of information an end of packet like this is signaled by the single-ended zero for approximately two bit times which we see followed by a j state for well it says one bit time but i think it means at least one bit time and then the start of packet is data line switch from idle to a k state and so this k is where the the start of packet actually occurs and then every packet starts with a sync pattern and it says it's required to be three kj pairs followed by two k's for a total of eight symbols so if we look here we've got one two three kj states followed by two k's and so that right there is our sink and then same thing here we've got one two three kj pairs followed by two k's and then for the last packet over here we've got one two three kj pairs followed by two k's and the reason that the sink starts that way is the kj pairs gives you this nice um you know oscillating signal here that you can use to synchronize your clock so you know you can kind of make your little tape measure here to figure out exactly what those bit timings are so that you know if you get further into you know some of these situations where you've got you know quite a bit of of time here you can figure out well this is this is going to be seven bit times but any event at this point the the sync pattern is over and we're actually into the the data part of the packet and the first few bits of the packet indicate the packet id which is essentially the type of packet but it's not encoded the way that you might think so it's not like you know case corresponds to a 0 j corresponds to a 1 or anything like that it actually uses a different type of encoding called nrzi non-return to zero inverted and with nrzi encoding the way it works is basically a one is represented by no change in level and a zero is represented by a change in level so for example here this first k is not a change in level right because the previous bit was a k this is a k so that's no change in level and so no change in level represents a one so this is actually a one then it changes from k to j so that represents a zero because that's a change in level then when we change from j to k that's also a change in level so that's also a zero but now k to k that's the same that's a one and so those are the first four bits that we decoded using this nrzi encoding and the reason to use this encoding instead of encoding the ones and zeros as just different levels high or low is that you know particularly higher speeds it's easier to detect a transition between two different voltage levels than it is to you know measure exactly what that voltage level is whether it's above some threshold or below some threshold at some particular time it's easier just to look for those transitions so detecting a one or a zero based on the presence or absence of a transition is is much more reliable and because a zero is represented by a level change that means that you know looking over here you can see so lots of level changes here so this suggests that this this area is probably going to be lots of zeros which we want because we want to be able to again recover that clock and be able to count you know how many pits we've got in fact one of the problems with encoding clock and data using the same signal is that if you don't have any level transitions for a period of time you could maybe lose track or lose count of how many bits you've got so for example again out here you know if we're counting these bits we get to this area here where we have no transitions for quite a while and if we count it looks like that's seven bits but if this went on for for too long and our clocks were not perfectly synchronized we could you know miscount this and so another thing that the usb protocol uses is it uses this thing called bit stuffing to ensure you know adequate signal transitions basically what happens is whenever there are you know six consecutive ones in the data stream um it basically just forces a zero in into the into the data stream to just to just ensure that there's you know some sort of transition here and so that actually appears to have happened here because we've got seven uh bit times here and so seven bit times means there's you know six times when it didn't transition so that that corresponds to six ones and so after six ones this uh this this j that's sort of stuck in here or really this transition that's stuck in here uh to signify a zero is you know the result of bit stuffing to say like okay we've gone too long without a transition we need a transition in here so that when we do clock recovery we don't have this long gap so anyway that's something to be aware of when we're decoding this in any event we've decoded our first four bits here one zero zero one and usb transmits least significant bit first so if we wanted to read this sort of in normal bit order it would well it would be one zero zero one because it's symmetrical um but those first four bits indicate the packet id and again we can look up in the spec at what those packet ids are and one zero zero one is um it's a token packet for the the in so it's basically saying this packet is is an in packet whatever that is because the packet id is one zero zero one so we can say this is going to be an in packet and then the next four bits if we decode them so this is a transition so that's a zero no transition no transition and then a transition to that k we get 0 1 1 0 and that is always going to be the complement of the first four bits so we get 1 0 0 1 and then 0 1 1 0. so it's just all of the bits flipped and that's basically just done as kind of a sanity check data integrity thing to make sure that we receive this correctly and so that's the first byte of data that we receive so now i'll go ahead and decode the rest of this packet so we can you know look at what it what it all means okay so that's the binary for the rest of the packet and this is an in packet so if we look up an impact is a type of token packet so if we look at what that looks like a token packet has the packet id which is eight bits that's what we've decoded here that's that's in and then it has a seven bit address a four bit endpoint and then a 5-bit crc and the crc is the same checks the address and end point it doesn't check the packet id which is why we had that duplicated inverted thing so let's see what we've got here so the next seven bits are going to be the address so that's up to sort of this point here so those seven bits are address then we've got four bits of endpoint and then these last five bits are crc and again all of these are transmitted least significant bit first so if you want to sort of look at this in in a normal kind of way that you might be used to looking at binary numbers if you're someone who's used to looking at binary numbers you'd flip all these bits around so it'd be 0 0 1 1 0 0 0. 0 0 1 1 0 0 0 which is going to be see a 1 8 in hex which if we convert that to decimal 1 8 in hex the decimal is 24. that was the address we have this endpoint and again 0 0 0 1 we read this backwards so if we flip that around it's 0 0 0 1 which of course is just one and then these last five bits are crc which just checks all of that we'll assume that that's right so we've decoded that and basically what it's saying is this is an in command i guess or in token packet for address 24 .1 so what might that mean well if we look at the computer that this is plugged into i've got this command lsusb that will show what usb devices are connected and you can see we've got the dell keyboard thing that we're looking at and the device id is 24. and so this first packet that we're seeing here is is literally the computer sending an in command saying i want to receive data from device 24 from that keyboard at endpoint 1 and endpoint one is you know that's just going to be the the first endpoint which you'll see just basically corresponds to what keys are pressed right now and then we have a crc that you know presumably checks all of that so the computer is asking the keyboard what keys are pressed next and presumably this is going to be the response so let's go ahead and decode that so this is the packet id one one zero zero actually backwards this will be zero zero one one will be the packet id and then we have the complement over here to check it but zero zero one one corresponds to zero zero one one data zero so this is a this is a data packet so we've got a data packet and then if we decode this we basically just get a whole bunch of zeros so all of these are zeros because every time the the signal transitions remember in nrzi encoding a transition means a zero so all of these are zeros and so the data is basically all zeros and so we break these into bytes we basically end up with a bunch of bytes of zeros and it looks like we've got one two three four five six seven eight zeros and then we get some other stuff here so let's go ahead and decode this and so now we've got six ones and after six ones we're going to have data we're going to bit stuffing so actually we're going to essentially ignore this this j because this or ignore this transition at least because this transition is only here for the purposes of bit stuffing to make sure that we don't get too long a run of one one signal level so that transition we're basically going to ignore but then this k is a change in state so that we're going to interpret as a zero because it is a change in state so we have kind of a missing gap here but anyway 0 1 and then the rest of this that's a transition transition no transition transition like that and now if we look at the format for a data packet we have the packet id eight bits and that's you know what we have here it says data zero we got that then we have data which is you know i guess between zero and eight thousand one hundred ninety two bytes or no i guess that would be bits and then a 16-bit crc which you know protects that data so in our case we've got eight bytes of data or i guess 64 bits and then this would be the crc so if we wanted to figure out what that crc is backwards be 1 1 1 1 so that's f and then 0 1 0 0 is 4 in hex and then 1 0 1 1 is b and then 1 1 1 1 is f so the the crc is f4 bf which i guess is the crc for all zeros does that make sense let's check that out we got a calculator here and this will be hex and let's see yep so that's eight bytes of zeros calculate a crc 16. and does any of these come out to f4 bf here we go f4bf and that is oh yeah crc16 usb so that sounds right that's what we're doing so that's our data packet we've got data we've got eight bytes of zeros and then we have a checksum or crc i guess and then we've got one more packet over here we've got our sync and then if we decode this so let's see there's a transition no transition transition transition no transition transition no transition no transition so that's zero zero one zero is the packet id and zero zero one zero is an acknowledgement so acknowledgement and that's really all there is to that packet it's just an acknowledgement so if we look at this whole sequence here we've got uh the computer well we assume it's the computer we actually can't tell which part of this transaction or which part of this communication is the computer which versus which part is the keyboard because they're both using the same signal lines but but presumably it's the computer pulling the keyboard asking for input from device 24 which we've determined as the keyboard at endpoint 1 which is going to correspond to what keys are pressed and then the keyboard responds with some data with eight bytes of zeros and because these are all zeros basically what the keyboard is saying is well there's no keys being pressed right now which which was the case when we captured this right there weren't any keys being pressed and then a checks are a crc for that and then the computer responds with an acknowledgement and so that's that whole transaction so the question of course now is well what does this look like if we're actually pressing some keys well we can give it a try and it does look like there's some bits changing in here though it's kind of hard to tell exactly what's going on and i don't really feel like you know trying to capture this and going through that process of decoding another of these packets though you know they do make fancy oscilloscopes that will decode usb automatically unfortunately this isn't one of them but the people over at keysight were nice enough to lend me one that does so i've got this hooked up the same way and we're seeing the d plus and d minus signals here and if i press some keys you can see there's bits flipping around here let's set up the serial decode so let's see we don't want i squared c we want usb and mode usb speed for this keyboard is low and then the signals d pluses on channel one d minus is on channel two and you can actually already see the data here so this shows the uh the in packet the data packet and then the acknowledgement and now you can see what happens when i press different keys on the keyboard some of these or this byte here appears to be changing when i press different keys the other thing you'll see is this flickering there appears to be two sorts of transactions happening so sometimes we get this full report which is just like what we manually decoded but then if i keep triggering here we go there's also a smaller transaction it's the same in token packet but instead of the data and the acknowledgement we get this this knack this negative acknowledgement this is basically the keyboard's way of saying nothing's changed it i guess it saves a bit of time and bandwidth if no new keys have been pressed or released so if we only want to see transactions with acknowledgements we can actually set up a trigger so go here and then trigger type we want usb and then we can do trigger on let's say we want token packet and then we can actually set the packet id to be well no we want to let's see we want to trigger on acknowledgements so that's a handshake packet and then acknowledgement so let's do that and then that'll trigger on the acknowledgement and there we go so now it's not flickering between the acknowledgement and the knack we're only seeing transactions that end with an acknowledgement and one thing you'll see is that sometimes the keyboard responds with the data zero and sometimes it responds with data one but otherwise everything's the same and there's really no difference between them it's just that the protocol says that every time a device sends data it should alternate back and forth between using data 0 and data 1 as the packet id so it really just gives the receiver a basic way to detect if it's missed a data packet anyhow you can see as i press keys the key codes are included in this data packet if i press multiple keys then multiple key codes are included and so it just lists whichever keys are are being pressed that's pretty straightforward the one thing that's different is how modifier keys are handled notice that if i press ctrl we get this one here that appears if i press shift it's a two alt is a four and then the windows key here is an eight so each of those corresponds to a single bit so if i hold down a combination of those keys it just represents the combination there so if control is one and alt is four one plus four if i hold them both down is five and so that's where the key is on the left and then the ones on the right the control shift and alt on the right use this other nipple so between that that first bite there it's got a bit for every modifier key so the first byte is always the state of the modifier keys the next byte is reserved and it is not used for anything as far as i know so that's always zero which leaves us with six bytes remaining four keys that are pressed and so you can see a b c and if i hold down multiple keys it just lists all of them and i can hold down up to six keys and it will report up to six keys being held so that means if we press more than six keys simultaneously there's no way to detect that um and we just kind of get this error where they they all are just reported as one so that's some sort of air condition although it seems like there are smaller combinations of keys let's see yeah there we go q w and a if we hold that down we also get an error so there are smaller combinations of keys which also result in an error and that's probably because they're sharing connections internally in the key matrix or something to save cost the keyboard but my understanding is that fancier keyboards don't have that limitation and in fact can even negotiate with a computer to use a larger data block so they can report more than six simultaneous key presses but as you can see six is typically the default that you get outside of you know any kind of fancy gaming hardware even still there's a reasonably involved initial setup that occurs when you first plug in a keyboard so let me actually try to set all this up so i can capture as much of that as possible so we can actually bring up a lister here to make it easier to see what everything that's happening and then i'll reset this for a single shot to try to capture as much as i can and then go ahead and plug the keyboard in and let's see what we've got and i won't dig into this too much but you can see it starts out with a setup packet and gets some data and then we've got some uh communication here with it looks like address 1e which i'm going to assume is the end point that it's assigned for the the keyboard when we when we first when we just plugged it in and there's a little bit more um back and forth now we have input for address one e and endpoint zero and you remember before it was endpoint one which is where we were reading which keys are pressed but endpoint zero is used for um sort of setup and configuring parameters and so forth and you'll see if we keep going here here this is this is kind of interesting one because we see that some of the data that it's transferring is 413c and 413c is the vendor id that corresponds to dell so that's the keyboard telling the computer that it was manufactured by dell and then we've got 2003 and 2003 corresponds to the particular model of keyboard i've got so you can see there's a bunch of negotiation that happens here before we're actually able to send key presses back and forth but anyway how about the original question does all this usb complexity introduce any meaningful latency over the old ps2 interface well certainly more data that gets sent when you press a key so initially you might think well you know if a ps2 keyboard only sends 11 bits when you press a key and it takes usb close to 200 bits to do the same thing surely that's something but of course ps2 is sending those bits at 16 kilobits per second versus usb which is either one and a half megabits for and that's low speed or 12 megabits for full speed so really you know usb is way faster the real concern comes from the fact that when you press a key on a ps2 keyboard it immediately sends the scan code but for usb the computer has to pull the keyboard by sending this in token packet so how often are those sent let's set up our trigger for usb and we want token packet for a pid of in there we go and then if we go back and zoom out we can see we're triggering on an in token packet here and then we're getting you know another one before it and so we can see the the period here and this uh this interval appears to be about 16 milliseconds and you know that's whether it's being being acknowledged with a knack or whether it's sending data either way the polling appears to be happening every 16 milliseconds now that's a big deal you know sure a ps2 keyboard is only sending data at 16 kilobits per second but sending an 11 bit scan code at 16 kilobits per second takes about 700 microseconds or 0.7 milliseconds so here it looks like we might have to wait up to 16 milliseconds versus you know 0.7 milliseconds after pressing a key before it's sent to the computer so that's like almost 20 times more latency with usb than with a ps2 so maybe there's something to that idea that ps2 is better but not so fast this is literally this is like an el cheapo usb low speed keyboard you know how about a better quality keyboard that operates at full speed you know is that going to make any difference let's plug that in and then we'll set this up for full speed you can see when i press keys we're that's showing up in the data here one thing that i notice is different with this keyboard is it's not periodically sending this data what's happening is if we trigger on the in packet for most inns for most in packets rather all we're getting is a a knack it's only sending data if it actually has something to report so you can occasionally see it show up if i press lots of keys but for the most part if nothing has changed this particular keyboard is just responding with a knack which is fine that's all it needs to do so the question though is how often is it polling and what you can see here is if i set this to one millisecond per division and you look at the times here as well you can see that it's pulling every one millisecond and so pulling every one millisecond versus every 16 milliseconds that's a big difference so now that 0.7 millisecond serialization delay of the ps2 keyboard doesn't have as much of an edge on this one millisecond pulling delay in fact since those are basically the same order of magnitude i'm convinced that there's really no practical advantage to ps2 over usb at all unless you're using quite literally the cheapest keyboard you can find and i think this is a really compelling way to see that i've got a ps2 keyboard and a usb keyboard both hooked up to the scope here and of course the usb keyboard is pulling every millisecond but i've got the scope set to trigger on the ps2 keyboard's clock so press the key you can see the clock and data from the ps2 keyboard but then down here you can see the one millisecond pulling from the usb keyboard so these little blips are every millisecond and so even though the usb keyboard takes more bits to sort of say what it's saying because those bits are happening 12 million times a second versus 16 000 times per second the usb exchange takes way less time but with the polling here of course if you pressed a key on the usb keyboard here you'd have to wait until the next poll over here before the computer would have any chance of seeing that but i think overall this shows that either way whether you're waiting to serialize the the data from the ps2 keyboard or you're waiting for that next poll interval from the usb keyboard these are basically the same so hopefully you found that interesting as always a big thanks to all my patrons for helping to make this video possible you can join them in supporting me via the link to patreon below and for more computer engineering videos and projects don't forget to check out my website eater.net

Channel: Ben Eater

Views: 575,711

Rating: 4.9851561 out of 5

Keywords:

Id: wdgULBpRoXk

Length: 34min 15sec (2055 seconds)

Published: Sat Jun 05 2021

Reddit Comments

[u/wildjokers]

A good way to see how a USB keyboard works is to look at the QMK source code. It is the firmware used by people who build their own mechanical keyboards, runs on a variety of boards like Arduino's with the 32u4 chip, STM32s, teensy's, etc

https://github.com/qmk/qmk_firmware

[u/smrq]

Seconding all the comments that USB is brutal. Last time I tried to write my own keyboard firmware, I was trying to use no external dependences-- so, no LUFA or whatever. Implementing everything manually according to the spec. It was SO INVOLVED and I still don't know if I did everything correctly or if there were weird edge cases where the whole thing would go to hell.

I'm building a new keyboard now and just using QMK. Screw doing that USB stuff again.

[u/browner87]

God the USB stack is such a pain in the ass. Sure you can sort of sum up a simple HID device like keyboard into a 40 minute video, but it still beings back the PTSD of looking into all the descriptors and intricacies of other non-HID crap in college. USB is convenient, but I'm never dealing with it at a low level again if I can help it. And the hardware and firmware for USB-C connectors is a nightmare now, at least USB A you could solder it through-hole or surface mount by hand.

[u/BigTunaTim]

When I watched this video this morning it struck me how in some aspects of both hardware and software we've come full circle in about 40 years from polling to event-driven and now back to polling again.

[u/DuncanIdahos9thGhola]

His videos are always awesome.

[u/_TheDust_]

Damn, that was fascinating. I never had 30 minutes pass by so quickly.

[u/mariotacke]

I absolutely love his videos. The explanation was easy to follow and for once, USB makes sense.

[u/Amazing_Breakfast217]

I always wondered how 'complicated' a USB keyboard is. I'm sure there's non keyboard stuff he skipped over regarding USB but this video was really good and I got a lot out of it.

Maybe I missed it but it seemed like there's no 'let go' signal? It strictly list the 6 + modifier keys that can be held down and if it isn't listed it isn't pressed?

Maybe it's me but I prefer that over 'events' that give me a per key down/press/up. Just give me a list of whats held down and I'll handle the rest

[u/jjrobinson-github]

holy crap, this is way cool to learn. I'll never ever need to know this, but this brings back memories of my CompE class work.