deskthority

my cherry g80-3000 seems to have failed, when pressing certain combinations like right shift + e + c it triggers a phantom press of left control, I have replicated this on multiple PCs, it does work fine otherwise. My question is, do you think this is the PCB gone bad? is this repairable/replaceable? I did use it with the PS2 adapter before but now I dont have access to any PC with that connector, that's the only thing that has changed since I noticed the problems. It feels like a shame to throw away the keyboard just for that but I don't know what else to do.

First off, throwing it is not a good idea, a bit of parts on that boards are still usable after the keyboard itself broke...

Then, well ... I don't really know, is it really annoying or is it just bothering you ?

The fact that the keyboard hasn't NKRO makes me wonder if this isn't it ?

it's very annoying because the spurious ctrl presses trigger random things like ctrl+o opens the open dialog and things like that while typeying. The problem is not that keys are not registered but that the ctrl key is assumed to have been pressed when it wasn't. I'm thinking maybe a diode broke when I cleaned the keyboard a few months back, but I don't know enough about electronics to diagnose or fix it. I also changed PCs at work so I assumed that was the cause all this time until I reproduced it at home, but I don't have the old PC I used to use to replicate it there using the PS2 converter.

ilcavero wrote: ↑it's very annoying because the spurious ctrl presses trigger random things like ctrl+o opens the open dialog and things like that while typeying. The problem is not that keys are not registered but that the ctrl key is assumed to have been pressed when it wasn't. I'm thinking maybe a diode broke when I cleaned the keyboard a few months back, but I don't know enough about electronics to diagnose or fix it.

hm well, it can have broken down but that'd be weird because they usually are really sturdy boards. You should maybe post a pic of the diode you think you broke ? Are you sure that your 3000 has diodes ?

It sounds like a 2kro problem, a g80-3000 normally has no diodes so this is likely

Do you have multiple PS/2 to USB converters?

@Darkshado the converters was actually PS/2 to USB, I used it until a few months ago, I don't use any kind of converter now, just plain USB

hansichen wrote: ↑It sounds like a 2kro problem, a g80-3000 normally has no diodes so this is likely

Is there something I could do? I doubt that's the behaviour out of the box, even without using the right shift I often end up triggering weird shortcuts with the space bar

Had a problem some years ago with the Ctrl key sometimes triggering combos I had definitely not pressed, I blew some canned air into the switch and the problem disappeared.
Perhaps worth a try in your case.

Being extremely simple and minimalistic construction G80s are ones of the easiest keyboards to fix. Just clean it up, dust it off, and if necessary open some switches (no desoldering required) that cause problems and dust off their insides. It's basically just a simple matrix and dumb PS2 (or optionally PS2/USB) controller - very little to go wrong here.

So I ordered a new G80 and was able to replicate all the problems in the new one as well, how did I use this keyboard everyday for 6 years without noticing that it has terrible ghosting? I have no idea. just typiying "tro" very fast as in electronics causes a ghost control_L press that makes that o become ctrl+o and opens an open dialog, very frustrating. I'm guessing that the PS/2 adapter that I no longer use somehow changed things in a way that hid this problem. I will return the new keyboard and buy another one with decent anti-ghosting.

I have a G80-3000LQCDE-2/01 (German). I'm surprised at the /01 revision (?) code considering that it's only a few years old (bought new from a reseller in 2012). I'm also assuming that, being in Ireland, your keyboard is ISO, but this may not be the case.

I've just connected it up and spammed t+r+o and shift+e+c (both your sequences and mashing all keys at once), and Switch Hitter is not showing any trouble (apart from 7 ms of chatter on O, just the once). Ghosting is nothing to do with speed. Ghosting is to do with circuit pathways. I've tried every additive combination of the T, R and O keys, and none of them ghost. Holding any of the three and mashing the other two does not cause a fault either. It's conceivable that the controller only blocks properly when it sees t, then t+r, then t+r+{other keys}, and that seeing t then t+{other keys} gets past the ghosting detection somehow, but I'm not able to reproduce this.

I guess step 1 is to verify what Switch Hitter is seeing coming out of the keyboard itself. I get spurious ctrl keypresses in JujuEdit on my work PC (and so far as I can tell, largely if not exclusively in JujuEdit) that seem to be a software fault, and lately I'm getting plagued with stuck modifier keys on that computer, but I don't think any of this is the keyboard. Something on my PC is not happy.


