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

[Pekka Paalanen]

On Fri, 7 Aug 2020 16:07:35 +0200
Merlijn Wajer <merlijn at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20200810/fae3f369/attachment.sig>