On Wednesday, March 16, 2011, Dmitry Torokhov wrote: > On Tue, Mar 15, 2011 at 12:58:46PM +0000, Alan Cox wrote: > > > 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 > > > > > but we certainly should not register completely non-functional input > > > device as the driver does now. > > > > Agreed > > > > > 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. > > > > > 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 ? > > > > > 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 -- 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
