Messages in this thread | | | Date | Mon, 29 May 2006 14:48:40 +0200 | From | Pavel Machek <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
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/
| |