Years ago, I used a Packard Bell 486 PC that was shipped with a BTC 5149 keyboard. Back then, it was still normal for people to share a keyboard for multiplayer games. We noticed in Tyrian Destruct that if the right-hand player used the primary set of keys, then a certain action would cause the left-hand player to shoot unexpectedly. This was resolved by using the secondary set of keys. I had no idea what was going on.

A few years after that, Lotus III unexpectedly developed a fault, where in two-player mode, one player's car would simply stop and refuse to move. Again, I had no clue. Due to many changes to the keyboard assignments of the game over the years, we must have arrived at an arrangement that was not compatible with this keyboard.

The latter problem seems to be blocking. The former problem, however, seems to be a classic example of ghosting. After Chyros expressed concern about the claim on the wiki that this model of keyboard exhibited ghosting, I retrieved it and tested it, and I cannot make it ghost. I wasn't prepared to set up the 486 PC and try to play against myself to verify that it ghosts in Destruct, but it does seem to have some arrangement of keys where it will ghost. (Since it has domes over a PCB, it could have NKRO if they wanted!)

Daniel, I tested it under windows with Switch Hitter and as it happened to you, it doesn't report any spurious key presses. I didn't mention it before but I had tested it under linux using xev and under osx using karabiner elements event viewer. The tester on https://www.microsoft.com/appliedscienc ... ained.mspx gave the same results (no ctrl_L on windows and spurious ctrl_L on linux/osx). I had used it on linux exclusively in the past back when it had the ps/2 adapter, I'll try to find a desktop PC with PS/2 to try it again under those conditions. Is your work PC windows?

I tested the G80-3000 in Windows 7, but I use Windows 10 normally, where JujuEdit gets those spurious ctrl keystrokes. I do have access to a Linux laptop that I could also test with (assuming it still works), but only in USB.

So, it works in Windows over USB, and breaks in macOS and Linux in USB?

And if you hold each of t, r and o and then (in sequence or together) add the remaining two keys, you don't see the problem? There is some sort of speed threshold required to trigger the fault?

yes, over usb press t+r+o simultaneously, what I meant about typeying fast was that I have no reason to press that combination, it's just that if I type fast enough those keys are all down together at some point

Someone suggests that the 104/105-key G80-3000 matrix is basically the Model M matrix with an extra column, and the Model M matrix should not ghost in that manner. Looking at someone's G80-3000 matrix analysis, it doesn't seem like these keys should ghost either, although it's hard to tell:

https://geekhack.org/index.php?topic=33370.0

LCtrl is on cyan while R is green and magenta, T is magenta and something, and O is green and green.

Assuming this is all correct, then T+R+O cannot produce LCtrl. (It would be nice to have this data confirmed. Someone did have spurious keystrokes on a keyboard, and the offending key was right where it should be in the matrix to get that kind of error if the controller were to generate spurious data.)

I don't know how low-level these various Linux, macOS and Windows tools are, since it seems that the keyboard is actually behaving differently depending on its host OS. You'd need to ask a protocol expert whether there's any way to initialise an HID device sufficiently differently that it could introduce this kind of bug. The modifier keys are separate flags in a bitfield in the report, and it's as though the keyboard is spuriously adding a bit to the modifier bitfield under certain conditions. It would be a different matter if the ghost keystroke were an ordinary key, but it happens to be something that is treated specially by USB, which is curious because you never saw this under PS/2.

So I went digging a bit more about the usb HID protocol, set up usbmon on my laptop and played around with the hex dump, what I have discovered is that when I press enough keys to "overload" the keyboard it outputs some bogus data "01010101 01010101", this could happen with just 3 keys as in t+r+o or with more keys (I had hard time finding a combination of 6 keys, the max supporte by usb, that behaved correctly but I did find some), now if you look at that data the first 2 digits are "01" and they usually represent the left control modifier (left shift would be 02, right control 10, etc) the second pair of digits are supposedly reserved and are usually 00 but somehow the keyboard sends a 01 as well, and from then on every pair of digits is a key. This is what it looks like when I press t+r+o without releasing it

ffff97ef1a750000 1499866769 C Ii:004:01 0 8 = 00001700 00000000 (this is a t)
ffff97ef1a750000 1499866832 S Ii:004:01 -115 8 <
tffff97ef1a750000 1499906776 C Ii:004:01 0 8 = 00001715 00000000 (this is the 17 of the t followed by 15 of the r)
ffff97ef1a750000 1499906826 S Ii:004:01 -115 8 <
rffff97ef1a750000 1500146757 C Ii:004:01 0 8 = 01010101 01010101 (kaboom)
ffff97ef1a750000 1500146813 S Ii:004:01 -115 8 <

