On Tue, May 31, 2016 at 8:29 AM, Gerd Hoffmann kraxel@redhat.com wrote:
but it also means that atomic userspace can't use hotspots before we add properties to fbs. And doing that is a bit tricky since drm_framebuffer objects are meant to be invariant - this assumption is deeply in-grained into the code all over the place, everything just compares pointers when semantically it means to compare the entire fb (including backing storage pointer/offsets and everything).
Hmm, the hotspot location for a given cursor image is invariant too, so I don't think that would be a big issue.
I'd expect userspace define a bunch of cursors, then switch between them (instead of defining a single cursor, then constantly updating it).
Agreed, conceptually it would be a really nice fit to put the hotspot into the invariant drm_framebuffer. I just meant to say that you need to add a bit of new uapi to make it happen, since we can't reuse our existing get/set_prop functions (since those only change props after the object is created). And we also can't use our existing ioctls to enumerate properties of an object (since chicken-egg: you want the list of properties before creating a new framebuffer, so can't use that framebuffer to enumerate them).
But really not a big concern. -Daniel