Re: OpenGL-based framebuffer concepts

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

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

Sorry by brain slipped I meant suspend/resume... not enough sleep too
much flamage..

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

But the things is today for many users suspend/resume to RAM works for
people running X drivers, I know on my laptop that my radeon
suspends/resumes fine when running vgacon/DRM/accelerated X, it
doesn't suspend/resume at all well when running vgacon on its own of
course. or with radeonfb for that matter. so I still believe the
suspend/resume code for a card can live in userspace if necessary but
it just shouldn't be part of X... it needs to be part of another
graphics controller process.

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

To be honest, not using fbdev may be a better long-term solutions I'm
wholly not convinced we can put enough support for things into the
fbdev drivers without a lot of work, I've concentrated before on
splitting X.org into two pieces, a device setup and control process
running most of the X driver, and a rendering server. The thing
currently missing from the equation is the memory management unit, so
I can say this buffer is the current front buffer, and things like
that, so that we can invalidate the front buffer on rotations and
other operations where it needs to be. This can all be built on top of
the DRM. We can then perhaps have an fbcon or drmcon that knows where
the card's frontbuffer is and what mode is set on it, so it can dump
oops etc...

vgacon causes problems of course with memory management, as I believe
that most graphics cards when in text mode, don't allow you to specify
what pieces of their VRAM are being used to display the text mode, so
you have to try and keep framebuffers at the start of RAM, when really
you'd like to not have that sort of restriction.

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