Oliver Neukum wrote:
Am Mittwoch 07 Mai 2008 00:24:58 schrieb Alan Jenkins:
I think I've worked out how to avoid the lost key-presses. Sometimes
they get lost; sometimes they don't. The difference seems to how long I
wait after the keyboard suspends. If I wait a few seconds after it's
suspended (as shown by the LEDs), then it resumes flawlessly. It should
be possible to reduce the impact of the hardware misfeature by
increasing the timeout. The longer the keyboard has been idle already,
the lower the probability it'll be used in the next few seconds.
This suggests a possible work around. Keyboards known to be buggy in this
way could be reawoken periodically before the critical amount of time is over.
How long is that time? What percentage of time does a keyboard need to be
suspended for a positive energy balance?
Sorry, I didn't explain that very clearly.
The problem happens if the keyboard resumes _immediately after_ it's
autosuspended. If I start typing as soon as the LED goes off, it loses
some of the keypresses. If I instead wait a few seconds before typing,
it works flawlessly. Since it's the keyboard that's resuming itself I
don't think you could fix this. Unless it's your code that's buggy and
not the keyboard :-).
What I was trying to say was that I can mitigate this problem by
increasing the autosuspend timeout from the default of 2 seconds. I
will quite often pause for periods of about 2 seconds while typing. But
if the keyboard is only suspended after 60 seconds of inactivity or
longer, then it's far less likely that I will start typing immediately
afterwards.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
