On Thu, Mar 26, 2009 at 4:25 PM, Arjan van de Ven <ar...@infradead.org> wrote: > On Thu, 26 Mar 2009 15:59:12 +0100 > Jakob Bornecrantz <wallbra...@gmail.com> wrote: > >> On Thu, Mar 26, 2009 at 3:25 PM, Arjan van de Ven >> <ar...@infradead.org> wrote: >> > On Thu, 26 Mar 2009 11:59:13 +0100 >> > Jakob Bornecrantz <wallbra...@gmail.com> wrote: >> > >> >> On Mon, Mar 23, 2009 at 9:46 PM, Arjan van de Ven >> >> <ar...@infradead.org> wrote: >> >> > >From 785bb9f968ead288395ead4f921d7c1fb794ee71 Mon Sep 17 >> >> > >00:00:00 2001 >> >> > From: Arjan van de Ven <ar...@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 <ar...@linux.intel.com> >> >> >> >> Not-acked-by: Jakob Bornecrantz <wallbra...@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? > >> > This patch has nothing to do with speed; it is only about >> > registration order. LVDS-before-CRT makes total sense (as long as >> > the lid of the laptop is not closed, which is why I added the >> > comment); while CRT-before-LVDS does not. >> >> It makes totally sense for you, for somebody else not, which is why >> policy in the kernel is a bad idea. > > complaining about a change in policy by saying "there should be no > policy" is not very useful; the policy is there today. > >> >> What happens if the lid is closed? Is no lvds connector created? The >> comment you added make it sounds so, at least that was my first >> impression. > > that is what the rest of the code says yes. I just wanted to add the > comment to show that. That sounds like a bug, I don't want to have to reload my i915 driver because I had the laptop lid closed when I booted it. Or is there some code in there that adds the connector later on? Cheers Jakob. ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
