On Sat, 17 Sep 2011 21:25:29 +0100 Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
