On Wed, Oct 11, 2017 at 12:56:33PM +0100, Daniel Stone wrote: > Hi Alex, > > On 11 October 2017 at 12:22, Alex Ivanov <gnidorah@xxxxx> wrote: > > On 11.10.2017 13:13, Daniel Stone wrote: > >> 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. > > Unfortunately it is indeed quite complex, but this approach doesn't > fundamentally remove complexity, but instead _add_ it. I'd much rather > fix these problems at the source - add idle-inhibition or DPMS support > where required to compositors and clients - than try to route around > it. Yes now that I understand that your goal is to just bypass the compositor it's clear to me we don't want this. Implementing a compositor is hard, hacking around broken compositors is worse. As Daniel explained, changing kms state behind the compositor's back is not going to work reliably either. Please fix your userspace. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
