[TMK] Alternative Controller for HHKB

[hasu]

Synopsis
This controller replaces PFU/Topre stock controller board and makes your HHKB(Pro, Pro2, JP and Type-S) full programmable, so you can do everything you want with the keyboard in theory. This controller works with AVR USB familly such like ATMega32U4 or AT90USB1286, also on ATMega328P with V-USB. It will need 32KB flash at least.

This controller doesn't support Professional BT(PD-KB600/620) and Professional Class/HYBRID series(PD-KB401/PD-KB800/PD-KB820).

My Story
I wanted to add vi cursor keys and mouse keys to HHKB. Stock HHKB controller is not programmable and firmware source code is not open. So customizing HHKB needed to replace original controller with programmable one. My controller and firmware are now mature enough for my daily job. I'm happy to use my HHKB with this controller every day, in particular I can't live without mouse keys!

Any suggestions or ideas are welcome.


Preassembled TMK Alt Controller Board is avialable here:
Type-C connector version is available as well as Mini-B now.(2020-01-15)
https://geekhack.org/index.php?topic=71517.0



DISCLAIMER
I'm not a professional for electronics and MCU programming. This may damage your HHKB.
And my English writing is poor, I'm not sure I can convey my notions accurately.




Update

• 2024-03-19 Update prebuilt firmware files
• 2017/01/16 New keymap editor is available now.
• 2016/01/11 Updated keymap editor(media keys for Mac)
  
• 2015/06/17 Pro controller board
  
• 2015/04/12 Add/Update Keymap Editor for TMK Alt Controller Board
• 2015/01/17 BT RN-42 support is integrated
• 2014/07/10 HHKB JP is supported
• 2013/07/11 Support TMK Alt Controller Board
• 2011/05/25 Add V-USB support: (You can use a plain ATMega168(328) as a controller now.)

Features

• Customizable keymap and multiple layers
• Mouse keys
• USB NKRO
• Media & system control

See README of firmware for more info.



TMK keyboard firmware for Alt Contrller
https://github.com/tmk/tmk_keyboard/tree/master/keyboard/hhkb



HHKB Internals
See this document and pics.
https://raw.github.com/tmk/tmk_keyboard/master/keyboard/hhkb/doc/HHKB.txt
https://github.com/tmk/tmk_keyboard/tree/master/keyboard/hhkb/doc/HHKB_img

More

Pro1, Pro2, JP Controller Board


Pro2 Board Dimension


Pro2 connector: JST ZH(13pin) http://www.jst-mfg.com/product/pdf/eng/eZH.pdf
Pro1 connector: JST PH(15pin) http://www.jst-mfg.com/product/pdf/eng/ePH.pdf
JP connector: Hirose DF14(15pin) http://www.hirose.co.jp/cataloge_hp/en_DF14_20130411.pdf

Digipot BU9831 for actuation point tweaking:
https://geekhack.org/index.php?topic=12047.msg2940666#msg2940666


Keymap Editor
You can edit your keymap on line with web browser.

Keymap Editor for TMK Alt Controller Board
http://www.tmk-kbd.com/tmk_keyboard/editor/

More

Hardware Implementation

(1) DIY Alt Controller
You can use PJRC Teensy, Pro Micro or other AVR boards to make your own Alt Controller hardware. See HHKB Internals section for more information to hack.

You can make you own!


Teensy2.0 in Pro2 This photo is from Deskthority thread.

More

