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? Thanks. -- Dmitry -- 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
