On Fri, Nov 11, 2011 at 7:17 PM, James Simmons <jsimmons@xxxxxxxxxxxxx> wrote: > >> 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 > Copying means you can convert the cursor to another format if needed. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
