On Tue, 31 May 2016 08:29:20 +0200 Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > 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). Except updating a single cursor (well, two alternating buffers) is exactly what Weston does, since there is no "set of cursors". On Wayland, a cursor is just a regular surface like any other with arbitrary content from a client, except it happens to be associated with a pointer device. Furthermore, in Weston a cursor plane is not special in any way. *Any* client surface can go on the cursor plane if it fits. Universal planes, and all that. That's one existing userspace. I suppose that is sub-optimal for virtual drivers, isn't it? But what else could Weston do without having separate paths for "normal DRM" vs. "virtual DRM"? Thanks, pq
Attachment:
pgpMojBdephxD.pgp
Description: OpenPGP digital signature
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
