| Message ID | 1362664882-16194-1-git-send-email-oskar.andero@sonymobile.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 15:01 Thu 07 Mar , oskar.andero@sonymobile.com wrote: > From: Aleksej Makarov <aleksej.makarov@sonymobile.com> > > 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. > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> > Reviewed-by: Radovan Lekanovic <radovan.lekanovic@sonymobile.com> > Signed-off-by: Aleksej Makarov <aleksej.makarov@sonymobile.com> > Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com> > --- > drivers/input/input.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/drivers/input/input.c b/drivers/input/input.c > index c044699..61ce19f 100644 > --- a/drivers/input/input.c > +++ b/drivers/input/input.c > @@ -1690,7 +1690,10 @@ static int input_dev_resume(struct device *dev) > { > struct input_dev *input_dev = to_input_dev(dev); > > - input_reset_device(input_dev); > + mutex_lock(&input_dev->mutex); > + if (input_dev->users) > + input_dev_toggle(input_dev, true); > + mutex_unlock(&input_dev->mutex); > > return 0; > } > -- > 1.7.8.6 > Ping. Any input on the patch above? -Oskar -- 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
Hi Oskar, On Thu, Mar 07, 2013 at 03:01:22PM +0100, oskar.andero@sonymobile.com wrote: > From: Aleksej Makarov <aleksej.makarov@sonymobile.com> > > 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... Thanks.
On 18:33 Thu 04 Apr , Dmitry Torokhov wrote: > Hi Oskar, > > On Thu, Mar 07, 2013 at 03:01:22PM +0100, oskar.andero@sonymobile.com wrote: > > From: Aleksej Makarov <aleksej.makarov@sonymobile.com> > > > > 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. You're absolutely right. But I guess you also see the case that the patch is trying to fix, right? To explain our use-case: We have a physical camera button on some devices. When the user long-presses the button, the system will wake up and jump directly in to the camera application. > Maybe we should release the keys during suspend time? I am not sure how > Android infrastructure will react to this though... That sounds like a good idea! Let me do some testing on that. Thanks! -Oskar -- 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
Hi Dmitry, On 18:33 Thu 04 Apr , Dmitry Torokhov wrote: > Hi Oskar, > > On Thu, Mar 07, 2013 at 03:01:22PM +0100, oskar.andero@sonymobile.com wrote: > > From: Aleksej Makarov <aleksej.makarov@sonymobile.com> > > > > 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? -Oskar -- 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
On 09:46 Fri 05 Jul , Oskar Andero wrote: > Hi Dmitry, > > On 18:33 Thu 04 Apr , Dmitry Torokhov wrote: > > Hi Oskar, > > > > On Thu, Mar 07, 2013 at 03:01:22PM +0100, oskar.andero@sonymobile.com wrote: > > > From: Aleksej Makarov <aleksej.makarov@sonymobile.com> > > > > > > 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 -- 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
diff --git a/drivers/input/input.c b/drivers/input/input.c index c044699..61ce19f 100644 --- a/drivers/input/input.c +++ b/drivers/input/input.c @@ -1690,7 +1690,10 @@ static int input_dev_resume(struct device *dev) { struct input_dev *input_dev = to_input_dev(dev); - input_reset_device(input_dev); + mutex_lock(&input_dev->mutex); + if (input_dev->users) + input_dev_toggle(input_dev, true); + mutex_unlock(&input_dev->mutex); return 0; }