Christian König writes:
Am Mittwoch, den 15.10.2008, 13:01 +0200 schrieb Matthias Hopf:
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 I vote for a as the default so the most common use case are met with a simple scheme, but with a xorg.conf option to switch to scheme b.
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 For me that's far away from being a theoretically option see below.
;) Sceme A would implicetly imply what Alex would prefer: to combine the two physical outputs into a single logical one (it would be closer to what we term a connector in RadeonHD) and only expose a single output to randr (and thus to the user). This would require an entirely different handling code wise than what we do at the moment. Thus if we have an option to select between both handlings (and to support devices like you've described) we'd have to keep both code paths around (I don't say it's impossible, it just is another degree of freedom that needs testing). Also it is not entirely clear to me (I would have to try it out) what will happen in sceme A if the user unplugs a digital display and then plugs in an analog one and requests a reprobe. The output will remain connected (possibly with the same modes), thus nothing on the upper layers will ever detect that something has changed and requires to be driven differently. In our current model it is pretty clear what will happen: the digital output will become disconnected loosing all its modes while the analog one will become connected acquiring a list of modes. Now the upper layer can act on this and choose a mode. In the combined case the driver would have to implement a policy how to deal with this situation. The described situation may not even be as corner case as one might think.
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. Actually i have some embedded systems at work used for industrial operations (in German you would call this "Hutschienenmodul" and i don't have a matching English translation for it, but the German speaking developers should know what i am talking about). AFAIK we don't use one with an ATI/radeon chipset at the moment (Intel or VIA based i think, actually don't know), but that's just depending on which model we sell.
Anyway, because of the limited size of these modules you usually have no more than a single DVI, Power, Ethernet and maybe an USB or other industrial bus connectors, but since the most common use case for these modules is collecting and displaying measured data, it's essential that you can connect more than one monitor to the DVI port.
We use different hardware to archive this goal, but one of the simpelst device we have in stock is an adapter cable were the single DVI port is split to TWO DVI connectors and one analog VGA connector. Normally we have to tell the operation system to use a specific resolution (because of the missing DDC capabilities), but recently we got some with an integrated I2C multiplexer (and only windows drivers :(.
Sounds like an interesting device :) Cheers, Egbert. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org