On 11/04/2011 03:36 PM, Ilija Hadzic wrote:
On Fri, 4 Nov 2011, 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?
Thanks,
Thomas
FWIW, Acked-by: Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx>
I have a few places where I could use such an ioctl.
Well, the idea was to reuse the DRM_IOCTL_MODE_CURSOR ictl that sets the
cursor BO, and require that it is re-emitted once the cursor image has
changed, since I guess that's what many X servers do anyway.
BTW, Thomas, in the above "since the cursor data is sent though the
command stream", did you mean "since the cursor data is *not* sent
though the command stream". If it was sent, through command stream,
then CS ioctl would know when the cursor changes.
I meant the device interface, not the drm interface. So when we have a
new cursor image, we need to collect the scanline data an send it
through the device command stream. We don't export that possibility in
the DRM interface.
My understanding is that the cursor data are mmap-ed letting userland
poke it at will (so the case when an "hourglass" changes into "arrow"
is particularly hard to know that it happened).
Yes. Hardware that scan out directly from the cursor BO don't really
need to know, but we do.
-- Ilija
Thanks,
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
