How to prevent input devices from unblanking the X screen when DPMS is on?

How to prevent input devices from unblanking the X screen when DPMS is on?

[Merlijn Wajer]

[-- Attachment #1.1.1: Type: text/plain, Size: 1815 bytes --]

Hi,

Is it possible to have X handle input events, but not actually unblank
the screen upon input events when dpms is enabled?

Our use case (in Maemo Leste, GNU/Linux+Debian smartphone OS) is
reporting physical volume buttons to X clients when the device is
locked. When the device is locked, the screen is blanked / turned off
(via DPMS), but pressing a volume button causes the screen to unblank,
leading to significant power drain.

I am aware that one can tell X to close certain/all input devices, but
then the volume buttons (and others: like 'next') would not be sent to X
applications.

I have not tested this, but I assume the same would apply for "headphone
buttons": play, stop, pause, etc. Or if someone has a phone in their
pocket: pressing a button by accident shouldn't cause the screen to
unblank and cause significant battery drain. By design, the DPMS timeout
is set to 0, and an external program will dim the screen brightness, and
tell X when to blank and unblank.

Turning off the screen with DPMS, and then disabling DPMS in an attempt
to keep the screen blanked (and have input not affect it) also does not
work - then the screen doesn't stay blanked - this is with the
modesetting driver.

Due to the way DRM works, X is the master of the screen, so it is my
understanding that there also cannot be another helper tool that blanks
the display via DRM, because X is still the master, even when DPMS is
disabled.

On older versions of Maemo, where DRM was not used (10+ years ago),
external tools can just blank the fb and everything works as expected.
Then DPMS is simply disabled, and external tools control the blanking
behaviour, but it looks like with DRM, this is no longer possible.

Any suggestions are highly appreciated.

Regards,
Merlijn


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: How to prevent input devices from unblanking the X screen when DPMS is on?

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 3046 bytes --]

On Fri, 7 Aug 2020 16:07:35 +0200
Merlijn Wajer <merlijn@wizzup.org> wrote:

> Hi,
> 
> Is it possible to have X handle input events, but not actually unblank
> the screen upon input events when dpms is enabled?

Hi,

by "blanking", do you mean that the CRTC turns off (as opposed to the
display turning off) so that it no longer produces a video stream
regardless of whether the display is actually receiving it or not?

> Our use case (in Maemo Leste, GNU/Linux+Debian smartphone OS) is
> reporting physical volume buttons to X clients when the device is
> locked. When the device is locked, the screen is blanked / turned off
> (via DPMS), but pressing a volume button causes the screen to unblank,
> leading to significant power drain.
> 
> I am aware that one can tell X to close certain/all input devices, but
> then the volume buttons (and others: like 'next') would not be sent to X
> applications.
> 
> I have not tested this, but I assume the same would apply for "headphone
> buttons": play, stop, pause, etc. Or if someone has a phone in their
> pocket: pressing a button by accident shouldn't cause the screen to
> unblank and cause significant battery drain. By design, the DPMS timeout
> is set to 0, and an external program will dim the screen brightness, and
> tell X when to blank and unblank.
> 
> Turning off the screen with DPMS, and then disabling DPMS in an attempt
> to keep the screen blanked (and have input not affect it) also does not
> work - then the screen doesn't stay blanked - this is with the
> modesetting driver.

What does "disabling DPMS" mean?

> Due to the way DRM works, X is the master of the screen, so it is my
> understanding that there also cannot be another helper tool that blanks
> the display via DRM, because X is still the master, even when DPMS is
> disabled.

There can be only one DRM master having access to KMS functionality at a
time, yes. This is deliberately designed to prevent any "rogue"
applications from touching the display state without going through the
display server in charge.

DRM is the wrong layer to look at. DRM only does what a display server
tells it to, and has no connection to any input side at all. Your
problem has to be solved in co-operation with the display server.

> On older versions of Maemo, where DRM was not used (10+ years ago),
> external tools can just blank the fb and everything works as expected.
> Then DPMS is simply disabled, and external tools control the blanking
> behaviour, but it looks like with DRM, this is no longer possible.

Have you tried using X11 RandR protocol to turn the output off? I'm
not sure it fits your use case, but maybe worth a try.

The ultimate solution in my opinion though is to ditch X11 and go for a
Wayland architecture. There you provide the display server yourself
(with the help from any Wayland compositor libraries you may want)
which means you are fully in control of the behaviour. Obviously that
would be a huge change.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: How to prevent input devices from unblanking the X screen when DPMS is on?

[Merlijn Wajer]

