> 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. Alan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
