Bug 10308 - Keyboards debounce ocasionally sets itself to ~1 second
Summary: Keyboards debounce ocasionally sets itself to ~1 second
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/Keyboard (show other bugs)
Version: 6.8.2
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-15 08:45 UTC by Darryl Miles
Modified: 2018-06-12 19:08 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Darryl Miles 2007-03-15 08:45:36 UTC
I hope I am using the correct terminology.

The problem happens occasionally (this latest time I was using SeaMonkey Mozilla Email), 5 times I can remember since I installed FC4 14 months ago.  The keyboard stops working a normal typing speed, I have to hold a key down for 1 second (estimated) before any application registers the keypress.  The auto-repeat timer appears unaffected by this bug.  I would guess my default X11 auto-repeat is in the order of 250ms @ 24 per second.

This means that while the bug occurs:

If I hold a key down for 150ms it does not register in the app.
If I hold a key down for 1001ms it registers as a single key press.
If I hold a key down for 1221ms it registers as a key press and 1 addtional press due to auto-repeat.
If I hold the key down for 1501ms it registers as a key press and 6 additional keypressed due to auto-repeat (on the basis I have it set to 24 per second, guess)

The above information is more estimate than fact but its the best way I can describe to someone else that happens.


Other interesting facts I can say (whilst the bug is in effect) :

 * In order to use multiple keys, like Shift or Ctrl+Alt+<key> I have to hold down each modifier key for 1 second first, before attempting to press the next key.  So even modifiers like shift will not register in the emitted char if I didn't hold the shift down on its own down for 1 seconds first.  When I am using 3 keys, I hold down Ctrl, then wait 1 second, then hold down Ctrl and Alt (without letting go of the Ctrl), then wait 1 second, then hold down Ctrl and Alt and F1 and wait for 1 second, then it will switch out to a text mode VC.

 * If I use Ctrl + Alt + F1 (to switch back to a text mode VC on linux), then the text mode VC has perfect keyboard operation, it is unaffected by this problem.

 * Swithing back to X11 (from the text mode VC) and the problem persists.

 * Mouse operations are unaffected when the bug occurs.

 * The only way I know to fix the problem is to logout of the X11 session, I believe Fedora Core 4 shuts down the X11 server and respawns a new one.


Maybe this is an SMP problem, in the area of modifying the internal keyboard timing parameters withing the server during keyboard grabs ?

From memory at the time I had operated a popup menu within Mozilla between the time the keyboard last worked normally and when the bug occured.

Is there a command line utility I can use to dump out the complete keyboard configuration, a bit like "xset" butI am not aware "xset" can be used to inspect the current configuration, it can only be used to set a new configuration.  I also don't believe "xset" allow configuration of the debounce timeout parameter.


My system is based on FC4, its a Dual CPU x86_64 clocked at 3.2 GHz.  The X server came from the package xorg-x11-6.8.2-37.FC4.49.2.

If there is any other information I can provide please ask.  I am not able to provide a procedure to follow to cause the problem, as I say its only happened a few times over the year or so I have been using this version and am hoping that a developer might know where to look from the information given above.
Comment 1 Adam Jackson 2018-06-12 19:08:56 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.