-
Notifications
You must be signed in to change notification settings - Fork 29
Add protocol to toggle output dpms #56
Comments
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.
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. |
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? |
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. |
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:
so things like only turning off would be the special case nowadays. |
So should we only keep |
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"?
If we're going for on/off, I'd call it something like (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?) |
I wonder if removing the DRM connector from the CRTC ( |
This was my long term plan too. Maybe we use output-power-management and only do 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 |
Something like that, yeah. We can discuss the details in a pull request. :) I'm not sure
Yeah, that makes sense. |
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: swaywm#56
This specifies how to control power management modes of outputs. Closes: #56
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 onoff
. 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.The text was updated successfully, but these errors were encountered: