linux-kernel - Re: [PATCH 0/2] input: mt: Add helper function to send end events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <52C5F42A.6010803@felipetonello.com>
Date:	Thu, 02 Jan 2014 15:20:10 -0800
From:	Felipe Ferreri Tonello <eu@...ipetonello.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Henrik Rydberg <rydberg@...omail.se>
CC:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] input: mt: Add helper function to send end events

Hi Dmitry and Henrik,

On 01/01/2014 11:18 AM, Dmitry Torokhov wrote:
> 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?

Yes, I guess. But why notificate only when it comes back from sleep?

Because the way it is today, if a user touches a device and suddenly the 
device sleeps, the user-space will not know that that device went sleep. 
Then when the device wakes up (resumes) the end touch event will never 
be sent even if the user releases his finger from it (because the actual 
hardware is in "sleep" mode or something), thus the user-space will 
continue to think the finger was not released from the touch screen.

Felipe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/