How do shift and caps lock work

[overture1928]

Is there any difference on the hardware/physical/electrical design around these keys? Or would they look exactly like any other key in the matrix if I were looking at the schematic?

[inteli722]

I believe the function is strictly in the firmware (AKA no special switch or PCB mount (MX Locks are a different story, but those are for another day))

[overture1928]

mx lock being like a thing that holds the caps lock key down so you know it is on like in old school keyboards?

[jabar]

mx lock being like a thing that holds the caps lock key down so you know it is on like in old school keyboards?

yes, they are still in production although I have yet to see any modern mechanical keyboard feature one.

[TotalChaos]

Regular keys are much better than locking keys because you can remap regular keys into another, more sensible key, any time you like and use it as any normal key.

[fohat.digs]

There is a lot to be said for a locking "Caps Lock" key, especially if there is no indicator LED.

If I had a keyboard that depended on a lot of Function stuff, I would want that one to lock down, too.

The only boards I own that have them are Apple Extended Keyboard and AEK2.

[rknize]

The only keyboard I can remember owning that had a mechanically-locking caps lock was on our old Xerox Model 820.  Horrible keyboard, BTW.  Linear springs against a steel plate that you had to bottom-out on to get the key to register.

The standard caps/num/scroll lock features and control of the LEDs is actually managed by your PC on a modern keyboard.  The lock keys send normal events just like any other key.  IIRC, the only key that is weird is "Pause", as it isn't supposed to send a release event.

[XTF]

I believe the function is strictly in the firmware (AKA no special switch or PCB mount (MX Locks are a different story, but those are for another day))

Are you sure it's in the keyboard firmware? AFAIK it's handled by the OS.
We should just get rid of Scroll-, Num- and maybe even Caps-Lock though, IMO they're useless keys.

[inteli722]

Caps lock give me an extra key to bind, and Numlock is anything BUT useless on a keyboard like a Quickfire TK or a Phantom with the Numpad layout.

[alaricljs]

Are you sure it's in the keyboard firmware? AFAIK it's handled by the OS.
We should just get rid of Scroll-, Num- and maybe even Caps-Lock though, IMO they're useless keys.

The particular functionality he's asking about is indeed handled inside the firmware.  He wants to know how the switch mechanism signals the matrix and if behavior inside the firmware is different than any other key.

[inteli722]

I was right about this?

[TotalChaos]

I believe the function is strictly in the firmware (AKA no special switch or PCB mount (MX Locks are a different story, but those are for another day))

Are you sure it's in the keyboard firmware? AFAIK it's handled by the OS.
We should just get rid of Scroll-, Num- and maybe even Caps-Lock though, IMO they're useless keys.

XTF, do u run a keyboard company?  You sound exactly like one of those guys who wears a suit and sits in an office at a keyboard company, sabotaging keyboards all day long.  "WHAT?!  The peasants don't deserve these 3 keys!  Let them eat cake!  I can increase my profits by $0.65 per keyboard by chopping off those keys! MUAHAHAHAHA!". 

Those keys are useful and millions of ppl use them.  Keyboards need more keys, not less.

[rootwyrm]

The standard caps/num/scroll lock features and control of the LEDs is actually managed by your PC on a modern keyboard.  The lock keys send normal events just like any other key.  IIRC, the only key that is weird is "Pause", as it isn't supposed to send a release event.

Pause and System Request (SysRq) both send make but do not have break codes. I would have to grab my sheet to double check. Most people forget about SysRq because it's rarely used these days.

Also the assumption that locking keys are handled by the firmware always is in fact, false. It depends on the locking type. Keys either lock in the 'closed' (on) position or 'open' (off) position. In a case where the key locks in the open position, there is absolutely no firmware handling required. The closed event happens at the bottom of the lock engagement and returns to an open position with the lock engaged. Cherry MX Locks lock in the closed position, which does require firmware handling.

[Strelok]

Those keys are useful and millions of ppl use them.  Keyboards need more keys, not less.

I completely disagree, I have never needed Capslock, scroll lock, menu, insert or right ctrl and alt, even under linux.
Num lock has had its uses but all of them would be better rebound to some other key.
I don't use function keys often enough to warrant them taking up extra space, same for numpad.

[TotalChaos]

