Message-ID: <20111031132437.23eae6b8@jbarnes-desktop>
Date:	Mon, 31 Oct 2011 13:24:37 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Dave Airlie <airlied@...il.com>, linux-fbdev@...r.kernel.org,
	linaro-dev@...ts.linaro.org,
	Florian Tobias Schandinat <FlorianSchandinat@....de>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	Archit Taneja <archit@...com>, Rob Clark <rob@...com>
Subject: Re: Proposal for a low-level Linux display framework

On Sat, 17 Sep 2011 21:25:29 +0100
Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> > Just tell the X driver to not use acceleration, and it you won't get
> > any acceleration used, then you get complete stability. If a driver
> > writer wants to turn off all accel in the kernel driver, it can, its
> 
> In fact one thing we actually need really is a "dumb" KMS X server to
> replace the fbdev X server that unaccel stuff depends upon and which
> can't do proper mode handling, multi-head or resizing as a result. A dumb
> fb generic request for a back to front copy might also be useful for
> shadowfb, or at least indicators so you know what the cache behaviour is
> so the X server can pick the right policy.
> 
> > We've fixed this in KMS, we don't pass direct mappings to userspace
> > that we can't tear down and refault. We only provide objects via
> > handles. The only place its a problem is where we expose fbdev legacy
> > emulation, since we have to fix the pages.
> 
> Which is doable. Horrible but doable. The usb framebuffer code has to
> play games like this with the virtual framebuffer in order to track
> changes by faulting.
> 
> There are still some architectural screwups however. DRM continues the
> fbdev worldview that outputs, memory and accelerators are tied together
> in lumps we call video cards. That isn't really true for all cases and
> with capture/overlay it gets even less true.

Sorry for re-opening this ancient thread; I'm catching up from the past
2 months of travel & misc.

I definitely agree about the PC card centric architecture of DRM KMS
(and before it, X).  But we have a path out of it now, and lots of
interest from vendors and developers, so I don't think it's an
insurmountable problem by any means.

I definitely understand Florian's worries about DRM vs fb.  If nothing
else, there's certainly a perception that fb is simpler and easier to
get right.  But really, as others have pointed out, it's solving a
different set of problems than the DRM layer.  The latter is actually
trying to expose the features of contemporary hardware in a way that's
as portable as possible.  That portability comes at a cost though: the
APIs we add need to get lots of review, and there's no doubt we'll need
to add more as newer, weirder hardware comes along.

Really, I see no reason why fb and DRM can't continue to live side by
side.  If a vendor really only needs the features provided by the fb
layer, they're free to stick with a simple fb driver.  However, I
expect most vendors making phones, tablets, notebooks, etc will need
and want an architecture that looks a lot like the DRM layer, with
authentication for rendering clients, an command submission ioctl for
acceleration, and memory management, so I expect most of the driver
growth to be in DRM in the near future.

And I totally agree with Dave about having a kmscon.  I really wish
someone would implement it so I could have my VTs spinning on a cube.

-- 
Jesse Barnes, Intel Open Source Technology Center

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists