Characters in programmed keys lost

[flathat]

An issue that is contemporary with my Ubuntu 14.04 upgrade #733 is loss of some characters in programmed keys. The keyboard is a Cherry G86-61411EUADAA.

I noticed it first with a "Non-Member" key 99999ID that was producing less than five 9s. It seemed to only happen during the first transaction after booting so I didn't worry too much about it.

Later it was reported with each of a group of keys that produce 5-digit PLUs like 80003. I've reproduced this. It is usually, but not always, one or more of the middle 0s that is lost. Pressing the key again, or three or four more times, eventually gets the complete value. It doesn't happen all the time, but once every three or four uses.

I will be replacing the keyboard for other reasons soon and wil report whether that changes anything.

I'm wondering if there may be something that is trying to compress multiples of a value, 9 or 0, and somehow it goes wrong sometimes.

[gohanman]

I'm wondering if there may be something that is trying to compress multiples of a value, 9 or 0, and somehow it goes wrong sometimes.

As far as I know there's nothing in CORE's parsing that would do this.

1. Is the problem reproducible in another application, e.g. a text editor?
2. Is the problem reproducible with the keyboard connected to another OS - Ubuntu 12.04, Mac, Windows, etc?

It sounds like either a software problem or an OS problem.

[jonkeim]

I've noticed that problem with our lanes occasionally. For us it happens when the keyboard sends keystrokes too quickly and the computer drops one. (We're using "Preh KeyTec MCI 128"s here.) Occasionally the Non-memeber key will type "9999id" into the input box instead of "99999id". If I'm remembering, I tested some six digit member IDs once (set-asides for system things), and they were even more prone to dropping a keystroke.

It also seems reasonable that keystrokes would be dropped more frequently just after boot if the computer is still busy with background boot tasks.

It doesn't happen a /lot/ on our lanes, though (a couple times a year?), so I've never bothered to figure out a solution. But you can probably adjust the speed that they keyboard sends multiple keystrokes at.

[flathat]

Further tests on this:

• It probably isn't a bad USB port. These machines have four and I tried three of them with no different results.
• It isn't the keyboard itself: I tried three different ones, including one brand new one.
• It is not reproducible in a text editor (vi): the complete sequence is always received; not what I would expect.
• It only affects keys that are programmed with multiple consecutive digits. I only have 0's and 9's as examples. There were no errors in many tries with keys that have five non-same-consecutive numbers or a mix of letters and numbers.
• Googling does not provide a lot of leads but repeated-keystrokes-lost-in-unity contains several approaches, some of which were successful for the people who described them, but, alas, were not for me. The most promising direction seemed to be that "Bounce" prevention, an accessibility option to not accept multiples of a key typed in quick succession, was getting enabled when it shouldn't. System settings > Universal Access > Typing > Bounce = off It was not enabled by mistake and toggling on then off again did not result in even momentary improvement, as it did for the writer. I understand Bounce to be kind of like stuttering, and not the same as holding a key down.
• Cherry (US) tech support provided a config file with a "secret" (not available in the config utility) option enabled which is said to slow rate of transmission of keystrokes but it didn't help. I asked him to "turn it up". He has referred the question to head office in Germany, so we'll see what follows. The config file is binary, I haven't tried to diff and hex-edit it.

Some other commands: xev, xset, kbdrate are mentioned in that and other pages, but often to say they don't do what is expected. Unfortunately I don't understand the the relationship between X, Xorg, gnome and Unity well enough to know which command to expect to have effect where, or even in which environment to invoke them.

There is a fair amount of forum discussion about adjusting repeat rates and general keyboard response. I haven't been able to actually type fast enough to see characters drop, although it is not easy to make realistic tests. I would like to slow the input from the programmed keys to the rate of a fast typist so that that condition that appears to be trapped doesn't arise. If the keyboard had a <pause> command to place between characters.

I've tried the keyboard option in System Settings > Keyboard > Repeat. The default of the two parameters are:

Delay: ~20% of Long, i.e. relatively short
Speed: ~60% of Fast, i.e. relatively fast

Reversing those, or setting them to either extreme, 5%, 95%, seems to have no effect or make things worse, e.g. never accept consecutive-same numbers. I don't know whether the submission of consecutive-same characters from a programmed key looks like a physical key being held down. If it doesn't, then none of the repeat-related settings are pertinent.

I've tried Universal Access > Typing > Slow Keys

Delay ~40%: no typed or programmed-key characters accepted (need to try this again)
Delay ~15%: can type but programmed-key input is not accepted
Delay ~0%: 99999ID never returns more than three 9's
                   8000*: fail most of the time, i.e. 2 or less 0's

It seems odd that I'm not finding more Internet discussion of this. I wonder if I need to be in a particular forum and if so which one(s).

[gohanman]

What happens if you add effectively null keystrokes between the repeated characters - eg., 9<down/up> shift<down/up> 9<down/up> alt<down/up> etc

[flathat]

I had some encouraging results from the "null" keystrokes approach. I tried <shift> and <end> and <home><end> but had best results with <numlock> (0x45), thus: 80003<enter> as 80<numlock>0<numlock>03<enter>.

It's important that the number of <numlock>s be even so the keypad will be left working as it was to begin with.

I had zero failures in a hundred or so tries. I'll see what cashiers report tomorrow. The other "nulls" were better than without but there were still losses, one or two in ten to one or two in forty. I have seven keys "fully" programmed, plus the partial "Non-member".

Cherry doesn't allow very many bytes in its programmed key macros so there wasn't enough room to put all the <numlock>s I wanted in 99999id<Enter> and it still drops some 9s fairly frequently, one in ten, say.

The Cherry Key Programming dialog has greyed delay controls, per-key and globally. I'm hoping my conversation with support there will eventually get me access to them. There is also a Pause button whose function is unknown. It does not put <pause> in the program for the key.

[gohanman]

Cherry doesn't allow very many bytes in its programmed key macros so there wasn't enough room to put all the s I wanted in 99999id and it still drops some 9s fairly frequently, one in ten, say.

Are you using "Keyboard programming" or "Software programming"? I'm pretty sure the latter has greater capacity although I don't know if the driver that makes software programming work exists for Linux. The per-key delay controls become available when using a Software programming macro so maybe the feature is only available that way.

[flathat]

Cherry tech support also suggested alternating 9's from keyboard and keypad. I tried and it seems to be better than all plain 9s. Worth a try.

Cherry says the "Software programming", in which keystroke delay can be specified, is only available under Windows.

[flathat]

After almost a month at two sites it seems that putting <numlock> between multiple consecutive characters is pretty effective.