[PATCH RFC wayland-protocols] unstable: add xcursor-configuration

[Simon Ser]

Clients are responsible for loading and setting cursors. For this
purpose they often use XCursor images via the libwayland-cursor
library. However clients have no way to know the user's preferred
theme and size. This results in inconsistent cursors across
clients (e.g. cursor growing bigger when entering a surface).

This protocol fixes this issue by sending the user's XCursor
preferences to the client. It also allows for per-seat cursor
configuration.

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

This is a draft of the XCursor configuration protocol. It's pretty
simple.

It still doesn't allow to configure differently wl_pointer's cursor
and the tablet tool's cursor. Maybe this can be done with an enum
and a new get_xcursor_configuration_seat argument?

Comments welcome!

unstable/xcursor-configuration/README | 4 +
.../xcursor-configuration-unstable-v1.xml | 105 ++++++++++++++++++
2 files changed, 109 insertions(+)
create mode 100644 unstable/xcursor-configuration/README
create mode 100644 unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml

diff --git a/unstable/xcursor-configuration/README b/unstable/xcursor-configuration/README
new file mode 100644
index 0000000..472e3bf
--- /dev/null
+++ b/unstable/xcursor-configuration/README
@@ -0,0 +1,4 @@
+xcursor configuration protocol
+
+Maintainers:
+Simon Ser <***@emersion.fr>
diff --git a/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
new file mode 100644
index 0000000..9d9d840
--- /dev/null
+++ b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
@@ -0,0 +1,105 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="wp_xcursor_configuration_unstable_v1">
+ <copyright>
+ Copyright © 2018 Simon Ser
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="protocol to configure XCursor themes">
+ This protocol allows compositors to advertize XCursor configuration to
+ clients.
+
+ Once compositor configuration is received, clients are responsible for
+ loading the XCursor theme, creating wl_buffers with cursor images and
+ setting the cursor.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <interface name="zwp_xcursor_configuration_manager_v1" version="1">
+ <description summary="XCursor configuration manager">
+ A global factory interface for wp_xcursor_configuration objects.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the XCursor configuration manager object">
+ Destroy the XCursor configuration manager. This doesn't destroy objects
+ created with the manager.
+ </description>
+ </request>
+
+ <request name="get_xcursor_configuration_seat">
+ <description summary="create a wp_xcursor_configuration object for a seat">
+ This creates a new wp_xcursor_configuration object for the given
+ wl_seat.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_xcursor_configuration_v1"/>
+ <arg name="seat" type="object" interface="wl_seat"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_xcursor_configuration_v1" version="1">
+ <description summary="XCursor configuration for a seat">
+ A Xcursor configuration seat object describes XCursor settings for a
+ specific seat.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy this object">
+ Using this request a client can tell the server that it is not going to
+ use this object anymore.
+ </description>
+ </request>
+
+ <event name="done">
+ <description summary="all information about the configuration has been sent">
+ This event is sent after all other properties of a
+ wp_xcursor_configuration have been sent.
+
+ This allows changes to the wp_xcursor_configuration properties to be
+ seen as atomic, even if they happen via multiple events.
+ </description>
+ </event>
+
+ <event name="theme">
+ <description summary="theme configuration">
+ The theme event describes XCursor theme configuration for this seat.
+ </description>
+ <arg name="name" type="string" summary="theme name"/>
+ <arg name="size" type="uint" summary="theme size"/>
+ </event>
+
+ <event name="default_cursor">
+ <description summary="default cursor name">
+ The default_cursor event describes the default XCursor cursor name to be
+ used for this seat.
+ </description>
+ <arg name="name" type="string" summary="default cursor name"/>
+ </event>
+ </interface>
+</protocol>

[Michael Arnold]

Hi,

Sean, this looks great. In the hope that basic questions help, I've
recorded my comments below - apologies if these questions reflection of my
lack of understanding.

My understanding:
Step 1: When an application loads, the application will check which
protocol extensions are common between the application and compositor. If
the zwp_xcursor_configuration_manager is common to both the application and
the compositor and the client is able to interact with the XCursor library
then the application will initiate the following conversation with the
compositor to retrieve the xcursor configuration information. Client ->
Compositor
request=get_xcursor_configuration_seat
id=123
interface=zwp_xcursor_configuration_v1
seat=1

Compositor -> Client
event=theme
name="Adwaita" //Theme name
size=24 //Theme size

Compositor -> Client
event=default_cursor
name:"abc" //default cursor name

