Hi, > > Why attach the hotspot to the plane? Wouldn't it make more sense to > > make it a framebuffer property? > > We don't have properties on the framebuffer. I guess you /could/ just add > it internally to struct drm_framebuffer, and not bother exposing to > userspace. I guess that would be a lot simpler, Yes. I can simply stick the hotspot into drm_framebuffer in drm_mode_cursor_universal() and pick up the values in the driver's plane update function. > 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). cheers, Gerd _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
