Dave Airlie <[email protected]> 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? I think my confusion about this stuff starts with the notion of what a 'master' provider is. From my understanding, a 'master' provider is something which has outputs and a rasterizer, and to which slave providers can be attached. Slave providers can then either have outputs or a rasterizer, but not both, and they can't have further slaves attached. This seems to make a 'master' provider be effectively an implicit union of two slave providers -- an output slave and a rendering slave. And then, it takes on a completely separate role as the locus of connection between those implicit providers and more explicit slave providers. Would it not be simpler to eliminate the notion of 'master' provider, and simply have the screen reference a collection of providers, those providers having either 'output' or 'rendering' roles (or both)? And then, OUTPUTs for each 'output' provider would have a list of conflicting OUTPUTs from other 'output' providers, exposing the limitations of the hardware precisely. > Yes we probably need to spec that a bit better, things should go off > when transitioning from master->off, output slave->off, > but with a GPU switch you probably want to avoid turning off the intel > panel if you can since it would look smoother. The only way to do that would be to have an atomic mode set which reconfigured the providers and crtcs all at once. Before we get there, I think this request should require that all CRTCs and OUTPUTs on an 'output' provider be disabled before the provider is disabled. -- [email protected]
pgp0is1rHPQwI.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