Compositor -> Client
event=done

Step 2: Based on the information received from the compositor the
application will use the XCursor library to load / display the appropriate
mouse cursors.

Step 3: When the application exists, if the application has made use of the
zwp_xcursor_configuration_v1 extension then the application will initiate
the following conversation with the compositor:
* I get stuck here - there are two destructor requests both called
'destroy' - are they both required?
* Neither of the 'destroy' requests have an id for the application to
identify to the compositor what should be destroyed? I assume that the
destroy request is associated with the get_xcursor_configuration_seat
request, so in-principle an application can destroy the seat information if
the application itself is multi-seat aware - is that right? In which case
is a seat parameter required for the destroy request?

Questions:
* What happens if a user changes the cursor theme / size / default cursor
while the application is running? I assume that the compositor must create
the 'theme', 'default_cursor' and 'done' events and the application must
update the cursor accordingly?
* Why are event 'theme' and event 'default_cursor' two separate events and
not handled by one event with 3 attributes?
* Is 'theme' a good name for an event and not something like
'xcursor_theme'? Is that implied by the context?
* It is implied on the XCursor man page that a theme may not be set. In
this case does the compositor return an empty theme 'name' on the 'theme'
event? Or is the 'name' set to 'default' if no theme is set?
* I see that XCursor interface has (
https://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml):
int XcursorGetDefaultSize (Display *dpy) //Gets the default cursor
size.
char *XcursorGetTheme (Display *dpy) //Gets the current theme
name.
I see that Display* is defined in Xlib.h and looks like it gets populated
when the application connects to an X server. So I assume that the 'theme'
event is required because the application can't interact with the XCursor
library to get this information directly, because it does not have an
XServer Display connection?
* For the XCursor interface (
https://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml), I can't
see where the default_cursor name is used. Likewise I can't see a setting
for default_cursor name under Gnome settings or in dconf editor. What is
the thinking behind the default_cursor event? Is this really the XCursor
'shape' parameter that the application needs to convert to an unsigned int?
* I see that Gnome settings has some interesting settings that are not
included in XCursor like:
- Is the primary button the left or right button?
- What is the mouse cursor speed?
I assume we'll pick those up in the more advanced protocol?

Kind regards,
Michael

Post by Simon Ser
Clients are responsible for loading and setting cursors. For this
purpose they often use XCursor images via the libwayland-cursor
library. However clients have no way to know the user's preferred
theme and size. This results in inconsistent cursors across
clients (e.g. cursor growing bigger when entering a surface).
This protocol fixes this issue by sending the user's XCursor
preferences to the client. It also allows for per-seat cursor
configuration.
---
This is a draft of the XCursor configuration protocol. It's pretty
simple.
It still doesn't allow to configure differently wl_pointer's cursor
and the tablet tool's cursor. Maybe this can be done with an enum
and a new get_xcursor_configuration_seat argument?
Comments welcome!
unstable/xcursor-configuration/README | 4 +
.../xcursor-configuration-unstable-v1.xml | 105 ++++++++++++++++++
2 files changed, 109 insertions(+)
create mode 100644 unstable/xcursor-configuration/README
create mode 100644
unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
diff --git a/unstable/xcursor-configuration/README
b/unstable/xcursor-configuration/README
new file mode 100644
index 0000000..472e3bf
--- /dev/null
+++ b/unstable/xcursor-configuration/README
@@ -0,0 +1,4 @@
+xcursor configuration protocol
+
diff --git
a/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
new file mode 100644
index 0000000..9d9d840
--- /dev/null
+++ b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
@@ -0,0 +1,105 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="wp_xcursor_configuration_unstable_v1">
+ <copyright>
+ Copyright © 2018 Simon Ser
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="protocol to configure XCursor themes">
+ This protocol allows compositors to advertize XCursor configuration to
+ clients.
+
+ Once compositor configuration is received, clients are responsible for
+ loading the XCursor theme, creating wl_buffers with cursor images and
+ setting the cursor.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <interface name="zwp_xcursor_configuration_manager_v1" version="1">
+ <description summary="XCursor configuration manager">
+ A global factory interface for wp_xcursor_configuration objects.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the XCursor configuration manager object">
+ Destroy the XCursor configuration manager. This doesn't destroy objects
+ created with the manager.
+ </description>
+ </request>
+
+ <request name="get_xcursor_configuration_seat">
+ <description summary="create a wp_xcursor_configuration object for a seat">
+ This creates a new wp_xcursor_configuration object for the given
+ wl_seat.
+ </description>
+ <arg name="id" type="new_id"
interface="zwp_xcursor_configuration_v1"/>
+ <arg name="seat" type="object" interface="wl_seat"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_xcursor_configuration_v1" version="1">
+ <description summary="XCursor configuration for a seat">
+ A Xcursor configuration seat object describes XCursor settings for a
+ specific seat.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy this object">
+ Using this request a client can tell the server that it is not going to
+ use this object anymore.
+ </description>
+ </request>
+
+ <event name="done">
+ <description summary="all information about the configuration has been sent">
+ This event is sent after all other properties of a
+ wp_xcursor_configuration have been sent.
+
+ This allows changes to the wp_xcursor_configuration properties to be
+ seen as atomic, even if they happen via multiple events.
+ </description>
+ </event>
+
+ <event name="theme">
+ <description summary="theme configuration">
+ The theme event describes XCursor theme configuration for this seat.
+ </description>
+ <arg name="name" type="string" summary="theme name"/>
+ <arg name="size" type="uint" summary="theme size"/>
+ </event>
+
+ <event name="default_cursor">
+ <description summary="default cursor name">
+ The default_cursor event describes the default XCursor cursor name to be
+ used for this seat.
+ </description>
+ <arg name="name" type="string" summary="default cursor name"/>
+ </event>
+ </interface>
+</protocol>
--
2.19.1
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[Simon Ser]

Hi Michael,

Thanks for you comments! Replies below.

Post by Michael Arnold
Step 3: When the application exists, if the application has made use of the
zwp_xcursor_configuration_v1 extension then the application will initiate the
* I get stuck here - there are two destructor requests both called 'destroy' -
are they both required?
* Neither of the 'destroy' requests have an id for the application to identify
to the compositor what should be destroyed? I assume that the destroy request
is associated with the get_xcursor_configuration_seat request, so in-principle
an application can destroy the seat information if the application itself is
multi-seat aware - is that right? In which case is a seat parameter required
for the destroy request?

You are right about the "setup" sequence. The "teardown" sequence is very
simple: since the Wayland protocol works with objects, when you send a request
on an object, the object itself is an implicit parameter to the request (just
like in object-oriented programming languages). The same applies to events.

That means the "theme" and "default_cursor" events are associated with the
configuration. The destroy requests are associated with either the manager or
the configuration.

The full sequence could look like this for the client:

-> config = manager.get_xcursor_configuration_seat(seat)
config.theme("Adwaita", 24)
config.default_cursor("left_ptr")
config.done()
[use the config, run the app]
-> config.destroy()
-> manager.destroy()

Post by Michael Arnold
* What happens if a user changes the cursor theme / size / default cursor while
the application is running? I assume that the compositor must create the
'theme', 'default_cursor' and 'done' events and the application must update
the cursor accordingly?

Yeah. I've added this text for the next version to make it more clear:

The theme event is sent after creating a wp_xcursor_configuration
(see wp_xcursor_configuration_manager) and whenever the theme
configuration changes.

(Same for the default_cursor event)

Post by Michael Arnold
* Why are event 'theme' and event 'default_cursor' two separate events and not
handled by one event with 3 attributes?

It's just to clearly make the difference between these two categories of
arguments.

Post by Michael Arnold
* Is 'theme' a good name for an event and not something like 'xcursor_theme'?
* Is that implied by the context?

"xcursor" is already in the interface name, I don't think it's necessary to add
it one more time.

Post by Michael Arnold
* It is implied on the XCursor man page that a theme may not be set. In this
case does the compositor return an empty theme 'name' on the 'theme' event?
Or is the 'name' set to 'default' if no theme is set?

I think it would be enough to just send "default". This is what
libwayland-cursor uses when the theme name is NULL. Is it really necessary to
make the "theme" and "default_cursor" events optional?

Post by Michael Arnold
* I see that XCursor interface has
int XcursorGetDefaultSize (Display *dpy) //Gets the default cursor size.
char *XcursorGetTheme (Display *dpy) //Gets the current theme name.
I see that Display* is defined in Xlib.h and looks like it gets populated when
the application connects to an X server. So I assume that the 'theme' event is
required because the application can't interact with the XCursor library to
get this information directly, because it does not have an XServer Display
connection?

Right.

Post by Michael Arnold
* For the XCursor interface
(https://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml), I can't see
where the default_cursor name is used. Likewise I can't see a setting for
default_cursor name under Gnome settings or in dconf editor. What is the
thinking behind the default_cursor event? Is this really the XCursor 'shape'
parameter that the application needs to convert to an unsigned int?

The use-case is to e.g. set a tablet tool cursor to be a cross, so you can have
both a normal pointer for you mouse/touchpad and a cross pointer for your tablet
device. One could also use an alternative default cursor to be able to keep the
same theme for two seats but to be able to tell the difference between those
(e.g. by using left_ptr for one and right_ptr for the other).

This protocol allows things that aren't possible with the XCursor library, such
as setting a default cursor, having per-seat configuration and allowing live
cursor updates.

Post by Michael Arnold
* I see that Gnome settings has some interesting settings that are not included
- Is the primary button the left or right button?
- What is the mouse cursor speed?
I assume we'll pick those up in the more advanced protocol?

I think those are out-of-scope for this protocol. Actually both of these
features could be implemented in the compositor directly, clients don't need to
know about this.

[Johan Helsing]

Hi Simon,

Thanks for working on this! :)

Is the intention to implement the client side inside libwayland-cursor? No
changes needed for toolkits except calling some new API when initializing
libwayland-cursor?

I guess it's also possible to implement it on the toolkit level using the old
libwayland-cursor API... Which would allow us to use the extension before
everyone has upgraded to the new libwayland-cursor.

Post by Simon Ser
+ <request name="get_xcursor_configuration_seat">

To me, this sounds a bit like we're getting some kind of seat from the
request. How about get_seat_xcursor_configuration? Or simply
get_xcursor_configuration?

Post by Simon Ser
+ <event name="default_cursor">
+ <description summary="default cursor name">
+ The default_cursor event describes the default XCursor cursor name to be
+ used for this seat.
+ </description>

Maybe explain the use case here?

And another thing, maybe we can explicitly say this is a hint for the client?
I'm asking because I don't think we have a matching concept of a default
cursor in Qt... We just have Qt::QCursorShape::ArrowCursor. We could
make this request override what that shape is, but that might be confusing
to application developers if some compositor decides to set the default
cursor to a cross or some other non-arrow cursor. Anyway, this event is
going to cause some minor issues in Qt, perhaps in other toolkits as well.

Otherwise, this looks great :) Looking forward to having uniform cursor
sizes!

Johan

________________________________
From: wayland-devel <wayland-devel-***@lists.freedesktop.org> on behalf of Simon Ser <***@emersion.fr>
Sent: Friday, October 12, 2018 7:40:21 PM
To: wayland-***@lists.freedesktop.org
Cc: Simon Ser
Subject: [PATCH RFC wayland-protocols] unstable: add xcursor-configuration

Clients are responsible for loading and setting cursors. For this
purpose they often use XCursor images via the libwayland-cursor
library. However clients have no way to know the user's preferred
theme and size. This results in inconsistent cursors across
clients (e.g. cursor growing bigger when entering a surface).

This protocol fixes this issue by sending the user's XCursor
preferences to the client. It also allows for per-seat cursor
configuration.

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

This is a draft of the XCursor configuration protocol. It's pretty
simple.

It still doesn't allow to configure differently wl_pointer's cursor
and the tablet tool's cursor. Maybe this can be done with an enum
and a new get_xcursor_configuration_seat argument?

Comments welcome!

unstable/xcursor-configuration/README | 4 +
.../xcursor-configuration-unstable-v1.xml | 105 ++++++++++++++++++
2 files changed, 109 insertions(+)
create mode 100644 unstable/xcursor-configuration/README
create mode 100644 unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml

diff --git a/unstable/xcursor-configuration/README b/unstable/xcursor-configuration/README
new file mode 100644
index 0000000..472e3bf
--- /dev/null
+++ b/unstable/xcursor-configuration/README
@@ -0,0 +1,4 @@
+xcursor configuration protocol
+
+Maintainers:
+Simon Ser <***@emersion.fr>
diff --git a/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
new file mode 100644
index 0000000..9d9d840
--- /dev/null
+++ b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
@@ -0,0 +1,105 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="wp_xcursor_configuration_unstable_v1">
+ <copyright>
+ Copyright © 2018 Simon Ser
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="protocol to configure XCursor themes">
+ This protocol allows compositors to advertize XCursor configuration to
+ clients.
+
+ Once compositor configuration is received, clients are responsible for
+ loading the XCursor theme, creating wl_buffers with cursor images and
+ setting the cursor.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <interface name="zwp_xcursor_configuration_manager_v1" version="1">
+ <description summary="XCursor configuration manager">
+ A global factory interface for wp_xcursor_configuration objects.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the XCursor configuration manager object">
+ Destroy the XCursor configuration manager. This doesn't destroy objects
+ created with the manager.
+ </description>
+ </request>
+
+ <request name="get_xcursor_configuration_seat">
+ <description summary="create a wp_xcursor_configuration object for a seat">
+ This creates a new wp_xcursor_configuration object for the given
+ wl_seat.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_xcursor_configuration_v1"/>
+ <arg name="seat" type="object" interface="wl_seat"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_xcursor_configuration_v1" version="1">
+ <description summary="XCursor configuration for a seat">
+ A Xcursor configuration seat object describes XCursor settings for a
+ specific seat.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy this object">
+ Using this request a client can tell the server that it is not going to
+ use this object anymore.
+ </description>
+ </request>
+
+ <event name="done">
+ <description summary="all information about the configuration has been sent">
+ This event is sent after all other properties of a
+ wp_xcursor_configuration have been sent.
+
+ This allows changes to the wp_xcursor_configuration properties to be
+ seen as atomic, even if they happen via multiple events.
+ </description>
+ </event>
+
+ <event name="theme">
+ <description summary="theme configuration">
+ The theme event describes XCursor theme configuration for this seat.
+ </description>
+ <arg name="name" type="string" summary="theme name"/>
+ <arg name="size" type="uint" summary="theme size"/>
+ </event>
+
+ <event name="default_cursor">
+ <description summary="default cursor name">
+ The default_cursor event describes the default XCursor cursor name to be
+ used for this seat.
+ </description>
+ <arg name="name" type="string" summary="default cursor name"/>
+ </event>
+ </interface>
+</protocol>
--
2.19.1

[Simon Ser]

Post by Johan Helsing
Hi Simon,
Thanks for working on this! :)

