Hi!

quoted

quoted

quoted

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.

Well; people want to do that on specialized hw/embedded sw. It could
work there. 

quoted

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.

I think it makes sense for wakeups; I doubt it makes sense for runtime
- the power savings are just not big enough.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html