On 2014-07-19 01:16, Dmitry Torokhov wrote:
<snip>
I'd say no.
Anyway, even though it is very tempting to declare inhibit a "deeper"
state of
runtime suspend maybe you are right and inhibit should really be
separate from
PM and drivers would have to sort out all the possible state
permutations.
Considering input devices:
input_open(): check if device is inhibited, if so do nothing. Otherwise
try
waking up itself and parent (via pm_runtime_get_sync() on itself), this
will
power up the device. Do additional configuration if needed.
input_close(): check if device is inhibited, if not do pm_runtime_put
(_sync?
to make sure we power off properly and not leave device up and running?
or
should we power down manually not waiting for runtime PM)?
inhibit(): check if device is opened, if opened do
pm_runtime_put_sync().
uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime
PM
bring up the device. Do additional config if needed -> very similar to
input_open(), different condition.
runtime_suspend(): power down the device. If not inhibited enable as
wakeup
source.
runtime_resume(): power up the device if device is opened and not
inhibited.
system_suspend(): check if device is opened, not inhibited and not in
runtimesuspend already; power down.
system_resume(): power up the device if it is opened and not inhibited.
I
guess it's OK to wake up device that shoudl be runtime-PM-idle since it
will
go to back sleep shortly.
Ugh.. This is complicated...
Seriously complicated. The compositor and/or X.org can handle most of
that for
input devices already. For the camera, you want the application to know
that
the device is present, but not usable, instead of making it vanish or
rendering
it unusable. And if you wanted to implement this in the kernel, even
with the aid
of a user-space daemon, you're still missing the most important part,
the device
tagging.
Once you've tagged the devices which would need to be left alone when
the lid is
closed, or the laptop is in tablet mode, see if the problem can be
solved within
user-space alone. I'm fairly certain it wouldn't take too long to fix
Xorg
or a state-of-the-art compositor to behave properly.
All I see right now is making it harder to write devices drivers with no
real benefits.
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
