On Sun, 10 Oct 2010, Dmitry Torokhov wrote: > > > OK, so how is a graphics driver going to figure out it should suspend when the > > > button is pressed in the example above? > > > > The graphics driver doesn't have to figure that out at all. It merely > > has to suspend the display whenever it can, i.e., whenever the usage > > count drops to 0 (or equivalently, whenever the runtime_idle callback > > runs). > > That makes sense for drivers that do very agressive PM, but fails for > cases when you have bigger timeouts. My phone shuts off its display > automatically after 30 seconds or a minute but I have an option of > pressing a button which causes it to shut off immediately. > > > > > It's up to userspace to make sure that the display's usage count goes > > to 0 at the proper time, i.e., when the button is pressed. Contrary to > > what you wrote above, we _do_ have an interface for this at the PM core > > level: power/control. > > > > I think that while using power/control is a _very_ good option "auto" > and "on" are not enough, we need 3 states: "on", "off" and "auto". Will the driver use autosuspend for the 30-second delay? Then all you have to do is this: When the button is pressed, write 0 to power/autosuspend_delay_ms, causing an immediate runtime suspend. Then before turning the display back on, write 30000 to set the delay to 30 seconds again. You can leave power/control set to "auto" the whole time. I don't like the idea of having an "off" setting in power/control. What happens if the user turns a disk drive controller "off" and the system needs to read or write something on that disk drive? Alan Stern -- 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
