Author
Topic: Alternative Controller for HHKB (Read 308918 times)

woody

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.

AVR is more than fast enough, just some level of indirection through tables.The unknown hell of high-level abstraction in the PC HID drivers is what would bother me, so I'd keep the report in a single array.

Quote

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.

You are supposed to enter boot mode only when SetProtocol is issued. After reset/re-enumeration, you must be back to default (long-report) mode. It doesn't matter if the BIOS set boot mode, once OS loads up it will power cycle the USB ports and re-enumerate devices.

Quote

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).

Correct. Boot mode is just a kludge.

Quote

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.

AVR is more than fast enough, just some level of indirection through tables.The unknown hell of high-level abstraction in the PC HID drivers is what would bother me, so I'd keep the report in a single array.

I meant effort to code, and I'm lazy ;-)I don't think a shorter 16 byte report would really give any advantage, apart from the satisfaction of being slightly more efficient. For my purpose (a PS/2 to USB adapter) it would also mean I'd have to decide which codes to leave out.

Quote from: woody;255476

You are supposed to enter boot mode only when SetProtocol is issued. After reset/re-enumeration, you must be back to default (long-report) mode. It doesn't matter if the BIOS set boot mode, once OS loads up it will power cycle the USB ports and re-enumerate devices.

Yeah, that's what I found out. I think I should move the 'reset' to where it handles SetConfiguration. The Microsoft tests demand being able to handle SetProtocol to go into full report mode (TD-9.27.3.3), but I've never seen it happen.

Quote from: woody;255476

No, keep it 8 bytes.

Oh, I will. No point in doing otherwise. But I found it curious, because it would mean that a device using the standard report layout, but extended with more keys, would work ok in the bios. Just another reason to ask 'why hasn't someone done this before'?

So why haven't they? Is there a nasty 'gotcha' lurking somewhere that we haven't spotted yet?

woody

On the last question - don't really know. Nevermind, though. I think that the original HID intent of having flexible descriptors and the boot mode is enough. How they ended up with most implementations being 6KRO is beyond me.

You and hasu provided great deal of useful information and beat the lazy me. Cheers.

What is the constraint on report lengths?I thought it was powers of two, and that's all that seems to work (32=ok, 30=ng, 24=ng, 16=ok). But I just saw a reference in the docs to a 10 byte HID report... confusing!

I don't think it's that - I wrote some macros to work out how much padding to add to make it up to whole bytes, and they seem to work fine. And I just tried a more hard-coded test of 24 bytes, which also failed.It's not really important, but as you say, from the docs you'd think there was no restriction other than being whole bytes.

Oh, I will. No point in doing otherwise. But I found it curious, because it would mean that a device using the standard report layout, but extended with more keys, would work ok in the bios. Just another reason to ask 'why hasn't someone done this before'?

So why haven't they? Is there a nasty 'gotcha' lurking somewhere that we haven't spotted yet?

The answer is easier than it sounds: it takes too much code to run an entire USB HID stack.

So what they do is send a SetProtocol command and then read the raw keyboard data: (written in pseudo-C++ for convenience)

unsigned char kbdData[12];cin >> kbdData;char key1 = kbdData[4];char key2 = kbdData[5];etc...char key6 = kbdData[11]Because the boot mode is very strict, they can make assumptions of where the scancodes are and ignore everything else.

Ah-ha, that's it, thanks! The PJRC code used the same #define for both configuration of the endpoint in the USB hardware and the max packet size in the endpoint descriptor. The hardware expects a power of two as the endpoint size, but the max packet size can be less than that.

unsigned char kbdData[12];cin >> kbdData;char key1 = kbdData[4];char key2 = kbdData[5];etc...char key6 = kbdData[11]Because the boot mode is very strict, they can make assumptions of where the scancodes are and ignore everything else.

Oh, I understand boot mode Sorry, what I said before wasn't clear... when I said 'why hasn't someone done this before'?, the 'this' meant switching to a better mode when an OS starts, since it has a full HID stack.

edit: The quirk that my BIOS doesn't mind longer reports, as long as the first 8 bytes match a boot mode report, if universal, would've made it easy for keyboards to support more than 6KRO - they wouldn't even need to switch.

So far, all I know is that switching works on my PC, the 'gotcha' could be that it doesn't work on other PCs.

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.

anyone know how this is possible to do? or a tutorial prehaps? id like change my layout from qwerty to colemak natively thru the kb(hhkb2) without replacing the controller.

