On Wednesday, September 09, 2015 06:02:02 PM Octavian Purdila wrote: > 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. Why would they be regarded as spurious then? They are just regular touch panel events in that case, aren't they? > 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? Well, if the device is capable of generating wakeup events while suspended, the current expected behavior is to do that, but of course that needs to be enabled by the driver/bus type too. Thanks, 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
