From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935230AbZLMBzz (ORCPT ); Sat, 12 Dec 2009 20:55:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S935219AbZLMBzv (ORCPT ); Sat, 12 Dec 2009 20:55:51 -0500 Received: from outbound-mail-301.bluehost.com ([67.222.53.8]:59987 "HELO outbound-mail-301.bluehost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S935144AbZLMBzc (ORCPT ); Sat, 12 Dec 2009 20:55:32 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=virtuousgeek.org; h=Received:Date:Subject:Message-ID:From:To:Cc:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Mk/b9YhIjrQILiON7jP09/2Ulpcyz0o9Lg4wWw8V1rIDwD1VcuaLjckFck+8K/ERN6KvyymaI8FSrkBPdSy0M03+fvNLRFrPvIdU8L6NRBRELN2BN2YBeulkC4Um+v2X; Date: Sat, 12 Dec 2009 13:55:40 -0800 Subject: Re: [PATCH] fb/intelfb: Do not depend on EMBEDDED Message-ID: From: Jesse Barnes To: Dave Airlie , Jean Delvare Cc: Jeff Mahoney , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=utf-8 X-Identified-User: {10642:box514.bluehost.com:virtuous:virtuousgeek.org} {sentby:smtp auth 70.210.201.34 authed with jbarnes@virtuousgeek.org} Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by alpha.home.local id nBD1uB16015330 Right, the logic is that the driver really is for embedded (i.e. very special purpose) use. It should not be selected unless you really know what you're doing or are building a very particular product. If you can think of a better way of preventing users and distros from accidentally selecting this, then please send a patch. Jesse Dave Airlie wrote: >>> I am worried that the intelfb driver depends on EMBEDDED. I consider>> this an abuse of the EMBEDDED configuration option, which as I>> understand it was originally meant to expose fine-tuning options,>> rather than to arbitrarily disable drivers when not selected.>>Since we merged a kms driver for Intel hw that supports all intel chipsets>and more importantly all the outputs on Intel chipsets, intelfb should>be considered legacy at the least and broken on > 50% of intel hw.>>We left it in in that most ppl who wanted it were using it in embedded >configs, whereas for most users it just doesn't work, like I don't thinkit>supports LVDS which means loading it on a laptop will trash it.>>Dave>>>> >> So I suggest that we drop this dependency now.>> >> Signed-off-by: Jean Delvare >> Cc: Jesse Barnes >> Cc: Dave Airlie >> --->> Jesse, in the original commit, you wrote that intelfb was "really a>> special purpose embedded driver". It looks like a perfectly standard>> framebuffer driver to me, which means that it may have users beyond>> embedded. For example I always prefer framebuffer over X for my>> servers. Or am I missing something and intelfb is really special?>> >> drivers/video/Kconfig | 2 +->> 1 file changed, 1 insertion(+), 1 deletion(-)>> >> --- linux-2.6.32.orig/drivers/video/Kconfig 2009-12-03 08:48:34.000000000 +0100>> +++ linux-2.6.32/drivers/video/Kconfig 2009-12-11 10:57:43.000000000 +0100>> @@ -1121,7 +1121,7 @@ config FB_CARILLO_RANCH>> >> config FB_INTEL>> tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM support (EXPERIMENTAL)">> - depends on EXPERIMENTAL && FB && PCI && X86 && AGP_INTEL && EMBEDDED>> + depends on EXPERIMENTAL && FB && PCI && X86 && AGP_INTEL>> select FB_MODE_HELPERS>> select FB_CFB_FILLRECT>> select FB_CFB_COPYAREA>> >> >{.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I