Thanks for your feedback! I've sent a first version of this patch. I've
added per-device configuration and addressed your comments. Let me know what
you think.

Post by Johan Helsing
Is the intention to implement the client side inside libwayland-cursor? No
changes needed for toolkits except calling some new API when initializing
libwayland-cursor?

Yeah, this is what's planned. The new design of the libwayland-cursor API will
be the difficult part of this task. I'll try to send a proposal soon.

Post by Johan Helsing
I guess it's also possible to implement it on the toolkit level using the old
libwayland-cursor API... Which would allow us to use the extension before
everyone has upgraded to the new libwayland-cursor.

Aye, this is possible.

Post by Johan Helsing

+    <request name="get_xcursor_configuration_seat">

To me, this sounds a bit like we're getting some kind of seat from the
request. How about get_seat_xcursor_configuration? Or simply
get_xcursor_configuration?

This makes sense, I'll rename to get_device_xcursor_configuration. I'd like to
make sure we can add new requests to create xcursor configuration objects in
the future, so I'd like to keep "device" in there.

Post by Johan Helsing

+    <event name="default_cursor">
+      <description summary="default cursor name">
+        The default_cursor event describes the default XCursor cursor name to be
+        used for this seat.
+      </description>

Maybe explain the use case here?

The use-case is to be able to tell the difference between two cursors without
having to pick two different cursor themes. For instance one could choose
left_ptr for the pointer and cross for the tablet tool.

Do you think we should include this example in the protocol?

Post by Johan Helsing
And another thing, maybe we can explicitly say this is a hint for the client?
I'm asking because I don't think we have a matching concept of a default
cursor in Qt... We just have Qt::QCursorShape::ArrowCursor. We could
make this request override what that shape is, but that might be confusing
to application developers if some compositor decides to set the default
cursor to a cross or some other non-arrow cursor. Anyway, this event is
going to cause some minor issues in Qt, perhaps in other toolkits as well.

You're right, I've mentioned this in the protocol description. Everything in
this protocol is a hint, clients could use it to e.g. just choose the cursor
size and use a custom theme.

For Qt, you could e.g. use default_cursor if the app doesn't set the cursor
itself, and switch to Qt::QCursorShape::ArrowCursor if the app requests it.
Of course, having Qt::QCursorShape::DefaultCursor would be nice too.

Post by Johan Helsing
Otherwise, this looks great :) Looking forward to having uniform cursor
sizes!
Johan