From: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
To: Hans de Goede <hdegoede@redhat.com>,
"Rafael J. Wysocki" <rafael@kernel.org>
Cc: Linux PM <linux-pm@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-iio@vger.kernel.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Samsung SoC <linux-samsung-soc@vger.kernel.org>,
linux-input@vger.kernel.org,
linux-tegra <linux-tegra@vger.kernel.org>,
patches@opensource.cirrus.com,
ibm-acpi-devel@lists.sourceforge.net,
Platform Driver <platform-driver-x86@vger.kernel.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Jonathan Cameron <jic23@kernel.org>,
Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Kukjin Kim <kgene@kernel.org>
Subject: Re: [PATCH v4 0/7] Support inhibiting input devices
Date: Wed, 10 Jun 2020 15:41:13 +0200 [thread overview]
Message-ID: <2d5fd063-66bc-c707-4041-84a17c0a7d04@collabora.com> (raw)
In-Reply-To: <3e61c9c1-b211-da9f-c55b-b44eb6522f2a@redhat.com>
Hi Hans,
W dniu 10.06.2020 o 15:21, Hans de Goede pisze:
> Hi,
>
> On 6/10/20 3:12 PM, Andrzej Pietrasiewicz wrote:
>> Hi All,
>>
>> W dniu 10.06.2020 o 12:38, Rafael J. Wysocki pisze:
>>> On Wed, Jun 10, 2020 at 11:50 AM Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> On 6/8/20 1:22 PM, Andrzej Pietrasiewicz wrote:
>>>>> This is a quick respin of v3, with just two small changes, please see
>>>>> the changelog below.
>>>>>
>>>>> Userspace might want to implement a policy to temporarily disregard input
>>>>> from certain devices.
>>>>>
>>>>> An example use case is a convertible laptop, whose keyboard can be folded
>>>>> under the screen to create tablet-like experience. The user then must hold
>>>>> the laptop in such a way that it is difficult to avoid pressing the keyboard
>>>>> keys. It is therefore desirable to temporarily disregard input from the
>>>>> keyboard, until it is folded back. This obviously is a policy which should
>>>>> be kept out of the kernel, but the kernel must provide suitable means to
>>>>> implement such a policy.
>>>>
>>>> First of all sorry to start a somewhat new discussion about this
>>>> while this patch set is also somewhat far along in the review process,
>>>> but I believe what I discuss below needs to be taken into account.
>>>>
>>>> Yesterday I have been looking into why an Asus T101HA would not stay
>>>> suspended when the LID is closed. The cause is that the USB HID multi-touch
>>>> touchpad in the base of the device starts sending events when the screen
>>>> gets close to the touchpad (so when the LID is fully closed) and these
>>>> events are causing a wakeup from suspend. HID multi-touch devices
>>>> do have a way to tell them to fully stop sending events, also disabling
>>>> the USB remote wakeup the device is doing. The question is when to tell
>>>> it to not send events though ...
>>>>
>>>> So now I've been thinking about how to fix this and I believe that there
>>>> is some interaction between this problem and this patch-set.
>>>>
>>>> The problem I'm seeing on the T101HA is about wakeups, so the question
>>>> which I want to discuss is:
>>>>
>>>> 1. How does inhibiting interact with enabling /
>>>> disabling the device as a wakeup source ?
>>>>
>>>> 2. Since we have now made inhibiting equal open/close how does open/close
>>>> interact with a device being a wakeup source ?
>>>>
>>>> And my own initial (to be discussed) answers to these questions:
>>>>
>>>> 1. It seems to me that when a device is inhibited it should not be a
>>>> wakeup source, so where possible a input-device-driver should disable
>>>> a device's wakeup capabilities on suspend if inhibited
>>>
>>> If "inhibit" means "do not generate any events going forward", then
>>> this must also cover wakeup events, so I agree.
>>
>> I agree, too.
>>
>>>
>>>> 2. This one is trickier I don't think we have really clearly specified
>>>> any behavior here. The default behavior of most drivers seems to be
>>>> using something like this in their suspend callback:
>>>>
>>>> if (device_may_wakeup(dev))
>>>> enable_irq_wake(data->irq);
>>>> else if (input->users)
>>>> foo_stop_receiving_events(data);
>>>>
>>>> Since this is what most drivers seem to do I believe we should keep
>>>> this as is and that we should just clearly document that if the
>>>> input_device has users (has been opened) or not does not matter
>>>> for its wakeup behavior.
>>>>
>>>> Combining these 2 answers leads to this new pseudo code template
>>>> for an input-device's suspend method:
>>>>
>>>> /*
>>>> * If inhibited we have already disabled events and
>>>> * we do NOT want to setup the device as wake source.
>>>> */
>>>> if (input->inhibited)
>>>> return 0;
>>
>> Right, if a device is inhibited it shouldn't become a wakeup source,
>> because that would contradict the purpose of being inhibited.
>
> Ack. Note I do think that we need to document this (and more
> in general the answer to both questions from above) clearly so
> that going forward if there are any questions about how this is
> supposed to work we can just point to the docs.
>
> Can you do a follow-up patch, or include a patch in your next
> version which documents this (once we agree on what "this"
> exactly is) ?
Sure I can. Just need to know when "this" becomes stable enough ;)
If this series otherwise looks mature enough I would opt for a
follow-up patch.
>
>>>>
>>>> if (device_may_wakeup(dev))
>>>> enable_irq_wake(data->irq);
>>
>> What would it mean to become a wakeup source if there are no users,
>> or nobody has ever opened the device? There are no interested
>> input handlers (users) so what's the point of becoming a wakeup
>> source? Why would the system need to wake up?
>
> Well this is what we have been doing so far, so arguably we
> need to keep doing it to avoid regressions / breaking our ABI.
>
> Lets for example take a laptop, where when suspended the
> power-button is the only valid wakeup-source and this is
> running good old slackware with fvwm2 or windowmaker as
> "desktop environment", then likely no process will have
> the power-button input evdev node open. Still we should
> wakeup the laptop on the power-button press, otherwise
> it will never wakeup.
>
True, thanks for explaining.
> Note I agree with you that the way this works is not
> ideal, I just do not think that we can change it.
>
Regards,
Andrzej
next prev parent reply other threads:[~2020-06-10 13:41 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200506002746.GB89269@dtor-ws>
2020-05-15 16:49 ` [PATCHv2 0/7] Support inhibiting input devices Andrzej Pietrasiewicz
[not found] ` <20200515164943.28480-1-andrzej.p-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2020-05-15 16:51 ` [PATCHv2 1/7] Input: add input_device_enabled() Andrzej Pietrasiewicz
2020-05-15 16:51 ` [PATCHv2 2/7] Input: use input_device_enabled() Andrzej Pietrasiewicz
2020-05-15 16:52 ` [PATCHv2 6/7] Input: Add "inhibited" property Andrzej Pietrasiewicz
2020-05-15 18:19 ` [PATCHv2 0/7] Support inhibiting input devices Hans de Goede
[not found] ` <842b95bb-8391-5806-fe65-be64b02de122-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2020-05-17 22:55 ` Peter Hutterer
2020-05-18 2:40 ` Dmitry Torokhov
2020-05-18 7:36 ` Hans de Goede
2020-05-22 15:35 ` Andrzej Pietrasiewicz
2020-05-27 6:13 ` Peter Hutterer
2020-05-18 10:48 ` Andrzej Pietrasiewicz
[not found] ` <e6030957-97dc-5b04-7855-bc14a78164c8-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2020-05-18 12:24 ` Hans de Goede
2020-05-18 13:49 ` Andrzej Pietrasiewicz
2020-05-18 14:23 ` Hans de Goede
2020-05-19 9:02 ` Andrzej Pietrasiewicz
2020-05-19 9:36 ` Hans de Goede
[not found] ` <aa2ce2ab-e5bc-9cb4-8b53-c1ef9348b646-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2020-05-27 6:34 ` Dmitry Torokhov
2020-06-02 16:56 ` Andrzej Pietrasiewicz
2020-06-02 17:52 ` Dmitry Torokhov
2020-06-02 18:50 ` Andrzej Pietrasiewicz
2020-06-02 20:19 ` Hans de Goede
[not found] ` <8f97d2e1-497a-495d-bc82-f46dbeba440c-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2020-06-03 13:07 ` Andrzej Pietrasiewicz
2020-06-03 17:38 ` Hans de Goede
2020-06-03 17:54 ` Andrzej Pietrasiewicz
2020-06-03 19:37 ` Hans de Goede
2020-06-04 7:28 ` Dmitry Torokhov
2020-06-05 17:33 ` [PATCH v3 " Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 3/7] ACPI: button: Access input device's users under appropriate mutex Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 5/7] iio: adc: exynos: Use input_device_enabled() Andrzej Pietrasiewicz
[not found] ` <20200605173335.13753-6-andrzej.p-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2020-06-05 19:49 ` Michał Mirosław
[not found] ` <20200605173335.13753-1-andrzej.p-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2020-06-05 17:33 ` [PATCH v3 1/7] Input: add input_device_enabled() Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 2/7] Input: use input_device_enabled() Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 4/7] ACPI: button: Use input_device_enabled() helper Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 6/7] platform/x86: thinkpad_acpi: Use input_device_enabled() Andrzej Pietrasiewicz
2020-06-07 20:24 ` [PATCH v3 0/7] Support inhibiting input devices Pavel Machek
2020-06-08 5:37 ` Dmitry Torokhov
2020-06-08 9:28 ` Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 7/7] Input: Add "inhibited" property Andrzej Pietrasiewicz
2020-06-05 17:41 ` Hans de Goede
[not found] ` <2336e15d-ff4b-bbb6-c701-dbf3aa110fcd-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2020-06-08 11:22 ` [PATCH v4 0/7] Support inhibiting input devices Andrzej Pietrasiewicz
2020-06-08 11:22 ` [PATCH v4 1/7] Input: add input_device_enabled() Andrzej Pietrasiewicz
2020-12-03 6:25 ` Dmitry Torokhov
2020-06-08 11:22 ` [PATCH v4 2/7] Input: use input_device_enabled() Andrzej Pietrasiewicz
2020-12-03 6:26 ` Dmitry Torokhov
[not found] ` <CGME20201207133237eucas1p26f8484944760a14e51dc7353ed33cd28@eucas1p2.samsung.com>
2020-12-07 13:32 ` Marek Szyprowski
2020-12-07 15:50 ` Andrzej Pietrasiewicz
2020-12-08 10:05 ` Marek Szyprowski
2020-12-09 6:37 ` Dmitry Torokhov
2020-12-11 7:09 ` [PATCH] Input: cyapa - do not call input_device_enabled from power mode handler Dmitry Torokhov
2020-12-11 8:22 ` Marek Szyprowski
2020-12-11 8:31 ` Dmitry Torokhov
2020-06-08 11:22 ` [PATCH v4 3/7] ACPI: button: Access input device's users under appropriate mutex Andrzej Pietrasiewicz
2020-06-24 15:00 ` Rafael J. Wysocki
2020-06-25 5:23 ` Dmitry Torokhov
2020-06-25 10:55 ` Rafael J. Wysocki
2020-10-05 5:08 ` Dmitry Torokhov
2020-06-08 11:22 ` [PATCH v4 4/7] ACPI: button: Use input_device_enabled() helper Andrzej Pietrasiewicz
2020-06-25 5:24 ` Dmitry Torokhov
2020-10-05 5:06 ` Dmitry Torokhov
2020-06-08 11:22 ` [PATCH v4 5/7] iio: adc: exynos: Use input_device_enabled() Andrzej Pietrasiewicz
[not found] ` <20200608112211.12125-6-andrzej.p-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2020-06-10 1:28 ` Michał Mirosław
2020-06-10 7:52 ` [FIXED PATCH " Andrzej Pietrasiewicz
2020-06-08 11:22 ` [PATCH v4 6/7] platform/x86: thinkpad_acpi: " Andrzej Pietrasiewicz
2020-06-08 11:22 ` [PATCH v4 7/7] Input: Add "inhibited" property Andrzej Pietrasiewicz
2020-10-05 18:10 ` Dmitry Torokhov
2020-10-06 13:04 ` Andrzej Pietrasiewicz
2020-10-07 1:11 ` Dmitry Torokhov
2020-10-07 1:12 ` Dmitry Torokhov
2020-12-03 6:26 ` Dmitry Torokhov
[not found] ` <20200608112211.12125-1-andrzej.p-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2020-06-10 9:49 ` [PATCH v4 0/7] Support inhibiting input devices Hans de Goede
2020-06-10 10:38 ` Rafael J. Wysocki
[not found] ` <CAJZ5v0hB2ra2K=dd9ZjVyy1V2b1PmFHm79uDO2HtHU1D_4YUbw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-06-10 13:12 ` Andrzej Pietrasiewicz
2020-06-10 13:21 ` Hans de Goede
2020-06-10 13:41 ` Andrzej Pietrasiewicz [this message]
[not found] ` <2d5fd063-66bc-c707-4041-84a17c0a7d04-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2020-06-12 8:30 ` Hans de Goede
2020-06-12 8:47 ` Andrzej Pietrasiewicz
2020-06-16 17:29 ` [PATCH] Input: document inhibiting Andrzej Pietrasiewicz
2020-06-16 17:38 ` Randy Dunlap
[not found] ` <20200616172909.21625-1-andrzej.p-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2020-06-17 7:44 ` Hans de Goede
[not found] ` <f9007f37-c526-5fa4-3188-a554d2434177-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2020-06-17 10:18 ` [PATCH v2] " Andrzej Pietrasiewicz
[not found] ` <20200617101822.8558-1-andrzej.p-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2020-06-17 10:21 ` Hans de Goede
2020-06-17 16:52 ` Randy Dunlap
2020-06-23 13:35 ` Pavel Machek
2020-12-03 6:27 ` Dmitry Torokhov
[not found] ` <3e61c9c1-b211-da9f-c55b-b44eb6522f2a-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2020-06-10 14:01 ` [PATCH v4 0/7] Support inhibiting input devices Rafael J. Wysocki
2020-06-10 13:52 ` Hans de Goede
2020-06-10 18:28 ` Dmitry Torokhov
2020-06-12 8:14 ` Hans de Goede
2020-06-12 8:17 ` Hans de Goede
2020-08-03 14:40 ` Andrzej Pietrasiewicz
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=2d5fd063-66bc-c707-4041-84a17c0a7d04@collabora.com \
--to=andrzej.p@collabora.com \
--cc=hdegoede@redhat.com \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=jic23@kernel.org \
--cc=kgene@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
/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).