On 11/04/2011 04:34 PM, Daniel Vetter wrote: > On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote: > >> Hi. >> >> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: >> >> Some hardware (vmware's virtual in particular) may not be able to >> pick up the changes from a bo directly, since the cursor data is >> sent though the command stream. Hence we need a notification when >> the cursor image has changed. >> >> Could we *require* that a cursor image change needs to be followed >> by an ioctl call with the flag >> DRM_MODE_CURSOR_BO? >> > On i915 we need the cursor in physical memory for some (old) platforms, > which is seperate storage from the bo backing storage. So we have the same > problem. We've solved it by intercepting pwrite ioctl calls and demanding > that userspace only uses these for cursor updates. Is there a special > reason you can't use such a driver-specific trick? > -Daniel > We have something similar in use today: We snoop DMAs to hardware cursor surfaces, but this gets a bit nasty when apps start to do hardware render to cursor surfaces, and we simply ignore that today.
Furthermore, maps rather than pwrites are the common usage-pattern for buffer-backed cursors on vmwgfx, and while it's possible to dirty those buffers based on page-faults, like we do with fb surfaces, we'd rather avoid having to implement and maintain that. I'm not sure whether / how you handle the case of hardware render to cursor surfaces on i915, but it seems to me like if a lot of drivers need to implement driver specific "tricks" to meet the semantics of a generic interface, we should perhaps consider specifying those semantics in a way that helps avoid driver-specific workarounds? /Thomas
