Proposal for a low-level Linux display framework
jbarnes at virtuousgeek.org
Mon Oct 31 13:24:37 PDT 2011
On Sat, 17 Sep 2011 21:25:29 +0100
Alan Cox <alan at lxorguk.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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the dri-devel