On 11/04/2011 11:49 PM, Maarten Maathuis wrote: > On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom<thellstrom at vmware.com> > wrote: > >> 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 >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> > As far as i know nouveau keeps an internal buffer object for the > cursor and relies purely on the ioctl to copy the cursor into the > actual cursor memory area. So why do you need tricks? > > Because I have a hard time judging whether the Intel implementation (needs tricks) or the Nouveau implementation (doesn't need tricks) should define the semantics of the ioctl, although I would prefer we could all agree on the "doesn't need tricks" semantics and put that down in writing in the drm_mode.h header file.
/Thomas
