On Wed, Dec 09, 2009 at 10:08:16PM +0100, Pavel Machek wrote:

quoted

quoted

quoted

I refuse it because it will be supported by exactly 1 driver in the
kernel - gpio-keys. It is the only driver that allows shut half of the
"device" (because in reality it is a group of disjoint devices). It is
the only case when "muting" a button means that IRQ is shut off abnd
thus CPU can continue to sleep if that button is pressed. For all other
devices that have 1 inettrupt per device, you still have to wake up,
because you don't know whether the button that generated event is
"important" or not.

Fair enough.

quoted

Now, there is a issue of waking up userspace task, additional scheduling
and keeping CPU running longer than necessary for "uninteresting" keys.
This can be solved by implementing a subscription model which allows
filtering uninteresing events on a per-client basis at evdev level.

Right. And for gpio_keys, this would be dine on the driver level.

But the semantics are different - if done on driver level you'd be
affecting _all_  consumers of the device; what I want to be done only
affects owner of the file descriptor.

Well, if _all_ consumers decide to ignore some key, we should be able
to ignore it at driver level.

The intesection of drivers allowing shut off individual buttons with
all consumers agreeing on not using a key would be pretty miniscule.

And actually it may make some sense -- I do not think disabling irq
during runtime is worth the effort, but disabling wakeup source and
getting rid of unneccessary wakeup when system is suspended is
probably worth it.

I don't believe Mika's patches touched wakeup in any way. So it has
been strictly about wakig up processor to service that interrupt so far.

-- 
Dmitry