On 11.10.2017 13:13, Daniel Stone wrote:
I'm sorry, but this is not the right way to go about things. If Xorg or GNOME Shell or Weston or whatever thinks the monitor is DPMS-off, the fact that someone else has forcibly switched it back on will not make them continue painting.
User should disable DPMS management of display server before using this ioctl.
Conversely, if they are painting and someone does DPMS-off from underneath them, they'll keep painting anyway: if they're using the legacy API that means the display will switch straight back on, and if they're using atomic that means their commits will suddenly fail for an unknown reason and they'll be very confused.
That's sad to hear. Is that the reason why xf86-video-intel driver switches the display back on, while modesetting driver doesn't do anything? DPMS is disabled in X.Org config.
If people are doing fancy new compositors without DPMS support, then I recommend they use an existing compositor base, such as libweston (others are also available) which actually implement DPMS. For Electron apps, there are a number of idle-inhibition options available for X11, and also for Wayland when that support lands in Electron. Unfortunately I don't think there is any way to just route around the compositor as this patch does.
libweston is still too tied to Weston at this moment, and other libraries are still underway. Your phrase is a great marker of how much complexity and trickery for user is added into display power management in comparison to power management of other components.
Cheers, Daniel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
