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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Jun 3 04:40:26 PDT 2014


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

--- Comment #2 from Greg Turner <gmt at be-evil.net> ---
(In reply to comment #1)
> You can't change the special case names as this will break the desktop for
> most people.  I had a similar clean up before but it breaks X for too many
> people.  Most desktop environments will just thow up an error saying they
> can't start up.

That certainly may have been the case not too long ago.  And, I'm not an
expert, so perhaps it still is for all I know.  But just to make the case for
this, consider that the victims are going to be only those whose distributions
absorb the 7.4.0 driver, but are still using the Driver-level
"Monitor-${OUTPUT_NAME}" trick to map their monitors.

Of course there will be a many such people, in absolute terms.  But I would
guess that these days, a majority of folks running bleeding edge versions of
this driver don't rely on xorg.conf at all.  Perhaps those that do are mostly
aware that this is no longer the mainstream, recommended way to set things up,
and are even prepared for a certain amount of upgrade troule.  Perhaps not --
but that was my line of thinking.

The other argument in favor of churning the output names stems from a look at
the code.  To preserve the old output names and the new randr 1.4 provider
functionality, and to ensure unique names going forward will likely require
some sort of matrix of output naming hacks to be maintained in place of the
numdvi, numhdmi, etc., variables that are in there now.  Even so, this won't
prevent people's output names from shuffling around if they plug things into
different ports or shuffle around cards in multi-gpu setups.

So, to me, it seemed that the best course of action would be to "rip the
bandaid off" now.  I worried I'd be contributing to a maintainability problem
adding more and more hacks to the code-base.

Yes some people's setups would break.  Undoubtedly when this change hit certain
distros there would be some nasty waves of unhappy campers showing up in
various support channels with blank screens.

But is the alternative better?  Extending those UMS-compatibility hacks to also
support multi-provider setups seemed like a recipe for continued output naming
snafus, quirky corner-case behavior, and so on, which could eventually total up
to a greater amount of human suffering than a one-time switch that people could
at least be prepared for via release notes, etc.

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

-- 
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/20140603/de7f300b/attachment.html>


More information about the xorg-driver-ati mailing list