GNOME Bugzilla – Bug 753429
HDMI audio turns off with display off
Last modified: 2021-07-05 13:45:06 UTC
My configuration: GNOME HTPC (running Fedora 22), with HDMI-out connected to a home-stereo receiver's HDMI-IN. Receiver's HDMI-out is then connected to a display. Scenario: - Start music playing, maybe a long playlist for a party. - Leave machine idle long enough for the display to be disabled Expectation: - Music can still be heard. Party is a huge success! Observation: - Music can not be heard. Party-goers are saddened. I considered changing settings or using an extension to disable the display-shutoff, but it's a large plasma display, which is subject to burn-in/image-retention.
Don't think there's any way to disable the screen without disabling the speakers. Reassigning to mutter where the screens are "turned off" in power management situations.
Windows simply prevents the screens from blanking if audio is playing through DP/HDMI (I didn't test what happens if no audio is playing but the sink is selected). That seems sane to me. Now, the interesting part is how to inhibit the screen from blanking. Detecting that the sink is in use by another processes doesn't really seem to be feasible to me right now. And the decision to blank is in the user session but playback might be happening from e.g. pulseaudio running as a system wide daemon. Then again, if we can assume that playback is coming from inside the session then pulseaudio could inhibit screen blanking through a DBus API.
(In reply to Benjamin Berg from comment #2) > Windows simply prevents the screens from blanking if audio is playing > through DP/HDMI (I didn't test what happens if no audio is playing but the > sink is selected). That seems sane to me. > > Now, the interesting part is how to inhibit the screen from blanking. > Detecting that the sink is in use by another processes doesn't really seem > to be feasible to me right now. And the decision to blank is in the user > session but playback might be happening from e.g. pulseaudio running as a > system wide daemon. > > Then again, if we can assume that playback is coming from inside the session > then pulseaudio could inhibit screen blanking through a DBus API. pulseaudio runs inside each session. The easiest would be for PulseAudio to take an inhibit cookie when audio is being output to HDMI, preventing the display from sleeping, though that wouldn't prevent the user from turning the display off. In GNOME, it's gnome-settings-daemon turning DPMS on/off as necessary (eg. turning the screen off when locking the screen, turning it on when a new notification appears on the lock screen), so how to untangle that might need some thought. Especially if you want to replicate Windows' behaviour and only one of a dual screen is the sound output for example.
Oh, and there are also non-HDMI screens and all-in-ones where the video output controls the power to the speakers. I had 2 such setups in the past: - a Dell VGA monitor with jack attached speakers, the speakers turned off when the display went to sleep - a Lenovo all-in-one which behaved similarly to HDMI, but wasn't connected through HDMI (the speakers looked like discrete components in the Sound preferences)
Oh, windows just leaves all monitors turned on. So if we want to replicate that we don't need to figure out to which monitor the sink belongs. I think that is sufficient for this use case. Yeah, I was under the wrong impression that pulseaudio might also be running as a system daemon. (In reply to Bastien Nocera from comment #4) > Oh, and there are also non-HDMI screens and all-in-ones where the video > output controls the power to the speakers. Hmm, that is interesting. I guess it is impossible to figure this out from the software side in those cases. So I think only solution would be to allow the user to inhibiting screen blanking entirely or only inhibiting it whenever audio is playing.
Bastien, do you think the following would be a sane way of moving forward here? 1. Add new flag to org.gnome.SessionManager.Inhibit 2. Handle the flag in g-s-d power plugin to not blank the screens 3. Create a pulseaudio module registering an inhibit lock for each application using a HDMI/DP sink That said, a freedesktop.org standard might be nice in the long run. Though I don't have an idea where that might live as of now (or how the process works).
Would be easier not to go through gnome-session. It might not even be necessary to involve gnome-settings-daemon and patch mutter to ignore screen blanks when inhibited instead. I'd start with 3 and then ask Rui whether g-s-d needs to be involved. With a bit of luck you just need the PA plugin to talk to mutter.
> Now, the interesting part is how to inhibit the screen from blanking. > Detecting that the sink is in use by another processes doesn't really > seem to be feasible to me right now. And the decision to blank is in > the user session but playback might be happening from e.g. pulseaudio > running as a system wide daemon. This reminded me -- we actually *do* want to be careful to make sure we *do* *blank* the screen, but not power it off. A common use case for playing audio through HDMI is going to be a home-theatre/audio-receiver setup, and (at least in my case) that means a plasma screen that is vulnerable to some burn-in/image-retention if the screen isn't blanked. We ditched the idea of a screensaver years ago because power-saving was a better solution, but if we're deliberately disabling power-saving to keep audio on, we do need some kind of screen-saving again (even just a plain blank screen).
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.