Mouse keys is a virtual pointing device implemented on my keyboard firmware, OS see it as a real mouse device so any special settings are not needed.Mouse keys is enough for most my daily work, but complicated GUI job like CAD, Photoshop and Eclipse need a real mouse.

I followed the advice given by hasu and traced the pcb for the pro2 I could verify that the LS145 pin positions were correct and the HC4051's C pin was in the correct position. HC4051's A and B appeared to be right but I could not verify. And I could the 2 tracers going to the TP1684, but could not tell their position. It looked good enough for me so I compiled the software and hooked up the teesnie++. The keys seemed to work fine and so did the various modes. I used the following diagram to hook up my HHKB pro2 to the teensie++.

Woooo it's working it's working I'm typing this from my PROGRAMMABLE HHKB Muahaha, the sky is the limit now. Now I can take a year off to come up with my own fn-layers.

Hasu, you're a genius! Thank you so much for this!

Hey Dox, thanks for nudging me in some other thread to finally do this.

BTW I'm running it on Teensy 2.0 (tweaked a line or two) and it seems it will fit almost perfectly in the space around the mini-USB hole in the case. (That's plain HH Pro, not Pro 2.) I'll just need to sand down like 0.1mm of plastic and it's snug. [ Attachment Invalid Or Does Not Exist ] 30899[/ATTACH]

It works well after tweaking code a bit. It is full functional as USB keyboard now, all parts needed for this are installeed in picture. Right part of PCB is optional for wireless option which is in development.

Yes, I have a plan to part with some of spare PCBs and parts. After some short testing I'll be able to offer some completed controllers or DIY kits. At this time wireless option will not be available.And PCB and schematic data will also be available some after.

- With this controller HHKB get programable while losing its USB Hub function as you can see.- You can install the controller PCB very easily with just screw drivers.- Components on right half part of PCB are not implemented it is for protyping purpose only and I don't know whether this part works or not atm.

- With this controller HHKB get programable while losing its USB Hub function as you can see.- You can install the controller PCB very easily with just screw drivers.- Components on right half part of PCB are not implemented it is for protyping purpose only and I don't know whether this part works or not atm.

Great work though! I look forward to the day when we can possibly make a HHKB controller with wireless/BT capability and a USB hub that does something. And I'm sure it will all stem from the great job you've put out so far here.

I ordered one of hasu's tmk board replacements for the hhkb pro 2 and it is amazing! Fast response + delivery, everything just fits together perfectly, highly recommended if you don't want to risk damaging your board like me.

I was working on this web based keymap editor recently. Now it can do the job somewhat.

This editor is a fully client side javascript web applicaton without using web app server, it works enven without network connection. You can download hex file after editing your keymap, just need to program it without compile process.

I was working on this web based keymap editor recently. Now it can do the job somewhat.

Show Image

This editor is a fully client side javascript web applicaton without using web app server, it works enven without network connection. You can download hex file after editing your keymap, just need to program it without compile process.

I posted this 'cause some people asked me by PM if spare controller boards remain on my hand for last weeks. Thanks for your interest!

All spare boards already had gone now. But I have a plan of next production of PCB. It will cost $20-30 for the completed board excluding shipping. (Shipping to US are estimated about $12 for EMS or $6 for Registered Air Mail.)

Plz watch this thread if you are interested. And your ideas or suggestions on next revision of PCB are welcomed.

I'll start to design Rev.B PCB before long. Before start the work I'd try to ask some.

1) Rev.A users, do you have any flaw or thought on the board?If you have requeset, complain, suggestion or anything, post it here(or PM me if it needs). Feedback from real users is very important and helps me a lot.

2) Other suggestion or idea on this?Are there missing or wanting features?(But... Don't say about USB hub and DIP switch I don't need them!)Or recommended compornent supplier PCB manufacturer or other production service?

3) Any advices on circuit or PCB work?I'm not an expert of electronics at all. No doubt I did and will make many mistakes. I need advices.

Why Rev.B?Rev.A works well with HHKB pro2 and Type-S as a wired USB controller. The reason why I set to Rev.B is to add wireless option with Bluetooth. Rev.B still works as USB controller and also can connect with wireless if you install BT module and other parts on it. In my plan you can switch between USB and Buletooth, and Li-po battery are charged with USB.

Wired controller part of Rev.A has no apparent flaws so I wont change its design except for some parts are removed or replaced, while its wireless portion has some flaws to be fixed. In Rev.B I'll use new module Roving RN-42 and add FET switching circuit for power control between USB and battery.