From: Daniel Drake <dsd@laptop.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, linux-pm@lists.linux-foundation.org,
rjw@sisk.pl, dilinger@queued.net, pgf@laptop.org
Subject: Re: [PATCH v4 1/2] Input: enable i8042-level wakeup control
Date: Sat, 3 Sep 2011 13:45:25 +0100 [thread overview]
Message-ID: <CAMLZHHQ_ErVVg0TqVuaA=R0SbYdn=htMN+2rcTEEqaF-i9LC4w@mail.gmail.com> (raw)
In-Reply-To: <20110817070351.GE29361@core.coreip.homeip.net>
Hi,
Sorry for the delay in replying to this - I took sime time off.
On Wed, Aug 17, 2011 at 8:03 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> OK, so we have the following scenario:
>
> - we do not need to worry about SND and LED on OLPC;
>
> - we do not need to worry about releasing the key that was pressed
> when we went to sleep because they system would not go to sleep while
> there is a key pressed. So the code in input_dev_resume() won't
> actually release any keys unless a key was held pressed and we forced
> system to sleep somehow.
>
> - we need to make sure we do not loose key press (and following events)
> when we are waking up.
Yes, that seems accurate, with one more addition:
- we need to make sure we do not loose mouse button press or mouse
movement (and following events) when we are waking up.
> Can atkbd driver stash away serio byte data (when not in command mode)
> and replay it when pm notifier signals us that resume process is done?
I'm having trouble understanding this suggestion or relating it to the
problems in question and the previous patches posted. Are you
suggesting stashing of data that is sent from the host to the
keyboard, or from the keyboard to the host? How does this solve our
issues? What about the mouse?
How is it going to avoid the input-level issues?
Thanks,
Daniel
--
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
next prev parent reply other threads:[~2011-09-03 12:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-02 15:49 [PATCH v4 1/2] Input: enable i8042-level wakeup control Daniel Drake
2011-08-03 6:59 ` Dmitry Torokhov
2011-08-03 8:04 ` Daniel Drake
2011-08-03 18:43 ` Dmitry Torokhov
2011-08-03 19:24 ` Daniel Drake
2011-08-03 19:38 ` Dmitry Torokhov
2011-08-03 19:51 ` Daniel Drake
2011-08-05 15:24 ` Daniel Drake
2011-08-11 18:02 ` Daniel Drake
2011-08-17 7:03 ` Dmitry Torokhov
2011-09-03 12:45 ` Daniel Drake [this message]
2011-08-03 8:12 ` Wanlong Gao
-- strict thread matches above, loose matches on Subject: below --
2011-08-02 15:49 Daniel Drake
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='CAMLZHHQ_ErVVg0TqVuaA=R0SbYdn=htMN+2rcTEEqaF-i9LC4w@mail.gmail.com' \
--to=dsd@laptop.org \
--cc=dilinger@queued.net \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=pgf@laptop.org \
--cc=rjw@sisk.pl \
/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).