Giving the XL something to draw on
I only have two displays - a 1920x1200 Dell 2405FPW and a 1600x1200 Philips 200P4SS, both LCDs - usually connected to the DVI ports on the GTX for multi-monitor and a 3520x1200 desktop space. Thankfully though, both monitors have additional inputs and quick switching between them from buttons on their respective bezels. With the analogue VGA input on the Dell 2405FPW used for test rigs when testing graphics, that left the analogue VGA input on the Philips as the best option for hooking up the Radeon.So two monitors but three displays, the Philips accepting input from both GTX and XL. Obviously I can't view both at once, and it would be nice if the additional inputs on both monitors were DVI, but with the Radeon seeing a display now things started to work correctly. CCC could now control the XL.
The obvious downsides are the analogue input from the XL, and the fact the Philips can only display output from GTX or XL at once, but for the time being it's a workable situation. In terms of video and 3D display on the Radeon, for specific applications, they all work fine (or at least everything tested so far does), providing the application doing the 3D or hosting the video is told what board to render it on.
Further, given the GTX and XL output to the same display, it makes it somewhat easier to do IQ comparisons between the two IHVs, because of display calibration.
When using the Cyberlink H.264 decoder mentioned in the Avivo article, it was simple matter of using GraphEdit to edit the filter graph for the DirectShow objects I was using, and place the output window on the Radeon's display for rendering. The decoder chose the right hardware and display driver and it worked correctly.
In short, the operating system, display drivers and applications all do The Right Thing™, at least for the most part. Infact, the only thing that's caused me real issue so far is one of my own software tools that makes assumptions about where displays will be, so I enumerate them wrong in the app code. I need to fix that and allow for arbitrary placement, which is what the OS supports.
So you can see SS2 getting the initial detection right (GTX on 1, XL doing 2 and 3, GTX doing 4), but it doesn't know what order they're enumerated in (1, 4, 2 with 3 unattached), which causes problems elsewhere in the application.
