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 > >> case, > > > > 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 there pre-suspend. Felipe, will that help in your case? Thanks. -- Dmitry -- 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
