Re: KMS cursor BO semantics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-- 
Daniel Vetter
Mail: daniel@xxxxxxxx
Mobile: +41 (0)79 365 57 48
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux