| Message ID | 20200917022309.30240-2-koba.ko@canonical.com |
|---|---|
| State | New |
| Headers | show |
| Series | Wakeup the system by touching the touchpad | expand |
On Thu, Sep 17, 2020 at 10:23:09AM +0800, Koba Ko wrote: > From: Kai-Heng Feng <kai.heng.feng@canonical.com> > > BugLink: https://bugs.launchpad.net/bugs/1888331 > > Many laptops can be woken up from Suspend-to-Idle by touchpad. This is > also the default behavior on other OSes. > > However, if touchpad and touchscreen contact to each other when lid is > closed, wakeup events can be triggered inadventertly. > > So let's disable the wakeup by default, but enable the wakeup capability > so users can enable it at their own discretion. > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> > Reviewed-by: Hans de Goede <hdegoede@redhat.com> > Signed-off-by: Jiri Kosina <jkosina@suse.cz> > (cherry picked from commit 52c978955c6475603c41aecba8fad587add9facd) This SHA is not present in Linus tree - where does it come from? If you are cherry-picking from any tree other than Linus, you should append it to the cherry-picked line.
On Thu, Sep 17, 2020 at 4:11 PM Paolo Pisati <paolo.pisati@canonical.com> wrote: > > On Thu, Sep 17, 2020 at 10:23:09AM +0800, Koba Ko wrote: > > From: Kai-Heng Feng <kai.heng.feng@canonical.com> > > > > BugLink: https://bugs.launchpad.net/bugs/1888331 > > > > Many laptops can be woken up from Suspend-to-Idle by touchpad. This is > > also the default behavior on other OSes. > > > > However, if touchpad and touchscreen contact to each other when lid is > > closed, wakeup events can be triggered inadventertly. > > > > So let's disable the wakeup by default, but enable the wakeup capability > > so users can enable it at their own discretion. > > > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> > > Reviewed-by: Hans de Goede <hdegoede@redhat.com> > > Signed-off-by: Jiri Kosina <jkosina@suse.cz> > > (cherry picked from commit 52c978955c6475603c41aecba8fad587add9facd) > > This SHA is not present in Linus tree - where does it come from? If you are > cherry-picking from any tree other than Linus, you should append it to the > cherry-picked line. > -- > bye, > p. It's from linux-next, so should I send the v2 to correct this?
On Thu, Sep 17, 2020 at 05:18:29PM +0800, Koba Ko wrote: > On Thu, Sep 17, 2020 at 4:11 PM Paolo Pisati <paolo.pisati@canonical.com> wrote: > > It's from linux-next, so should I send the v2 to correct this? I'll fix it when applying the patch.
On Thu, Sep 17, 2020 at 10:23:09AM +0800, Koba Ko wrote: > From: Kai-Heng Feng <kai.heng.feng@canonical.com> > > BugLink: https://bugs.launchpad.net/bugs/1888331
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index dbd04492825d..87ff93bf76ba 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -935,6 +935,14 @@ static void i2c_hid_acpi_fix_up_power(struct device *dev) acpi_device_fix_up_power(adev); } +static void i2c_hid_acpi_enable_wakeup(struct device *dev) +{ + if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) { + device_set_wakeup_capable(dev, true); + device_set_wakeup_enable(dev, false); + } +} + static const struct acpi_device_id i2c_hid_acpi_match[] = { {"ACPI0C50", 0 }, {"PNP0C50", 0 }, @@ -949,6 +957,8 @@ static inline int i2c_hid_acpi_pdata(struct i2c_client *client, } static inline void i2c_hid_acpi_fix_up_power(struct device *dev) {} + +static inline void i2c_hid_acpi_enable_wakeup(struct device *dev) {} #endif #ifdef CONFIG_OF @@ -1076,6 +1086,8 @@ static int i2c_hid_probe(struct i2c_client *client, i2c_hid_acpi_fix_up_power(&client->dev); + i2c_hid_acpi_enable_wakeup(&client->dev); + device_enable_async_suspend(&client->dev); /* Make sure there is something at this address */