KMS cursor BO semantics

[James Simmons]

> 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?