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

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

[Felipe F. Tonello]

From: "Felipe F. Tonello" <eu@felipetonello.com>

Adds a helper function to send end touch events for active tracking ids.
And also implements it in egalax driver.

Felipe F. Tonello (2):
  input: mt: Add helper function to send end events
  input: egalax: report end state in suspend callback

 drivers/input/input-mt.c              | 33 +++++++++++++++++++++++++++++++++
 drivers/input/touchscreen/egalax_ts.c |  5 +++++
 include/linux/input/mt.h              |  2 ++
 3 files changed, 40 insertions(+)

-- 
1.8.3.1

[PATCH 1/2] input: mt: Add helper function to send end events

[Felipe F. Tonello]

From: "Felipe F. Tonello" <eu@felipetonello.com>

This is useful to report for users of devices that don't know anything
about the suspension of the device. So users will receive a touch end event
when the device is about to suspend, making it more user friendly.

One example of users is the X Server with the evdev input driver. This patch
make sure that the X server will propagate a touch end event to its windows.

Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
---
 drivers/input/input-mt.c | 33 +++++++++++++++++++++++++++++++++
 include/linux/input/mt.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
index d398f13..6010357 100644
--- a/drivers/input/input-mt.c
+++ b/drivers/input/input-mt.c
@@ -157,6 +157,39 @@ void input_mt_report_slot_state(struct input_dev *dev,
 EXPORT_SYMBOL(input_mt_report_slot_state);
 
 /**
+ * input_mt_report_end_state() - report end touch events
+ * @dev: input device with allocated MT slots
+ *
+ * Reports a touch end event for current active slots (with active tracking id).
+ * This is useful when the device might suspend (or sleep) while there were
+ * still active tracking ids.
+ */
+void input_mt_report_end_state(struct input_dev *dev)
+{
+	struct input_mt *mt = dev->mt;
+	struct input_mt_slot *slot;
+	int id, i;
+
+	if (!mt)
+		return;
+
+	for (i = 0; i < mt->num_slots; ++i) {
+		slot = &mt->slots[i];
+		slot->frame = mt->frame;
+
+		id = input_mt_get_value(slot, ABS_MT_TRACKING_ID);
+
+		/* if id == -1 is 'unused' */
+		if (id >= 0) {
+			input_mt_set_value(slot, ABS_MT_TRACKING_ID, -1);
+			input_event(dev, EV_ABS, ABS_MT_TRACKING_ID, -1);
+		}
+	}
+}
+EXPORT_SYMBOL(input_mt_report_end_state);
+
+
+/**
  * input_mt_report_finger_count() - report contact count
  * @dev: input device with allocated MT slots
  * @count: the number of contacts
diff --git a/include/linux/input/mt.h b/include/linux/input/mt.h
index 1b1dfa8..0e6c9f7 100644
--- a/include/linux/input/mt.h
+++ b/include/linux/input/mt.h
@@ -103,6 +103,8 @@ static inline bool input_is_mt_axis(int axis)
 void input_mt_report_slot_state(struct input_dev *dev,
 				unsigned int tool_type, bool active);
 
+void input_mt_report_end_state(struct input_dev *dev);
+
 void input_mt_report_finger_count(struct input_dev *dev, int count);
 void input_mt_report_pointer_emulation(struct input_dev *dev, bool use_count);
 
-- 
1.8.3.1

[PATCH 2/2] input: egalax: report end state in suspend callback

[Felipe F. Tonello]

From: "Felipe F. Tonello" <eu@felipetonello.com>

Make sure user-space will receive the touch end event even if the device
driver suspends while touchscreen is still active (with fingers touching it).

Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
---
 drivers/input/touchscreen/egalax_ts.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/input/touchscreen/egalax_ts.c b/drivers/input/touchscreen/egalax_ts.c
index 054d225..9cf4cdb 100644
--- a/drivers/input/touchscreen/egalax_ts.c
+++ b/drivers/input/touchscreen/egalax_ts.c
@@ -247,8 +247,13 @@ static int egalax_ts_suspend(struct device *dev)
 		0x3, 0x6, 0xa, 0x3, 0x36, 0x3f, 0x2, 0, 0, 0
 	};
 	struct i2c_client *client = to_i2c_client(dev);
+	struct egalax_ts *ts = i2c_get_clientdata(client);
 	int ret;
 
+	input_mt_report_end_state(ts->input_dev);
+	input_mt_report_pointer_emulation(ts->input_dev, true);
+	input_sync(ts->input_dev);
+
 	ret = i2c_master_send(client, suspend_cmd, MAX_I2C_DATA_LEN);
 	return ret > 0 ? 0 : ret;
 }
-- 
1.8.3.1

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

[Henrik Rydberg]

Hi Felipe,

> Adds a helper function to send end touch events for active tracking ids.
> And also implements it in egalax driver.

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, for instance. Instead of
hardcoding this in the kernel, userland can easily detect long intervals
directly using the event time.

Unless there is already a reasonable mechanism in your user application which
deals with cases like this but fails to account for your particular problem
scenario, the patch will not be applied.

Thanks,
Henrik

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

[Dmitry Torokhov]

Hi Henrik,

On Tue, Dec 31, 2013 at 10:26:31AM +0100, Henrik Rydberg wrote:
> Hi Felipe,
> 
> > Adds a helper function to send end touch events for active tracking ids.
> > And also implements it in egalax driver.
> 
> 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?

> 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.

> 
> Unless there is already a reasonable mechanism in your user
> application which deals with cases like this but fails to account for
> your particular problem scenario, the patch will not be applied.
> 

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.

Thanks.

-- 
Dmitry

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

[Henrik Rydberg]

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.

Thanks,
Henrik

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

[Dmitry Torokhov]

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

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

[Felipe Ferreri Tonello]

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