<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Changing device profile to HDMI is reset to default after monitor goes into powersave" href="https://bugs.freedesktop.org/show_bug.cgi?id=93946#c59">Comment # 59</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Changing device profile to HDMI is reset to default after monitor goes into powersave" href="https://bugs.freedesktop.org/show_bug.cgi?id=93946">bug 93946</a> from <a class="email" href="mailto:arun@accosted.net" title="Arun Raghavan <arun@accosted.net>"> Arun Raghavan</a> <pre>(In reply to Tanu Kaskinen from <a href="show_bug.cgi?id=93946#c58">comment #58</a>) > (In reply to Arun Raghavan from <a href="show_bug.cgi?id=93946#c57">comment #57</a>) > > My primary concern with this patch series is that it is very common to plug > > in multiple HDMI devices to a single laptop (monitors, projectors, ...), and > > it appears that a preference to route to a single device ends up applying to > > all devices. > > > > David had mentioned that this *may* be a problem. I'd go as far as to say > > that this is definitely a problem. > > A worse problem than what my patches fix? I don't think so. > > 2. DPMS causing an HDMI unplug > > > > For the first, I concur with David about this not being an issue we should > > try to solve, and we should let underlying layers fix this properly. *Maybe* > > we could look at having a pavucontrol option to mark a system as not having > > internal speakers (and store this on the card in some way). > > > > For the second, I don't have a good solution. Yes, it would be a _lot_ > > better to be able to distinguish between the DPMS and unplugged states. > > There seemed to be a suggestion that this is possible at the graphics driver > > level. Is that true? > > I don't know. Was it suggested in this bug thread? I tried to search for > "driver", "kernel" and "graphics", and I didn't find a place where that > would have been suggested. There seemed to be some discussion around this at: <a href="https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-February/025394.html">https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-February/025394.html</a> > > As an alternative, it may make sense to at least tie the preferred port > > setting with the corresponding device names from ELDs. That would prevent us > > from explicitly having to route to and away from every HDMI device > > explicitly. It's still not great since ELDs lie, and it's common to have > > multiple monitors of the same type being connected to (e.g. an office with > > homogenous monitor setups, but you only have headphones connected to your > > own workstation). > > Creating separate ports based on ELD seems like an improvement for some > later time. Doing a port based on ELDs is one way to do this. The other way to do this is to change how we store preferred_port in module-card-restore from a boolean choice to some other mechanism that allows a more fine-tuned selection of whether the port is the preferred port or not. As an example, it could be a list of key/value pairs such that if we find any property on a card's port that matches the given (key, value), then it is a preferred port. We could special-case the "name" key to just be the port's name. Now this does mean that module-card-restore will need to start being aware of the property we'll be adding on the ports. I don't see a way to avoid that.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>