On Tue, Jul 3, 2012 at 10:49 AM, Dave Airlie <airl...@gmail.com> wrote: > On Tue, Jul 3, 2012 at 3:25 PM, Alex Deucher <alexdeuc...@gmail.com> wrote: >> On Tue, Jul 3, 2012 at 10:10 AM, Dave Airlie <airl...@gmail.com> wrote: >>> On Tue, Jul 3, 2012 at 2:57 PM, Alex Deucher <alexdeuc...@gmail.com> wrote: >>>> On Tue, Jul 3, 2012 at 7:57 AM, Dave Airlie <airl...@gmail.com> wrote: >>>>> (forgot list first time I sent this). >>>>> >>>>> On Mon, Jul 2, 2012 at 10:03 PM, Keith Packard <kei...@keithp.com> wrote: >>>>>> Dave Airlie <airl...@gmail.com> writes: >>>>>> >>>>>>> On Mon, Jul 2, 2012 at 8:54 PM, Keith Packard <kei...@keithp.com> wrote: >>>>>>>> Dave Airlie <airl...@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? _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel