-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HHKB JP with RN42 need 1min to response via usb #407
Comments
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? |
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 the hid_listen: |
Did you try different usb ports and cables? What's your OS and hardware actually? Firmware download from keymap editor has same problem? |
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. |
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 ? |
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. |
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 |
Thanks for your effort :) |
Same ISSUE. |
@yzprofile which is your keyboard, JP or Pro2? |
Pro2 |
Could you try these firmawares? The firmwares were compiled with build option
For BT Pro2: For BT JP: |
Cool, The new firmaware make the latency low to 3 seconds. And How it works? Thanks |
- Enable build option INTERRUPT_CONTROL_ENDPOINT of LUFA - Shorten LED blink at startup
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. |
Yes, commit 0de581e, the HHKB JP response almost immediately. Great work! Thank you :) |
Now I'm using 093bfd6 and under OSX.
I tested the orignal controller, responsed within seconds.
How can I provide the debug info?
Regards,
Yuwei
The text was updated successfully, but these errors were encountered: