On Thu, Oct 16, 2008 at 6:20 AM, Egbert Eich
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.
I don't follow your argument. Why would this be any different whether you use scheme a or scheme b? When you reprobe you detect a new monitor and setup the encoders appropriately based on the type of monitor connected. The old modes are replaced by the ones from the new monitor. How is it any different whether you expose a connector or an encoder as a randr output? Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org