04.02.2016 10:45, David Henningsson пиÑ?еÑ?: > So, there has been a few bugs related to the new routing, in particular > [1] which while related to whether or not the actual system has an > internal speaker or not, also highlights the use case of letting an HDMI > monitor go to powersave. This will, starting from 8.0, cause sound to be > rerouted to internal speakers, even after the HDMI monitor comes back > online. > > Here's a recap. > > 1) The old situation of playing back audio to an unconnected monitor > (or powersaved monitor) was not user friendly. Partially agree. As always with old bugs, there may be people for whom they are features. > 2) There is no way (AFAIK) we can distinguish between a monitor being > in powersave mode, or permanently unconnected. No opinion here, ask the graphics guys. > 3) Hence, the proper solution is to switch to analog when the monitor > is off/powersaved/unconnected and then switch back when it comes back > online. Well, here I also don't 100% agree. You are focusing on the "what happens when the monitor comes back from powersaving mode" side of things - which is too late and too passive. My opinion, as a user, is: 1. If audio is playing on HDMI (even if this is a music file), it is a mistake to apply DPMS. Black out the screen if needed for screensaver - maybe, DPMS - no. Personally, I have disabled DPMS on my desktop PC, but this is also due to a different bug, unrelated to audio. 2. An attempt to play audio to a DPMSed monitor should try to wake it up. I understand that we lack an infrastructure to do this. But, ultimately, only if that fails or times out, audio should be moved to analog (if moved at all). I understand that this is better discussed on something like dri-devel, but I have no concrete-enough proposal to actually present there. > 4) The easiest way to do that is, at least after the priority patch > [2] has been applied, to adjust the port priorities so that HDMI ports > have a higher priority than analog-speakers. This is also consistent > with a suggestion from GNOME [3]. However, doing so might instead upset > people who would like to stay on analog-speakers when their HDMI monitor > comes back online. Let's see whether such people exist. But I have another class of upset people: those whose monitor supports HDMI audio and has only headphones output, which is unused (but we can't know that it is unused, i.e. that the monitor is in fact a glorified null sink). Which is exactly what the proposal at the end of your email addresses (better accounting of HDMI port availability). And also the case of two audio-capable monitors. When the graphical session power-saves them "at the same time", there is a race. Suppose that the user wants his audio on HDMI2, but there is also HDMI1. So, if HDMI1 is slower to respond to DPMS, the audio could be rerouted this way: HDMI2 -> HDMI1 (temporarily) -> analog. When the monitors come back up: analog -> HDMI2, but then HDMI1 (with a higher priority) comes up. This is also addressed by your proposal. > 5) We could then tell those people that they should manually increase > the priority or analog-speakers in our configuration files, but it could > be argued that this is not user friendly enough either. It is indeed not user friendly. But we don't have a 100% user-friendly solution, because mind-reading technology is not quite there yet. So some user interaction is definitely needed. > 6) Tanu suggested in [1] to add functionality to remember the latest > user-selected port and/or profile to module-switch-on-port-available. > I'm hesitant to that solution, because ... > 6a) It breaks the main idea of module-switch-on-port-available being > strictly rule/priority-based, leaving the "remember" feature to the not > yet finished module-port-manager. My opinion (a trivial one, I'd admit) is that any rule/priority-based zero-configuration logic is busted in at least one case. We definitely need to take user interaction into account somewhere if we don't want to require explicit configuration. > 6b) It seems non-trivial, and I have a gut feeling it will break some > other use case, that neither of us is thinking about right now. Based on our past experience here, I agree. > 6c) I realize neither of 6a) or 6b) are particularly strong arguments > against actually fixing a problem... I think here you meant "trying to fix". I also think the real problem here is to convince others that you have indeed fixed the original problem :) so for me 6b is strong enough. > 7) So, this morning I came up with another idea. And this is the RFC > part of this email. We're not sure whether or not a just > connected/online monitor has "usable" HDMI audio or not. Hence, maybe > plugging in a monitor should lead to the HDMI port availability being > "unknown" rather than "yes"? module-switch-on-port-available will not > route to something that changes availability from "no" to "unknown". Makes sense, given the additional module mentioned below. Is there any other (non-HDMI) example of a port availability going from "no" to "unknown"? > For this to make sense, we need to add yet another module, which > determines whether an HDMI port should be "unknown" or "yes" when coming > back online. If a user manually switches to the HDMI profile then that > means "yes" from now on, if a user manually switches away then that > means "unknown" from now on. As a bonus, we could potentially use ELD > info as a key to a database of "yes" and "unknown" values (this could be > useful for module-port-manager as well). I'm not sure whether the key > should be "sink+port", "ELD" or "sink+port+ELD", but probably > "sink+port+ELD" is the best one considering people with dual monitors. > What do you think? I am a bit concerned with assigning numbers dynamically for HDMI/DisplayPort audio pcms. So, given the semi-dynamic proposal that you made a year ago, I'd say the key should be "sink+port+ELD if dynamic numbering is not in use, sink+ELD if it is in use". > > 8) Everything said about HDMI applies to DisplayPort as well. Definitely. -- Alexander E. Patrakov
