Re: [RFC] Three pipe support for IVB

[Daniel Vetter <daniel@ffwll.ch>]

On Thu, Oct 06, 2011 at 08:18:30AM -0700, Jesse Barnes wrote:
> On Thu, 6 Oct 2011 07:31:44 +0100
> Dave Airlie <airlied@gmail.com> wrote:
> > On Wed, Oct 5, 2011 at 9:18 PM, Keith Packard <keithp@keithp.com> wrote:
> > > On Wed, 5 Oct 2011 12:56:47 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > >
> > >> Unfortunately, (2) complicates our mode list output.  If you query for
> > >> available modes, you'll definitely see some that you can't drive with 3
> > >> pipes enabled.  I'm not sure if the best way to handle that...
> > >
> > > All we can do is say 'no' when someone tries to select that
> > > configuration. We've never figured out a better way to list valid
> > > settings.
> > >
> > > The proposed RandR 1.4 protocol has a 'set everything all at once' API
> > > which allows you to say 'no' before even starting the mode setting
> > > process, which is kinda nice. We just need to make sure sure this can be
> > > mirrored through KMS to the hardware.
> > 
> > Fine for dynamic stuff, how do you pick a correct initial mode?
> > 
> > You can't say no there, you need to make a decision from the
> > information provided.
> 
> Yeah that's a good point.  There's something weird going on in general
> with X's default config on my system at least.  All 3 heads come up at
> 1280x1024, but the two identical HDMI heads come up with different
> refresh rates for some reason (one uses the preferred mode and the
> other tries to get 75Hz).
> 
> Of course I'd prefer an extended config as the default, which might
> make it easier to choose all the preferred modes, but that doesn't
> solve the problem of having say two 1920x1200 monitors attached along
> with a 2560x1600, which won't work on IVB...
> 
> Should we add a new mode flag to indicate which modes are conditional
> on config and which modes can always be supported?  That way X and
> other tools could get all the heads lit up by default at least...

For the kernel console we have the identical "light up as much as possible
in the hope the user can see something" problem. So I think the only thing
to do is to expose the kernel console mode somewhere (in case a running X
session has totally mangled the modeset config). This way we need to solve
the problem only once and the kernel has all the information to make the
best out of it.

For everything else userspace just has to remember the users preferred
modeset layout and restore it on boot-up. I should be safe to assume that
a given mode that once worked should continue to do so, and if it fails
userspace can fall back to the kernel console configuration.

-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48