Matthias Hopf writes:
RandR isn't exactly verbose in specifying, what an output actually is. So far, two interpretations have been used, with one limitation or another.
Most drivers interpret outputs to be connectors (a), so they have outputs named like
VGA-1 DVI-1
radeonhd instead uses signal routes as outputs (b), so the same set as above is specified as 3 outputs, named
VGA-1 DVI-I_1/analog DVI-I_1/digital
The advantage of a) is that this is much more user friendly due to the short names. The disadvantages (and main reason for radonhd to be implemented differently) are
1) that there is little metainformation on the connectors 2) you can (theoretically) drive both the analog and digital lines on a DVI port, even with different signals - which cannot be realized with scheme a) at all
radeonhd connector names bear a 'purely informational' and a functional content: Since analog and digital lines could be driven independently on a DVI connector (which we don't support ATM) analog/digital serves to sdistnguish these two. The '-I', '-D' and '-A' is purely informational as it identifies what signals a connector provides. The user should not be able to plug an analog DVI plug into a DVI-D connector thus the user should not have to care (having said this I've got and HDMI->DVI dongles which also accepts DVI->VGA dongles).
The disadvantage of b) is mainly that the names are awkward to use, and having the same connector listed twice leads to confusion.
Regarding a)'s disadvantages 1) can be sort-of removed by presenting the meta information over properties (something to be standardized with RandR 1.3), and 2) is theoretically possible, but typically impracticable, and also not really supported (there's only one DDC line per DVI connector). DMS-59 connectors would fit in this scheme, but are already represented as two DVI connectors nowadays.
So the question is with the property system in place (some corrections need to be applied) is whether to keep the old style, or whether to convert to the apparently standard style other drivers have used so far. I remember a discussion with Alex Deucher, after which both of us were basically convinced, that the solution of the other one (respectively) is the right one :-P
I'd like to ask for reasons for one approach or the other, and for the general feeling about this issue. Maybe we have a strong majority for one of the two solutions. Somehow, I guess we will be closer to 50:50, though :-]
So please post your conclusion, especially if you can back it up with experience or configurations that would work well in one of the scenarios, but not in the other.
While for driver purposes the purely informational content is irrelevant as well as part of the functional content currently both provide valuable information for debugging and support. The user mainly encouters these strings when using xrandr to configure outputs. There are already GUI tools avaiable to do the same thing and I'd expect them to become really usable soon. Therefore most users will not encounter those names any more and the issue will become moot. Cheers, Egbert. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org