Thread (101 messages) 101 messages, 11 authors, 2020-12-11

Re: [PATCH v4 0/7] Support inhibiting input devices

From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: 2020-06-10 14:02:02
Also in: linux-acpi, linux-arm-kernel, linux-iio, linux-pm, linux-samsung-soc, linux-tegra, lkml, platform-driver-x86

On Wed, Jun 10, 2020 at 3:21 PM Hans de Goede [off-list ref] wrote:
Hi,

On 6/10/20 3:12 PM, Andrzej Pietrasiewicz wrote:
quoted
Hi All,
[cut]
quoted
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.

Note I agree with you that the way this works is not
ideal, I just do not think that we can change it.
Please note that "no users" merely means that user space is not
interested in receiving and processing the events from that device.

If it is configured for system wakeup, it doesn't matter whether or
not user space will consume the related events.

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