<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - xorg/driver/xf86-video-ati: output name duplication for providers #1 and up" href="https://bugs.freedesktop.org/show_bug.cgi?id=79531#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - xorg/driver/xf86-video-ati: output name duplication for providers #1 and up" href="https://bugs.freedesktop.org/show_bug.cgi?id=79531">bug 79531</a> from <a class="email" href="mailto:gmt@be-evil.net" title="Greg Turner <gmt@be-evil.net>"> Greg Turner</a> <pre>(In reply to <a href="show_bug.cgi?id=79531#c2">comment #2</a>) > That stated, once could salvage the legacy behavior by creating a second > array of output names; the old array would pertain to the "primary" card > (however, using the type id's to determine primacy is clearly not correct On second thought, maybe an approach along these lines is not so bad -- one could just hard-code the legacy-compatibility values into the case-statement and fix the array for everything else as in my patch. That should provide cake and eating too -- avoiding massive breakage for mainstream use-cases while fixing name duplication, all without making the code uglier. This does leave the question of how to properly identify the actual primary GPU, to which the legacy-output-naming-compatibility hack should apply. The "id #1 must be the primary card" assumption made, now, fails in my case (second card listed first in xorg.conf in order to make it the main one). Is it safe, by any chance, to assume that whatever drmModeConnector libdrm returns for drmmode->mode_res->connectors[0] would always be the primary one (even in the face of hotplug etc)? If that were the case, drmmode_output_init could just "make a note" (i.e., by means of a new variable passed back and forth to it by drmmode_pre_init) of the connector_type found in its first iteration, and replace the constant "1" currently used to test for primacy (and activate the output numbering hacks), with this remembered value. Or, perhaps there some more "xorg-ly correct" way to pick the primary? If I could get some feedback on that one issue, I'm quite sure I could spin up a better version of my previous patch that addresses the backward-compatibility concern while still fixing the output-name-uniqueness problem.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>