Pressing Seven Keys on a 6-KRO keyboard

[Findecanor]

I know, it is possible to do n-key rollover over USB. That is not what this thread is about.

I am intrigued by how different keyboards with 6-key rollover over USB behave when they have hit the limit of 6 pressed non-modifier and a seventh key is pressed.
There seems to be two ways of behaving:

* Ducky G2 Pro: Stops accepting more non-modifier keys after six. New presses are blocked. (Let's call this behaviour "Block")

* Topre Realforce 105UB: Gives up the oldest pressed key to give room for the next new press. (Let's call this behaviour "FIFO" for first-in-first-out)

What do you think is the preferred behaviour? "Block" like Ducky or "FIFO" like Topre?

Microsoft has a web app for testing rollover and ghosting here if you are interested. Click the app and see what happens when you press down six non-modifier keys and then one more.

By the way, I also tested a Kinesis Advantage. It has a bug: when the seventh key is pressed, it empties the array and reports the next pressed key only after about a second if it is still pressed. If the array is full and you press a key very quickly, all keys are only automatically released - and the seventh press is not reported.

[FoxWolf1]

My Das has the "Block" behavior. I should also add that if you press more than six keys quickly and simultaneously, rather than adding keys one at a time, you can sometimes have fewer than 6 keys (or even 0) register.

I think I might prefer "FIFO", based on the alarming feeling of hitting the 7th key and getting no response at all with the "Block" behavior (I'm probably the one person in the entire universe who actually runs into the 6KRO limit when gaming...I even hit it sometimes in games where one hand is on the mouse, since I do not limit myself to 1 key per finger).

[Oobly]

FIFO is better. It takes a bit more work to program, but it's nicer to actually have the new keys register. I do prefer the old PS/2 protocol of events, though, rather than the USB keyboard version with "states".

@FoxWolf1: Wow, I've never hit the limit, but I guess I just don't play the kinds of games you do I've hit the limit of my Microsoft X6 "designed for gaming" board and a Model M, though, but those are matrix limits, not protocol limits.

[Nai_Calus]

My Monoprice board does blocking. I think I'd actually prefer the other way, though of course NKRO would be preferable.

[Oobly]

My GoN NerD60 blocks

[sidel]

My Poker 2 blocks.  In practicality this will never make a difference to me, but if I was to be given the choice I'd rather the behavior be FIFO.

[metalliqaz]

This is a very interesting question and I ran into it when writing my firmware.  I started a thread on the same topic at some point.

Initially I programmed it "FIFO" like your Realforce, because I figured that any new input would be the user's highest priority.  It queued up the keys and when you let go of keys, it would go back to the previous keys in order.  However, this causes a bit of a problem.  When a user lets go of the 7th key, the 1st key is re-pressed automatically.  So an action is put into the system that the user never made.  I considered that to be a bug.

I then made it block by default, and made the behavior configurable so the user could choose their favorite.  Then I made it NKRO and none of it mattered anymore.

[Oobly]

This is a very interesting question and I ran into it when writing my firmware.  I started a thread on the same topic at some point.

Initially I programmed it "FIFO" like your Realforce, because I figured that any new input would be the user's highest priority.  It queued up the keys and when you let go of keys, it would go back to the previous keys in order.  However, this causes a bit of a problem.  When a user lets go of the 7th key, the 1st key is re-pressed automatically.  So an action is put into the system that the user never made.  I considered that to be a bug.

I then made it block by default, and made the behavior configurable so the user could choose their favorite.  Then I made it NKRO and none of it mattered anymore.

I would implement it that it removes the 1st key from the packet when the 7th is pressed and simply handles the releases as normal without re-actuating any characters.

[Findecanor]

Yeah, the reason I am asking is because I am revisiting firmware that I have written and am trying to reason what the best choice would be. I have been using the FIFO method, because I think it would work best while typing normally.
I think that text editing would actually work quite well even with only 1KRO for the alphanumeric keys, as long as the next key replaces the last.

However, when gaming with the WASD keys you would not want any of those to be "breaked" by the firmware if the actual key is not released.

I have been toying with the idea of having codes for different directions be mutually exclusive to improve rollover performance in games. For example: left-arrow and right-arrow could be mutually exclusive because they don't make sense together. Shifting from one of those to the other would therefore not break any other key.
Similarly you could have relationships W<->S and A<->D, but that could be disastrous for gamers who use ESDF instead of WASD.

When a user lets go of the 7th key, the 1st key is re-pressed automatically.

That is not a problem if you keep matrix-state and USB-state separate.

By the way, the USB HID specification mandates the Block method, but with a special type of report sent on the seventh key press: The array should be filled with a code named "ErrorRollOver".
I suppose that the bug in Kinesis' firmware is caused by not using separate buffers for the different types of reports.

[Oobly]

Yeah, the reason I am asking is because I am revisiting firmware that I have written and am trying to reason what the best choice would be. I have been using the FIFO method, because I think it would work best while typing normally.
I think that text editing would actually work quite well even with only 1KRO for the alphanumeric keys, as long as the next key replaces the last.

However, when gaming with the WASD keys you would not want any of those to be "breaked" by the firmware if the actual key is not released.

I have been toying with the idea of having codes for different directions be mutually exclusive to improve rollover performance in games. For example: left-arrow and right-arrow could be mutually exclusive because they don't make sense together. Shifting from one of those to the other would therefore not break any other key.
Similarly you could have relationships W<->S and A<->D, but that could be disastrous for gamers who use ESDF instead of WASD.

When a user lets go of the 7th key, the 1st key is re-pressed automatically.

That is not a problem if you keep matrix-state and USB-state separate.

Actually, the USB HID specification mandates the Block method, but with a special type of report sent on the seventh key press: The array should be filled with a code named "ErrorRollOver".
I suppose that the bug in Kinesis' firmware is caused by not using separate buffers for the different types of reports.

I guess the question is do the games that require 7+KRO use WASD? Since I see gaming as the only scenario this is needed, I think implementing the FIFO the way you are is fine, although I like the idea of "exclusive" combinations. One thing to keep in mind is if you want to connect the keyboard to a non-PC device, such as a phone, they may be expecting HID-compliant implementation.

[metalliqaz]

Yeah, the reason I am asking is because I am revisiting firmware that I have written and am trying to reason what the best choice would be. I have been using the FIFO method, because I think it would work best while typing normally.
I think that text editing would actually work quite well even with only 1KRO for the alphanumeric keys, as long as the next key replaces the last.

However, when gaming with the WASD keys you would not want any of those to be "breaked" by the firmware if the actual key is not released.

I have been toying with the idea of having codes for different directions be mutually exclusive to improve rollover performance in games. For example: left-arrow and right-arrow could be mutually exclusive because they don't make sense together. Shifting from one of those to the other would therefore not break any other key.
Similarly you could have relationships W<->S and A<->D, but that could be disastrous for gamers who use ESDF instead of WASD.

When a user lets go of the 7th key, the 1st key is re-pressed automatically.

That is not a problem if you keep matrix-state and USB-state separate.

Actually, the USB HID specification mandates the Block method, but with a special type of report sent on the seventh key press: The array should be filled with a code named "ErrorRollOver".
I suppose that the bug in Kinesis' firmware is caused by not using separate buffers for the different types of reports.

I guess the question is do the games that require 7+KRO use WASD? Since I see gaming as the only scenario this is needed, I think implementing the FIFO the way you are is fine, although I like the idea of "exclusive" combinations. One thing to keep in mind is if you want to connect the keyboard to a non-PC device, such as a phone, they may be expecting HID-compliant implementation.

Real NKRO iS HID compliant.  It just isn't a 'boot'  keyboard

[Oobly]

Yeah, the reason I am asking is because I am revisiting firmware that I have written and am trying to reason what the best choice would be. I have been using the FIFO method, because I think it would work best while typing normally.
I think that text editing would actually work quite well even with only 1KRO for the alphanumeric keys, as long as the next key replaces the last.

However, when gaming with the WASD keys you would not want any of those to be "breaked" by the firmware if the actual key is not released.

I have been toying with the idea of having codes for different directions be mutually exclusive to improve rollover performance in games. For example: left-arrow and right-arrow could be mutually exclusive because they don't make sense together. Shifting from one of those to the other would therefore not break any other key.
Similarly you could have relationships W<->S and A<->D, but that could be disastrous for gamers who use ESDF instead of WASD.

When a user lets go of the 7th key, the 1st key is re-pressed automatically.

That is not a problem if you keep matrix-state and USB-state separate.

Actually, the USB HID specification mandates the Block method, but with a special type of report sent on the seventh key press: The array should be filled with a code named "ErrorRollOver".
I suppose that the bug in Kinesis' firmware is caused by not using separate buffers for the different types of reports.

I guess the question is do the games that require 7+KRO use WASD? Since I see gaming as the only scenario this is needed, I think implementing the FIFO the way you are is fine, although I like the idea of "exclusive" combinations. One thing to keep in mind is if you want to connect the keyboard to a non-PC device, such as a phone, they may be expecting HID-compliant implementation.

Real NKRO iS HID compliant.  It just isn't a 'boot'  keyboard

That's something different entirely. Soarer has made a nice firmware with full HID-compliant NKRO that even includes a boot protocol packet so it works in both "modes" at the same time

Here we're discussing supporting extra keypresses by dropping old ones.

[Daniel Beardsmore]

Filco FKBN105M/UKB — blocking
Cherry G84-4135PTMDE/00 — blocking
Matias Tactile Pro 3 (Mac) — blocking

Interestingly, the G84 clearly demonstrates the real meaning of "2RKO". "2KRO" does not mean "two keys maximum" but rather "two key guarantee". I can get a full six keys to register at once with the G84-4135, despite it not having diodes. The controller knows what combinations are valid and which are not; there are other sets of keys where I can only get two to register at once.

Also, Microsoft use "ghosting" to mean missing keypresses (the result of deliberate blocking), while I've always used it to mean extraneous keypresses (which you get in some keyboards such as the OK-100M and BTC 5139/5149).

For me, this question is academic: if you're in a situation where the keyboard is being given excessive input, it's time to just buy an NKRO product. GIGO and all that.

[Daniel Beardsmore]

Interestingly, my Blue Cube seems to cut out at five keys. Having tried with two separate keyboards (KPT KPT-84 and Tulip ATK 03.01.44), I can't get any more than five keys to register concurrently on either. I also tried my Nan Tan KB-6251EA with the Blue Cube, but the keyboard just restarts endlessly.

[mouse.the.lucky.dog]

My keyboard just blows up.

[Findecanor]

I have heard before that the Blue Cube uses an unusual report format, but I have not (yet) checked its report descriptor.

[intelli78]

My keyboard just blows up.

That must get messy after the 8th or 9th time.

[Nai_Calus]

For the record, the WASD Code does FIFO. When I hit a seventh key it releases the first pressed of the initial 6. (I should plug it into my PS/2 port but I don't have a USB to PS/2 adapter and I'm too lazy to get one) (Actually it does much better reporting all around than the Monoprice, hitting both shifts and typing just gets capital letters, doing that on my Monoprice ends up with a lot of non-registering letters.)

[Findecanor]

I found an interesting bit in an old note. Apparently, the Linux kernel's USB keyboard driver in versions before 2.4.4 did not work correctly if the keyboard reported ErrorRollOver.
The kernel handled proper reporting of 6+1 keys pressed as if all keys had been released ...

[metalliqaz]

I found an interesting bit in an old note. Apparently, the Linux kernel's USB keyboard driver in versions before 2.4.4 did not work correctly if the keyboard reported ErrorRollOver.
The kernel handled proper reporting of 6+1 keys pressed as if all keys had been released ...

Yeah, that's unfortunate but not surprising.  The spec says that when you set ErrorRollover, you also don't send any scancodes.

[Lu_e]

Why does my PC beep (through speakers) when I push like this on PS2 ? [CM QFR / Win8.1 pro]



Is it not unlimited? I am not pressing any modifiers, just alphanumerics (using my phone )

Also some of the keys stay green when I let off? and I have to press each one again to get them back to white?

This is with nothing being pressed after letting off from the above;


Hell if I press all four arrow keys I can get it to beep every time? I hate windows sound effects! lol