The standard caps/num/scroll lock features and control of the LEDs is actually managed by your PC on a modern keyboard.  The lock keys send normal events just like any other key.  IIRC, the only key that is weird is "Pause", as it isn't supposed to send a release event.

Pause and System Request (SysRq) both send make but do not have break codes. I would have to grab my sheet to double check. Most people forget about SysRq because it's rarely used these days.

Wow!  Thanx for the info!  This means I cannot try to redefine SysRq (or Pause) as something more useful to me with AutoHotKey or whatever?

I have to say though... its really hard for me to believe that a keyboard has keys that send KEYDOWN events but not KEYUP events.  I thought they all did that.

[TotalChaos]

Those keys are useful and millions of ppl use them.  Keyboards need more keys, not less.

I completely disagree, I have never needed Capslock, scroll lock, menu, insert or right ctrl and alt, even under linux.

I use all those keys, except insert.  But I might want to use insert one day in some certain piece of software.  So I want the key there for when that day arrives.  The other keys in your list I use every day.

You never use capslock?  Ever?  You just manually hold down the shift key when you write out long capitalized words?

Num lock has had its uses but all of them would be better rebound to some other key.
I don't use function keys often enough to warrant them taking up extra space, same for numpad.

They already make lots of 60% and 75% keyboards just for you.

Do you use one of them?

[overture1928]

Are you sure it's in the keyboard firmware? AFAIK it's handled by the OS.
We should just get rid of Scroll-, Num- and maybe even Caps-Lock though, IMO they're useless keys.

The particular functionality he's asking about is indeed handled inside the firmware.  He wants to know how the switch mechanism signals the matrix and if behavior inside the firmware is different than any other key.

You are exactly right about my question.

[Soarer]

The standard caps/num/scroll lock features and control of the LEDs is actually managed by your PC on a modern keyboard.  The lock keys send normal events just like any other key.  IIRC, the only key that is weird is "Pause", as it isn't supposed to send a release event.

Pause and System Request (SysRq) both send make but do not have break codes. I would have to grab my sheet to double check. Most people forget about SysRq because it's rarely used these days.

Wow!  Thanx for the info!  This means I cannot try to redefine SysRq (or Pause) as something more useful to me with AutoHotKey or whatever?

I have to say though... its really hard for me to believe that a keyboard has keys that send KEYDOWN events but not KEYUP events.  I thought they all did that.

So, I presume we're talking about extended scan code set 2 since USB sends make and break codes uniformly for each key

SysRq is handled by the OS... the key itself being Print Screen, which sends codes on both make and break (actually sequences that add in modifier changes).

Pause, on the other hand, only sends a sequence on make. However, it is composed of make and break codes:
E1,14, -- fake control make
77, -- num-lock make
E1,F0,14, -- fake control break
F0,77 -- num-lock break

So... a computer that understands extended scan code set 2 sees it as a make and break of Pause, while a computer that only understands scan code set 2 sees it as makes and breaks of Ctrl + Num-lock. The E1 signals that the following code is being used for such trickery.

[rootwyrm]

So, I presume we're talking about extended scan code set 2 since USB sends make and break codes uniformly for each key

Because USB is foul and makes me want to hit everyone involved with HID because of ALL THINGS TO DO WITH HID.

SysRq is handled by the OS... the key itself being Print Screen, which sends codes on both make and break (actually sequences that add in modifier changes).

Uh...

Complete Scan Code Reference |  USB Reference
All keys are non-typematic (I forget if it's the BIOS that's required to implement it or the peripheral side.)
Set 2:
Print Screen: E0 12 E0 7C (Make) E0 F0 7C E0 F0 12 (Break)
System Request (Alt+PrtScr): 84 (Make) F0 84 (Break)
Pause: E1 14 77 E1 F0 14 F0 77 (Make) -> No Break
Break (Ctrl+Pause): E0 46 E0 C6 (Make) -> No Break
Set 1:
Print Screen: E0 2A (Make) E0 B7 E0 AA (Break)
System Request: 54 (Make) D4 (Break)
Pause: E1 1D 45 E1 9D C5 (Make) -> No Break
Break: E0 46 E0 C6 -> No Break

E1,F0,14, -- fake control break
F0,77 -- num-lock break

