On Wed, Sep 9, 2015 at 4:55 PM, Oliver Neukum <oneukum@xxxxxxxx> wrote: > On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote: >> > Note that when the screen is turned-on again, we want to resume the >> > touchscreen so that it can send events again. > > Why is it impractical to close the fd for the touchscreen? > I am not sure, but I think it is this way due to historical reasons. On Android devices early-suspend was used originally to save power when the screen was turned-off but the device was not suspend. Later Android moved to power HAL [1] and run-time PM for some devices, however that is not sufficient for touchscreen. i2c touchscreen devices usually have two low-power states: a deep power state where event collection is disabled and the device needs to be poked via i2c to restart collecting events and a shallow power state where the device reduces the internal polling rate after it is idle for some time. The latter it is usually implemented directly in hardware. That means that you can't really implemented auto-suspend with the deep power state, since the device can not resume itself. To address this limitation, Android used early suspend (and then the power HAL mechanism) where the upper layers signals when you can turn on or off certain devices. I have added Colin and Arve to this thread who maybe can answer this better. >> In fact, then, what you need seems to be the feature discussed by Alan >> and me some time ago allowing remote wakeup do be disabled for runtime >> PM from user space as that in combination with autosuspend should >> address your use case. > > I'd doubt that. Suppose you put the phone into your pocket while > the device isn't suspended. The continuous stream of spurious events > will keep it awake. I agree. > The ability to disable remote wakeup is necessary but not sufficient. > I don't know enough about remote wake-up, but do we even need to use it for this kind of devices? -- 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
