On 09/20/2016 01:36 PM, Felipe Sateler wrote:
> On 19 September 2016 at 15:00, Manuel Amador (Rudd-O) <rudd-o at rudd-o.com> wrote:
>
>> I believe that there's a good compromise to be made:
>>
>> 1. if PulseAudio ('s D-Bus session) is tied to a GUI session in X11 or
>> Wayland,
> It appears the world is moving towards per-user daemons from the
> per-session model.
Not quite, as the portals work I'm pretty sure will require some sort of
sub-sessions, but I get the meaning of what you are saying.
It will still probably suffice to ask the current session's D-Bus daemon
if the org.freedesktop.ScreenSaver service is available. That suffices
as a check, and it works both in X11 and Wayland. See my other e-mail
about D-Bus APIs to interact with the screensaver.
> This means this part may not be valid. However, a
> different solution might be to use the logind api[1] to determine if
> there is any graphical session by the current user attached to the
> seat corresponding to the hdmi device (this can be obtained via the
> ID_SEAT udev property, or seat0 as fallback).
Interesting analysis.
Let me try to break it down from a desktop session perspective.
If PulseAudio knows of >0 HDMI audio output devices, you know one of two
things:
1. The screensaver can set the HDMI port to DPMS off / standby. This
is the case when you have an HDMI port that is connected to a
monitor which is configured as part of the overall display surface.
2. The CRTCs of the HDMI port are simply offline, thus no audio will
come out anyway. This is typically the case when you have an HDMI
port that is connected to nothing, or you have an HDMI port that is
connected to a monitor but the monitor is not part of the overall
configured display surface.
It would be a mistake to prevent screen saving if audio was "playing"
(quotes, because no actual sound will come out) to one of the ports
known to be in state (2), but it would be correct to prevent screen
saving if audio was playing to one of the ports in state (1).
I think this describes your concern well.
Under those circumstances, what the module-prevent-hdmi-screensaving
needs to do, is collect and maintain a list of HDMI devices that are
active parts of the display surface (of course, if such a list cannot be
collected, the module will simply do nothing).
You can obtain which devices are part of the display surface (in KDE) by
talking to org.kde.KScreen (path /backend) and subscribing to the D-Bus
signal org.kde.KScreen.Backend.ConfigChanged. I don't understand the
returned data, but I know it mentions the HDMI port number, and that can
be correlated to the HDMI display device that loginctl knows of.
You can also obtain which devices are part of the user session by
talking to loginctl seat-status <seatname>.
The PROBLEM with this data, is that the user session data does not tell
you which HDMI "sound card" corresponds to which HDMI display device,
which you need to know in order to figure out which HDMI "sound card" is
actually active and connected to a monitor that is part of the display
surface (otherwise the CRTC will be off, and no sound will come out).
So there is literally no way of figuring out a solution to your concern.
It's therefore far easier (if not 100% correct in all cases) to just
assume any playback of audio on any HDMI device means that screen saving
should be blocked. And, for that other 1% of the cases where people are
doing "weird shit" (I know of someone who runs a virtual X server which
owns his HDMI port, just so the port can be active and he can play audio
to his receiver), the setting "do not inhibit screen saver" should suffice.
--------------------------------
Another concern which just occurred to me. This policy module I am
proposing needs to disable DPMS screen standby/off, but it must NOT
interfere with actual screen saving or locking functions. That is, if
the user runs a screen saver, it should trigger normally, and so should
the locking feature â?? it is only the display that must never turn off
(or at least while their music / sound app is playing to HDMI devices).
Otherwise we risk this policy module breaking security policy.
Anyway, anyone interested in collecting the bounty for a minimum viable
thing that I can test?
--
Rudd-O
http://rudd-o.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20160921/2a90a973/attachment.sig>
