With the latest Fedora kernel build (4.2.8-200.fc22.x86_64), I see this behavior:
A string of spurious characters, beginning with a digit 6 and continuing with an unending stream of digit-8 characters, suddenly appears and fills whatever text workspace, dialog box, etc. currently has the focus. If the application has the focus, these spurious characters act like keystrokes attempting to initiate a keyboard-triggered menu command or other command.
Sometimes the string consists of digits 5. This can cause a problem with applications like Thunderbird, which uses digit 5 as a command to toggle the "can wait" flag on a piece of e-mail.
Version-Release number of selected component (if applicable):
4.2.8-200.fc22.x86_64
How reproducible:
Happens at random during a session with any application putting a focus on a particular text working area or other area sensitive to keystrokes of any kind.
Steps to Reproduce:
1. Start a browser, a word processor, a text editor, or any other application having a text working area of any kind.
2. Place the focus on a particular text working area. For safety's sake, do this in an empty document in a plain-text editor, like KWrite.
3. Watch and wait. (Although sometimes spurious characters will appear as you type!)
Actual results:
Without your typing anything, the machine will start with a digit 6 and then continue with an unbreaking string of 8's. The only way to break it is with another keystroke of your own. After that you have to erase the spurious characters.
Sometimes the machine will throw a number "68" into your text as you are typing. This leaves you with a typographical error you must correct. And it can salt your text with typographical errors requiring as much time to remove as it took to type the text to begin with!
Expected results:
No character, of any description, should appear without your striking a key.
Additional info:
This error has occurred before. It crops up on occasion with a kernel update and vanishes one or at most two updates later. Everyone knows about it. Before now, it was a Plague of Fives. Now it is a Plague of Eights.
A spurious number 68 introduced itself into my text as I was typing this report.
The nature of the error, and its apparent dependency on versions of the kernel, should preclude any consideration of a hardware fault like "sticking keys."
Filed with Bugzilla as Bug No. 1299130. Assigned to the Kernel Maintainers' Group. Add this to it: I fell back on the next earlier version of the kernel. And the problem vanished. So let no one say I'm just typing on a keyboard with sticky keys. Temlakos
On 01/16/2016 11:16 AM, Temlakos wrote:
Filed with Bugzilla as Bug No. 1299130. Assigned to the Kernel Maintainers' Group. Add this to it: I fell back on the next earlier version of the kernel. And the problem vanished. So let no one say I'm just typing on a keyboard with sticky keys. Temlakos
Did you mention this in your report? If not, you need to.
On 01/16/2016 02:33 PM, Joe Zeff wrote:
On 01/16/2016 11:16 AM, Temlakos wrote:
Filed with Bugzilla as Bug No. 1299130. Assigned to the Kernel Maintainers' Group. Add this to it: I fell back on the next earlier version of the kernel. And the problem vanished. So let no one say I'm just typing on a keyboard with sticky keys. Temlakos
Did you mention this in your report? If not, you need to.
Added as a comment after I filed the report. You can see it there.
Temlakos
On 01/16/2016 11:46 AM, Temlakos wrote:
Added as a comment after I filed the report. You can see it there.
Good! I don't have any x64 systems (Although, if I ever need to do a clean install on this box, I'll migrate from PAE to x64.) so it doesn't concern me directly. Also, what happens if you boot into an earlier kernel? If it works correctly, that needs to be documented, so that whoever's working on it knows that it's specific to this kernel.
Sorry if I'm telling you things you already know, but I can't judge what needs to be said and what doesn't from this thread. (If you'd been active on the list for years, that might be different.) The thing I'm trying to avoid is having you waste time proving that it's this specific kernel that's at fault while they try to point a finger at something unrelated. (No, I'm not claiming that they will, just that they can.)
On 01/16/2016 03:00 PM, Joe Zeff wrote:
On 01/16/2016 11:46 AM, Temlakos wrote:
Added as a comment after I filed the report. You can see it there.
Good! I don't have any x64 systems (Although, if I ever need to do a clean install on this box, I'll migrate from PAE to x64.) so it doesn't concern me directly. Also, what happens if you boot into an earlier kernel? If it works correctly, that needs to be documented, so that whoever's working on it knows that it's specific to this kernel.
Sorry if I'm telling you things you already know, but I can't judge what needs to be said and what doesn't from this thread. (If you'd been active on the list for years, that might be different.) The thing I'm trying to avoid is having you waste time proving that it's this specific kernel that's at fault while they try to point a finger at something unrelated. (No, I'm not claiming that they will, just that they can.)
As I said before: when I boot into what I call the "last known good kernel," meaning the kernel one version earlier than the current one, I don't have this problem. As I specifically say in my comments to this bug.
Temlakos
On 01/16/2016 12:09 PM, Temlakos wrote:
As I said before: when I boot into what I call the "last known good kernel," meaning the kernel one version earlier than the current one, I don't have this problem. As I specifically say in my comments to this bug.
Great! I don't keep posts like this after I've read them and didn't take the time to chase through the Trash looking for it. Think of it as Better Safe Than Sorry.
-
Joe Zeff -
Temlakos