I want to connect the keyboard to INPUT-B

[hiraken]

I noticed some that I have not caught first time. The bInterval (polling rate) of your keyboard is set to 10ms. Normally the bInterval is some number power of 2. This may be causing the issue. To confirm that, please set the "Input Polling Rate" to 125Hz, test and let me know your results.

Thank you for your reply.

I followed your advice and set the "Input Polling Rate" to 125Hz for testing.
But, the results did not change and the problem was not solved.
Tests were performed on both the Owltech keyboard and the BUFFALO keyboard described earlier, but both did not change the results.

However, there was a new discovery.
It is about keyboard of "BUFFALO BSKBC16BK".
This keyboard has a "Game Mode button".
By pressing the button, Windows key and application key are disabled, and the function to perform key scan 10 times per second is attached.
And when this button was pressed to switch to Game mode, this keyboard worked correctly even when connected to INPUT-A or INPUT-B.
In addition, after switching to Game mode once and then returning to normal mode again, the behavior remained normal.
This will continue until I unplug the keyboard or turn off the Titan two.
In addition, this behavior showed the same behavior for all “Input Polling Rate” settings regardless of “Input Polling Rate”.

However, this "BUFFALO BSKBC16BK" is a cheap keyboard obtained to increase the amount of test information.
It's too poor to use it for games.
I am eager to eventually use Owltech's keyboard if possible.

As a precaution, I will attach the USB DESCRIPTOR of "BUFFALO BSKBC16BK" and the document URL.
The document is in Japanese, but the "Game Mode button" function is described in the upper right corner of the first page.


BUFFALO BSKBC16BK Document
http://manual.buffalo.jp/buf-doc/supply/bskbc16-100.pdf

BUFFALO BSKBC16BK USB DESCRIPTOR

Code: Select all

[USB DESCRIPTOR]
12 01 00 02 00 00 00 08 D5 05 4C 62 20 01 01 02 00 01 09 02 3B 00 02 01 00 A0 FA 09 04 00 00 01 03 01 01 00 09 21 11 01 00 01 22 36 00 07 05 81 03 08 00 0A 09 04 01 00 01 03 00 00 00 09 21 11 01 00 01 22 47 00 07 05 82 03 08 00 0A 
 
[STRING 1 DESCRIPTOR]
00 00 00 03 00 00 02 01 80 06 03 01 04 09 00 06 
06 03 4B 00 42 00 
 
[STRING 2 DESCRIPTOR]
00 00 00 03 00 00 02 01 80 06 03 02 04 09 00 0E 
0E 03 55 00 53 00 42 00 20 00 4B 00 42 00 
 
[INTERFACE 0 HID DESCRIPTOR]
00 00 00 03 00 00 02 01 81 06 22 00 00 00 00 36 
05 01 09 06 A1 01 05 08 19 01 29 03 15 00 25 01 75 01 95 03 91 02 95 05 91 01 05 07 19 E0 29 E7 95 08 81 02 75 08 95 01 81 01 19 00 29 91 26 FF 00 95 06 81 00 C0 
 
[INTERFACE 1 HID DESCRIPTOR]
00 00 00 03 00 00 02 01 81 06 22 00 00 01 00 47 
05 0C 09 01 A1 01 85 01 19 00 2A F0 02 15 00 26 F0 02 95 01 75 10 81 00 C0 05 01 09 80 A1 01 85 02 19 81 29 83 25 01 75 01 95 03 81 02 95 05 81 01 C0 05 01 09 06 A1 01 85 0B 05 07 19 00 29 91 95 07 75 08 81 00 C0 

I also have additional information about the symptoms of the problem I'm experiencing.
I have previously written the following to explain this phenomenon.

There will be no response or the key will remain pressed.

But, this information was not a complete description.
If you hit any other key repeatedly, other keys will occasionally react.
However, the key will remain pressed as well as the first key pressed.
At this time, keys that were determined to have been pressed before that time are finally released.
This phenomenon is not caused by the result of the “Input Polling Rate” setting change.
This phenomenon has existed since the beginning of this issue.
I'm sorry, my explanation was insufficient. I made up for it here.

[J2Kbr]

Thank you hiraken for the very detailed information your provided.

This issue definitively seems to be related with the polling rate, let me try explain.

The Input-A, Input-B and Output ports are managed by a dedicated High Speed USB controller IC. The polling rate on these ports are controlled by hardware and can only have power of 2 rates: 1ms, 2ms, 4ms, 8ms, 16ms, 32ms. If the device reports some other bInterval value, it is rounded to the closest lower power of 2. For example 10ms will be rounded to 8ms, which causes the Titan Two to poll the device faster than it is expects.

On the other hand, the PROG port is directly connected to the main micro-controller, where the polling rate is controlled by software and can be any arbitrary value, for example 10ms.

When you put your keyboard on game mode, I am mostly sure it allows faster polling rates (eg. 8ms or lower).

[hiraken]

Thank you hiraken for the very detailed information your provided.

This issue definitively seems to be related with the polling rate, let me try explain.

The Input-A, Input-B and Output ports are managed by a dedicated High Speed USB controller IC. The polling rate on these ports are controlled by hardware and can only have power of 2 rates: 1ms, 2ms, 4ms, 8ms, 16ms, 32ms. If the device reports some other bInterval value, it is rounded to the closest lower power of 2. For example 10ms will be rounded to 8ms, which causes the Titan Two to poll the device faster than it is expects.

On the other hand, the PROG port is directly connected to the main micro-controller, where the polling rate is controlled by software and can be any arbitrary value, for example 10ms.

When you put your keyboard on game mode, I am mostly sure it allows faster polling rates (eg. 8ms or lower).

Thank you for your reply.
I don't have much knowledge about USB device specifications.
But I understand the outline of your explanation.

Is the conclusion that the relationship between the High Speed USB controller IC and the keyboard Interval value is a hardware problem and cannot be solved?
If it's impossible to solve this problem, it's a disappointing result, but I endure using a keyboard with a PROG port.
Also, when purchasing a new keyboard, there are few cases where the keyboard is generally sold with "Interval value" displayed in advance. I'm hesitant to buy a new keyboard for the Titan two.

[J2Kbr]

Is the conclusion that the relationship between the High Speed USB controller IC and the keyboard Interval value is a hardware problem and cannot be solved?

We could be implementing a firmware update where, when detected a bInterval value (polling rate) not power of two, a software implemented polling system is used in place of the hardware solution.

[hiraken]

We could be implementing a firmware update where, when detected a bInterval value (polling rate) not power of two, a software implemented polling system is used in place of the hardware solution.

I see!
I was able to hear from you a very good story and have hope.
If you realize the method you have proposed, I will be relieved from the stress of unplugging and plugging in the PROG port every time I connect the Titan two to my PC.
It's a shame that my keyboard isn't processed at high speed by the High Speed ​​USB controller IC, but I'm more intolerant of stress when plugging and unplugging cables.
And I don't have enough gaming skills to experience the speed difference between hardware and software. haha

[J2Kbr]

I will try get this done on the next firmware update. Thank you for your support.