Error: LIBUSB_TRANSFER_NO_DEVICE

[Aszarsha]

Hi,

Tried your program, but this is the output that I get:

Found device in normal mode on bus 7, device 8.
Switching to program mode.
Error: LIBUSB_TRANSFER_NO_DEVICE

After that, the keyboard becomes unresponsive (as if disconnected) and I have to unplug and replug it.
Thankfully it continues to work after I plug it back. ^^" Maybe the driver doesn't recognize the keyboard after what the program does (although it definitely does not flash the keyboard since the layout haven't changed).

I even tried to change the TAG+="uaccess" into MODE="0666" in the udev rule just in case, to no avail...

Do you have any idea?

EDIT: Forgot this info: running Arch Linux fully updated.

[Aszarsha]

Ok... I switched to windows to try with their (teck company) software and it turns out that my keyboard is one of those that emit "DFU_Reset_to_ISP fail" in their software (see https://www.trulyergonomic.com/store/troubleshooting--truly-ergonomic-mechanical-keyboard#Reset) when trying to update (at the switch to programmable mode).
I had to manual reset the keyboard by opening it.
And I tried: I have to manually reset every time that I want to patch. Hu...

Anyway, when this error occurs you might want to refer to the web page that I mentioned, so that user that don't have a windows box can still find out what's going on, manually reset their keyboard, and hopefully update their firmware with this patcher.

Cheers! :)

[yurikhan]

@Aszarsha You’re not forgetting to set the DIP switch 5 to the position that allows reprogramming before trying to use any firmware update tools, are you?

[Aszarsha]

@yurikhan Haha, no no, I didn't. ;) I had (and still have... :() so many key chattering issues that I was willing to open the damn thing just to patch with a 20ms debouncing (and make a few adjustments to the layout that I had postponed for a long time).

Ho, and since you wrote the v3 firmware, do you mind if I ask what's the difference between v3 and the v4.00 on the website ? :)

[m-ou-se]

@Aszarsha After the tool reports 'Switching to program mode.', the device should disconnect and reconnect using a different USB ID, but apparently it doesn't reconnect. (That's also what the "DFU_Reset_to_ISP fail"-error means.) Can you check dmesg to see if it does anything at all after it disconnects? Or check lsusb afterwards to see if it reconnected using a (unknown?) USB ID? Does it work if you run the tool again a few seconds after it fails?

[yurikhan]

@Aszarsha I did not actually write any of them; the majority of the code is still by Truly Ergonomic’s unnamed and unresponsive subcontractor.

I don’t track the version numbers very closely. My involvement with the TECK firmware started before v3; when v3 came out, I re-applied my changes on v3 and published on GitHub. Then Truly Ergonomic contacted me and I did some additional changes on their request. The changes I made include:

• Streamlining the keycode matrix so that Num Lock and Fn layers are more easily configurable
• Adding a web-based configurator
• Changing the debouncing algorithm
• For the Model 22x release, changing the DIP switch assignments to preload the keyboard with more layouts

I believe the last one is the only actual difference between the v3 and v4 branches, and it is only beneficial for users who will not bother customizing the layout. v3 has two layouts (normally designated as PC and Mac, but fully reprogrammable) while v4 has 16 (PC and Mac variants for each of 8 national layouts, fixed).

(Apologies to @m-ou-se for off-topic.)

[Aszarsha]

@m-ou-se The problem is that I have only this one keyboard available right now, and in order to do what you ask I would need to be able to do some input. Which I can't anymore once I try to patch, probably for the reason you said.
I'll try to find another keyboard soon, but if I don't come back to you in maybe two or three weeks feel free to ping me then. :)

@yurikhan Thank you for the info, and for your work!
Couldn't we, in some way, have access to the firmware source? I'd be willing to work on it (if opened) but I definitely don't want to work on reverse-engineered assembly.

[yurikhan]

I would need to be able to do some input