So in conclusion the random garbage the keyboard emits when it gets "overloaded" (don't know what the actual term is) is wrongly interpreted as a left control modifier.

https://docs.mbed.com/docs/ble-hid/en/l ... c_HID.html

[Edit]
Now I went to windows and used wireshark/USBCap and saw exactly the same dumps "01010101...." so there has to be something in the HID driver in windows that recognizes this as garbage and filters it out

That's very weird. That value "0101…" is not accidental — it looks like someone meant for it to be used internally within the controller (to denote that blocking has occurred, I suppose), and by accident it leaks out into the host, and on Windows, it has always gone unnoticed. I don't know if any of the controller code is shared with G83-6000; there is or was a specific Linux model in that series (6188, e.g. G83-6188LPNDE-0).

I assume that after blocking has occurred, it should retrieve and repeat the last known good list of keys, and instead it's sending back the magic internal word.

Sounds like a case for Cherry to investigate.

The keyboard is not "overloading": blocking after two keys are held is a legitimate mode of operation. Since your keyboard won't have diodes, the maximum number of keys that it can guarantee can be pressed simultaneously is two. Depending on the way the controller is programmed, it may allow higher numbers of simultaneous keys (up to six non-modifier keys in typical USB operation) if it's aware of their position in the matrix and that no ghosting will have occurred. Stopping after five or fewer keys isn't an overload — the controller is either aware that ghosting would have occurred or it's afraid that it might but isn't clever enough to tell.

To get 6KRO or better, you would need a diode by each switch. You get this in Cherry G80-3850, but not G80-3000.

Fault confirmed in Ubuntu 14.04.1 LTS 32-bit. I've not done any low-level testing, but I get similar behaviour to what you describe (but not exactly the same).

Without doing extensive testing, I can say that the way to verify the behaviour exists on your keyboard is as follows. Use a document editor such as Gedit (which is what I was testing with, as it's what I found on that laptop for a search of "text"):

Press and hold a key
Then press and hold a second key whose shortcut you wish to trigger
Finally, tap a third key

The first two keys need to remain held while the third is tapped. That is, pressing T+O+R rapidly doesn't generally exhibit the fault: you have to keep T+O held for a brief moment before adding R. The second key cancels the autorepeat of the first, and the third key adds LCtrl to the second. The delay for which the first two keys have to be held is only brief (in tens of milliseconds I suppose — you'd have to measure it with an event logger), but longer than a tap.

Not all sequences work. Using O is clumsy; using A as the middle key is easier as it simply selects all the text and there's no Open dialog to keep dismissing. If you hold Q, then also hold A, then ctrl+A is triggered if the third key is any of: P, L, K, W, R, S, E, D, F, U, J, I and O. Symbols and other letters simply cancel the autorepeat of the second key and type the symbol pressed, so those are going to be cases where 3KRO+ is possible and the controller knows it.

From what I can tell, you cannot get ctrl+O from T+R+O in "electronics" as the T is cancelled and the O adds LCtrl to R, giving T+R+O → ctrl+R. The shortcut is derived from the last successfully-registered keystroke.

Testing the same in Windows shows that the third keypress is totally ignored, i.e. the autorepeat of the second key isn't even stopped. Windows senses the nonsense HID report and throws it away. Linux however does not.

I see what you mean, thanks for taking the time to replicate it, in my tests sometimes it is the second letter but sometimes is the third letter the one that gets modified with left control, for example shift+e+c always gives me a ctrl+c on the console, anyways that's not that important. I did send an email to cherry support as this is quite a major issue for non-windows USB users, let's see if it reaches someone who knows what's happening.

The third character cannot be received (it gets blocked), so the second character must be the one that is affected.

Shift being a modifier is treated differently — I'm guessing that the HID report would contain shift + zero non-modifier keys. For shift+E+C, C is the second non-modifier, which is why ctrl+C is being generated. To get ctrl+C, then shift+E+C cannot have triggered blocking, so you're getting the effects of blocking when no blocking even occurred. That suggests that it's counting the detected keys incorrectly too.

I'm curious — in general, in Linux, if you hold a key and then additionally hold a modifier, does that trigger a keyboard shortcut? I wonder if the auto-repeat in Linux is re-examining the modifier status each time. Windows does not do this: you can't turn autorepeat into a shortcut.