Re: OpenGL-based framebuffer concepts

["Jon Smirl" <jonsmirl@gmail.com>]

On 5/28/06, Dave Airlie <airlied@gmail.com> wrote:
> I've already pointed out to Jon the problems with this approach on
> numerous occasions and to be honest do not have the time to do so
> again,
>
> I will not accept patches to make DRM drivers rely on fbdev drivers in
> the kernel for many many many reasons, two quick ones :

Hence we will have no forward progress in kernel graphics for the next
few decades.

> a) we don't always have a fully functional fbdev driver, see intel fb drivers.

Binding the drivers to each other does not cause any code to be called
in either driver. This is just the first step down a long path to
making the merged drivers work.

> b) loading fbdev drivers breaks X in a lot of cases, we need to be a
> bit more careful.

It is perfectly legal to load an fbdev driver with X today. If it
doesn't work it is a bug in X and should be fixed.

> c) Lots of distros don't use fbdev drivers, forcing this on them to
> use drm isn't an option.

Why isn't this an option? Will the distros that insist on continuing
to ship three conflicting video drivers fighting over a single piece
of hardware please stand up and be counted? Distros get new drivers
all the time, why will this be any different?

> should I go on?

yes

You do realize that in a merged fbdev/DRM driver that if the mode
setting code is pushed into a user space library (I've said that would
be part of the path to a fully merged driver) that there really isn't
much left to a fbdev driver besides the binding and initialization
code.

> I've made suggestions I've given you patches that start the work, I'm
> going to finish that work, but I've no timeline, I'd hope at KS/OLS
> this year to do it..

In your scheme the 60 existing fbdev drivers need to be edited to
remove their code that binds them to the hardware and make them use a
new low level driver. Are you signing up to edit all of these drivers?
I'll shut up when I see a tested patch that edits all 60 drivers and
make them use the new layer. My fear is that half the fbdev drivers
will get adjusted and no one will get around to fixing the rest,
effectively creating two fbdev architectures. A complete patch would
address that concern.

BTW, I've done patches that touched all of those drivers and it is a
very painful process. Be prepared to work on code for every
architecture supported by Linux.

--
Jon Smirl
jonsmirl@gmail.com
-
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/