On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:

On Sun, Dec 06, 2009 at 09:47:04AM +0100, Pavel Machek wrote:

quoted

Hi!

quoted

But runtime-pm.txt says for example:

    Generally, remote wake-up should be enabled for all input devices
    put into a low power state at run time.

But in this case the requirement is to suppress input events from a
given device, effectively muting and putting it into low power state,
even though it's still open by some other parties.  Runtime PM, on the
other hand tries not to interfere with the normal usage of the device.

Later:

(3) ->runtime_idle() and ->runtime_suspend() can only be executed for a
    device the usage counter of which is equal to zero _and_ [...]

which underlines the difference again: the usage counter (defined by
common sense) won't be zero in our case, because the device is
constantly kept open, while we want to mute it, putting it into a low
power state. 

...

quoted

Actually, this could be implemented by the various users cooperating in
closing the device, letting it go to sleep automatically.  But this
requires strictly cooperating parties and is more complicated that
flipping some master switch of the device.  We're looking for this
master switch, before needlessly building our own.

Please just close the device properly. I do not think we want 100
different 'please mute keys A and G', 'please mute middle mouse button',
... interfaces anywhere near mainline.

I do not think it is practical to simply close the device, given that
there may be several applications that have it open. I constantly see
embedded guys adding custom knobs to the devices allowing them to shut
off the device when not in use. Kind of runtame PM but user-initiated.

I would really love to have it implemented in the driver core so the
interface is the same for all drivers (that support this future).

quoted

Or just do it as local patch.

I also see that gpio-keys is quite different in the sence that it can
shut off buttons selectively. I fact, at the moment every button can be
considered a separate device... But that would be too much overhead.

They could probably split the keys into 2 groups (critical that should
be always active) and not critical, that could be shut off, but I think
they want teh flexibility of controlling this at runtime instead of
doing it in board data.

I suggested including this into the "abstract input device" model, but
you refuse this. But I still think it is a good idea.

Indeed, if we look at an input device as at something abstract which has
many keys, why we cannot assume that separate keys can be
enabled/disabled? Just imagine you have a very advanced keybord :-) And
we simply implement an ioctl which enables/disables a specific key. The
generic layers just pass this ioctl down to the lower lever drivers. If
the specific input device or driver support it - fine, if not - it
returns -EINVAL or something like that.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html