[-- Attachment #1.1.1: Type: text/plain, Size: 5440 bytes --]

Hi Pekka,

Thanks for the reply -

On 10/08/2020 09:43, Pekka Paalanen wrote:
> On Fri, 7 Aug 2020 16:07:35 +0200
> Merlijn Wajer <merlijn@wizzup.org> wrote:
> 
>> Hi,
>>
>> Is it possible to have X handle input events, but not actually unblank
>> the screen upon input events when dpms is enabled?
> 
> Hi,
> 
> by "blanking", do you mean that the CRTC turns off (as opposed to the
> display turning off) so that it no longer produces a video stream
> regardless of whether the display is actually receiving it or not?

Right - the idea is that the LCD display of the phone turns off so that
it no longer draws any power. So I believe that would be to have the
CRTC turn off. We are using libX11 for this purpose [1], but I think the
same can be achieved with "xset dpms force off".


>> Our use case (in Maemo Leste, GNU/Linux+Debian smartphone OS) is
>> reporting physical volume buttons to X clients when the device is
>> locked. When the device is locked, the screen is blanked / turned off
>> (via DPMS), but pressing a volume button causes the screen to unblank,
>> leading to significant power drain.
>>
>> I am aware that one can tell X to close certain/all input devices, but
>> then the volume buttons (and others: like 'next') would not be sent to X
>> applications.
>>
>> I have not tested this, but I assume the same would apply for "headphone
>> buttons": play, stop, pause, etc. Or if someone has a phone in their
>> pocket: pressing a button by accident shouldn't cause the screen to
>> unblank and cause significant battery drain. By design, the DPMS timeout
>> is set to 0, and an external program will dim the screen brightness, and
>> tell X when to blank and unblank.
>>
>> Turning off the screen with DPMS, and then disabling DPMS in an attempt
>> to keep the screen blanked (and have input not affect it) also does not
>> work - then the screen doesn't stay blanked - this is with the
>> modesetting driver.
> 
> What does "disabling DPMS" mean?

I should have written "disabling the DPMS extension". It is possible to
disable the DPMS extension at runtime, if I understand correctly. This
is what the xset manpage says about it:

> -dpms   The -dpms option disables DPMS (Energy Star) features.
> +dpms   The +dpms option enables DPMS (Energy Star) features.

The idea was to use the DPMS extension to turn the screen off (say with
'xset dpms force off'), and then disable the DPMS extension (while the
screen is in the off mode) to workaround the DPMS always waking up the
screen upon any input.

But it seems like disabling the DPMS extension at runtime after the
screen is off turns the screen back on (at least looking at the power
consumption of the device).

>> Due to the way DRM works, X is the master of the screen, so it is my
>> understanding that there also cannot be another helper tool that blanks
>> the display via DRM, because X is still the master, even when DPMS is
>> disabled.
> 
> There can be only one DRM master having access to KMS functionality at a
> time, yes. This is deliberately designed to prevent any "rogue"
> applications from touching the display state without going through the
> display server in charge.
> 
> DRM is the wrong layer to look at. DRM only does what a display server
> tells it to, and has no connection to any input side at all. Your
> problem has to be solved in co-operation with the display server.

I understand - and I think the DRM design makes sense. I was wondering
if this (not being able to forcibly keep the display blanked with a DRM
backend while still processing input) is an oversight in X11 (since DRM
was introduced way later, and support for it was added to X11). I am
hoping to avoid having to ship/maintain a custom/patched X11 server, so
if there's potential workaround, I'd be very interested.

Perhaps it's also possible to extend the DPMS API in the X11 server to
disable waking up on input. That might be a relatively small change to
carry, and could be entirely backwards compatible. But I don't know what
it takes to get (any) new features into X11.

>> On older versions of Maemo, where DRM was not used (10+ years ago),
>> external tools can just blank the fb and everything works as expected.
>> Then DPMS is simply disabled, and external tools control the blanking
>> behaviour, but it looks like with DRM, this is no longer possible.
> 
> Have you tried using X11 RandR protocol to turn the output off? I'm
> not sure it fits your use case, but maybe worth a try.

I think this is a way to force the display off, but I also believe it
usually confuses a lot of window managers and clients - if this is the
only display, then what is the size of the desktop after the display is
turned off - etc.

> The ultimate solution in my opinion though is to ditch X11 and go for a
> Wayland architecture. There you provide the display server yourself
> (with the help from any Wayland compositor libraries you may want)
> which means you are fully in control of the behaviour. Obviously that
> would be a huge change.

That would indeed be quite nice -- although I am afraid we are stuck
with X11 for a while until we get all the other bits working well. Only
then does it make sense to think about replacing X11.

Cheers,
Merlijn

[1]
https://github.com/maemo-leste/mce/commit/57786e7d26cb32fefc149d8d07ceee239e0bdd08


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: How to prevent input devices from unblanking the X screen when DPMS is on?

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 6483 bytes --]

On Mon, 10 Aug 2020 10:43:42 +0200
Merlijn Wajer <merlijn@wizzup.org> wrote:

> Hi Pekka,
> 
> Thanks for the reply -
> 
> On 10/08/2020 09:43, Pekka Paalanen wrote:
> > On Fri, 7 Aug 2020 16:07:35 +0200
> > Merlijn Wajer <merlijn@wizzup.org> wrote:
> >   
> >> Hi,
> >>
> >> Is it possible to have X handle input events, but not actually unblank
> >> the screen upon input events when dpms is enabled?  
> > 
> > Hi,
> > 
> > by "blanking", do you mean that the CRTC turns off (as opposed to the
> > display turning off) so that it no longer produces a video stream
> > regardless of whether the display is actually receiving it or not?  
> 
> Right - the idea is that the LCD display of the phone turns off so that
> it no longer draws any power. So I believe that would be to have the
> CRTC turn off. We are using libX11 for this purpose [1], but I think the
> same can be achieved with "xset dpms force off".

