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. 2) There is no way (AFAIK) we can distinguish between a monitor being in powersave mode, or permanently unconnected. 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. 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. 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. 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. 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. 6c) I realize neither of 6a) or 6b) are particularly strong arguments against actually fixing a problem... 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". 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? 8) Everything said about HDMI applies to DisplayPort as well. [1] https://bugs.freedesktop.org/show_bug.cgi?id=93946 [2] http://patchwork.freedesktop.org/patch/72053/ [3] https://wiki.gnome.org/Design/SystemSettings/Sound - section "Guidelines" -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
