[PATCH] randr: add provider object (v7)

[Dave Airlie]

On Tue, Jul 3, 2012 at 3:25 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Tue, Jul 3, 2012 at 10:10 AM, Dave Airlie <airlied at gmail.com> wrote:
>> On Tue, Jul 3, 2012 at 2:57 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
>>> On Tue, Jul 3, 2012 at 7:57 AM, Dave Airlie <airlied at gmail.com> wrote:
>>>> (forgot list first time I sent this).
>>>>
>>>> On Mon, Jul 2, 2012 at 10:03 PM, Keith Packard <keithp at keithp.com> wrote:
>>>>> Dave Airlie <airlied at gmail.com> writes:
>>>>>
>>>>>> On Mon, Jul 2, 2012 at 8:54 PM, Keith Packard <keithp at keithp.com> wrote:
>>>>>>> Dave Airlie <airlied at gmail.com> writes:
>>>>>>>
>>>>>>>
>>>>>>>> Yes thats going to be the standard on switchable GPU machines, two masters
>>>>>>>> and the ability to jump between them. In that case max master is one, and you'd
>>>>>>>> have to set the provider roles. If maxmaster > 1 then xinerama
>>>>>>>> emulation is available.
>>>>>>>
>>>>>>> In those machines, isn't the limitation that only one of them can drive
>>>>>>> the LVDS panel at a time? Can't you have the internal GPU driving the
>>>>>>> LVDS while the external GPU drives other outputs?
>>>>>>
>>>>>> Yes but you don't configure it in xinerama mode for that, there are
>>>>>> mux and muxless configurations.
>>>>>
>>>>> I think I understand what the hardware does now, just trying to figure
>>>>> out how to provide a reasonable description of that to applications
>>>>> while not just providing a big 'muxless/muxed' switch, which seems
>>>>> restricted to precisely how the hardware that we have works today.
>>>>>
>>>>>> In mux configuration, you switch the mux between GPUs when the master
>>>>>> is switched.
>>>>>
>>>>> Right, the mux just rewires things so that the other GPU is hooked up to
>>>>> the LVDS. I'd expect the LVDS outputs to reflect a suitable connection
>>>>> status for these changes.
>>>>>
>>>>> The only question is how you drive the mux switch. Is this switch
>>>>> selectable per-output? Or is is global? And, how do we label which
>>>>> outputs are affected by a global switch?
>>>>
>>>> We don't really know with 100% certainty since the specs for all these
>>>> things are closed. We've done a lot of RE work, and it mostly appears
>>>> to be a single global switch that turns any connected outputs. There is
>>>> a table in the intel bios which can tell you about which outputs are muxed
>>>> etc, but this isn't always present. Again we also have laptops that have
>>>> a mux but don't expose this table, as they only have the MUX so the
>>>> BIOS can pick IGP/discrete for Vista, and Windows 7 operates in
>>>> muxless mode.
>>>>
>>>> The current problem is I'm not sure any OS exposes muxless and mux
>>>> in one OS. Mac OSX always uses muxed, Vista the same, and I think
>>>> Windows 7 always exposes muxless if the bios reports optimus support
>>>> or the AMD equivalent.
>>>
>>> All new AMD systems are muxless and I suspect most other vendors are
>>> doing the same.  I'm wondering if there is any reason to bother with
>>> proper muxed support at all?  We should be able to treat muxed systems
>>> as muxless just fine.
>>>
>>
>> Apple hw is the only one I know off persisting with a muxed design,
>>
>> Whether it buys us much supporting the mux on it I'm not sure, I've no
>> idea to what degree they power down the intel hardware on it.
>
> I doubt they can do anything more than on the PC side otherwise the PC
> side probably would have done it too.
>

Well they designed a MUX that wasn't pure shit, they have the ability
to do glitchess mux changes, where they set the intel refreshing the display
at 50Hz and the discrete at 60Hz, then when the vblanks crossover the chip
notices and does the switch. I don't think anyone in PC land had the
brains/balls
 to do such a thing ;-)

Dave.