You could copy and paste dmesg using the mouse, or run sleep 60; dmesg in a separate terminal beforehand. Alternatively, you could re-plug the keyboard; it would generate some dmesg noise when unplugged and re-plugged, but it would be pretty straightforward to identify that.

Couldn't we, in some way, have access to the firmware source?

It’s pretty ridiculous; according to Truly Ergonomic, the contractor guys who originally wrote the firmware refuse to hand over the source.

So I have come to the conclusion that the easiest way to access the firmware source is to write a new one, and I unfortunately haven’t gotten around to doing that yet.

Alternatively, Somebody™ could try porting any of the Ergodox firmwares to TECK. Less writing, more digging in somebody else’s code; not sure which is more complex.

[Aszarsha]

@m-ou-se So I did some testing using sleep 10 ; <cmd> and the funny thing is that the keyboard actually reconnect in firmware update mode... So I don't know, really. Here are the traces:

lsusb before:

Bus 006 Device 013: ID 0e6a:030c Megawin Technology Co., Ltd Truly Ergonomic Computer Keyboard

after:

Bus 006 Device 014: ID 0e6a:030b Megawin Technology Co., Ltd Truly Ergonomic Computer Keyboard (Device Firmware Update mode)

new kernel buffer messages after the command:

[40883.665802] usb 6-5: USB disconnect, device number 11
[40884.394155] usb 6-5: new full-speed USB device number 12 using ohci-pci
[40884.553903] hid-generic 0003:0E6A:030B.0018: No inputs registered, leaving
[40884.554152] hid-generic 0003:0E6A:030B.0018: hidraw0: USB HID v1.00 Device [HID 0e6a:030b] on usb-0000:00:12.0-5/input0

And whenever I disconnect and reconnect the keyboard I get the following kern msgs (modulo device numbers and such):

[40996.997718] usb 6-5: USB disconnect, device number 14
[41000.576847] usb 6-5: new full-speed USB device number 15 using ohci-pci
[41000.741565] input: TrulyErgonomic.com Truly Ergonomic Computer Keyboard as /devices/pci0000:00/0000:00:12.0/usb6/6-5/6-5:1.0/0003:0E6A:030C.001C/input/input28
[41000.793881] hid-generic 0003:0E6A:030C.001C: input,hidraw0: USB HID v1.11 Keyboard [TrulyErgonomic.com Truly Ergonomic Computer Keyboard] on usb-0000:00:12.0-5/input0
[41000.799619] input: TrulyErgonomic.com Truly Ergonomic Computer Keyboard as /devices/pci0000:00/0000:00:12.0/usb6/6-5/6-5:1.1/0003:0E6A:030C.001D/input/input29
[41000.850551] hid-generic 0003:0E6A:030C.001D: input,hidraw1: USB HID v1.11 Device [TrulyErgonomic.com Truly Ergonomic Computer Keyboard] on usb-0000:00:12.0-5/input1

It seems recognized as both an USB Keyboard and an USB Device. Is that expected?

@yurikhan Do we know which controller the keyboards use?

[m-ou-se]

@Aszarsha Looks like the time the tool waits for the keyboard to reconnect is simply too low. In this tool, it's set to one second, and it doesn't retry. I should probably change that.

Can you try running the tool again after a few seconds? (something like: <cmd>; sleep 5; <cmd>) Alternatively, you could try the gui tool (https://github.com/m-ou-se/tek), which does retry a couple of times before giving up.

[yurikhan]

It seems recognized as both an USB Keyboard and an USB Device. Is that expected?

The first endpoint is a garden-variety HID keyboard, Boot protocol, 6KRO + modifiers. The second endpoint reports media and application keys, 1KRO only.

Do we know which controller the keyboards use?

We do. It’s a Megawin MG84FL54BD. Basically a variant of 8051 plus a USB stack implementation exposed to the controller as a bunch of special function registers. The SDCC compiler can target it just fine.