> 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
