Re: OpenGL-based framebuffer concepts

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >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:

Vojtech Pavlik is the one who done inputs... not me. (I admit we have
similar names).

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

Okay, we are in deeper trouble then I thought, then.

> >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 :-)

No, to the contrary. suspend/resume can't ever work properly with
vgacon and vesafb. It works okay with radeonfb tooday, and in fact
radeonfb is neccessary today for saving power over S3.

> 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.

These are very reasonable rules... but still, I think we need to move
away from vgacon/vesafb. We need proper hardware drivers for our
hardware.

Now, having DRM depend on framebuffer driver sounds like a right
long-term solution. We probably need to do something with
vesafb/vgacon... like stub it out or something, and deprecate them,
long-term.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/