Thread (6 messages) 6 messages, 2 authors, 2013-07-12

Re: [PATCH] input: don't call input_dev_release_keys() in resume

From: Oskar Andero <hidden>
Date: 2013-07-12 07:44:47
Also in: lkml

On 09:46 Fri 05 Jul     , Oskar Andero wrote:
Hi Dmitry,

On 18:33 Thu 04 Apr     , Dmitry Torokhov wrote:
quoted
Hi Oskar,

On Thu, Mar 07, 2013 at 03:01:22PM +0100, oskar.andero@sonymobile.com wrote:
quoted
From: Aleksej Makarov <redacted>

When waking up the platform by pressing a specific key, sending a
release on that key makes it impossible to react on the event in
user-space.
No, we can not simply not release keys after resume from suspend, as
this leads to keys being stuck. Consider you are holding an 'I' key on
your external USB keyboard and close your laptop's lid. Then you release
the key and leave. Later you come back, open the lid waking the laptop
and observe endless stream of 'I' in your open terminal.

Maybe we should release the keys during suspend time? I am not sure how
Android infrastructure will react to this though...
I finally got the time to try this out. Releasing the keys in suspend
also solves our problem. Would such patch work for the USB keyboard
case you described? Theoretically, I think it should, right?

So, basically:

static int input_dev_suspend(struct device *dev)
 {
        struct input_dev *input_dev = to_input_dev(dev);
 
-       mutex_lock(&input_dev->mutex);
-
-       if (input_dev->users)
-               input_dev_toggle(input_dev, false);
-
-       mutex_unlock(&input_dev->mutex);
+       input_reset_device(input_dev);
 
        return 0;
 }
 
 static int input_dev_resume(struct device *dev)
 {
-       struct input_dev *input_dev = to_input_dev(dev);
-
-       input_reset_device(input_dev);
-
        return 0;
 }

Should I send the patch?
Ping. Any thoughts on this?

Thanks!

-Oskar
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help