[Intel-gfx] [PATCH] KMS: register the LVDS before the CRT

[Jesse Barnes]

On Thu, 26 Mar 2009 16:39:31 +0100
Jakob Bornecrantz <wallbraker at gmail.com> wrote:

> On Thu, Mar 26, 2009 at 4:25 PM, Arjan van de Ven
> <arjan at infradead.org> wrote:
> > On Thu, 26 Mar 2009 15:59:12 +0100
> > Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> >
> >> On Thu, Mar 26, 2009 at 3:25 PM, Arjan van de Ven
> >> <arjan at infradead.org> wrote:
> >> > On Thu, 26 Mar 2009 11:59:13 +0100
> >> > Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> >> >
> >> >> On Mon, Mar 23, 2009 at 9:46 PM, Arjan van de Ven
> >> >> <arjan at infradead.org> wrote:
> >> >> > >From 785bb9f968ead288395ead4f921d7c1fb794ee71 Mon Sep 17
> >> >> > >00:00:00 2001
> >> >> > From: Arjan van de Ven <arjan at linux.intel.com>
> >> >> > Date: Mon, 23 Mar 2009 13:34:46 -0700
> >> >> > Subject: [PATCH] KMS: register the LVDS before the CRT
> >> >> >
> >> >> > for the cases where the user only really cares about lighting
> >> >> > up one output, or only one output at first, lighting up the
> >> >> > LVDS (which only gets detected with lid-up) rather than the
> >> >> > CRT is the right answer.
> >> >> >
> >> >> > This patch flips their order of registration so that this
> >> >> > becomes possible.
> >> >> >
> >> >> > Signed-off-by: Arjan van de Ven <arjan at linux.intel.com>
> >> >>
> >> >> Not-acked-by: Jakob Bornecrantz <wallbraker at gmail.com>
> >> >>
> >> >> I'm going to nack this patch out of principle, getting the
> >> >> correct behavior from userspace depending on the order of
> >> >> connectors is bad.
> >> >
> >> > this has nothing to do with userspace though, but all about user
> >> > choice.
> >>
> >> Hard coding a specific order is not giving the user choice. Please
> >> tell me how doing crt-before-lvds fails with something that isn't
> >> userspace, currently I don't see how the order is important?
> >>
> >> Last time I checked there where only one kernel side consumer of
> >> the kms, the legacy fbdev stuff. Which if I remember correctly
> >> tried to clone one fb to all connectors. If you want to do some
> >> sort of no clone setup with fbdev you should let the user define
> >> the binding on the command line. Something like "i915 fb0=lvds0
> >> fb1=crt0". There might be some issues with this naming and
> >> hotplugable connectors.
> >
> > so the other patches in this patch series added a consumer that
> > basically lights up the first one and then continues booting the
> > kernel, while the "all but first" get detected asynchronously.
> > The concern from various people was that if there was an oops,
> > around that time, it should be on the "primary" display, where the
> > driver decided what was primary.
> 
> Now we are talking. Having a primary screen does make sense, but I do
> not think that the order in which they where discovered on the device
> should decide that.
> 
> Couldn't there be some sort of primary field on the dev struct that
> get turned on? And that could be selected by a command line option
> like "i915.primary=hdmi0" and the default being lvds, if it is
> present. Giving choice to the user and the default being something
> which I have to agree does make sense. Does this sounds okay with you?
> 
> Also a primary option for drm would be smart of multi gpu systems like
> "drm.primary=i915" maybe?

Yeah that would be great.  The driver should be able to indicate to the
core (or just init the fb driver directly on) which output is the
"primary" head, i.e. which is most likely to be available and visible
at driver init time, and which head should be used for panic & kernel
messages.  The module params you propose here sound great; we'd also
need some structure internals to handle it (and default to the "clone
everything" in the absence of a primary head).

-- 
Jesse Barnes, Intel Open Source Technology Center