On Wed, 11 Oct 2017, Alex Ivanov wrote:
> On 11.10.2017 12:04, Daniel Vetter wrote:
>>
>> Why exactly is the existing dpms ioctl not good enough? it's implemented
>> as the "DPMS" property attached to connectors, but that's the only
>> difference compared to your code here.
>>
>> Also, that one do
On Wed, Oct 11, 2017 at 12:56:33PM +0100, Daniel Stone wrote:
> Hi Alex,
>
> On 11 October 2017 at 12:22, Alex Ivanov 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
Hi Alex,
On 11 October 2017 at 12:22, Alex Ivanov 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 implemen
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 disab
On 11.10.2017 12:04, Daniel Vetter wrote:
Why exactly is the existing dpms ioctl not good enough? it's implemented
as the "DPMS" property attached to connectors, but that's the only
difference compared to your code here.
Also, that one doesn't have any XXX about atomic like yours.
I also hav
Hi,
On 11 October 2017 at 08:46, Alex Ivanov wrote:
> Display power management should be available to user no matter whether
> display server implements it or not and should be made server agnostic
> (X.Org, Wayland compositor), without need of TTY change.
>
> Reasons:
> 1. User implements an own
On Wed, Oct 11, 2017 at 10:46:44AM +0300, Alex Ivanov wrote:
> Display power management should be available to user no matter whether
> display server implements it or not and should be made server agnostic
> (X.Org, Wayland compositor), without need of TTY change.
>
> Reasons:
> 1. User implement
Display power management should be available to user no matter whether
display server implements it or not and should be made server agnostic
(X.Org, Wayland compositor), without need of TTY change.
Reasons:
1. User implements an own universal power management daemon. He has no
interest to deal wi