On 06/10/11 16:56, Henrik Rydberg wrote:
On Fri, Jun 10, 2011 at 03:55:02PM -0400, Derek Foreman wrote:
Some input devices have a non-uniform report rate, which can make it difficult for a userspace driver to distinguish between a lack of motion or a lack of new input.
With this patch, if multiple duplicate events (after defuzz) are received in a row, the first duplicate is posted to userspace.
Every change is already propagated exactly once, which seems to amount
to the same thing your patch is aiming at. The evdev event signifies
the change itself (and when it occurs), so there is actually no
difference between the lack of motion and the lack of input.
Hi Henrik,
Thank you for all your input.
The specific problem that this patch aims to solve is that a certain
family of synaptics devices drops from 80Hz to 40Hz reporting when 2 or
more fingers are on the pad. As the screen refresh rate for a modern PC
is generally 60Hz, input feels subjectively much less interactive.
It is possible - by maintaining a short history of past events and
predicting where the cursor would be in the future - to do a reasonable
job of creating 60Hz motion from this lower input rate. This is where
the difference between lack of motion and lack of input is key.
If I receive an event, then 1/80th of a second later I do NOT receive
another one, I don't know whether the device has dropped to a lower
reporting rate (lack of input), or whether the device reported the same
event 2 times in a row, and the kernel "defuzz" code filtered it (lack
of motion).
In the "lack of input" case, I want to fabricate a synthetic event to
keep the pointer motion fluid. In the "lack of motion" case, I want
pointer motion to stop.
Currently, the kernel knows it has started to filter unchanging input,
but userspace has no mechanism to detect that this filtering has begun.
As two identical events in a row is an impossibility in the face of
the defuzz code, I had thought this would be a good way to expose this
information without confusing any existing applications...
Thanks,
Derek
--
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
