Re: KMS cursor BO semantics

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

 



> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
> > 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?
> 
> We don't handle really hanlde rendering to cursor objects. I think the
> "require a set_cursor after every cursor bo change" semantic is good, I've
> just feared that when only vmgfx needs this, no generic kms user will
> actually implement it. But nouveau seems to require this too, so I think
> at least for this case reality (and generic kms clients) will play along.

I know this is a bit off topic but I see two approaches to the cursor api. 
One is the nouveau method which is 

...
	drm_gem_object_lookup
	internal_mmap gem object
	copy to another internally allocated buffer objec
	unmap gem object
	drm_gem_object_unreference_unlocked
...

Or the radeon approach

...
	drm_gem_object_lookup
	gem_object_pin
	program cursor location
	gem_object_unpin
	drm_gem_object_unreference_unlocked
...

What are the pros and cons to each method?
_______________________________________________
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