[RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
Michal Suchanek
hramrach at gmail.com
Tue Mar 1 10:34:56 UTC 2016
On 24 February 2016 at 10:54, Jonas Ådahl <jadahl at gmail.com> wrote:
> On Wed, Feb 24, 2016 at 10:25:19AM +0100, Michal Suchanek wrote:
>> On 24 February 2016 at 05:33, Jonas Ådahl <jadahl at gmail.com> wrote:
>> > On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote:
>> >> From: Lyude <cpaul at redhat.com>
>> >>
>> >> This primary selection is similar in spirit to the eponimous
>> >> in X11, allowing a quick "select text + middle click" shortcut
>> >> to copying and pasting.
>> >>
>> >> It's otherwise very similar to it wayland counterpart, and
>> >> explicitly made consistent with it.
>> >>
>> >> Signed-off-by: Lyude <cpaul at redhat.com>
>> >> Signed-off-by: Carlos Garnacho <carlosg at gnome.org>
>> >> ---
>> >> After having talked with Lyude, I'll be trying to move this ahead.
>> >>
>> >> Changes since v3:
>> >> - Added a rather verbose protocol description, including a
>> >> high-level overview of the workings.
>> >> - Made event emission 1:1 with wayland core protocol selections,
>> >> wp_primary_selection_offer.offer events are now expected to be
>> >> emitted between wp_primary_data_device.data_offer and
>> >> wp_primary_data_device.selection
>> >> - Improved wording here and there.
>> >> - Added serial argument to wp_primary_data_offer.receive that can be
>> >> used to match against recent events.
>> >>
>> >>
>> >> Makefile.am | 1 +
>> >> unstable/primary-selection/README | 4 +
>> >> .../primary-selection-unstable-v1.xml | 229 +++++++++++++++++++++
>> >> 3 files changed, 234 insertions(+)
>> >> create mode 100644 unstable/primary-selection/README
>> >> create mode 100644 unstable/primary-selection/primary-selection-unstable-v1.xml
>> >>
>> >> diff --git a/Makefile.am b/Makefile.am
>> >> index 57d0023..eefa20f 100644
>> >> --- a/Makefile.am
>> >> +++ b/Makefile.am
>> >> @@ -7,6 +7,7 @@ unstable_protocols = \
>> >> unstable/xdg-shell/xdg-shell-unstable-v5.xml \
>> >> unstable/relative-pointer/relative-pointer-unstable-v1.xml \
>> >> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
>> >> + unstable/primary-selection/primary-selection-unstable-v1.xml \
>> >> $(NULL)
>> >>
>> >> stable_protocols = \
>> >> diff --git a/unstable/primary-selection/README b/unstable/primary-selection/README
>> >> new file mode 100644
>> >> index 0000000..6d8c0c6
>> >> --- /dev/null
>> >> +++ b/unstable/primary-selection/README
>> >> @@ -0,0 +1,4 @@
>> >> +Primary selection protocol
>> >> +
>> >> +Maintainers:
>> >> +Lyude <cpaul at redhat.com>
>> >> diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml b/unstable/primary-selection/primary-selection-unstable-v1.xml
>> >> new file mode 100644
>> >> index 0000000..a3618d5
>> >> --- /dev/null
>> >> +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml
>> >> @@ -0,0 +1,229 @@
>> >> +<?xml version="1.0" encoding="UTF-8"?>
>> >> +<protocol name="primary_selection_unstable_v1">
>> >> + <copyright>
>> >> + Copyright © 2015 Red Hat
>> >> +
>> >> + 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="Primary selection protocol">
>> >> + This protocol provides the ability to have a primary selection device to
>> >> + match that of the X server. This primary selection is a shortcut to the
>> >> + common clipboard selection, where text just needs to be selected in order
>> >> + to allow copying it elsewhere. The de facto way to perform this action
>> >> + is the middle mouse button, although it is not limited to this one.
>> >> +
>> >> + Clients wishing to honor primary selection should create a primary
>> >> + selection source and set it as the selection through
>> >> + wp_primary_selection_device.set_selection whenever the text selection
>> >> + changes. In order to minimize calls in pointer-driven text selection,
>> >> + it should happen only once after the operation finished. Similarly,
>> >> + a NULL source should be set when text is unselected.
>> >> +
>> >> + wp_primary_selection_offer objects are first announced through the
>> >> + wp_primary_selection_device.data_offer event. Immediately after this event,
>> >> + the primary data offer will emit wp_primary_selection_offer.offer events
>> >> + to let know of the mime types being offered.
>> >> +
>> >> + When the primary selection changes, the client with the keyboard focus
>> >> + will receive wp_primary_selection_device.selection events. Only the client
>> >> + with the keyboard focus will receive such events with a non-NULL
>> >> + wp_primary_selection_offer. Across keyboard focus changes, previously
>> >> + focused clients will receive wp_primary_selection_device.events with a
>> >> + NULL wp_primary_selection_offer.
>> >> +
>> >> + In order to request the primary selection data, the client must pass
>> >> + a recent serial pertaining to the press event that is triggering the
>> >> + operation, if the compositor deems the serial valid and recent, the
>> >> + wp_primary_selection_source.send event will happen in the other end
>> >> + to let the transfer begin. The client owning the primary selection
>> >> + should write the requested data, and close the file descriptor
>> >> + immediately.
>> >> +
>> >> + If the primary selection owner client disappeared during the transfer,
>> >> + the client reading the data will receive a
>> >> + wp_primary_selection_device.selection event with a NULL
>> >> + wp_primary_selection_offer, the client should take this as a hint
>> >> + to finish the reads related to the no longer existing offer.
>> >> +
>> >> + The primary selection owner should be checking for errors during
>> >> + writes, merely cancelling the ongoing transfer if any happened.
>> >> + </description>
>> >> +
>> >> + <interface name="zwp_primary_selection_device_manager_v1" version="1">
>> >> + <description summary="X primary selection emulation">
>> >> + The primary selection device manager is the base interface of primary
>> >> + selection, it allows to create wp_primary_selection_source objects, as
>> >> + well as retrieving the per-seat wp_primary_selection_device objects.
>> >> + </description>
>> >> +
>> >> + <request name="create_source">
>> >> + <description summary="create a new primary selection source">
>> >> + Create a new primary selection source.
>> >> + </description>
>> >> + <arg name="id" type="new_id" interface="zwp_primary_selection_source_v1"/>
>> >> + </request>
>> >> +
>> >> + <request name="get_device">
>> >> + <description summary="primary selection device manager">
>> >> + Singleton global object that manages the zwp_primary_selection_device_v1
>> >> + objects for each wl_seat.
>> >> + </description>
>> >> + <arg name="id" type="new_id" interface="zwp_primary_selection_device_v1"/>
>> >> + <arg name="seat" type="object" interface="wl_seat"/>
>> >> + </request>
>> >> +
>> >> + <request name="destroy" type="destructor">
>> >> + <description summary="destroy the primary selection device manager">
>> >> + Destroy the primary selection device manager.
>> >> + </description>
>> >> + </request>
>> >> + </interface>
>> >> +
>> >> + <interface name="zwp_primary_selection_device_v1" version="1">
>> >> + <request name="set_selection">
>> >> + <description summary="set the primary selection">
>> >> + Set the current contents of the primary selection buffer. This clears
>> >> + anything which was previously held in the primary selection buffer.
>> >> + </description>
>> >> + <arg name="source" type="object" interface="zwp_primary_selection_source_v1" allow-null="true"/>
>> >
>> > While reviewing the implementation, I noticed that while
>> > wl_data_device.set_selection takes a serial, the set_selection here
>> > doesn't. Does this mean that a client can set the selection without
>> > foucus and without any user interaction?
>> >
>> > It seems reasonable to me to require this as (not only offer.receive)
>> > would require a valid serial to have any effect.
>> >
>>
>> Actually it seems reasonable to not require a serial for anything. If
>> the application has a valid offer for the current selection it should
>> be able to get it or set a new one (unless it's for some reason denied
>> one of the operations altogether).
>
> The serial is there to make it possible to match an event in the server
> with the received event on the client. We cannot know what event a
> client is responding to without such an serial.
>
> The comment above is about adding a requirement that the set_selection
> (which sets a source object as the primary selection) is in response to
> an event of some kind (I'd say click/press/release/touch-down/touch-up
> etc). Exactly what that event is is up to the compositor, but we should
> set up expectations on what type of events it is, so that clients don't
> start trying to set selections or receive offers on only wl_pointer
> enter if that most likely will not work.
It's reasonable so long as it is a selection offer serial. However,
you require an unrelated and possibly hard to figure out input event
serial making the protocol needlessly vague and fragile.
>
>>
>> That's one place to check the policy and it works with middle mouse
>> button paste, any other event the compositor knows of, any even the
>> compositor dose not know of ( such as remote desktop/remote control
>> apps, input devices used directly by the application, .. ) and
>> anything else.
>
> Not sure what it is you are talking about here. In Wayland the
> compositor is definitely aware of remote desktop and other "remote
> control" systems. Applications has no way of injecting events in the
> event stream via the Wayland protocol and that is by design.
>
OK, so let's take an example of an application that uses a special
controller directly without going through the compositor. Then pasting
using one button (compositor controlled) will work and pasting using
other button (directly application-controlled) will not. We cannot
expect that wayland will at all times have driver for every input
controller under the sun so things like this will probably happen.
Users will probably not find it too strange that pasting using special
controller button will fail at the same time pasting using a mouse
button would.
Another application is remote control client showing a remote desktop.
Looking at the current remote wayland solution wayland protocol does
not seem to be used even for remote wayland desktops. For other
desktops it cannot be used at all. A paste on the remote desktop may
be triggered by an event that was caused locally and went through the
local compositor or an event that was forwarded by another client from
another location or an event that happened on the physical seat if one
exists. Either way inferring a local event that triggered the paste is
pretty much impossible even if one existed in the first place. Even if
wayland protocol was used on the wire you would need to keep a
dictionary of event serials so you can translate remote event serials
to local event serials. What event serial should the remote desktop
client application supply when forwarding the local clipboard seems to
be the right thing according to its clipboard handling settings?
Thanks
Michal
More information about the wayland-devel
mailing list