Date: Mon, 13 Dec 2010 16:25:13 +0100
From: Florian Mickler <florian@mickler.org>
To: David Fries <david@fries.net>
Cc: linux-kernel@vger.kernel.org, David Airlie <airlied@linux.ie>,
        dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] [correction] load fbcon from drm_kms_helper
Message-ID: <20101213162513.6281f5af@schatten.dmk.lab>
In-Reply-To: <20101213003411.GM13567@spacedout.fries.net>
References: <20101212183921.GA25744@spacedout.fries.net>
	<20101212230128.47c20b10@schatten.dmk.lab>
	<20101213003411.GM13567@spacedout.fries.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3458
Lines: 80

On Sun, 12 Dec 2010 18:34:11 -0600
David Fries <david@fries.net> wrote:

> On Sun, Dec 12, 2010 at 11:01:28PM +0100, Florian Mickler wrote:
> > On Sun, 12 Dec 2010 12:39:22 -0600
> > David Fries <david@fries.net> wrote:
> > 
> > > Kconfig says fbcon is required by drm_kms_helper.  If radeon, fbcon,
> > > and drm_kms_helper are all modules, radeon is auto loaded (by PCI id?),
> > > drm_kms_helper is loaded because of the module dependency, but fbcon
> > > isn't loaded leaving the console unusable.  Since fbcon is required
> > > and there isn't an explicit module dependency, request the module
> > > to be loaded from drm_kms_helper.
> > > 
> > > Signed-off-by: David Fries <david@fries.net>
> > > Cc: David Airlie <airlied@linux.ie>
> > > Cc: dri-devel@lists.freedesktop.org
> > > ---
> > > The last patch had a typo 'namue', mental reminder, test again after
> > > running checkpatch.pl.
> > > 
> > > This solves compiling CONFIG_FB=m and being left with a blank screen
> > > because the radeon module is automatically loaded, but fbcon isn't.
> > > If radeon had to be manually loaded, then it would be the user's fault
> > > for
> > > not loading fbcon as well, but as radeon is being loaded
> > > automatically,
> > > there isn't much a user can do from console to even fix it.  More bug
> > > details from here,
> > > https://bugzilla.kernel.org/show_bug.cgi?id=16221
> > 
> > I guess this is reasonable. Maybe _if_ there actually is a usecase for
> > a drm driver without fbcon, the drm could provide a
> > parameter to skip loading fbcon?
> 
> My question was more, is there a usecase for a drm driver with
> the fbcon module available, but not wanting it loaded?

Isn't that the same question? I intended it to be in any case.  :)


> 
> > But also the drm Kconfig seems to be bogus? SELECT is not transitiv. 
> > So selecting DRM_KMS_HELPER is not enough, as it will not select FB
> > and FRAMEBUFFER_CONSOLE. Maybe the drm drivers that currently
> > select DRM_KMS_HELPER should instead depend on it.  
> 
> But the "select FB" and "select FRAMEBUFFER_CONSOLE if !EMBEDDED"
> Kconfig for DRM_KMS_HELPER is the mechanism that cause FB and
> FRAMEBUFFER_CONSOLE to be compiled.  The was the other part of my
> reasoning, if there is a case for drm without fbcon, DRM_KMS_HELPER
> shouldn't force fbcon to be compiled.  But as it does require fbcon to
> be compiled, and things are clearly broken if a drm driver is loaded
> (radeon) but fbcon isn't loaded (no usable console) DRM_KMS_HELPER
> should try to load it, hence the patch.
> 
> Just for a check I used `make xconfig` to verify they are
> automatically selected.
> set FB, DRM_RADEON, DRM etc to =n so FRAMEBUFFER_CONSOLE can also be set to =n
> set DRM=m (FRAMEBUFFER_CONSOLE still =n)
> set DRM_RADEON=m (DRM_KMS_HELPER, FB, and FRAMEBUFFER_CONSOLE become =m)
> That's because DRM_RADEON sets DRM_KMS_HELPER, and DRM_KMS_HELPER selects
> FB and FRAMEBUFFER_CONSOLE
> config DRM_RADEON
> 	select DRM_KMS_HELPER
> config DRM_KMS_HELPER
> 	select FB
> 	select FRAMEBUFFER_CONSOLE if !EMBEDDED
> and FRAMEBUFFER_CONSOLE is forced to =m 
> 

You are right. Sorry for the confusion. select is indeed
transitive. (I could have sworn... bah..)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/