On Tue, May 31, 2016 at 8:29 AM, Gerd Hoffmann <kraxel@xxxxxxxxxx> 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
