On Sat, 17 Sep 2011 21:25:29 +0100
Alan Cox [off-list ref] wrote:
quoted
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.
quoted
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