[PATCH] drm, i915: select framebuffer support automatically

[Ingo Molnar]

* Eric Anholt <eric@xxxxxxxxxx> wrote:

> On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
> > * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > > On Wed, 4 Feb 2009, Norbert Preining wrote:
> > > > 
> > > > The problem is that if you have a configuration under 2.6.28 without 
> > > > CONFIG_FB and just call make oldconfig, or even make config and don't 
> > > > know that you loose the DRM. And I was using make oldconfig (there is a 
> > > > graphical config?? ;-))
> > > 
> > > Sure. It's inconvenient, no question about that. I asked the i915 people 
> > > to look into not requiring CONFIG_FB, and I hope they will, but my point 
> > > is that I don't think we can consider "small one-time inconvenience" to be 
> > > a "regression".
> > 
> > if you mean that as a general principle, there's four very real downsides in 
> > my opinion.
> > 
> > Firstly, we could have done better (and still can do better), via various 
> > easy and non-intrusive measures:
> > 
> >    - We could add a runtime warning:
> > 
> >       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
> >       that there's no DRM because CONFIG_FB is not selected and oldconfig 
> >       loses the I915 setting silently - placed in a key DRM ioctl, would 
> >       have gone a long way addressing the issue. Testers do notice kernel 
> >       warnings that pop up when their X gets slow. (This approach might also 
> >       have the added bonus of warning folks who enable the wrong driver for 
> >       the hardware.)
> > 
> >    - Or we could add a more thoughtful Kconfig migration:
> > 
> >       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
> >       DRM_I915 as a non-interactive migration helper: if set, it 
> >       auto-selects both FB and DRM_I915_FB.
> > 
> >       While CONFIG_FB is an interactive Kconfig option so a select can be 
> >       dangerous to a correct dependency tree, it seems safe to do in this 
> >       specific case because it seems to be a rather leaf entry with no 
> >       dependencies.
> 
> I tried select FB.  It's the right thing to do.  It doesn't work.  I
> posted to the mailing list two weeks ago about the insane dependency
> chain that kbuild comes up with and fails on when we do this, and got
> silence.

I mean the patch below.

I have tested it here it works fine and has no dependency problems, nor any 
build breakages on 32-bit or 64-bit x86. When you tried this you probably 
ran into the FB_I810 and FB_INTEL complication - this patch solves that too.

What do you think?

	Ingo

--------------->