HHKB JP with RN42 need 1min to response via usb

[acevery]

Now I'm using 093bfd6901d6153f4c3bc03d38c1bae8717065e8 and under OSX.

I tested the orignal controller, responsed within seconds.

How can I provide the debug info?

Regards, Yuwei

[tmk]

I think you can find kernel log output somewhere in file system. output of hid_listen would be also helpful.

And, how did you build your firmware?

[acevery]

Yes, I can find the dmesg, and the hid_listen output, when keyboard start to respond, however, the dmesg need about 1min to appear, and I would attach the hid_listen output at the last lines:

+SmartBattery: finished polling type 4 +Report bytes: input:8 output:1 feature:0Collections : 2Buttons : input:2 output:1 feature:0Values : input:0 output:0 feature:0Element value capacity 6656Report count: 1Report ID: 0 input:64 output:8 feature:0IOHIDInterface: stalling for module +Report bytes: input:5 output:0 feature:0Collections : 3Buttons : input:1 output:0 feature:0Values : input:4 output:0 feature:0Element value capacity 244Report count: 1Report ID: 0 input:40 output:0 feature:0IOHIDInterface: stalling for module +Report bytes: input:3 output:1 feature:1Collections : 3Buttons : input:2 output:0 feature:0Values : input:0 output:0 feature:0Element value capacity 17448Report count: 3Report ID: 0 input:0 output:0 feature:0Report ID: 2 input:24 output:8 feature:8Report ID: 3 input:24 output:8 feature:8IOHIDInterface: stalling for module +Report bytes: input:32 output:32 feature:0Collections : 2Buttons : input:0 output:0 feature:0Values : input:1 output:1 feature:0Element value capacity 1692Report count: 1Report ID: 0 input:256 output:256 feature:0IOHIDInterface: stalling for module +HID Activity Tickle (type:0 sender:1000006a8)HID Activity Tickle (type:0 sender:1000006a8)HID Activity Tickle (type:0 sender:1000006a8)HID Activity Tickle (type:0 sender:1000006a8)HID Activity Tickle (type:0 sender:1000006a8)HID Activity Tickle (type:0 sender:1000006a8)Matching service count = 7 +IOHIDInterface: match category IODefaultMatchCategory exists +IOHIDInterface: match category IODefaultMatchCategory exists +IOHIDInterface: match category IODefaultMatchCategory exists +com_driver_GxxxDriver::probe(IOHIDInterface) +com_driver_GxxxDriver::probe fails +HID: Legacy shim 2 +com_driver_GxxxDriver::probe(IOHIDInterface) +com_driver_GxxxDriver::probe fails +com_driver_GxxxDriver::probe(IOHIDInterface) +com_driver_GxxxDriver::probe fails +com_driver_GxxxDriver::probe(IOHIDInterface) +com_driver_GxxxDriver::probe fails +HID: Legacy shim 2 +HID: Legacy shim 2 +Matching service count = 7 +IOHIDInterface: match category IODefaultMatchCategory exists +IOHIDInterface: match category IODefaultMatchCategory exists +IOHIDInterface: match category IODefaultMatchCategory exists +IOHIDInterface: match category IODefaultMatchCategory exists +IOHIDInterface: match category IODefaultMatchCategory exists +IOHIDInterface: match category IODefaultMatchCategory exists +IOHIDInterface: match category IODefaultMatchCategory exists +IOHIDInterface: match category IODefaultMatchCategory exists +com_driver_GxxxDriver::probe(IOHIDInterface) +com_driver_GxxxDriver::probe fails

the hid_listen: ./hid_listen.mac Waiting for device:............................................................... Listening:

[tmk]

Did you try different usb ports and cables? What's your OS and hardware actually?

Firmware download from keymap editor has same problem?

[acevery]

Yes, I test the different 2 usb port with new usb cables. I use MacBook Pro (Retina, 15-inch, Mid 2014) with macOS Serra 10.12.2 (16C67).

I flashed the binary/hhkb_jp_rn42_unimap.hex, same result.

[tmk]

OK. The original firmware works with Sierra? Or with previous version of osx?

Do you think recent tmk firmware change causes the problem or difference of osx versions raises error ?

[acevery]

The tmk_keybord works well with previous version of osx, at least the Version 10.10: "Yosemite". From Version 10.11: "El Capitan", this problem started. However, the original controller works without this problem, even with Sierra.

[tmk]

Reportedly USB power control in osx has changed since El Capitan, I guess this causes this issue on USB enumeration process. I'll check codes of that part.

Thanks

[acevery]

Thanks for your effort :)

[yzprofile]

Same ISSUE.

[tmk]

@yzprofile which is your keyboard, JP or Pro2?

[yzprofile]

Pro2

[tmk]

@acevery @yzprofile

Could you try these firmawares? The firmwares were compiled with build option INTERRUPT_CONTROL_ENDPOINT. This would improve keyboard responsiveness in enumaration process of USB.

diff --git a/keyboard/hhkb/Makefile b/keyboard/hhkb/Makefile
index 2ba1786..c902753 100644
--- a/keyboard/hhkb/Makefile
+++ b/keyboard/hhkb/Makefile
@@ -96,7 +96,7 @@ ARCH ?= AVR8
 F_USB ?= $(F_CPU)

 # Interrupt driven control endpoint task
-#OPT_DEFS += -DINTERRUPT_CONTROL_ENDPOINT
+OPT_DEFS += -DINTERRUPT_CONTROL_ENDPOINT

 # Boot Section Size in *bytes*

For BT Pro2: https://dl.dropboxusercontent.com/u/1033342/hhkb/endpoint_interrupt/hhkb_rn42_unimap.hex

For BT JP: https://dl.dropboxusercontent.com/u/1033342/hhkb/endpoint_interrupt/hhkb_jp_rn42_unimap.hex

[yzprofile]

Cool, The new firmaware make the latency low to 3 seconds.

And How it works?

Thanks

[tmk]

Thank your for testing.

Seems like USB communication on control endopoint were prevented while blinking LED(2 sec) at startup.

Fixed this issue at commit 0de581e hopefully. This commit shortens LED blinking term and makes controller responsive while the blinking. With the commit keyboard shows up within a sec and registers key immediately now.

Firmware of keymap editor is also updated, it should work with MacOS now.

[acevery]

Yes, commit 0de581ee82d03689e1703a9d2a239b2091c14097, the HHKB JP response almost immediately. Great work! Thank you :)