[Bug 79531] xorg/driver/xf86-video-ati: output name duplication for providers #1 and up

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79531

--- Comment #3 from Greg Turner <gmt at be-evil.net> ---
(In reply to comment #2)
> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20140604/151b2433/attachment.html>