Concerning keyboard drivers and USB PS2

[fart_toast]

Hi all,

There is some stuff I will get wrong/ don't fully understand...so please bear with me and correct me where possible!

The keyboards I own are a Ducky Shine 2 TKL, Ducky shine 3 Yellow edition TKL and a poker 2. All of these seem driver/firmware dependent and don't work in a ps2 mode.

I have a round 5 order in place and want to make a sort of retro looking board using these keycaps and some cherry white switches. My initial idea was to use the shine 2 TKL as a donor (don't use it since I have my shine 3) BUT after some thought I want the board to be ps2 compatible to be true to the retro nature of the build.

Basically from what I understand so far, the shines and pokers wouldn't work when freshly introduced to a BIOS environment as they need to plugged in and drivers downloaded as they are USB only. I want something that is most likely to work if I were to take it and plug it into any machine...perhaps an old pc with no internet connection to auto-download drivers or a linux box for whatever reason etc.....

I want to get a basic board that is the nearest to "plug and play" i.e it would work in the most basic of cases. My guess is that I would therefore be wanting a ps2 compatible board...would a filco TKL be suitable as these come with ps2 adapters....? (I want TKL or 60%)

Again, I don't fully understand how this aspect of keyboards works...please help!

Fart_toast

[Muirium]

USB keyboards don't need drivers either. There's a basic spec called the USB Human Input Device which they all conform to. So if you plug your Ducky into a Linux box or a Mac (like I did in my review as I don't use Windows), no drivers are downloaded and it works just fine. Including in the Mac's EFI, which I assume also means a PC's BIOS.

I don't know what Windows is up to downloading drivers for keyboards. But it's always been like that. Other operating systems don't bother nagging you as much.

As for PS/2: same story. PS/2 has a fixed way of talking to the computer, without drivers at all. The reason some modern USB keyboards come with PS/2 adapters is to support NKRO. Which is a whole other story…

[M'er Forever]

[Account and posts deleted on request]

[bhtooefr]

Gah, looks like I need to rewrite the wiki article on USB.

So, here's a summary of some actual facts on how USB keyboards work.

• I do not know of a single USB keyboard that requires a driver that isn't included with the OS's USB stack. Some have additional functionality exposed by installing a third-party driver, but it's not required. Windows does conspicuously install a driver when you plug a given USB keyboard into a port that it hasn't been plugged into before, but it's simply putting registry keys in to tell it to use the copy of hidclass.sys that's already on the system.
• Damn near everything from at least the Pentium 4 era on has supported USB HID keyboards in the BIOS.
• There is a special "boot mode" that is supported by USB, and is easier for a simple USB stack in the BIOS to support. It also has a predefined format for how the keyboard sends reports to the computer, which is limited to 6KRO. Most keyboards just use the boot mode report format for everything (and their report descriptor matches the boot mode format), because it also reduces their effort required.
• There are at least two ways to do NKRO, one of which is fully compatible with everything (even non-compliant BIOSes), and one of which doesn't work on Macs.
  • The right way: A USB HID device can define a descriptor that has full NKRO instead (or reports special keys, or several other things - that said, to have a NKRO descriptor and have a sufficiently fast polling rate, it needs to be full speed (12 Mbps), not low speed (1.5 Mbps)). Boot mode won't use this, but there's a command in the USB spec to tell the keyboard to switch to a boot mode report. Some BIOSes handle that badly, but there's compliant tricks to get around that, too, involving two different endpoints (a NKRO one that cannot be used as boot mode (and gets ignored by the BIOS), and an endpoint that has a zero-key report descriptor (which gets ignored by the OS) but a boot mode report and that reports as a boot mode capable keyboard (and therefore gets handled by the BIOS)). I'll quote a post from Geekhack by Soarer:

    BIOSs are happy with 6KRO over full-speed. If they didn't then you'd be right; the only way to work would be to switch completely from one speed to the other.
    
    BIOSs should issue a SetProtocol command to make the keyboard use 6KRO, but some don't. That's key. If they all complied with the spec, a firmware writer could simply follow the guidelines in the spec to implement 6KRO for the BIOS, and then whatever they liked for the OS.
    
    The 'trick' is to keep a 6KRO report running always, and have its descriptor tell the OS that it contains no keys, so that the OS ignores it. BIOSs see that it has the 'boot keyboard' flag set, so they see the keys in it fine (they ignore descriptors). A second endpoint provides the NKRO keyboard which doesn't have the 'boot keyboard' flag set, so the BIOS ignores it. Where a BIOS does issue SetProtocol, I suppress output on all but the 6KRO endpoint. It's all perfectly compliant with the spec

  • The wrong way: Simulate multiple 6KRO keyboards that only have six keys each. Works perfectly fine on anything that isn't a Mac, because Apple's design decision was to treat different keyboards as independent, which means that modifiers on one virtual keyboard don't get applied to another.

Really, guys, USB never actually had the 6KRO limitation - the final version of the USB 1.0 HID spec, dated 1997-06-21, has support for this. It was just poor implementations of keyboard controllers.

And, by 2003 or so, everything new had working USB HID support in the BIOS, too.

[Muirium]

Nicely laid out, Bhtooefr, and consistent with everything I've heard about it.

If I dared rewrite the wiki, and I don't because I fail to fully understand how sourcing works, I'd put the end of what you said at the beginning. Always good to have a TL;DR for people who "just want the answer" and would glaze over if they encountered the actual answer!

Keyboards connected by USB typically suffer from 6KRO {give a link to the definition of rollover} for historical reasons. However, USB supports full NKRO natively.

I do wonder how long we'll be stuck with artificially limited rollover, now that everything has been in place for more than a decade. Even Apple, who never had a legacy BIOS to worry about in the first place, makes USB keyboards without KNRO. In fact, make that 5KRO according to Hasu! Why? Why!

We also need an authoritative explanation of why NKRO matters to non-gamers. It's a tricky one, because it's about the interplay between matrix, controller and protocol. But I encountered it head on with a 122 key Model M, and 2KRO is anything but subtle or academic!

[Findecanor]

The wrong way: Simulate multiple 6KRO keyboards that only have six keys each. Works perfectly fine on anything that isn't a Mac, because Apple's design decision was to treat different keyboards as independent, which means that modifiers on one virtual keyboard don't get applied to another.

Weird. I thought I had connected two keyboards to a Mac and combined modifiers on one keyboard with an alphanumeric key on the other, and it worked. Maybe I did it wrong... I don't have any Mac at home, so I can't test again.

[Findecanor]

Even Apple, who never had a legacy BIOS to worry about in the first place, makes USB keyboards without [NKRO]. In fact, make that 5KRO according to Hasu! Why? Why!

Interesting... I have been looking for the information in the post you linked to, even created at thread on Geekhack asking for it.

On the Apple Aluminum keyboard, the Fn key does not enable any hardware layers, but is supposed to be interpreted on the host side. (or it may actually do both.. I have still to look into that). Apple uses special drivers for its keyboard, both on MacOS and Windows (with Boot Camp) to catch the Fn key and produce special keyboard codes depending on driver settings.

I think that Apple's report format is a hack to make the keyboard report (backwards-)compatible with the 6KRO format that some (non-USB compliant but common) BIOS:es and other host drivers take for granted.

The 6KRO format contains a 6-byte array where each byte is either 0 for "No key" or contains the code of a key that is pressed.
Apples format reallocates a byte from this array to be exclusively for the Fn key. It contains the value 0 if the Fn key is not pressed or 3 if the key is pressed. In the 6KRO format, the value 3 means "Undefined key", which means that the host should recognize that a key has been pressed but that it should not act on it.

That way, Apple's keyboard's microcontroller can keep simple and to the USB HID spec. The format is compatible with non spec-compliant BIOS:es and it does not need to support two different protocols for BIOSes that actually do send the SetProtocol request.

[fart_toast]

Thanks for that guys, so basically (take a ducky shine for example) it would still function as a USB HID keyboard without all its crazy lighting things in the worse case scenario?

[Muirium]

It will function perfectly in any scenario where you can plug it in! The lighting modes are all done purely on the keyboard. The computer doesn't know about them.

[fart_toast]

Ok wonderful. I feel a lot better informed now! Learning so much since joining