This is incorrect; see translate.pdf. Implementations doing this are in fact, absolutely dead wrong and should fail WHQL.
Pause is E1 14 77, E1 F0 14, F0 77 or E1 1D 45, E1 9D C5 and on USB it is 07,48.
Break is E0 7E, E0 F0 7E or E0 46, E0 C6 and on USB it is ALSO 07,48.
So the reason is obvious. And yes, they're on the same damn scan and code page. So thanks USB-SIG and USB HID! Thanks a bunch! (USB committees, you are incompetent half-witted boobs. Please lose all your fingers to leprosy and never write standards anyone sane has to deal with again.)

So... a computer that understands extended scan code set 2 sees it as a make and break of Pause, while a computer that only understands scan code set 2 sees it as makes and breaks of Ctrl + Num-lock. The E1 signals that the following code is being used for such trickery.

Well, see above, my friend. They're two very distinct scan codes. Num Lock isn't even close - it's 77, F0 77 - but on "F0 77" i8042 would try to set, get an error, then request retransmit. (BTW, Set 1 is 45, C5 for NumLock.) And as mentioned above, they're part of Set 1 and Set 2 dating to XT. Basically there isn't an i8042 out there that doesn't understand them correctly, unless the i8042 itself was probably designed by the USB HID Committee to convince you they weren't completely and utter morons. Yes, there's a good half dozen ways I agree it can (and likely does) break - but all of them require being broken in other ways to begin with.

Remember all your fun with signal timing as well - that's supposed to prevent misinterpretation of F0 77 since remember that the first thing it should be seeing is the "E1" which was used exclusively for Pause and "E0 7E" is not duplicated in Set 2 and flagged "DNU" for Set 1. (Ah, the days when people actually thought things through before inflicting them on the rest of us...)
Of course, that didn't prevent Microsoft and IBM from completely screwing up anyway. (Especially since 07,45? Is F12.)

[Soarer]

Just... LOL!

While some things about HID might be worthy of debate, the fact that it uses one code per key is really not one of them. It's the only sane choice.

My explanation of the codes that Pause sends is correct. Go plug a PS/2 keyboard into a PC-AT and see what happens.

That E1 would be just another E0 if it wasn't for the fact that E0 14 is right control already. It's not a special code that means Pause, it's just that that's the only place they needed to go to a second level of 'extension' in the PS/2's 'extended' set 2.

Print Screen does much the same thing - it's an 'extended' shift followed by an 'extended' Numpad *, since PrtScr was on Shift  + Numpad * on the 84-key AT keyboard.

The machinations that are gone through to make the cursor keys and nav block compatible with an AT are nasty...

[rootwyrm]

That E1 would be just another E0 if it wasn't for the fact that E0 14 is right control already. It's not a special code that means Pause, it's just that that's the only place they needed to go to a second level of 'extension' in the PS/2's 'extended' set 2.

There's a ton of room. It could have easily been 0E or E0 01, list goes on for a mile. E1 was always an obviously conscious decision. It is literally the only scan code beginning E1, and the standalone E1 is explicitly prohibited. They didn't need to 'extend' further - they had well over 100 other unallocated, unreserved codes available. More to the point, Break predates the XT significantly and has been carried forward time and time and time again. Pause also predates PC-AT - it used to be Ctrl-Numlock. (And those following along in the audience just went "... oh @#%*. I SEE IT TOO NOW.")
Wanna know how it worked? Went like this:
LCtrl MAKE -> Num Lock MAKE -> LCtrl BREAK -> Num Lock BREAK or in Set2 parlance 14, 77, F0 14, F0 77
So, like I said, E1 was a deliberate choice to ensure differentiation without being selective about which Ctrl modifier it was. E0 14, 77... would be the exact same, except with RCtrl. However, they could have used E0 1E 77... or E0 24 77.... But the E0 24 could be confused for an explicit "RCtrl", 84 and 7F were odd BIOS-level functions as I recall. Compare for yourself here:

Code: [Select]

   14, 77,    F0 14, F0 77    /* LCtrl + NumLock */
E0 14, 77, E0 F0 14, F0 77    /* RCtrl + NumLock */
E1 14, 77, E1 F0 14, F0 77    /* Break */

The machinations that are gone through to make the cursor keys and nav block compatible with an AT are nasty...
(image snip)

This just proves that how USB HID does it is incredibly stupid. Well, and that PC-AT remains an ugly kludge in many regards. What's really funny? Peripheral side complexity was added - to reduce it on the host side. (Instead of a check for Shift/Ctrl/Alt in buffer, give it a unique scan code, as those combinations had specific functions. Plus if someone did "BLAHBLAHBLAHBLAH PgUp" you likely only got PgUp.) Remember that HID has the capability for "pages" of an essentially arbitrary nature. But it's not. They crammed two distinct scan codes into one and instead you get stuck with a modifier check dance. Which was my point - which I get the impression you actually agree with.
Well especially since a lot of that dancing was IBM specific to my knowledge. Modern ITE parts for Shift-PgUp from relatively modern keyboards? 14, E0 7D, E0 F0 7D, F0 14.

They could have basically kept the sane nature of Break/SysRq but instead they did something completely idiotic by cramming them onto the exact same code and increasing the duct-tape-it-together solution illustrated above. It's like when people reimplement the broken parts of software when they rewrite it, but that's not good enough, so they expand the breakage to affect other parts and make it more severe. Despite the fact that there's no actual requirement or reason to maintain the breakage, and a perfectly good solution for removing it.
Remember that in USB HID active and available code pages are 01, 07, 0C and each code page (excepting 07) has a range of 0-FFFF (not 0000). And there is also a high level of host interpretation. Meaning they could have, in fact, put the number pad with NumLock off as 0C,(54-63) and done Pause as 07,48 and Break as 0C,48 - which of course, greatly simplifies the host side since it can now make accurate presumptions about keyboard state with a minimum of overhead on both sides. Instead, they elected to make things more difficult by imposing a new host-side test for Pause/Break differentiation that could have been avoided. To illustrate more succinctly, here's the gymnastics for USB - atkbd.c watches for 0xE1, if code is not 0x45 carry on, if it is then set 0x68. (atkbd.c has to handle dozens of layouts plus ISA, PCI, MCA and oddities like OFW (Mac), PSM, keyboard MUXing, and ADB to name a few.)

Code: [Select]

uhid.c:
    case 0x68:          /* pause/break */
        if (sc->sc_flags & CTLS) {
            keycode = 0x6c; /* break */
        }