Wiring

    HHKB connector lines:
    JP   Pro2   Pro     Function    Description                               ATMega32U4
    --------------------------------------------------------------------------------------------
                 1      Vcc(5V)                                               5V
     1    1      2      Vcc(5V)                                               5V
     2    2      3      Vcc(5V)                                               5V
     3    3      4      TP1684      ~KEY: Low(0) when key is pressed          PD7 input(with pullup)
     4    4      5      TP1684      HYS: High(1) when key is pressed          PB7 output
     5    5      6      HC4051      A(bit0)\                                  PB0 output
     6    6      7      HC4051      B(bit1) > select row 0-7                  PB1 output
     7    7      8      HC4051      C(bit2)/                                  PB2 output
     8    8      9      LS145       A(bit0)\                                  PB3 output
     9    9     10      LS145       B(bit1) > select column 0-7               PB4 output
    10   10     11      LS145       C(bit2)/                                  PB5 output
    11   11     12      LS145       ~D(enable) Low(0) enables selected column PB6 output
    12   12     13      GND                                                   GND
    13   13     14      GND                                                   GND
                15      GND
    14                  HC4051(Z2)  ~Enable of Z2   row0-7                    PC6
    15                  HC4051(Z3)  ~Enable of Z3   row8-15                   PC7

Also see these nice writeups to make Alt Controller.
https://geekhack.org/index.php?topic=57008.msg1292217#msg1292217
http://deskthority.net/workshop-f7/hardware-dvorak-hhkb-t3415.html

(2) TMK Alt Controller
TMK Alt Controller Board is a hardware designed and assembled by hands of me(hasu). This board is fully assembled so you can install it just with screw driver.

Schematic and PCB design files are also available.
https://github.com/tmk/HHKB_controller/ [PCB]
https://github.com/tmk/HHKB_controller/tree/master/schematic [Schematic]

USB Controller:


Bluetooth Controller


You can buy this here!
[TMK] Alt Controller Board for HHKB Artisan Service Thread:
https://geekhack.org/index.php?topic=71517.0
https://geekhack.org/index.php?topic=56494.0







Goodies from community

- Cover for USB Hub hole by alienman82
https://geekhack.org/index.php?topic=12047.msg1752328#msg1752328
https://geekhack.org/index.php?topic=12047.msg1754098#msg1754098

- Cover for USB Hub hole and Qi charger by manisteinn
https://geekhack.org/index.php?topic=12047.msg1558708#msg1558708

- You need hub? See these.
https://geekhack.org/index.php?topic=12047.msg1699177#msg1699177
https://geekhack.org/index.php?topic=57008.msg1491318#msg1491318

- Cover by RavenIl
https://geekhack.org/index.php?topic=12047.msg2165570#msg2165570





Old DIY HHKB BT(Bluegiga WT12)
https://geekhack.org/index.php?topic=20851.0 (Archived)

More

Some thoughts(2014/05/23):
Battery life: IIRC, finally it is around 18hours with 310mAh Lipo when my usual usage, this is, almost idle. Yes I think you can get run-time longer with big battery. My implementation was not completely tuned and remains room to tweak, though, I don't think you can get long battery life as weeks or months like consumer products. I'm sure you can have Sparkfun 850mA(or 1000mA?) in HHKB case but not sure about larger battery.

USB/BT: It is possible and not difficult to switch protocol between USB and Bluetooth. This is useful especially with short battery life keyboard like HHKB. You can used it as normal wired keyboard when you are on your desk without concerning about battery. When it is connected with USB it is charged its battery and can be used as normal USB keyboard.


My HHKB BT code is old and not used now, but you can still see them in my repository.
https://github.com/tmk/tmk_keyboard/tree/f4760c822a34c338250dc47ff6d195935986bdae/keyboard/hhkb
https://github.com/tmk/tmk_keyboard/tree/f4760c822a34c338250dc47ff6d195935986bdae/protocol/iwrap

You may be interested in code around here, it switches protocols:
https://github.com/tmk/tmk_keyboard/blob/f4760c822a34c338250dc47ff6d195935986bdae/protocol/iwrap/main.c#L289

Schematics of HHKB BT:
https://raw.githubusercontent.com/tmk/tmk_keyboard/f4760c822a34c338250dc47ff6d195935986bdae/keyboard/hhkb/doc/Bluetooth_img/BT_circuit.jpg

Pic of HHKB BT:
http://i.imgur.com/4YXc8SF.jpg

New controller schematics(WIP):
https://github.com/tmk/HHKB_controller
https://github.com/tmk/HHKB_controller/blob/master/HHKB_controller_B140314.pdf

In this moment no code for new controller.

Pic of new controller:
http://i.imgur.com/ivekyC6.jpg

[Rajagra]

Wow. I would have assumed everything in the HHKB Pro would be integrated, and inaccessible to tinkerers. I'm impressed they were methodical enough to separate functional tasks into multiple chips. That is pro. Even more impressed that someone has found a way to hack into it. Good job!

[lowpoly]

Awesome.

[didjamatic]

Oh my!!!  Fantastic mod!  That is seriously impressive.

[itlnstln]

That's money.  Great job.

-Sent from my muhf*ckin' HHKB Pro 2

[Daniel Beaver]

Excellent. I would love to have a fully-reprogrammable HHKB.

[itlnstln]

The one thing I would do is create a virtual numpad on mine.  That's the only thing I miss on the HHKB, but the size more than makes up for it.

[lowpoly]

unavailability of Teensy++/Teensy(because of PS3 cracking boom?)

Please explain.

[RickyJ]

^ Sony's PS3 finally got cracked, group that did it released USB dongles that jailbreak the PS3.  After Sony threatened legal action against any online store selling the dongles, the group released the source code.  Now anyone can do it using a Teensy, or certain other Atmel based devices.

I've been thinking of resurrecting my other Nan-Tan board that has a fried controller, using an Arduino that I have on my work bench.  Thanks for the added motivation!

[hasu]

lowpoly:
Open source PS3 jailbreak - PSGroove has been public last month. PSGroove uses AT90USB to crack PS3.
So, the demand of AT90USBs rose sharply. AT90USB boards(Teensy, USBKEY and etc)  has disappeared on the planet.

[kishy]

Makes me glad I grabbed my Teensy++ when I did.

Interesting point is, AFAIK, the Teensy-based PS3 hacks are still unusable, broken by a PS3 update during the hack's rise to popularity.

[kishy]

Yes, well, as it was explained to me...a good number of people did the update while waiting for their Teensies to arrive.

[JBert]

@the OP: you say you're no professional but you still got some logic analyser around. Which hardware/software combo is it?

[hasu]

It is a sample application for CPLD dev board which was available in Japan several years ago. It is no longer available and supported. All information is Japanese only.
http://translate.google.co.jp/translate?u=http%3A%2F%2Foptimize.ath.cx%2Fcusb%2Flogiana.html&hl=en&langpair=auto|en&tbb=1


I would like a open source logic analyzer or the Saleae Logic if I buy now.

http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer
http://www.saleae.com/logic/

[hasu]

I added this video on article page.
This video show some keymap layers and case mod for USB receptacle.

Left side USB jack is very nice when I use HHKB on ThinkPad.

[Laser Freud]

Thanks for posting, this is very helpful information. I have the HHKB pro 2 and I want to keep the USB hub intact, so instead of replacing the controller completely I'm going to program an AVR to just translate the address bits on 6-11 to the remapped keys.

[hasu]

I added USB 12KRO support and some features to my firmware.
I know 6KRO is enough for most people include me, though it's just possible and fun.
Auido control and sleep/wakeup feature is more essential for me.

12KRO:

audio control/power down & wakeup:
Not a valid youtube URL

[nanu]

Too pro.

[woody]

How did you add 12KRO support to a USB keyboard.  Are you using a custom driver or the standard Microsoft HID keyboard driver?

I'd guess more reports in the firmware. There is nothing about 6 in the USB specs, so the HID driver should handle any KRO.

[hasu]

It uses two standard HID endpoints for 12KRO and standard driver is used.
Windows sees this as two another keyboards on Device Manager.
AVR(AT90USB) has 6 endpoints, 6*6KRO should be possible.