Yeah, I suppose nowadays turning the CRTC off does imply DPMS-off and
everything else as well (including backlight?).

> >> Our use case (in Maemo Leste, GNU/Linux+Debian smartphone OS) is
> >> reporting physical volume buttons to X clients when the device is
> >> locked. When the device is locked, the screen is blanked / turned off
> >> (via DPMS), but pressing a volume button causes the screen to unblank,
> >> leading to significant power drain.
> >>
> >> I am aware that one can tell X to close certain/all input devices, but
> >> then the volume buttons (and others: like 'next') would not be sent to X
> >> applications.
> >>
> >> I have not tested this, but I assume the same would apply for "headphone
> >> buttons": play, stop, pause, etc. Or if someone has a phone in their
> >> pocket: pressing a button by accident shouldn't cause the screen to
> >> unblank and cause significant battery drain. By design, the DPMS timeout
> >> is set to 0, and an external program will dim the screen brightness, and
> >> tell X when to blank and unblank.
> >>
> >> Turning off the screen with DPMS, and then disabling DPMS in an attempt
> >> to keep the screen blanked (and have input not affect it) also does not
> >> work - then the screen doesn't stay blanked - this is with the
> >> modesetting driver.  
> > 
> > What does "disabling DPMS" mean?  
> 
> I should have written "disabling the DPMS extension". It is possible to
> disable the DPMS extension at runtime, if I understand correctly. This
> is what the xset manpage says about it:
> 
> > -dpms   The -dpms option disables DPMS (Energy Star) features.
> > +dpms   The +dpms option enables DPMS (Energy Star) features.  
> 
> The idea was to use the DPMS extension to turn the screen off (say with
> 'xset dpms force off'), and then disable the DPMS extension (while the
> screen is in the off mode) to workaround the DPMS always waking up the
> screen upon any input.
> 
> But it seems like disabling the DPMS extension at runtime after the
> screen is off turns the screen back on (at least looking at the power
> consumption of the device).

Hmm, I always thought that those commands only enable or disable the
timers measuring idle time that then causes Xorg to change the monitor
from "on" to one of the power save modes.

I'm actually surprised if 'xset -dpms' didn't force monitors on.

> >> Due to the way DRM works, X is the master of the screen, so it is my
> >> understanding that there also cannot be another helper tool that blanks
> >> the display via DRM, because X is still the master, even when DPMS is
> >> disabled.  
> > 
> > There can be only one DRM master having access to KMS functionality at a
> > time, yes. This is deliberately designed to prevent any "rogue"
> > applications from touching the display state without going through the
> > display server in charge.
> > 
> > DRM is the wrong layer to look at. DRM only does what a display server
> > tells it to, and has no connection to any input side at all. Your
> > problem has to be solved in co-operation with the display server.  
> 
> I understand - and I think the DRM design makes sense. I was wondering
> if this (not being able to forcibly keep the display blanked with a DRM
> backend while still processing input) is an oversight in X11 (since DRM
> was introduced way later, and support for it was added to X11). I am
> hoping to avoid having to ship/maintain a custom/patched X11 server, so
> if there's potential workaround, I'd be very interested.
> 
> Perhaps it's also possible to extend the DPMS API in the X11 server to
> disable waking up on input. That might be a relatively small change to
> carry, and could be entirely backwards compatible. But I don't know what
> it takes to get (any) new features into X11.

Me neither. Also, Xorg itself seems to be more or less in
maintenance-only mode if even that.

> >> On older versions of Maemo, where DRM was not used (10+ years ago),
> >> external tools can just blank the fb and everything works as expected.
> >> Then DPMS is simply disabled, and external tools control the blanking
> >> behaviour, but it looks like with DRM, this is no longer possible.  
> > 
> > Have you tried using X11 RandR protocol to turn the output off? I'm
> > not sure it fits your use case, but maybe worth a try.  
> 
> I think this is a way to force the display off, but I also believe it
> usually confuses a lot of window managers and clients - if this is the
> only display, then what is the size of the desktop after the display is
> turned off - etc.

Sure. I assumed you'd have your own special window manager at least, so
that behaviour is under your control already. What I don't know is how
Xorg deals with turning all outputs off.

> > The ultimate solution in my opinion though is to ditch X11 and go for a
> > Wayland architecture. There you provide the display server yourself
> > (with the help from any Wayland compositor libraries you may want)
> > which means you are fully in control of the behaviour. Obviously that
> > would be a huge change.  
> 
> That would indeed be quite nice -- although I am afraid we are stuck
> with X11 for a while until we get all the other bits working well. Only
> then does it make sense to think about replacing X11.

All the best with that. :-)


Thanks,
pq

> Cheers,
> Merlijn
> 
> [1]
> https://github.com/maemo-leste/mce/commit/57786e7d26cb32fefc149d8d07ceee239e0bdd08
> 


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel