The Inhibited Wayland Desktop – Part 2
This article is part one of a two part series on screen inhibition in Wayland:
In the first part of this blog series, I drilled into how screensaving, screen power management, and locking are designed to work in the Wayland protocol and how Weston implements the functionality. Now it’s time to take a look at the newly-proposed idle behavior inhibition.
Idle inhibition enables client applications to disable the idle behavior from being triggered while the application is running. For compositors that support this protocol extension, clients can make an API call to create an ‘inhibitor object’ associated with one of their surfaces. The inhibition request lasts for this object’s lifetime, so if the client exits, crashes, deletes the inhibit object or the surface, or otherwise becomes invalid, the screensaver will be restored to its normal state. The client can also drop their inhibition request by simply deleting their inhibitor object.
The idle inhibit protocol for Wayland doesn’t specify exactly what must happen when a client requests inhibition, and different compositors can make different decisions about what it means. In Weston, for example, this will inhibit screen locking and display power management (DPMS); there is no screensaver apart from the lock screen.
Likewise, it is left to the compositor’s policy as to when to honor inhibition requests and when to ignore them. For instance, one compositor might honor it for any application that covers more than a quarter of the screen; another might take into account the type of display the application is on. In Weston, the inhibition request is only honored if the client application’s surface is considered “active”.
Different Weston shells can define what “active” means in this context. For Weston’s desktop shell this is an application with a keyboard focus. Desktop shells can have multiple “seats” – i.e. multiple users, each with their own keyboard and mouse, sharing the same set of displays. It’s conceivable that each user’s keyboard might have its own inhibition active on different surfaces and/or displays.
Previously, there was a single idle counter that all seats poked whenever they got input from their user. With this patchset, each seat gets its own idle counter, meaning that shells can connect an inhibit to an active surface with the seat generating the input events for that surface. Even though idle is now tracked per-seat, the Weston sleep state is still global. That is to say, idle will only kick on when all users are idle. There’s no provision for, say, showing the lock screen for one user’s display while another user on a different seat is actively typing in a client shown on a different display.
Keyboard focus is just one possible scheme a Weston shell could use for tracking activity. A shell might set the “active” surface based on which surface has the largest amount of screen real estate, specific application identities, or some other scheme. Again, this whole notion of “activity” is not part of the Wayland protocol, but rather an implementation detail particular to Weston.
Applications for Inhibition
How might this functionality conceivably be employed by users?
Automotive infotainment systems are using Wayland and Weston via its IVI backend. In configurations with multiple displays for driver and passengers one might wish to provide inhibition support in the movie player, but otherwise have aggressive idling on games, information screens, and so on. On the driver’s display you might inhibit idle behavior across the board, and only allow idling when no application is running.
Smart TVs and DVRs would be another logical place for inhibition. Generally any video should inhibit, but UI screens or during a video pause screen power saving should be allowed to kick in. Perhaps certain apps running on the TV permit dimming and/or powering down the display, such as music playback, or audio-only news broadcasts. The Wayland inhibition protocol provides a clean way of managing all of this.
Certain kinds of kiosk applications might find this functionality of use, where a user interaction (e.g. button press) wakes the system and starts up an application. While the application runs, the display power management is inhibited. Then when the application exits, power management resumes normally until the next patron engages it.
One of the promises of the Internet of Things is a higher level of integration between discrete devices, this includes some awareness of our presence. For example, a smartwatch with an activity sensor that can detect when you’ve fallen asleep and trigger the television to power down.
There are of course a rich assortment of idle inhibition use cases for desktop environments.
An important use case to get right is presentation. You connect your laptop (running on battery with aggressive power savings settings) to the projector and run your slide software. This software holds an inhibit in the compositor so if you spend an especially long time talking on one slide the screensaver doesn’t come on. Once you finish, you alt-tab out of the slide software (neglecting to actually terminate it). Fortunately, the loss of active status is sufficient to restore your system’s regular idle behavior, and your laptop again minimizes power usage effectively while you’re busy chatting with attendees and whatnot.
Another interesting desktop use case is movie playback on one display, while allowing the other unused displays to be blanked or powered down. The movie player app would establish an inhibit so you can continue watching the movie while the rest of your system’s displays sleep.
With the Wayland idle inhibit protocol, we’ve limited its scope to functionality that pertains to display: Screensaving, blanking, locking, display power management, and dimming. Generalizing this concept further, there are a range of other software services that could benefit from awareness of the user’s state, and might benefit from some sort of analogous inhibition support.
In designing this protocol with the presentation and movie playback use cases in mind, popup notices were considered for inclusion. Obviously you wouldn’t want these randomly popping up while you’re giving a talk, and probably would want to filter out unimportant ones while watching a movie; a method for the client to inhibit them seems logical. Similarly for sound notifications like private message alerts. But these are all probably better managed through various established intra-client communication paths (e.g. d-bus), and were omitted from the idle inhibit protocol.
Is there an even broader generalization we should consider here? Certainly, if we remove the limitation of sticking to display management only and consider the notion of idle more broadly a number of other ideas come to mind. For example, inhibition in relation to desktop telephony makes an interesting use case. When a call comes in and is answered, the telephony app would request inhibition (i.e. pausing) on all video players, music players, and games, and then resume at the end of the call. While ideas like this are not good fits for Wayland, it’s not clear where such a functionality should be implemented in the software stack.
The Wayland idle inhibit protocol is currently under review by the core Wayland development team, but hasn’t landed at the time of this writing, and thus is subject to change. It is unlikely the general behavior will change, but details about request or event names or parameters could be adjusted. The Weston implementation is under a separate review, and is more likely to be changed before it lands. If you want to keep up with development on this, feel free to join the Wayland development mailing list.