Some source says M$ driver can recognizes 10Keys a each endpoint, and if so,
6*10KRO will be possible on Windows without custom driver.

How did you add 12KRO support to a USB keyboard.  Are you using a custom driver or the standard Microsoft HID keyboard driver?

[woody]

It uses two standard HID endpoints for 12KRO and standard driver is used.
Windows sees this as two another keyboards on Device Manager.

You have to be careful with that - if a report moves between "keyboards", it will be like releasing the key on one and pressing it on the other virtual keyboard.

BTW, why don't you just try increasing the number of reports with a single keyboard, along with a proper descriptor?

[hasu]

You have to be careful with that - if a report moves between "keyboards", it will be like releasing the key on one and pressing it on the other virtual keyboard.

BTW, why don't you just try increasing the number of reports with a single keyboard, along with a proper descriptor?

Your point-out is right. To avoid this problem, it uses some extra memory and cycles.

I am not sure that increasing over 6 keys on single report is recognized by OS keyboard driver. The keyboard which needs a custom driver is cumbersome.

[woody]

I am not sure that increasing over 6 keys on single report is recognized by OS keyboard driver. The keyboard which needs a custom driver is cumbersome.

The HID doesn't specify anything about limit, so I don't see why HID drivers should have any limit, let alone at 6. That's the whole purpose of the cumbersome HID and the descriptors after all! I can speculate that the keyboards are 6KRO because the firmware developer just copied some example descriptors, or was lazy and chose easier compatibility with the boot mode.

On the other hand, if some OS' driver is hardcoded to a limit, that'll be useful information. Can you verify that?

I'll get to it someday soon, but you have all the tools at your disposal. Be the hero to uncover the mystery. ;-)

[hasu]

The HID doesn't specify anything about limit, so I don't see why HID drivers should have any limit, let alone at 6. That's the whole purpose of the cumbersome HID and the descriptors after all! I can speculate that the keyboards are 6KRO because the firmware developer just copied some example descriptors, or was lazy and chose easier compatibility with the boot mode.

I agree.
But the problem exist  in not only keyboard firmware but also OS driver side.
I can't believe driver/kernel can understand such complex HID report descriptors, I guess it doesn't even read

Using 8bytes(6keys)+ report may cause a compatibility problem on some circumstance(which expect a 8bytes report only). This is reason why I use two reports for 12KRO.

On the other hand, if some OS' driver is hardcoded to a limit, that'll be useful information. Can you verify that?

I'll get to it someday soon, but you have all the tools at your disposal. Be the hero to uncover the mystery. ;-)

I guess the driver is hardcoded on almost OS.
If I get spare time, I'll try to verify the limit on Windows/Linux. (I have no working Mac now

I'm not familiar with Linux internal, but this seems to be hardcoded.
http://lxr.linux.no/#linux+v2.6.36/drivers/hid/usbhid/usbkbd.c#L101

Code: [Select]

