[PATCH RFC] cursor: add wl_cursor_manager

[Simon Ser]

Signed-off-by: Simon Ser <***@emersion.fr>
---

This patch only includes changes to libwayland-cursor's header file.
The goal is to show how the new API could look like.

This patch adds a new wl_cursor_manager. When created, it only binds
to wl_shm and discovers additional protocols the compositor might
support. These include the xcursor-configuration protocol draft [1]
and the future compositor cursors protocol. In order to make sure this
libwayland-cursor API is compatible with the latter, a proof-of-concept
(undocumented) protocol has been drafted [2].

This manager allows users to create cursor themes (wl_cursor_theme) by
specifying a seat, an input device type and a scale factor. Then
individual cursors (wl_cursor) with cursor image metadata
(wl_cursor_image) can be retrieved as usual. Buffers (wl_buffer) can
be created with cursor images.

We are pretty lucky because wl_cursor_theme is an opaque struct and
wl_cursor doesn't expose raw image data. I hope we can continue to
use the existing API and make it work with both protocols by simply
adding this new wl_cursor_manager.

Is it necessary to add a default_theme and a default_size argument
to wl_cursor_manager_create?

As always, comments and questions are welcome!

[1]: https://patchwork.freedesktop.org/series/50948/
[2]: https://gist.github.com/emersion/ad8225bbe30767d6821346c08fda407a

cursor/wayland-cursor.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)

diff --git a/cursor/wayland-cursor.h b/cursor/wayland-cursor.h
index 40d3fc5..9523de6 100644
--- a/cursor/wayland-cursor.h
+++ b/cursor/wayland-cursor.h
@@ -70,6 +70,26 @@ int
wl_cursor_frame_and_duration(struct wl_cursor *cursor, uint32_t time,
uint32_t *duration);

+struct wl_cursor_manager;
+struct wl_registry;
+
+enum wl_cursor_device_type {
+ WL_CURSOR_DEVICE_TYPE_POINTER,
+ WL_CURSOR_DEVICE_TYPE_TABLET_TOOL,
+};
+
+struct wl_cursor_manager *
+wl_cursor_manager_create(struct wl_registry *registry);
+
+void
+wl_cursor_manager_destroy(struct wl_cursor_manager *manager);
+
+struct wl_cursor_theme *
+wl_cursor_manager_get_theme(struct wl_cursor_manager *manager,
+ struct wl_seat *seat,
+ enum wl_cursor_device_type device,
+ int32_t scale);
+
#ifdef __cplusplus
}
#endif

[Simon Ser]

Ah, I forgot to say that an issue with this design is that some
libwayland-cursor would need to block until the compositor sends the required
metadata (ala-wl_display_roundtrip). I'm not sure if this is an issue or not.

If we don't want to block, then we'll need a much more complicated design with
callbacks or signals, and we wouldn't be able to re-use parts of the current
API.

Thoughts?