Gigabyte keyboard does not work on Teensy 3.6 host port

Status
Not open for further replies.
G

gdsports

Well-known member
My Gigabyte USB keyboard works with Due but not with Teensy 3.6. The difference is Due sends SET PROTOCOL to boot mode while keyboard.cpp does not. I added SET PROTOCOL to keyboard.cpp and now the keyboard works. I suspect the keyboard defaults to HID mode so the SET PROTOCOL forces the keyboard to boot mode. Other keyboards work maybe because they default to boot mode.

Attached is a Beagle USB capture showing Due, T36, and T36 with patch. The first enumeration is for Due running the KeyboardController example. The second is for Teensy 3.6 which fails. The third is for Teensy 3.6 with patch. The Mouse example is used on the T36.

Code change is just 3 lines.

Code: 
--- a/USBHost_t36.h
+++ b/USBHost_t36.h
@@ -731,6 +731,7 @@ private:
        void (*keyReleasedFunction)(int unicode);
        Pipe_t *datapipe;
        setup_t setup;
+       setup_t protocol;
        uint8_t report[8];
        uint16_t keyCode;
        uint8_t modifiers;
diff --git a/keyboard.cpp b/keyboard.cpp
index bfc127c..ba2bf0d 100644
--- a/keyboard.cpp
+++ b/keyboard.cpp
@@ -138,6 +138,8 @@ bool KeyboardController::claim(Device_t *dev, int type, cons
        datapipe = new_Pipe(dev, 3, endpoint, 1, 8, interval);
        datapipe->callback_function = callback;
        queue_Data_Transfer(datapipe, report, 8, this);
+       mk_setup(protocol, 0x21, 11, 0, 0, 0); // 11=SET_PROTOCOL
+       queue_Control_Transfer(dev, &protocol, NULL, this);
        mk_setup(setup, 0x21, 10, 0, 0, 0); // 10=SET_IDLE
        queue_Control_Transfer(dev, &setup, NULL, this);
        return true;
 

Attachments

  • gigakbd.zip
    15.7 KB · Views: 78
The problem is this keyboard implements N key rollover (NKRO) where N = 64.

The Gigabyte mechanical keyboard works on a Ubuntu Linux 18.04 system so I captured USB HID reports. The keyboard sends a HID report where the first byte is a bitmap of the modifier keys as in the boot mode HID report. But the next 14 bytes are a bitmap for 112 keys. When I lean my forearm and hand on the keyboard, lots of bits light up in the report. The bit offset is the Usage ID from Table 12 of USB HID Usage Tables document.

It would be nice if this keyboard had a switch to force boot mode.

Adding a constructor option to force boot mode would help for oddball keyboards like this. There is no reason to hardcode boot mode since it prevents the use of consumer keys. Supporting NKRO in an embedded system is not worth the trouble.
 
Maybe this can be supported by a driver using the generic hid parser?

Can you give me any more info about this keyboard? Specifically, if I was going to buy one for testing, how would I be sure to get this exact model?
 
I am tempted to pick one up, to try out, both because of trying to make sure it works with the code.

But also wondering how well it would work for me as my main keyboard/mouse... Maybe something like: https://www.amazon.com/Gigabyte-Mechanical-GK-FORCE-K83-RED/dp/B07BHK6VYW?th=1

I am looking for keyboard that works well for someone who had RSI hand issues... Currently using a Microsoft Wave... keys are easy on hands, BUT after a few years of usage, the other keys, still don't work naturally for me, I am still always hitting the wrong keys (delete, insert, arrow, home, end...) Logitech one was more natural but the keys did not feel right... Problem with this size keyboard is it won't fit in keyboard 21" drawer and leave any room for mouse...

Question is, will the one I show in the link show the issue?
 
I'm using the Gigabyte model GK-Force K83 with blue switches (clicky audible feedback). There is a K83 with red switches (no click) but I assume it works the same way over USB. Other models with LED backlight may have the same NKRO but I am not sure.

A few odd things. The Scroll Lock LED has been replaced with the Win Lock LED. The Right GUI key is the Win Lock key which disables the Left GUI key. This is a gamer keyboard (but I am not) so it prevents accidental pressing of the GUI key during a game. The Right context menu key has been replaced with a Fn key. These changes do not bother me but YMMV. I was just looking for a less than $50 clicky mechanical keyboard so this is fine for me.

https://www.amazon.com/dp/B01BMJ0Y76

I also found in an old HP laptop this keyboard fails in BIOS mode. The old BIOS fumbles when sending the SET PROTOCOL request so the K83 never switches to boot mode!
 
The keyboard arrived...

I made a similar change as @gdsports did, except I did it in similar way to some other device controllers. That is I did not create another data structure, but instead setup to do the set_protocol mode first and then in the ::callback function detected that the last setup data was that and then do set_idle call...

I tried it on the Gigabyte keyboard and it now acts similar to other keyboards. I then did a quick check with a dell keyboard and a Logitech mouse/keyboard controller to verify that they still worked.

Issued Pull Request: https://github.com/PaulStoffregen/USBHost_t36/pull/21

Also decided that while I like key placements on this board... I don't think it will work for me...
 
Thanks KurtE. I tried the patch on my 4 keyboards. All work fine including the Gigabyte K83. I thought the multimedia keys would not work in boot mode but they work fine. I did not know it is necessary to wait for setup transfers to finish before starting the next one so I will keep that in mind. I was also thinking forcing keyboard boot should be optional but I cannot find any instance where it does not work.
 
Status
Not open for further replies.
Back
Top