From: Jakob B. <wal...@gm...> - 2009-03-26 14:59:16
|
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. And all the other users that I know of is userspace. > > > >> The interface gives you enough information to find the LVDS and turn >> that on only that on. > > >> Is there some other reason that the getting of >> output name is slow? If so I would be happy to see patches that fixes >> that. > > 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. 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. Cheers Jakob. |