[Bug 79531] New: output name duplication for providers #1 and up

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jun 2 01:05:46 PDT 2014


          Priority: medium
            Bug ID: 79531
          Assignee: xorg-driver-ati at lists.x.org
           Summary: output name duplication for providers #1 and up
        QA Contact: xorg-team at lists.x.org
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: gmt at be-evil.net
          Hardware: All
            Status: NEW
           Version: git
         Component: Driver/Radeon
           Product: xorg

Created attachment 100274
  --> https://bugs.freedesktop.org/attachment.cgi?id=100274&action=edit

Thanks to a Dave Airlie and others in irc for helping me get to the bottom of

For cards other than "#0" (I'm still quite unclear on where exactly the
numbering comes from -- I presume it's the same place as the /dev/dri/card*
specials), it is still quite possible to get duplicated output names.

This is because the code identified in the source as "for compatibility with
UMS output names" does not run; instead, for these non-#0-cards, only the
human-readable output type name (i.e.: "DVI", "HDMI", etc.) differentiates the
various outputs.  Unfortunately these names are not at all unique:

const char *output_names[] = {

The result, depending on your hardware: adding a second card results in 
duplicate output names in the global randr namespace.  Wouldn't be so terrible,
except it makes xrandr go utterly berzerk.*

Rather than pile more output numbering kludges on top of the ones already in
drmmode_output_init, folks in IRC seemed to agree that a better solution would
be to go ahead and allow the output names to churn and replace the duplicate
values in the above array with unique ones.

I posted this to the mailing list some days ago and no flame-war ensued.  But,
I'm new in town; perhaps bugzilla is a better way to get my patch looked at?

* This may represent a second bug in apps/xrandr, as I noticed several
third-party consumers of libXrandr continued to work correctly in spite of the
duplicate names; however, apps/xrandr always freaked out, even if I only fed it

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/20140602/a4160225/attachment.html>

More information about the xorg-driver-ati mailing list