From: Thomas Poussevin <thomas.poussevin@parrot.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Subject: Re: Input sync flag when registering.
Date: Wed, 27 Aug 2014 11:12:43 +0200 [thread overview]
Message-ID: <53FDA10B.8010601@parrot.com> (raw)
In-Reply-To: <20140825181906.GA35881@core.coreip.homeip.net>
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
prev parent reply other threads:[~2014-08-27 9:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-25 8:52 Input sync flag when registering Thomas Poussevin
2014-08-25 18:19 ` Dmitry Torokhov
2014-08-27 9:12 ` Thomas Poussevin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53FDA10B.8010601@parrot.com \
--to=thomas.poussevin@parrot.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).