On Sat, 17 Sep 2011 21:25:29 +0100 Alan Cox alan@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.