Re: [PATCH] fb/intelfb: Do not depend on EMBEDDED

[Jean Delvare <jdelvare@suse.de>]

Hi Dave, Jesse,

Dave Airlie <airlied@linux.ie> 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.

Are you suggesting that the "kms driver" is a drop-in replacement for
intelfb? More specifically, can I use that "kms driver" to get a
high-resolution console?

>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 think
>it supports LVDS which means loading it on a laptop will trash it.

The intelfb driver is marked EXPERIMENTAL, so it is already expected to not
work perfectly in all cases.

Le samedi 12 décembre 2009 22:55, Jesse Barnes a écrit :
> 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.   

The Kconfig help text doesn't say anything about this.

My understanding is that the intelfb driver was not _designed_ to be
useful on embedded designs only. It just happens to be incomplete in
such a way that it works only in a few selected cases, which happen
to be embedded cases, and it fails in many other cases.

The proper way to handle this is not to make the driver depend on
EMBEDDED. The proper way would be to change the intelfb driver so
that it no longer binds to devices it will not properly support. If
the driver doesn't support LVDS (whatever it is) then it should
cleanly fail on systems which have that.

> If you can think of a better way of preventing users and distros
> from accidentally selecting this,

The reason why I sent a patch in the first place is exactly opposite:
I want to let distros select this driver. My case is as follows: we
had a product which included the intelfb driver, which we are in the
process of upgrading. Now we find that the intelfb driver is gone
(no longer selectable), which causes a problem as far as the upgrade
path of our customers is concerned.

So the problem I have to solve is: given a customer who was
successfully using the intelfb driver before, what solutions can we
offer when said customer upgrades to our new product? My own solution
was straightforward: keep including the intelfb driver in the new
product. Thus my patch dropping the dependency on EMBEDDED. If
another solution exists, please let me know.

> then please send a patch. 

First of all, I'd need to better understand how the various drivers
relate to each other, and what functionality they provide. In my
little outdated mind, framebuffer is for high-resolution console
without X, while drm is for accelerated X. Apparently this changed
more or less recently, but the documentation wasn't updated.

It would help if the DRM option description was updated. It still
reads: "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)". If the DRM core is now also providing support for
framebuffer-like functionality (again, if I understand correctly)
then the reference to XFree86 should be dropped. The help text
should also be updated to properly describe all that the DRM core
offers today.

Honestly, I'm probably not the best person to write this text, as I
don't know much about the current state of this graphics stuff.

Thanks,
-- 
Jean Delvare
Suse L3