On Wed, Jan 01, 2014 at 05:19:10PM +0100, Henrik Rydberg wrote:Hi Dmitry,
What problematic scenario is this supposed to solve?
The 'release on suspend' is only an approximation to the 'close
laptop' scenario, it is certainly not correct in the coffee table
Why would it not be correct for coffee table? Do we expect the touches
to remain valid while the device is asleep?
In some scenarios with placed objects (like a cup or a marker), that would be
the case, yes.
for instance. Instead of
hardcoding this in the kernel, userland can easily detect long intervals
directly using the event time.
But with slots it is not only problem with old events being sent out
later, it is that we have mix of old (pre-sleep) and new state.
The new state is not really a problem, it will look exactly the same regardless
of how 'old' releases are handled.
We do that for keys (release them when we transition to system sleep)
and I think it might be worthwhile to do the same for touch data.
I agree that keyboard applications seldom look at time intervals and hence are
well helped by such a strategy, even though it is not strictly 'correct'.
However, touch interfaces are quite dependent on time intervals, and it
therefore makes a lot of sense to resolve touch timeouts directly in the
application. It also puts less restrictions on what can be done.
Regarding notifications in general, perhaps it would be interesting to be able
to send a notification event via the input interface when a device comes back
from sleep. It could help resolve other complex issues, if there were any.
OK, fair enough. If there is a demand we could send SYN_SYSTEM_RESUME
event though the interfaces to allow clients "flush" the state or
otherwise decide if new touch data is actually old touches that were
Felipe, will that help in your case?