[PATCH] randr: add provider object (v7)

[Alex Deucher]

On Tue, Jul 3, 2012 at 10:49 AM, Dave Airlie <airlied at gmail.com> wrote:
> 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 ;-)

Does that work properly with DP or eDP?