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

Submitted by Simon Ser on Oct. 12, 2018, 5:40 p.m.

Details

Message ID Rw-3vSnG0-e34tn1ISo8ZfeiUnC1NOge4cy1enahW7BhfJR_VXIGU_SlFVi_YA_0OGl9inVteMA4-XFawrKBtGThoMOmWmL4EwWRyEzPBys=@emersion.fr
State New
Series "unstable: add xcursor-configuration"
Headers show

Commit Message

Simon Ser Oct. 12, 2018, 5:40 p.m.
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 <contact@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

Patch hide | download patch | download mbox

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 <contact@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>

Comments

Michael Arnold Oct. 14, 2018, 2:05 a.m.
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

On Sat, Oct 13, 2018 at 1:41 AM Simon Ser <contact@emersion.fr> wrote:

> 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 <contact@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 <contact@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
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
Simon Ser Oct. 14, 2018, 7:06 a.m.
Hi Michael,

Thanks for you comments! Replies below.

On Sunday, October 14, 2018 4:05 AM, Michael Arnold <myk321@gmail.com> wrote:
> 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?

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()

> 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?

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)

> * 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.

> * 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.

> * 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?

> * 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?

Right.

> * 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.

> * 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?

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.