09-29-2018 10:24 AM - edited 09-29-2018 09:54 PM
After seeing the A/E485 keyboard issues, the reddit Thinkpad community investigated the remaining Thinkpad keyboards. We discovered that these other, non-A/E485 Thinkpad keyboards also have significant coalescing problems which scramble keys. A test program to quantify the issue reveals that keys closer than 23ms are scrambled. Many people collaborated over many machines to provide data. To easily see the problem, press "asdf" simultaneously, and note that "fdsa" will appear. It's much easier to type fdsa really fast than to type asdf fast, on a Thinkpad keyboard. We hope that this can be fixed because the E-series does not experience this issue.
The trackpoint also has poor sampling behavior, with a 7ms internal sampling rate and a 16ms external sampling rate. This causes timepoints to be staggered in an uneven 10-17-17 manner.
All T-series, X-series keyboards are affected, both Windows and Linux. That includes the 7-row keyboards.
E-series is not affected.
Nobody has yet submitted data for E/A485 either pre-patch or post-patch. We are interested in testers.
External USB keyboards and mice not affected.
Laptops from other manufacturers (Dell) not affected.
Technical summary of the issue:
09-30-2018 06:45 PM - edited 09-30-2018 06:45 PM
Well yes, the keyboard is multiplexed.
Keys are going to be scanned at different points in time.
What did you expect?
09-30-2018 07:05 PM
BrianG61UK, you don't understand the issue. The problem is a special delay-and-coalesce behavior, not scanning. The E-series has the same sequential scanning ("multiplexing"), but no coalescing. Therefore the E-series doesn't suffer from this problem. No other keyboards other than X and T Thinkpads have this problem either. Please read through the technical description first if you are inclined to make such comments. Our community is aware of these basic keyboard firmware concepts.
09-30-2018 07:15 PM
I've written firmware to scan multiplexed keyboards. You can never completely fix this kind of issue. All you can do is scan faster if the wiring and RF compatibility restrictions allow and do less debouncing if you're going so fast you need to debounce in addition to the debouncing effect of the scanning.
09-30-2018 07:26 PM
You have still not read either the first post or the technical description. We are perfectly aware of everything you are saying, and the issue we describe is totally different. The initial post and my response tell you the exact issue and how scanning is not the cause. No keyboard we have tested faces this issue other than X/T-series Thinkpads, even though all of them do sequential scanning. Please read the first post before commenting again.
10-25-2018 10:22 AM
I have two different A485 both on bios1.05. Other than the asdf test (which I get varried results pushing all 4), is there any other tests I can do?
10-25-2018 10:53 AM - edited 10-25-2018 10:53 AM
Yes! You're exactly the tester we need, we are missing A485s. See https://github.com/ad8e/input-polling-test on how to get timing measurements. Samples of previous measurements by other users are at https://www.reddit.com/r/thinkpad/comments/9j70v6/thinkpad_keyboard_firmware_worse_than_anyone/. If you have any questions, feel free to ask me right away, because your data is the most valuable in the lot.
10-25-2018 11:17 AM - edited 10-25-2018 11:21 AM
I don't really understand the numbers, but here's a quick sample of the numbers I was getting. Most of these were me pushing lk either together, or very closely together. Let me know if I should do the test differently.
10-25-2018 11:24 AM
Your numbers are good, and you followed the testing procedure perfectly. I would have liked more data, but what you have shown is enough to demonstrate that your keyboard is problem-free. Lenovo has fixed your machine. Thanks for the testing!
10-25-2018 11:27 AM
I can provide more data later today. This was on one of my A485, but I'll have access to the other in a few hours.
Should I be pushing them as fast as I can or does that not matter?