Add protocol to toggle output dpms

[agx]

Since #38 doesn't deal with output DPMS it would be good to be able to toggle an output's power save mode via a wayland protocol. I have put together a prototype in phoc/phosh to see how things go:

https://source.puri.sm/Librem5/phoc/merge_requests/60/diffs#808a606abe792c793cb5ed64b63f99d6dcb86a60_77_82

If it makes sense I'd like to turn it into a wlr-output-dpms so phosh can continue to run with other compositors and other shell's/daemons don't need to grow custom protocol. In this case should we still call it DPMS? Modern drm mostly treats it as legacy and does on/off only. However keeping different states gives the compositor more room like e.g. only turning off the backlight on standby and fully turning off the display pipeline on off. This is something e.g. needed on a phone since the time to bring back the display pipeline from off is too long when the user expects a quick unblank.

[ddevault]

Do we need a whole protocol for this or can't we just update wlr-output-management?

[emersion]

Do we need a whole protocol for this or can't we just update wlr-output-management?

-1. Clients interested in output management (deamons listening to hotplugs and output configuration apps) don't intersect with clients interested in power management (e.g. swayidle). Moreover output management deals with disabled outputs, power management doesn't.

However keeping different states gives the compositor more room like e.g. only turning off the backlight on standby and fully turning off the display pipeline on off. This is something e.g. needed on a phone since the time to bring back the display pipeline from off is too long when the user expects a quick unblank.

What would the logic be in the client to decide when to transition from suspend to off? Couldn't it be implemented in the compositor?

[agx]

What would the logic be in the client to decide when to transition from suspend to off? Couldn't it be implemented in the compositor?

I was thinking to keep policy out of the compositor (go from standby to off after n minutes, standby is enough when not running on battery, power off faster when only background tasks are running). While all of this could be done in the compositor other systems have more knowledge about this.

[emersion]

I was thinking to keep policy out of the compositor

This makes sense, but I'm wondering whether it's fine to have suspend in a general protocol. What kind of API would the compositor have to shut down the whole display pipeline? Is this somewhat exposed via DRM?

[ascent12]

I'm not really convinced about the general applicability of this. The option of having various states (e.g. affecting backlight control) is not something that applies to desktops, and as you mentioned, they are completely useless in modern DRM, which reflects how LCDs work.

If its up to compositor policy as to how it treats these states, it limits how useful this really is to general purpose clients. I see the kind of backlight control thing to be more suited to being handled by the compositor or private extensions.

[agx]

This makes sense, but I'm wondering whether it's fine to have suspend in a general protocol. What kind of API would the compositor have to shut down the whole display pipeline? Is this somewhat exposed via DRM?

Atomic modeset basically does only on/off only already (shutting down the whole pipeline e.g. in the case of a LCD panel: panel, dphy, dsi host controller, display controller). Waking things up again takes a considerable amoun of time. See e.g. https://www.kernel.org/doc/html/latest/gpu/drm-client.html:

For atomic drivers mode is reduced to on/off.

so things like only turning off would be the special case nowadays.

[agx]

So should we only keep on/off? Should we still call the protocol dpms then?

[emersion]

Atomic modeset basically does only on/off only already

Oh okay. Then what kind of API would you use to only go to suspend without tearing down the whole pipeline? The sysfs backlight "API"?

So should we only keep on/off? Should we still call the protocol dpms then?

If we're going for on/off, I'd call it something like output-power-management or output-blanking.

(In my Future Plans I want to make it so the screen backlight is exposed as a DRM property on the connector instead of as a sysfs file. This would make a lot more sense and would allow to control the backlight per screen. Maybe backlight could be part of the protocol when that happens?)

[ascent12]

I wonder if removing the DRM connector from the CRTC (CRTC_ID=0), but leaving ACTIVE=1 on the CRTC works as a kind of lightweight screen-blanking, since it's not actually tearing down the display pipeline. I can't say I've tried that before or that's what it's intended to be.

[agx]

(In my Future Plans I want to make it so the screen backlight is exposed as a DRM property on the connector instead of as a sysfs file. This would make a lot more sense and would allow to control the backlight per screen. Maybe backlight could be part of the protocol when that happens?

This was my long term plan too. Maybe we use output-power-management and only do on/off as an enum for the moment adding other states like backlight_off later on?

Short term i'll just use GNOME settings daemon to turn down the backlight (which uses the sysfs interface). My main point was to have a protocol that is extendable enough so we can do that later on e.g. via the DPMS suspend state in the protocol or something completely new.

[emersion]

Maybe we use output-power-management and only do on/off as an enum for the moment adding other states like backlight_off later on?

Something like that, yeah. We can discuss the details in a pull request. :)

I'm not sure backlight_off/suspend will be a state. If we add backlight, we'll probably also want to allow clients to set the backlight value (in %)?

Short term i'll just use GNOME settings daemon to turn down the backlight (which uses the sysfs interface). My main point was to have a protocol that is extendable enough so we can do that later on e.g. via the DPMS suspend state in the protocol or something completely new.

Yeah, that makes sense.