Re: OpenGL-based framebuffer concepts

["Dave Airlie" <airlied@gmail.com>]

> > a) we don't always have a fully functional fbdev driver, see intel fb
> > drivers.
>
> Well, we need to write those fbdev drivers, then.

And you propose to get specs from hw vendors how? (please provide
solutions for practical problems)

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

we don't have the manpower to do even that...

> > c) Lots of distros don't use fbdev drivers, forcing this on them to
> > use drm isn't an option.
>
> Let the distros catch up with current state of technology....
>
> I mean, it is crazy. We have complex subsystem (graphics), that is
> made even more complex because of crazy design (independend fbdev and
> DRM, X handling PCI from userspace).

and you are not going to fix it with a big lot of code, you need to
fix it one problem at a time,

> Now, lets take common hardware like radeon. You want these
> combinations to be supported:
>
> vgacon
> vesafb ( + unaccelerated X )
> radeonfb ( + unaccelerated X )
>
> vgacon + accelerated X
> vesafb + accelerated X
> radeonfb + accelerated X
>
> vgacon + DRM + accelerated X
> vesafb + DRM + accelerated X
> radeonfb + DRM + accelerated X
>
> ...that's crazy! You claim that for various reasons (mostly bugs) we
> need to keep that complexity. That's not the way forward, with
> manpower we have I'm afraid.

We have to support what we support now, regressions in what we support
are not acceptable, we would spend all our time just having Linus
backing out changes, I'm sorry Pavel I respect what you've done with
input, but your list below cuts out a number of currently support
configurations the main ones currently in use are:

vgacon + DRM + accelerated X
vesafb + DRM + accelerated X

If you take a look at the stuff required to get r300 support in the
drm and X into the kernel without breaking current systems you'll get
an idea of what we have to do..

Linus has so far reverted a number of patches from the DRM as they
cause regressions, anything done in this area has to be careful to
have a complete understanding of the area.

> vgacon
> vesafb ( + unaccelerated X )
> radeonfb ( + unaccelerated X )
> radeonfb + accelerated X
> radeonfb + DRM + accelerated X
>

Again this gets rid of the two most popular combinations in use today.
I don't think this is acceptable, and you'll also break suspend/resume
on every radeon based laptop in use today, but I'm sure you thought
about all of that before posting :-)

I'm not knocking solutions here for the fun of it, I've tried a lot of
different combinations of things to find an answer, and until someone
supplies some code that doesn't regress or works in an incremental
manner to improve the situation....

Here are the rules:
1. No regressions.
2. Doesn't require lockstep changes in X and kernel, i.e. a new kernel
can't break old X, and new kernel can't require a new X, new config
features in the kernel can require a new X of course but anything
using and old config feature must still work.

Dave.