But to get back on topic as to the original question:
On modern PS/2 keyboards, the keyboard sends the Make code for Shift and only sends the Break code when Shift is released. Until the Break code is received, the host controller (AKA i8042) is supposed to consider the Shift key to be on.
Caps Lock relies on a combination of peripheral plus host test - when pressed, it transmits 58 but the host may send an inquiry of E0 00000100 (though I think that's set not inquiry) which the keyboard will reply to with 58 for on and F0 58 for off. YMMV, because honestly, I don't remember the exact inquiry/set methods, but you get the general idea of it.

On USB keyboards, well, this code snippet from FreeBSD ukbd.c is probably a better explanation than I can manage:

Code: [Select]

uint16_t sc_modifiers;

#define UKBD_FLAG_SHIFT_L   0x00001000

        if ((sc->sc_flags & UKBD_FLAG_SHIFT_L) &&
            (id == sc->sc_id_shift_l)) {
            if (hid_get_data(sc->sc_buffer, len, &sc->sc_loc_shift_l))
                sc->sc_modifiers |= MOD_SHIFT_L;
            else
                sc->sc_modifiers &= ~MOD_SHIFT_L;
        }Where sc->sc_buffer is is UKBD_BUFFER_SIZE (64 bytes) and the actual UKBD_NKEYCODE is 6 units. The complete source code is probably more enlightening, since the FreeBSD UHID implementation's primary function is to translate USB HID into AT. (ukbd_trtab[256] is left as an exercise to the reader.)

(edit 1; just some formatting cleanup)

[TotalChaos]

Wow, rootwrym, ur awsome. :bowdown:

You melted my brain though. 

Could you percahnce answer me the following question that I have been wondering about for a long time:

How many IF-THEN statements must be gone thru on PS/2 to process each key press?

How many IF-THEN statements must be gone thru on USB to process each key press?

How many lines of code overall would be interesting to know also.

I specifically asked about IF-THENs since unpredictable branches are horrifically expensive on modern processors.  You can execute a whole basketfull of normal instructions in the time that gets wasted in a single mispredicted branch.  Fast code is code that has few branches.

[Soarer]

rootwrym, why are you even arguing?! The first part of your post is mostly saying exactly what I originally said about the Pause sequence! (except that you seem a little foggy about when Pause moved from Ctrl-NumLock).

What I'm saying about the E1 is this: it is not to identify Pause specifically, it is just to make that Ctrl code unique. Had there been another case of a function moved from Ctrl-Something that needed it, it would've been used again, and that sequence would've also begun with E1 14. Of course there are other codes that could've been used, but since E0 had already been chosen to mark extended keys, E1 was logically the next one to use. These codes are essentially the 'extended' part of extended set 2, since they extend the code set by another page of codes (xx, E0 xx, E1 xx, E2 xx, ...).

How the modifier dance for cursors etc. gets twisted to a minus point for USB HID, I do not fathom. Keyboards have a mostly simple task - tell the computer what keys are pressed. One code per key is a fine way to do it, as is leaving the OS to translate it back into whatever its favourite legacy codes are. For the sake of allowing a few people to use the new 101-key keyboard with their old PC-AT during a small window of time in the mid-80s, we got stuck with bizzarro sequences coming from keyboards for 25 years. LOL!

So, no, I 100% disagree with your hate for USB only having one code for Pause and Break, since it is only one key.

The 'plan' when extended set 2 was put together was that it would just be a temporary kluge. Set 3 was supposed to take over, but various things conspired to prevent that happening. Set 3 is of course one-code-per-key, just like PC/XT Set 1, PC-AT Set 2 (non-extended), and USB.

[XTF]

Caps lock give me an extra key to bind, and Numlock is anything BUT useless on a keyboard like a Quickfire TK or a Phantom with the Numpad layout.

I meant on a standard full-size keyboard. What would you use NumLock for?

[TotalChaos]

Caps lock give me an extra key to bind, and Numlock is anything BUT useless on a keyboard like a Quickfire TK or a Phantom with the Numpad layout.

I meant on a standard full-size keyboard. What would you use NumLock for?

On my fullsize keyboard numlock switches between the following 2 states:
A: numpad numbers produce actual numbers
B: numpad numbers are used for movement, cursor control, page up, page down, home, end, etc.  Its all written right on the keys.

There are various oldsk00l RPGs that require the numeric keypad for moving your character around in 8 directions but I don't know offhand which mode they use.

NumLock key might possibly be useful when redefining the numpad keys to do different things, it might allow you to have 32 keys that could be redefined instead of only 16.  But I don't know what it does with the keycodes so I donno if that actually works or not.  Just throwing out an idea since I have in the past, redefined numpad keys to do other things.  Since the keyboard industry does not usually let us have our F13-F24 keys I have used the numpad as function keys before.. and probably will again.

[XTF]

Cherry MX Locks lock in the closed position, which does require firmware handling.

I assume the OS locks on break, so the firmware would translate a make into a make/break pair and suppress the break. Is this right?
What's the advantage of this locking scheme?

[alaricljs]

You can easily disprove that by pressing and holding down the CapsLock and typing.  It's in caps because lock goes on at make/key_down in the OS.

To handle a locking switch you have to handle telling the OS it can't change the state if it requests it and you have to internally take a make signal and send key_down/key_up and a break signal and send.... Key_down/Key_up

[Soarer]

Cherry MX Locks lock in the closed position, which does require firmware handling.

I assume the OS locks on break, so the firmware would translate a make into a make/break pair and suppress the break. Is this right?
What's the advantage of this locking scheme?

There is no advantage... some people just think it's cool 

Firmware could send a make/break on both make and break, I guess. It would still be foiled by something else changing the caps-lock state though - another keyboard, rebooting PC, software, etc. In such cases the switch could be closed, but caps lock off, or vice-versa.

It would work better as a shift-lock. For that, the firmware could just treat it as one of the shift keys, and while it's latched on the PC simply sees the shift as being in the pressed state.

[XTF]

You can easily disprove that by pressing and holding down the CapsLock and typing.  It's in caps because lock goes on at make/key_down in the OS.

I'm not sure what that'd (dis)prove given the firmware between key and OS.