QMK Toolbox does not launch if an unsupported device (XD002) is also connected about qmk_toolbox HOT 14 CLOSED

Sorry, I should have been more clear in the scenario.

I'm not expecting the application to launch automatically once a device is connected. I was referring to a scenario where I had a supported device (KBDfans KBD67) AND XD002 attached, where QMK Toolbox would not open after double clicking on the executable.

from qmk_toolbox.

@BramVer That shouldn't matter. As long as the bootloader is one of the supported type, and identified, it doesn't matter. You can flash other hex files too (eg, you could flash an arduino sketch, if you have the actual hex file from it)

@chrisnylen is the XD002 in bootloader mode when this happens? Or is it "just connected"?

Also, do you know what firmware it is using?

from qmk_toolbox.

Well I'm not sure what you expect it to do honestly.
QMK Toolbox doesn't launch automatically when a compatible device is connected for as far as I know, imagine having it popup automatically each time your device is connected.

On top of that, the XD002 isn't supported by QMK Firmware,
search through the list of QMK supported keyboards here.

from qmk_toolbox.

@drashna The XD002 was not in bootloader mode, just attached to the PC (I use it for volume control) at the same time as my KBD67. The XD002 doesn't use QMK firmware, and the manual on their GitHub repo says: The hardware of XD002 is developed by Xiudi and the software is developed by Zian1. The final interpretation of firmware and software belongs to Zian1

from qmk_toolbox.

@chrisnylen the last couple of releases (latest as of writing is 0.0.14) have hopefully fixed a bunch of crashes. Are you able to test this again and tell us if there's still an issue?

from qmk_toolbox.

Same here. If I have my maypad connected. qmk toolbox won't open. It uses a pro micro
https://keyhive.xyz/shop/may-pad

from qmk_toolbox.

This is still an issue. Toolbox doesn't open when the XD002 is connected to the PC.
I can see the process for a second in the taskmanager before it disappears again.

I grabbed the usb descriptors from the XD002 in case that might be helpful for someone to debug this.
https://pastebin.com/raw/8F8MiPmk

from qmk_toolbox.

The source code of the XD002 is available:
https://drop.com/buy/xd002-hot-swappable-2-keys-aluminum-macro-pad/talk/2180635

I found something interesting - it's got some kind of "raw HID"-like interface, presumably for configuration with the provided app, but it's using the HID vendor defined usage page 0xFF31 and usage 0x74:
https://github.com/panhao4812/Attiny85_vusb_pad_test/blob/1afa45509fde17994a012acdf6cd7e1fa72b7848/Attiny85_Test3/usbdrv/usbdrv.c#L40-L58
The Toolbox looks for any HID interfaces on all devices with this usage pair, but expects it to be emitting console/debug messages. This is something of a defacto standard originating with PJRC's hid_listen. QMK's own Raw HID feature uses 0xFF60/0x61 instead.

Evidently something about the descriptors that the XD002 is declaring is tripping the Toolbox (or equally likely, HidLibrary) up, but the fact it's using the "wrong" usage pair makes me wonder if we should bother fixing this at all. I'm not 100% sure this is where the problem lies, but the easiest thing to do would probably be to add another predicate to GetListableDevices() making sure the VID and PID are not that of the XD002, but perhaps there are other devices out there which similarly crash the Toolbox.

from qmk_toolbox.

@elmo-space Unfortunately, the utility that you have used did not dump the most interesting piece of information — the HID report descriptors. However, the device that you had advertised 3 interfaces, so the firmware definitely was different from the source code linked in the next comment — that one had only 2 interfaces. Do you still have the device with that firmware?

One suspicious thing is that the third interface has only a single OUT endpoint; this is probably because V-USB does not support having more than 2 IN endpoints on the device (unless patched, and the patch is not compatible with some hardware configs), but technically this violates the HID specification (the Interrupt In endpoint is marked as required, only the Interrupt Out endpoint is optional). It is very likely that the HID descriptor (which was not dumped) did not declare any Input reports, so the InputReportByteLength calculated by Windows was 0, which was probably hitting a bug described in this comment.

I found an older version of the XD002 code, which actually had just a single Output report defined in the HID descriptor; maybe your XD002 had that firmware version installed, which would definitely cause the problem. However, when I copied the USB descriptor from a newer firmware version (with 8 byte Input and Output reports) into an atmega32u4 testing project, I could not reproduce the toolbox crash.

from qmk_toolbox.

@sigprof it's definitely the code I linked. The V-USB "endpoint 3" is set to 2 here: https://github.com/panhao4812/Attiny85_vusb_pad_test/blob/1afa45509fde17994a012acdf6cd7e1fa72b7848/Attiny85_Test3/usbdrv/usbconfig.h#L103
The OUT endpoint 3 is defined here:
https://github.com/panhao4812/Attiny85_vusb_pad_test/blob/1afa45509fde17994a012acdf6cd7e1fa72b7848/Attiny85_Test3/usbdrv/usbdrv.c#L237
And is handled elsewhere.

from qmk_toolbox.

@fauxpark The important difference is that the raw interface has one IN and one OUT endpoint (comments are wrong): https://github.com/panhao4812/Attiny85_vusb_pad_test/blob/1afa45509fde17994a012acdf6cd7e1fa72b7848/Attiny85_Test3/usbdrv/usbdrv.c#L209-L240

And the descriptor dump in pastebin shows that the problematic device had 3 interfaces instead of 2, and the last of those interfaces did not have an IN endpoint.

from qmk_toolbox.

Ah, right.

As for this:

However, when I copied the USB descriptor from a newer firmware version (with 8 byte Input and Output reports) into an atmega32u4 testing project, I could not reproduce the toolbox crash.

I think that may have been solved by:
https://github.com/qmk/qmk_toolbox/pull/186/files#diff-49b767a1ddefaf2cb398264cd3b9a695R441

from qmk_toolbox.

@sigprof unfortunately I don't have the original firmware on the device anymore. I flashed QMK on it (now that it is supported).

from qmk_toolbox.

I also have a CD002, in my case from drop.com and it causes the same exact problem: #147 (comment)

from qmk_toolbox.