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 Content-Length: 2413 Lines: 5 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?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?