> > > Yes, I think so. One reason to lock is to make sure the GTT page table > is really repopulated after a resume, but that can be handled in the DRM > driver resume function, and we could perhaps > change the user-space lock_mm() to ignore kernel_bos.
It defintely should all be handled in-kernel, putting functionality like that under user space control is a throw back, the lock-mm should maybe only apply to the bos allocated to that user who locks.. or really I'm not sure we really need a lock function if we have a proper kernel driver.. > > We also have a another possibility where an ioctl makes the drm fb evict > its scanout buffers and one that brings them back. This preserves > aperture space when X is doing its allocation, but it's abit > error-prone since it requires that fb can live with updated offsets and > kernel virtual addresses. It apparently can, but there's no mutex > generally protecting these variables so it seems quite fragile. Again we can't do this with an ioctl as it leaves us open to userspace whims, however with modesetting branch I'm hoping to come up with something to allow this, myself and Jakob have discussed a driver specific ioctl, which can swap fbs out of the aperture on the fly, so the driver can swap in X's fb and when X exits swap in the fb fb.. Yes fb is a bit messy, it doesn't have a prepare/commit type functionality, and we may have to come up with a map/unmap interface with a mutex for it to use to update the screen... Dave. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
