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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