101        for (i = 2; i < 8; i++) {
 102
 103                if (kbd->old[i] > 3 && memscan(kbd->new + 2, kbd->old[i], 6) == kbd->new + 8) {
 104                        if (usb_kbd_keycode[kbd->old[i]])
 105                                input_report_key(kbd->dev, usb_kbd_keycode[kbd->old[i]], 0);
 106                        else
 107                                dev_info(&urb->dev->dev,
 108                                                &quot;Unknown key (scancode %#x) released.\n&quot;, kbd->old[i]);
 109                }
 110
 111                if (kbd->new[i] > 3 && memscan(kbd->old + 2, kbd->new[i], 6) == kbd->old + 8) {
 112                        if (usb_kbd_keycode[kbd->new[i]])
 113                                input_report_key(kbd->dev, usb_kbd_keycode[kbd->new[i]], 1);
 114                        else
 115                                dev_info(&urb->dev->dev,
 116                                                &quot;Unknown key (scancode %#x) released.\n&quot;, kbd->new[i]);
 117                }
 118        }
 119
 120        input_sync(kbd->dev);
 121
 122        memcpy(kbd->old, kbd->new, 8);


[kps]

If I get spare time, I'll try to verify the limit on Windows/Linux. (I have no working Mac now

I don't know whether the Mac driver has the same limit, but it has one other notable difference: keyboard state is separate for each keyboard, so a modifier key only applies to the keyboard it is on. For example, if you have two keyboards, and press the shift key on one keyboard and the ";:" key on another, Linux & Windows will process this as ":" but OS X will treat it as ";".

[Soarer]

Thanks to the OP for the idea, this (ed: the multiple virtual keyboards bit) has now become a 'to-do' for my Teensy based PS2 to USB adapter.

I vaguely remember the problem with using larger reports being related to the bios... and that switching to larger reports once Windows boots should be possible, but isn't for some reason.

I wonder if it would work if the first virtual keyboard used 6-key reports and the second used larger reports?

It's rather academic because 12-key really is enough!

I don't know whether the Mac driver has the same limit, but it has one other notable difference: keyboard state is separate for each keyboard, so a modifier key only applies to the keyboard it is on. For example, if you have two keyboards, and press the shift key on one keyboard and the ";:" key on another, Linux & Windows will process this as ":" but OS X will treat it as ";".

In this case, the solution is simple - just send the same modifiers for all the virtual keyboards. :-)

[hasu]

Thanks for an interesting info.
Hmm. I have to try my keyboard on Mac.

I don't know whether the Mac driver has the same limit, but it has one other notable difference: keyboard state is separate for each keyboard, so a modifier key only applies to the keyboard it is on. For example, if you have two keyboards, and press the shift key on one keyboard and the ";:" key on another, Linux & Windows will process this as ":" but OS X will treat it as ";".

[kishy]

Like I've said earlier I've seen lots of people saying you can simply change a HID descriptor but I'm pretty sure the OS will not  recognize it.

If it was that easy some keyboard manufacturer would have done it by now other than Microsoft's Sidewinder X4.

If I am to understand it correctly, it isn't an OS support issue. It's the boot mode which doesn't work.

dfj knows more than I, I just spew whatever little I retain from our lengthy conversations.

[ricercar]

The HID doesn't specify anything about limit, so I don't see why HID drivers should have any limit,

Packet size. I don't have the numbers handy, but there can be only so much data in a USB packet. In the USB Keyboard HID this comes out to 6 keys and some overhead.

[kishy]

Whatever the reason is, far more than 6kro is possible using standard HID drivers. I have seen this on my own computers and I have a device that does it cable-tied to the back of my desk...

There can be low-level BIOS incompatibilities, however, which is one conceivable reason why we don't see this as the standard.

[kishy]

Whatever the reason is, far more than 6kro is possible using standard HID drivers.

There can be low-level BIOS incompatibilities, however, which is one conceivable reason why we don't see this as the standard.

[hasu]

woody, kishy, You guys win!

I verified that 62KRO by big HID report and standard driver(kbdhid.sys) is possible at least on Windows 7. (Behaviour on other platform and boot protocol is not verified.)
This is not my expectation at all about OS driver implementation. I'm very impressed:)

This is easy to implement, even easier than 12KRO by virtual 2 keyboards method.
Why don't  keyboard  manufactures do this?
62KRO may not be actual merit, but must be hype for some buyers

BTW, HHKB has only 52 normal keys, so my HHKB can be called NKRO. right ?

[sixty]

Wow, outstanding results hasu!
Probably one of the best mods on the site, now that the miniguru project has died.

Great work.

[Soarer]

As I understand it...
HID keyboards must support 'boot mode', to be used by the BIOS.
Boot mode is predefined (8 bytes) so that the BIOS doesn't have to read descriptors.
Low speed USB HID packets are a maximum of 8 bytes.
Full speed USB HID packets are a maximum of 64 bytes.
But... a 'report' may use multiple packets.
When an OS starts it should read descriptors from all HID devices.
So a HID keyboard could (in theory) then switch to using larger reports.

In practice though...
Most keyboard manufacturers have little motivation to support more than 6KRO.
OS developers have even less motivation (to support keyboards that don't exist).
Keyboard makers need to aim for maximum compatibility.
If there are bugs in any OS's HID implementation, it reduces the lowest common denominator.
And those bugs won't be classed as high priority.

hasu, I still think the idea of using two endpoints is very good.
If the first is configured for 6 keys and the second for 62 keys, it should be very compatible with most BIOS and OS (all of them, if you don't press more than 6 keys!).

[hasu]

Thanks for your insightful comment, Soarer.

I also think a compatibility is a first target for a keyboard.
A keyboard which doesn't work  in some platform is lame.
64bytes report should be an option not a default, of course.
It is a excess and resource waste for normal use.

hasu, I still think the idea of using two endpoints is very good.
If the first is configured for 6 keys and the second for 62 keys, it should be very compatible with most BIOS and OS (all of them, if you don't press more than 6 keys!).

[woody]

I verified that 62KRO by big HID report and standard driver(kbdhid.sys) is possible at least on Windows 7. (Behaviour on other platform and boot protocol is not verified.)

Hasu, you receive the title "The Great GeekHack Un-Mystifier". Nice job!

So, W7 is ok. Linux is probably not - it seems hardcoded as far as I can see by quick glance from the snippet you posted, but there could be other code eventually in another file. So that needs further check. As the other older OSes.

The sad point will be if one of those legacy OSes had hardcoded 2+6 keyboard data, effectively restricting the keyboard manufacturers even today. Which probably happened. Meh.

BTW, Linux HID is easy to fix if it's really lacking.

[woody]

When an OS starts it should read descriptors from all HID devices.
So a HID keyboard could (in theory) then switch to using larger reports.

Descriptors are read on every USB device enumeration, i.e. each time they connect/re-connect. Host can force re-connect, too.

[Soarer]

Descriptors are read on every USB device enumeration, i.e. each time they connect/re-connect. Host can force re-connect, too.

True, I was making a distinction between BIOS and OS there - the BIOS doesn't enumerate fully and makes lots of assumptions, and it's possible that an OS could do the same (or have bugs in its implementation) with keyboards - hence the (legally cautious) 'should' and 'could' terms in my description. :-)

[Soarer]

Thanks for your insightful comment, Soarer.

I also think a compatibility is a first target for a keyboard.
A keyboard which doesn't work  in some platform is lame.
64bytes report should be an option not a default, of course.
It is a excess and resource waste for normal use.

Well, you have a space for some DIP switches ;-)

But I don't think you'd need to use a switch - in normal use the second (64 byte) endpoint would just be idle, with the first (8 byte) endpoint doing all the work.

[Soarer]

Large reports seem to work on Windows XP also :-)

[Soarer]

It also works to send a 32 byte report, with a bit for each possible USB key-code.

240KRO :-D

Code: [Select]

#if 0
        0x95, USB_NUM_KEYS,          //   Report Count (6),
        0x75, 0x08,          //   Report Size (8),
        0x15, 0x00,          //   Logical Minimum (0),
        0x25, 0xFF,          //   Logical Maximum(255), // was 0x68,          //   Logical Maximum(104),
        0x05, 0x07,          //   Usage Page (Key Codes),
        0x19, 0x00,          //   Usage Minimum (0),
        0x29, 0xFF,          //   Usage Maximum (255), // was 0x68,          //   Usage Maximum (104),
        0x81, 0x00,          //   Input (Data, Array),
#else
0x75, 0x01,          //   Report Size (1),
0x95, 0xF0,          //   Report Count (240), // 30 bytes
0x05, 0x07,          //   Usage Page (Key Codes),
0x19, 0x04,          //   Usage Minimum (4), // start at 'A'
0x29, 0xF3,          //   Usage Maximum (243), // 30 bytes worth
0x15, 0x00,          //   Logical Minimum (0),
0x25, 0x01,          //   Logical Maximum (1),
0x81, 0x02,          //   Input (Data, Variable, Absolute), ;keys bit array
#endif


[hasu]

Wow, 240KRO by only 32bytes, nice!
I needed some time to understand this
It uses 1bit each a key... genius.

It works with Windows standard driver?

[Soarer]

Yes, standard driver on XP!
It works the same way as the modifier keys, so I used that section of the definition as a guide.

[woody]

Soarer, you da man, too. I haven't thought about this approach, but apparently it's the best one for a 32 byte packet. Can you verify Linux and other OSes?

[Soarer]

Probably safe to assume that Vista and 7 will be the same as XP. I'll try to find time to grab a live CD and test on Linux later.

The descriptor change I posted still needs some work, but it looks very promising.
I think the neatest would be to simply have the whole 32 bytes of the report as bits, representing codes from 0 to 255, but I haven't tried it yet.

[woody]

Yep, that might do, too. How about for a 16-byte report, if you don't need codes above 128?

BTW, are you using this on a different endpoint/interface?

[hasu]

Yep, that might do, too. How about for a 16-byte report, if you don't need codes above 128?

I am thinking same thing.
I think 16byte report is enough for almost keyboard.
Japanese keyboard is one of exception, it used usage ID 135-140.

[Soarer]

A 16-byte report would almost certainly work, and could handle most common keyboards. The codes don't have to all be consecutive, you can have multiple definition sections so for example you could use the 128 bits for codes 4 to 100 (general), 133 (keypad comma), 135 to 140 (int'l), 144 to 148 (lang), 240 to 247 (modifiers), and then add padding to make it up 128.

Apart from the patch above, I think the only change to the config was to adjust the size of the keyboard report twice - in the endpoint config table, and in the endpoint descriptor in the config descriptor. In the AVR code I'm using (from PJRC), there's already a #define for it called KEYBOARD_SIZE.

[woody]

Splitting into regions would be ok. I can't really predict what's theoretically better - shortening the packet size will free few negligible bytes off USB, but splitting into regions might eat host CPU cycles due to more complex processing in the high-level HID code.

[Soarer]

Splitting into regions would be ok. I can't really predict what's theoretically better - shortening the packet size will free few negligible bytes off USB, but splitting into regions might eat host CPU cycles due to more complex processing in the high-level HID code.

It wouldn't bother the PC side, but on the Teensy it would be more effort, and probably not worth it. But it's certainly possible.

...

Speaking of possible, I have just managed to get my adapter to switch from NKRO mode to boot mode and back... at the right times!!!

This is my modified version of the PJRC keyboard code:

It isn't finished, but it proves the concept.

The BIOS scans USB devices, reading their descriptors, and if it finds a keyboard it issues a SetProtocol command to put it in boot mode. That's the easy switch.

Windows scans devices but does NOT issue a SetProtocol command. IIRC this has been given before as an answer to why more than 6KRO is not possible under Windows (without tricks). But, I thought, what if Windows expects the device to initialize to the correct protocol? I'm still not sure exactly when that initialization should happen, so I reset the protocol to NKRO when the host is starting to read the descriptors.

The BIOS ignores the descriptors it reads, and simply expects to get standard boot mode reports (modifiers + 6 keys). So in the code, there is no descriptor defined that matches boot mode (it sends the NKRO one).

Along the way, I discovered that my BIOS doesn't seem to mind if it gets a larger report, as long as it begins with the standard 8 bytes. I don't know if that could be relied on across all machines.