On Wednesday, March 16, 2011, Dmitry Torokhov wrote:

On Tue, Mar 15, 2011 at 12:58:46PM +0000, Alan Cox wrote:

quoted

quoted

I'd be more happy if it was just an input device. If non-wired interrupt
is a common case then we should probably add polled input device mode,

I can't really answer how common it is or would be - its a generic chip
that is used on all sorts of equipment

quoted

but we certainly should not register completely non-functional input
device as the driver does now.

Agreed

quoted

We also have a way of retrieving current (or rather most recent)
coordinates via EVIOCGABS so I am not sure why we want the sysfs way of
retrieving coordinates as well.

The sysfs way comes about because the devices are very very power
oriented, waking up and polling regularly burns power, hence also the
power control side. Opening an input device would power it up for the
duration it was open and the polling would cause a lot of wakeups burning
power.

Doing open/EVIOCGABS/close to avoid that aspect of the input layer
won't ensure you get current data that I can see - because an IRQ may not
have occurred between the open and the EVIOCGABS so any data may be very
stale or non-existent.

I would be perfectly fine with a driver that does refresh it's state in
dev->open() if we expect that data might be stale. We normally do not do
that because old data is normally not interesting for touchpads, mice or
keyboards and we not always have option of querying current hardware
state.

quoted

The polled case looks trivial to sort but for an IRQ driver driver it
looks like you would need a new "get co-ordinates right now" optional
method tht EVIOCGABS would use if available ?

quoted

Regarding power mode - I really believe that this should be done on the
driver core level instead of implementing "manual off" in every single
driver out there.

Definitely - not sure what plans Rafael has there ?

Last time we discussed this we were talking about sysfs entry at the
driver core level allowing userspace to "expire" idle timer and force
runtime PM action. Rafael, did I remember that right?

Well, I'm not exactly sure what the question is about. :-)

There's the family of pm_*_autosuspend() routines in the runtime PM
framework (recently introduced by Alan Stern) that allow you to use delay
timers and deal with them automatically (as described in
Documentation/power/runtime_pm.txt, Section 9).

Is that what you mean?

Rafael