<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#c54">Comment # 54</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:frnchfrgg@free.fr" title="Julien "_FrnchFrgg_" RIVAUD <frnchfrgg@free.fr>"> Julien "_FrnchFrgg_" RIVAUD</a> <pre>As for the patch series that were submitted (and especially the 6th which is where all heuristics lie): - It seems to me rather hand-wavy the way you try to know if the profile change was intentional or not, and I worry about false positives. - Why not just remember: * whether the current profile/sink was switched to automatically by switch-on-port-available), and if true * the profile/sink that was active prior to the automatic switch ? Then in profile_good_for_output(), if the profile being checked is the previously checked one, accept it (and maybe give it a priority boost since IIUC only the good profile with the highest priority is kept). Maybe this logic belongs to the caller of profile_good_for_output() to avoid the need for an output param for the new priority, or worse to change the priority in the profile struct. This seems far simpler, and less subject to false positives, while solving this specific case of intermittent unavailability. That way you don't tread into the territory of a real profile manager, and the patch set would be accepted more easily. The first three patches look OK to me. Cheers</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>