Input sync flag when registering.

Input sync flag when registering.

[Thomas Poussevin]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

Hi,
I noticed that with touchscreen drivers that don't explicitly call a 
input_sync after input_register_device, suspend to ram is blocked if no 
event is sent, because the input_dev created is considered as not 
synchronized. The problem was seen with Atmel mxt driver. When any event 
is sent, the driver explicitly ask a sync, so the problem is solved.
The problem occurs only when the screen has never send any event before 
suspend to ram.
I solved it setting the sync element to true (when input dev is created, 
no element is pending).
Is there a better way to solve the problem ?
Thanks.
Thomas.


[-- Attachment #2: 0001-DEV-input-Set-input-sync-param-default-status-to-tru.patch --]
[-- Type: text/x-patch, Size: 967 bytes --]

>From d0edf89b99de37e366d5ad1ab08e3c936ac553ae Mon Sep 17 00:00:00 2001
From: Thomas Poussevin <thomas.poussevin@parrot.com>
Date: Fri, 22 Aug 2014 17:56:17 +0200
Subject: [PATCH] [input] Set input sync param default status to true, to
 prevent touchscreen suspend fails. Problems used to happen only when
 touchsreen had not been touched since boot. When the first event is sent,
 input status is actualized.

Signed-off-by: Thomas Poussevin <thomas.poussevin@parrot.com>
---
 drivers/input/input.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 8921c61..c214b39 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -1652,6 +1652,7 @@ struct input_dev *input_allocate_device(void)
 	if (dev) {
 		dev->dev.type = &input_dev_type;
 		dev->dev.class = &input_class;
+		dev->sync = true;
 		device_initialize(&dev->dev);
 		mutex_init(&dev->mutex);
 		spin_lock_init(&dev->event_lock);
-- 
1.9.2

Re: Input sync flag when registering.

[Dmitry Torokhov]

Hi Thomas,

On Mon, Aug 25, 2014 at 10:52:51AM +0200, Thomas Poussevin wrote:
> Hi,
> I noticed that with touchscreen drivers that don't explicitly call a
> input_sync after input_register_device, suspend to ram is blocked if
> no event is sent, because the input_dev created is considered as not
> synchronized. The problem was seen with Atmel mxt driver. When any
> event is sent, the driver explicitly ask a sync, so the problem is
> solved.
> The problem occurs only when the screen has never send any event
> before suspend to ram.
> I solved it setting the sync element to true (when input dev is
> created, no element is pending).
> Is there a better way to solve the problem ?

It is not clear to me what the problem is. The kernel as far as I
remember never checked state of 'sync' field when executing suspend
callbacks. Moreover there is no longer 'sync' field at all in mainline.

It sounds like some userspace code makes assumptions that are not always
valid.

Thanks.

-- 
Dmitry

Re: Input sync flag when registering.

[Thomas Poussevin]

Le 25/08/2014 20:19, Dmitry Torokhov a écrit :
> Hi Thomas,
>
> On Mon, Aug 25, 2014 at 10:52:51AM +0200, Thomas Poussevin wrote:
>> Hi,
>> I noticed that with touchscreen drivers that don't explicitly call a
>> input_sync after input_register_device, suspend to ram is blocked if
>> no event is sent, because the input_dev created is considered as not
>> synchronized. The problem was seen with Atmel mxt driver. When any
>> event is sent, the driver explicitly ask a sync, so the problem is
>> solved.
>> The problem occurs only when the screen has never send any event
>> before suspend to ram.
>> I solved it setting the sync element to true (when input dev is
>> created, no element is pending).
>> Is there a better way to solve the problem ?
> It is not clear to me what the problem is. The kernel as far as I
> remember never checked state of 'sync' field when executing suspend
> callbacks. Moreover there is no longer 'sync' field at all in mainline.
>
> It sounds like some userspace code makes assumptions that are not always
> valid.
>
> Thanks.
>

Indeed, there is no longer 'sync' field in mainline. I realized i missed 
some commits, specifically  "Input: Send events one packet at a time" one.

Before theses commits, there used to be this problem, that is not 
relevant anymore :
It happened when Atmel mxt driver goes to suspend. mxt_stop func send a 
"input_sync" to mxt input device.
A input_sync has never been send before in input events.
The input_sync consists in : input_event(dev, EV_SYN, SYN_REPORT, 0);
In input_handle_event, if (!dev->sync) , then dev->sync = true; 
disposition = INPUT_PASS_TO_HANDLERS; . So finally there is a call to 
input_pass_event(dev, type, code, value);
But the input device created by mxt driver is allready suspending.
Suspend is canceled.

So i have 2 solutions (other than kernel update): either, in mxt driver, 
sending a input_sync after creating input device in order than the 
suspend sync call is not the first one (dev->sync will be true next 
time). Either, in the input driver, the default value of sync field is 
true (coherent with a just created device). I choosed this one.

Thanks.
Thomas.


--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html