search

coseyfannitutti / mysterium

TKL keyboard that can be entirely assembled using only through hole components, including usb type-c
GNU General Public License v3.0
506 stars 107 forks source link

General USB connectivity question #16

Open dhanakane opened 3 years ago

dhanakane commented 3 years ago

When using a USB switcher to switch between devices, I observe a lag and sometimes a complete lack of connectivity. This is resolved by plugging and unplugging the USB cables. Switching always requires a replug of the cables if it is the first time a device is being switched to after booting/awaking the computer being switched to.

I observe this problem using a Discipad as well. I have tried swapping cables, but the issue does not go away.

There is also a marked "lag" detecting the device. Is there a reason for this?

I notice this issue on MacOS, but I can test with Raspbian if required. I have tried troubleshooting with dmesg to see if there are any errors, but I see none. It just looks like there is a delay before the device is recognised. If you have any tips on how to get the device to be recognised more reliably or to reduce the time to detection then that would be much appreciated.

coseyfannitutti commented 3 years ago

No, at this time I am unsure of the root cause of it being detected slowly on MacOS. This issue does not happen with Windows. When I find some time, I'll look into it a bit more. It may be related to the Raw HID enabled version of the firmware, which allows VIA compatibility. Typically pressing the reset button a few seconds after connecting is an alternative to unplugging and plugging back in. When I've got some free time, I'll see if using the original firmware without Raw HID enabled eliminates the lag issue on MacOS.

If you can beat me to it, though, you could try using firmware compiled from https://config.qmk.fm/ or by manually compiling via command line with any of the layouts besides the VIA layout, which will not have RawHID enable, and let me know if that fixes your issue.

This is most likely a firmware issue, but not one that is able to be fixed directly by me. This is likely something deep in QMK core code for V-USB devices, which is the software-only implementation of USB for microcontrollers like ATmega32A and ATmega328P, which do not have an integrated USB controller.

On Tue, Sep 29, 2020 at 4:13 AM Dhana Kaneshayogan notifications@github.com wrote:

When using a USB switcher to switch between devices, I observe a lag and sometimes a complete lack of connectivity. This is resolved by plugging and unplugging the USB cables. Switching always requires a replug of the cables if it is the first time a device is being switched to after booting/awaking the computer being switched to.

I observe this problem using a Discipad as well. I have tried swapping cables, but the issue does not go away.

There is also a marked "lag" detecting the device. Is there a reason for this?

I notice this issue on MacOS, but I can test with Raspbian if required. I have tried troubleshooting with dmesg to see if there are any errors, but I see none. It just looks like there is a delay before the device is recognised. If you have any tips on how to get the device to be recognised more reliably or to reduce the time to detection then that would be much appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/coseyfannitutti/mysterium/issues/16, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKJQCCB6RXGMRCUBAQQDCKTSIGJJLANCNFSM4R5O4PCA .

dhanakane commented 3 years ago

So, if it helps, I believe I compiled my keymap from the command line using the Makefile in QMK. I also have the same problem with the Discipline I built and occasionally the Discipad too. Is this what you mean by manually compiling, or is there something I am missing? Running through the code in the link seems to use the Makefile to compile a keymap.

The suggestion of using the reset button is a good one. I will use that. Could I understand what the Reset button is doing in this case? Is it just a simple reboot for the keyboard? If this consistently resolves the issue, then I will recut my case to incorporate a window to access the boot and reset buttons. And perhaps the 6 pin header too, unless I can flash the firmware over USB once the keyboard is in bootloader mode.