On 09/20/2016 01:36 PM, Felipe Sateler wrote: > On 19 September 2016 at 15:00, Manuel Amador (Rudd-O) <rud...@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 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/
Description: OpenPGP digital signature
_______________________________________________ pulseaudio-discuss mailing list firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss