From: Arjan v. de V. <ar...@in...> - 2009-03-26 15:24:41
|
On Thu, 26 Mar 2009 15:59:12 +0100 Jakob Bornecrantz <wal...@gm...> wrote: > On Thu, Mar 26, 2009 at 3:25 PM, Arjan van de Ven > <ar...@in...> wrote: > > On Thu, 26 Mar 2009 11:59:13 +0100 > > Jakob Bornecrantz <wal...@gm...> wrote: > > > >> On Mon, Mar 23, 2009 at 9:46 PM, Arjan van de Ven > >> <ar...@in...> wrote: > >> > >From 785bb9f968ead288395ead4f921d7c1fb794ee71 Mon Sep 17 > >> > >00:00:00 2001 > >> > From: Arjan van de Ven <ar...@li...> > >> > 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...@li...> > >> > >> Not-acked-by: Jakob Bornecrantz <wal...@gm...> > >> > >> 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. > > 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. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org |