On Tue, 31 May 2016 08:29:20 +0200 Gerd Hoffmann kraxel@redhat.com 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