On 11/04/2011 11:49 PM, Maarten Maathuis wrote:
On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom<thellstrom@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
