On 2016-02-04 08:47, Alexander E. Patrakov wrote: > 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. Right, this is a very valid point. We could instead try to fix graphics driver(s) to make sure a) monitors appear connected when they are in powersave b) to not make them go to powersave when an audio stream is currently playing back c) to wake them up from powersave when an audio stream is started. We also do not know (or at least I don't) whether some graphics drivers already work this way, but the person in the bug seems to use standard Ivybridge graphics, so that probably means that a fair share of existing HDMI ports appear disconnected when they are in DPMS. So, while this seems to be an interesting route forward (especially given the i915 component framework which can transfer ELD and PD bits without taking a hardware detour), we still have a problem here and now. > >> 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). Indeed. In the best of worlds, the HDMI port availability should be the same as whether those headphones are plugged in or not, but I doubt this works. > > 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. We can also debate whether mind-reading technology in itself is user friendly, but that's hardly on topic here :-) > >> 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. Agreed. There is also problem here with interpreting users intent through the existing API: that we have default-sink and default-source but not default-port (-input/ -output), and that there is no API to switch a profile and port simultaneously. > >> 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"? Internal speakers toggle between "no" and "unknown" today; i e, when you unplug your headphones, internal speakers go to "unknown" rather than "yes". This somewhat indicates that speakers are now available, but you did not make an active choice to use them. > >> 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". Actually I think it should be card+ELD and card+port+ELD rather than sink, as the sink name changes when the profile changes. And we need the card+port+ELD version to cope with two identical monitors, right? > >> >> 8) Everything said about HDMI applies to DisplayPort as well. > > Definitely. > -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
