Re: Governance Meeting Announcement: Text-Input (Was: Call for proposals for the next governance meeting)

[Carlos Garnacho]

Hi!,

On Sun, May 12, 2024 at 2:18 AM Carlos Garnacho  wrote:
>
> On Tue, May 7, 2024 at 1:40 PM Carlos Garnacho  wrote:
> >
> > Hi!,
> >
> > On Wed, Apr 17, 2024 at 2:37 PM Vlad Zahorodnii  
> > wrote:
> > >
> > > Hello,
> > >
> > > The Wayland Governance Meeting is semi-regular meeting to drive
> > > discussion on wayland-protocols forward.
> > >
> > > We are looking for the proposals for the next meeting as well as people
> > > who can lead/drive the discussion. If there is a protocol that you would
> > > like to be on the agenda, please submit your proposals here.
> >
> > I would like to propose a meeting around the attempt to push forward
> > text-input protocol features at
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/282
> > as there are changes there benefiting IM integration.
> >
> > The meeting could be held at https://meet.gnome.org/car-oot-bcf-kt4,
> > and the date/time can be decided at
> > https://nuudel.digitalcourage.de/mdlGZkeersnxI8fS
> >
> > I will announce the poll results on May 12th.
>
> The meeting will be held on Monday May 13th 15:00 CEST (13:00 UTC) at
> https://meet.gnome.org/car-oot-bcf-kt4.

There's now some minutes of the meeting at
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings#2024-05-13-text-input-32.
Feel free to edit/report inconsistencies.

Cheers,
  Carlos

Re: Governance Meeting Announcement: Text-Input (Was: Call for proposals for the next governance meeting)

[Carlos Garnacho]

On Tue, May 7, 2024 at 1:40 PM Carlos Garnacho  wrote:
>
> Hi!,
>
> On Wed, Apr 17, 2024 at 2:37 PM Vlad Zahorodnii  
> wrote:
> >
> > Hello,
> >
> > The Wayland Governance Meeting is semi-regular meeting to drive
> > discussion on wayland-protocols forward.
> >
> > We are looking for the proposals for the next meeting as well as people
> > who can lead/drive the discussion. If there is a protocol that you would
> > like to be on the agenda, please submit your proposals here.
>
> I would like to propose a meeting around the attempt to push forward
> text-input protocol features at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/282
> as there are changes there benefiting IM integration.
>
> The meeting could be held at https://meet.gnome.org/car-oot-bcf-kt4,
> and the date/time can be decided at
> https://nuudel.digitalcourage.de/mdlGZkeersnxI8fS
>
> I will announce the poll results on May 12th.

The meeting will be held on Monday May 13th 15:00 CEST (13:00 UTC) at
https://meet.gnome.org/car-oot-bcf-kt4.

Cheers,
  Carlos

Governance Meeting Announcement: Text-Input (Was: Call for proposals for the next governance meeting)

[Carlos Garnacho]

Hi!,

On Wed, Apr 17, 2024 at 2:37 PM Vlad Zahorodnii  wrote:
>
> Hello,
>
> The Wayland Governance Meeting is semi-regular meeting to drive
> discussion on wayland-protocols forward.
>
> We are looking for the proposals for the next meeting as well as people
> who can lead/drive the discussion. If there is a protocol that you would
> like to be on the agenda, please submit your proposals here.

I would like to propose a meeting around the attempt to push forward
text-input protocol features at
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/282
as there are changes there benefiting IM integration.

The meeting could be held at https://meet.gnome.org/car-oot-bcf-kt4,
and the date/time can be decided at
https://nuudel.digitalcourage.de/mdlGZkeersnxI8fS

I will announce the poll results on May 12th.

Cheers,
  Carlos

Re: Wayland Governance Meeting - Oct 30 / Nov 01

[Carlos Garnacho]

Hi,

On Thu, Oct 19, 2023 at 11:58 PM Carlos Garnacho  wrote:
>
> Hi,
>
> I would like to propose a meeting about the color management protocol
> [1] after next week (it's late to schedule for next, plus there's
> people still likely at XDC). After talking with GIMP maintainers, I
> think this topic might welcome some higher bandwidth place to discuss.
> The doodle is at [2] to poll for the best day/time, the final date
> will be announced by Wednesday 25th.

There are now some minutes for this meeting at
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings#2023-11-01-color-management.
Feel free to add or report/edit inconsistencies.

Cheers,
  Carlos

Re: Wayland Governance Meeting - Oct 30 / Nov 01

[Carlos Garnacho]

Hi,

On Thu, Oct 19, 2023 at 11:58 PM Carlos Garnacho  wrote:
>
> Hi,
>
> I would like to propose a meeting about the color management protocol
> [1] after next week (it's late to schedule for next, plus there's
> people still likely at XDC). After talking with GIMP maintainers, I
> think this topic might welcome some higher bandwidth place to discuss.
> The doodle is at [2] to poll for the best day/time, the final date
> will be announced by Wednesday 25th.

According to the poll, the best day/time is Nov 1st at 14:00 CET. See
you there! [1]

Cheers,
  Carlos

[1] https://meet.gnome.org/car-oot-bcf-kt4 , to reiterate

Re: Wayland Governance Meeting - Oct 30 / Nov 01

[Carlos Garnacho]

Hi Pekka,

(this time on list)

On Fri, Oct 20, 2023 at 12:44 PM Pekka Paalanen  wrote:
>
> On Thu, 19 Oct 2023 23:58:18 +0200
> Carlos Garnacho  wrote:
>
> > Hi,
> >
> > I would like to propose a meeting about the color management protocol
> > [1] after next week (it's late to schedule for next, plus there's
> > people still likely at XDC). After talking with GIMP maintainers, I
> > think this topic might welcome some higher bandwidth place to discuss.
> > The doodle is at [2] to poll for the best day/time, the final date
> > will be announced by Wednesday 25th.
> >
> > The meeting will be held at GNOME servers [3], anyone is free to join
> > to listen if they want to, anonymously or not.
> >
> > The notes for this meeting, along with the ones from the previous meetings 
> > can
> > be found on the wayland-protocols wiki page [4].
> >
> > Cheers,
> >   Carlos
> >
> > [1] 
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
> > [2] https://nuudel.digitalcourage.de/QYCvHEj5KR4HADfD
>
> Hi,
>
> what's the timezone of the proposed times?
>
> Europe will switch away from DST on Oct 29, so right before the
> proposed times.

Oops. I was implicitly assuming the central european time in place,
CET shall be it for those dates :)

Cheers,
  Carlos

Wayland Governance Meeting - Oct 30 / Nov 01

[Carlos Garnacho]

Hi,

I would like to propose a meeting about the color management protocol
[1] after next week (it's late to schedule for next, plus there's
people still likely at XDC). After talking with GIMP maintainers, I
think this topic might welcome some higher bandwidth place to discuss.
The doodle is at [2] to poll for the best day/time, the final date
will be announced by Wednesday 25th.

The meeting will be held at GNOME servers [3], anyone is free to join
to listen if they want to, anonymously or not.

The notes for this meeting, along with the ones from the previous meetings can
be found on the wayland-protocols wiki page [4].

Cheers,
  Carlos

[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
[2] https://nuudel.digitalcourage.de/QYCvHEj5KR4HADfD
[3] https://meet.gnome.org/car-oot-bcf-kt4
[4] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings

Re: How does "move cursor one word to the right" work in zwp_text_input_unstable_v3?

[Carlos Garnacho]

Hi Filip,

On Sat, Dec 17, 2022 at 12:09 PM Filip Filmar  wrote:
>
> Hi folks!
>
> I am exploring the features of the v3 text input API as seen at 
> https://wayland.app/protocols/text-input-unstable-v3.
>
> I am curious, how does this API then implement operations such as "move 
> cursor one word to the right" or "move cursor to the end of the line" or 
> "move cursor to the end of the field"?

It currently does not. The text_input_v3 protocol does not offer
capabilities for altering the text caret position. See
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/73
for an action system that allows for caret navigation between other
things.

>
> I ask because, IIUC, the wayland side of this API does not know the entire 
> string being edited - it can only instruct adding or removing the text 
> surrounding the cursor position.

That is correct. The limited surrounding text snapshot is enough for
autocorrection and other advanced input features (e.g. context aware
text suggestions). Traditionally input methods have been
keyboard-driven, and caret navigation is already something done by the
client for the IM here. Non-keyboard-driven text input might welcome
these additional high-level actions, but it also would benefit of
toolkit buy-in besides compositors/IMs, it is not something clients
were used to being told to do.

Cheers,
  Carlos

Re: Difficulties with Wayland D protocol - D source persistence

[Carlos Garnacho]

Hi Martin,


On Mon, Oct 24, 2022 at 11:43 AM Martin Stransky  wrote:
>
> Hi folks,
>
> I'd like to point out how Wayland D protocol limits real life
> applications.
>
> Main limitation is a requirement that D source window has to be kept
> opened and D is cancelled otherwise.
>
> That's especially painful with popups. See this Mozilla bug and video
> attached there [1].

OTOH it is also what makes DnD neatly abort if the source surface and
its ongoing operations got legitimately destroyed.

>
> What's the problem?
>
> - When a popup window is source of D (a bookmark entry on the example
> here), we can't close it.
>
> - It's difficult to do D to another popup as the source one has to me
> kept opened. That means we need to show popups which are not intended to
> be shown together:
>   - if the popups are adjacent, xdg-positoner can be used.
>   - if the popups are not adjacent (an example on the clip),
> wl_subsurface popup has to be used with its consequences (buggy
> compositor/gtk3 implementation).
>
> So may be the D source persistence condition relaxed?

To allow a fix for this case, I think it would be more backwards
compatible and coherent to relax wl_data_device.start_drag conditions,
so that it's only required that the serial/grab is on a surface of the
same client, and a different source surface may be used. Firefox could
then pass the toplevel surface as the drag source. This way lifetime
correctness is guaranteed, and "snap back" animations on failed DnD
have a surface to return to.

Cheers,
  Carlos

Re: Wrong (non modified) key under Wayland when multiple events combined in single SYN_REPORT

[Carlos Garnacho]

Hi!,

On Tue, Sep 13, 2022 at 11:36 AM Hans de Goede  wrote:
>
> Hi,
>
> On 9/12/22 23:20, Peter wrote:
> > Hi all,
> >
> >
> > Op maandag 12 september 2022 om 15:14:09 +0200 schreef Juerd Waalboer 
> > :
> >> Hans de Goede skribis 2022-09-12  7:16 (+0200):
> >>> During a big hacker event in the Netherlands this summer (MCH) the 
> >>> logistics
> >>> team used custom barcodes to keep track of inventory. These custom 
> >>> barcodes
> >>> contain a # symbol.
> >>
> >> In other barcodes, @ symbols. Quite possibly anything with shifted 
> >> characters; I vaguely recall a mixed case (ascii) string where the 
> >> uppercasing was on the wrong letter.
> >
> > Yes, that definitely also happened.
> >
> >>
> >>> Juerd, we did not discuss how you were running Wayland (which compositor),
> >>> I guess you were using GNOME3 when you hit this ?
> >>
> >> I'm not sure, as I only encountered the bug as an end user and suggested 
> >> changing to X to work around it (which worked). I've added Peter Hazenberg 
> >> to the CC list; he installed and maintained the computers, and is familiar 
> >> with the bug. Peter, can you confirm that we were using GNOME 3 in both 
> >> Wayland and X?
> >
> > Yes, we used gnome 3. It was mostly a boring default Fedora 36 Workstation 
> > installation.
> >
> > Good to hear Hans already reproduced the issue at the mentioned 
> > hackerspace, I assume with the exact same hardware
>
> Yes I reproduced it on my own laptop inside a terminal under GNOME3. I 
> suspect that it reproduces on any (VTE based?) terminal running under GNOME3 
> Wayland when using the right barcode-scanner model and scanning specific 
> barcodes.

Thanks Hans/Juerd/Peter. I can reproduce this issue on GNOME Shell
with the evemu logs provided. From my multiple tries, the libinput
debug output seems pretty much consistent and in line with the evemu
output (i.e. press shift, release 't', press '3', release shift), so
there does not seem to be any issue there. At the wayland level, the
wl_keyboard.modifier events received by the client are somewhat amiss
though.

Amusingly, running on plain Mutter (e.g. `mutter --wayland
--display-server` on a TTY) does also seem to fix the issue. The most
immediate difference I can think of is the involvement of input
methods.

Since this does not seem to be a generic Wayland issue, feel free to
file a bug at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues and
move discussion there, this might still end up in Mutter, or in IBus,
unclear yet.

Cheers,
  Carlos

Re: accessibility: implementation of zoom/invert on Wayland?

[Carlos Garnacho]

Hi Patrick,

On Thu, Jul 1, 2021 at 11:11 PM Patrick Pelletier
 wrote:
>
> Hi,
>
> I'm new to Wayland and only have a fairly basic understanding of how the
> different parts fit together.  I'm trying to find out more about how the
> following two accessibility features (for visually impaired users) are
> implemented and how I might be able to contribute to them:
>
> * Zoom
> * Invert colors
>
> For example, these features are described in the Ubuntu documentation here:
>
> https://help.ubuntu.com/stable/ubuntu-help/a11y-mag.html.en
>
> I'm assuming zoom and invert are implemented in the Wayland compositor?
> Is there any code for this in the reference implementation (Weston) or
> does each desktop environment have to implement these features from
> scratch in their own compositor?
>
> Background/motivation: I have a visually impaired friend who is
> currently "trapped" on MacOS because Linux's implementation of zoom and
> invert does not have feature parity with MacOS's implementation.  (For
> example, keyboard or keyboard+mouse shortcuts for changing the zoom
> factor on the fly.)  I'd like for her to be able to use Linux, so I'm
> interested in finding out how I can contribute to solving the following
> problems:
>
> * Some desktop environments (such as Xfce) don't seem to support zoom
> and invert at all.
>
> * The default desktop environment for Ubuntu (see link above) implements
> zoom and invert in a very clunky way.  To change the zoom factor, you
> have to go to the settings application.  (Versus just being able to use
> a modifier key and the scroll gesture to be able to zoom in and out on
> MacOS.)

It seems that this piece of the documentation is incomplete, the
"Plus" and "Minus" keyboard shortcuts should
work to change zoom level when Zoom is enabled..

> Also, it appears that there is no way to invert without also
> turning on zoom.

The zoom level goes down to 1.0, that would achieve inverted+unzoomed.

>
> Is this a battle that has to be fought on a per-desktop environment
> basis, or would it be possible to contribute some code to Weston that
> would make a good implementation of zoom and invert available to all
> desktop environments?

For these specific accessibility features, this is something that each
compositor has to deal with by themselves. Wayland is largely an IPC
protocol, and does not specify how images get to your screen. Weston
is a reference implementation of a wayland compositor, but that does
not mean its graphics layer shall be reused by other implementations.

FWIW, Weston already implements scroll to zoom in/out, only
palette inversion is missing AFAICS.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Keyboard issues w/Orca screen reader

[Carlos Garnacho]

Hi Mike!,

On Wed, Feb 24, 2021 at 11:03 PM Mike Gorse  wrote:
>
> As part of the GNOME project, we have Orca. It is a screen reader that reads
> what an application is displaying out loud, or sends it to a Braille display.
> It allows a blind user to interact with GNOME. There are currently several
> issues with Orca on Wayland, since it (and AT-SPI, the accessibility API that
> it uses) were originally designed for X11, without regard to the kind of
> security constraints that Wayland has.
>
> Traditionally, Orca has used what amounts to a key filter implemented by
> AT-SPI. The toolkit (gtk, qt, etc) would make a dbus method call to AT-SPI 
> when
> a key is pressed, passing on the keycode, keysym, and text associated with the
> key (Orca uses the latter to announce the key that was just pressed). The
> AT-SPI registry daemon would make a method call to Orca, Orca would return a
> boolean to indicate whether it consumed the key or not, and AT-SPI would 
> return
> the result to the toolkit. This is no longer supported by gtk 4, so I am 
> trying
> to solve things another way. There is a good amount of discussion at
> https://gitlab.gnome.org/GNOME/gtk/-/issues/1739
>
> Orca uses this key filter for a few things. It wants to announce the key that
> the user just pressed. If the user presses the control key, then Orca will 
> stop
> reading whatever it is reading. It also implements commands in this way (the
> user can press a key to have it read the current line, to give one example).

I may need to be reminded again... are there other commands that are
contextual to the application? I mainly wonder about whether there's a
reason to keep applications in the event emission chain. Otherwise,
seems like part of this could be covered by a "description query"
protocol.

> For X11, I can have AT-SPI/Orca watch for XI_KeyPress events and call
> XIGrabKeycode when Orca wants to grab a key, but I'm struggling to figure out
> what to do on Wayland. I think that I would need to propose a new protocol or
> two, but I foresee security being a challenge/concern, so I'm wondering if
> anyone has any advice in particular. Xwayland-keyboard-grab looks like it 
> would
> do part of what I need, if Orca ran as an xwayland client, but it wouldn't 
> help
> in terms of passing key press notifications on to Orca for the purposes of key
> echoing and interrupting speech, unless a grab was active for the particular
> key. If I enable my X11 code for Wayland, then I don't see XI_KeyPress events
> for keys going to other applications, which I think is expected given 
> Wayland's
> security model.

IIUC (and I'm sure I miss/forget things), there's 2 needs expressed here:
1. To make Orca part of the chain of command
  - Getting notified of all key events
  - Handle global keyboard shortcuts
- And make others miss them (i.e. in a grabbing manner)
2. To make clients work seamlessly with Orca

To fix 1, I tend to think this is something best left to an
integration library (as IIUC the goal is also to maximize
reutilization). The API sounds like it could be reasonably agnostic of
compositor details.

Fixing 2 sounds most definitely protocol land, which I wonder if it
could be more semantic and less attached to input specifics.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user

[Carlos Garnacho]

Hi Pekka,

Thank you for your comments!

On Wed, Oct 16, 2019 at 11:31 AM Pekka Paalanen  wrote:

> On Wed, 16 Oct 2019 10:54:08 +0200
> Olivier Fourdan  wrote:
>
> > Hey Carlos,
> >
> > On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho 
> wrote:
> > >
> > > This protocol takes over 3 different, but interrelated aspects of
> > > DE/client interaction:
> > > - Startup notification: presenting feedback about applications
> > >   being launched, either through the compositor or another client
> > > - Focus stealing prevention: letting the compositor figure out
> > >   whether immediately switching focus to a surface makes sense.
> > > - Window raising/activation: allowing existing clients to request
> > >   focus in a controlled manner.
> > >
> > > Signed-off-by: Carlos Garnacho 
>
> Hi Carlos,
>
> this seems well written and a good idea to me. More comments inline.
>
> > > ---
> > >  Makefile.am   |   1 +
> > >  unstable/presentation/README  |   5 +
> > >  .../presentation/presentation-unstable-v1.xml | 175 ++
> > >  3 files changed, 181 insertions(+)
> > >  create mode 100644 unstable/presentation/README
> > >  create mode 100644 unstable/presentation/presentation-unstable-v1.xml
> > >
> > > diff --git a/Makefile.am b/Makefile.am
> > > index d2c89a8..bd0e52d 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -24,6 +24,7 @@ unstable_protocols =
>   \
> > > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
> > >
>  
> unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
> \
> > > unstable/primary-selection/primary-selection-unstable-v1.xml
>   \
> > > +   unstable/presentation/presentation-unstable-v1.xml
>   \
> > > $(NULL)
> > >
> > >  stable_protocols =
>  \
> > > diff --git a/unstable/presentation/README
> b/unstable/presentation/README
> > > new file mode 100644
> > > index 000..5a77e97
> > > --- /dev/null
> > > +++ b/unstable/presentation/README
> > > @@ -0,0 +1,5 @@
> > > +Presentation protocol
> > > +
> > > +Maintainers:
> > > +Carlos Garnacho 
> > > +
> > > diff --git a/unstable/presentation/presentation-unstable-v1.xml
> b/unstable/presentation/presentation-unstable-v1.xml
> > > new file mode 100644
> > > index 000..84bf961
> > > --- /dev/null
> > > +++ b/unstable/presentation/presentation-unstable-v1.xml
> > > @@ -0,0 +1,175 @@
> > > +
> > > +
> > > +  
> > > +Copyright 2018-2019 © Red Hat, Inc.
> > > +
> > > +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.
> > > +  
> > > +
> > > +  
> > > +This description provides a high-level overview of the interplay
> between
> > > +the interfaces defined this protocol. For details, see the
> protocol
> > > +specification.
>
> This is the protocol specification, the whole file.
>

Uh, got that bit of the wording from

Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user

[Carlos Garnacho]

Hi Dorota!

On Wed, Oct 16, 2019 at 11:16 AM Dorota Czaplejewicz <
dorota.czaplejew...@puri.sm> wrote:

> On Wed, 16 Oct 2019 10:43:00 +0200
> Carlos Garnacho  wrote:
>
> > This protocol takes over 3 different, but interrelated aspects of
> > DE/client interaction:
> > - Startup notification: presenting feedback about applications
> >   being launched, either through the compositor or another client
> > - Focus stealing prevention: letting the compositor figure out
> >   whether immediately switching focus to a surface makes sense.
> > - Window raising/activation: allowing existing clients to request
> >   focus in a controlled manner.
> >
> > Signed-off-by: Carlos Garnacho 
> > ---
> >  Makefile.am   |   1 +
> >  unstable/presentation/README  |   5 +
> >  .../presentation/presentation-unstable-v1.xml | 175 ++
> >  3 files changed, 181 insertions(+)
> >  create mode 100644 unstable/presentation/README
> >  create mode 100644 unstable/presentation/presentation-unstable-v1.xml
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index d2c89a8..bd0e52d 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -24,6 +24,7 @@ unstable_protocols =
>   \
> >   unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
> >
>  
> unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
> \
> >   unstable/primary-selection/primary-selection-unstable-v1.xml
>   \
> > + unstable/presentation/presentation-unstable-v1.xml
>   \
> >   $(NULL)
> >
> >  stable_protocols =
>  \
> > diff --git a/unstable/presentation/README b/unstable/presentation/README
> > new file mode 100644
> > index 000..5a77e97
> > --- /dev/null
> > +++ b/unstable/presentation/README
> > @@ -0,0 +1,5 @@
> > +Presentation protocol
> > +
> > +Maintainers:
> > +Carlos Garnacho 
> > +
> > diff --git a/unstable/presentation/presentation-unstable-v1.xml
> b/unstable/presentation/presentation-unstable-v1.xml
> > new file mode 100644
> > index 000..84bf961
> > --- /dev/null
> > +++ b/unstable/presentation/presentation-unstable-v1.xml
> > @@ -0,0 +1,175 @@
> > +
> > +
> > +  
> > +Copyright 2018-2019 © Red Hat, Inc.
> > +
> > +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.
> > +  
> > +
> > +  
> > +This description provides a high-level overview of the interplay
> between
> > +the interfaces defined this protocol. For details, see the protocol
> > +specification.
> > +
> > +The finality of the protocol is defining a compositor context for
> > +surfaces requesting to be presented. Presentation requests are
> usually
> > +initiated by an existing surface, and acknowledged by a surface
> being
> > +mapped. By having both ends talk with the compositor through this
> protocol,
> > +the compositor has the information to implement different
> commonplace
> > +policies:
>
> Why does a presentation request have to come from a surface? I would
> expect that, similarly to creating a surface, presenting it would not
> require anything but a client (and maybe even no specific client) at least
> in the case of startup notification.
>

Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user

[Carlos Garnacho]

Hey :),

On Wed, Oct 16, 2019 at 10:54 AM Olivier Fourdan 
wrote:

> The name itself, “presentation” might be confusing considering we
> already have a “presentation-time” protocol.
>

Right... I'm open to naming suggestions. Struggled a bit there, other
single word that I could come up with are "activation" or "launch",
"presentation" sounded more neutral though.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user

[Carlos Garnacho]

This protocol takes over 3 different, but interrelated aspects of
DE/client interaction:
- Startup notification: presenting feedback about applications
  being launched, either through the compositor or another client
- Focus stealing prevention: letting the compositor figure out
  whether immediately switching focus to a surface makes sense.
- Window raising/activation: allowing existing clients to request
  focus in a controlled manner.

Signed-off-by: Carlos Garnacho 
---
 Makefile.am   |   1 +
 unstable/presentation/README  |   5 +
 .../presentation/presentation-unstable-v1.xml | 175 ++
 3 files changed, 181 insertions(+)
 create mode 100644 unstable/presentation/README
 create mode 100644 unstable/presentation/presentation-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index d2c89a8..bd0e52d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -24,6 +24,7 @@ unstable_protocols =  
\
unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \

unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
 \
unstable/primary-selection/primary-selection-unstable-v1.xml
\
+   unstable/presentation/presentation-unstable-v1.xml  
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/presentation/README b/unstable/presentation/README
new file mode 100644
index 000..5a77e97
--- /dev/null
+++ b/unstable/presentation/README
@@ -0,0 +1,5 @@
+Presentation protocol
+
+Maintainers:
+Carlos Garnacho 
+
diff --git a/unstable/presentation/presentation-unstable-v1.xml 
b/unstable/presentation/presentation-unstable-v1.xml
new file mode 100644
index 000..84bf961
--- /dev/null
+++ b/unstable/presentation/presentation-unstable-v1.xml
@@ -0,0 +1,175 @@
+
+
+  
+Copyright 2018-2019 © Red Hat, Inc.
+
+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.
+  
+
+  
+This description provides a high-level overview of the interplay between
+the interfaces defined this protocol. For details, see the protocol
+specification.
+
+The finality of the protocol is defining a compositor context for
+surfaces requesting to be presented. Presentation requests are usually
+initiated by an existing surface, and acknowledged by a surface being
+mapped. By having both ends talk with the compositor through this protocol,
+the compositor has the information to implement different commonplace
+policies:
+
+- Startup notification: The compositor may track wp_presenter interfaces
+  being created from the launcher side, and replied upon on the launchee
+  side. Compositors may also perform the application launcher role
+  themselves.
+
+- Focus stealing prevention: The compositor may know whether there is
+  recent user input that happened after the presentation request, and
+  ensure no disruptions happen.
+
+- Window raising/activation: The presented surface may be another 
previously
+  existing one, which might require bringing it to focus.
+
+A client that wishes to present another surface (of its own or from another
+client) will call wp_presentation_manager.create_presenter to create a
+presentation request. Compositors may use this object to track the source 
of
+the request in order to apply its policies when mapping the surface or
+bringing an existing one to focus.
+
+In the presented surface side, the request token will be notified upon
+through the wp_presentation_manager.acknowledge request. The method to pass
+the token across clients is considered an implementation detail, and is
+explicitly not observed here.
+
+Upon a successfully acknowledge

Re: RFC libinput high-resolution wheel scrolling

[Carlos Garnacho]

Hi!,

I surely missed the gitlab ping, hope this makes up for it :).

On Fri, Jan 25, 2019 at 6:28 AM Peter Hutterer  wrote:
>
> I'm sending this here to get some more exposure. The kernel will get
> high-resolution scroll wheels with the 5.0 release. The details are in the
> blog post linked below [1], but the short summary is that we now get
> REL_WHEEL for full clicks and REL_WHEEL_HI_RES for fine-grained events.
>
> The units REL_WHEEL_HI_RES are: 120 is one logical wheel click, a fraction
> thereof indicates a wheel movement by that. The 120 value comes from the
> Windows Vista API btw.
>
> So an event sequence for a 20 degree wheel movement on my Logitech MX
> Anywhere 2S is this:
>
> EV_REL REL_WHEEL_HI_RES 15
> EV_SYN SYN_REPORT
> EV_REL REL_WHEEL_HI_RES 15
> EV_SYN SYN_REPORT
> EV_REL REL_WHEEL_HI_RES 15
> EV_SYN SYN_REPORT
> EV_REL REL_WHEEL_HI_RES 15
> EV_SYN SYN_REPORT
> EV_REL REL_WHEEL_HI_RES 15
> EV_SYN SYN_REPORT
> EV_REL REL_WHEEL_HI_RES 15
> EV_SYN SYN_REPORT
> EV_REL REL_WHEEL_HI_RES 15
> EV_SYN SYN_REPORT
> EV_REL REL_WHEEL_HI_RES 15
> EV_REL REL_WHEEL 1
> EV_SYN SYN_REPORT
>
> In short, we get 7 event frames with hi-res only, then one frame with both
> hi-res and the low-res event.
>
> libinput's API has libinput_event_pointer_axis_get_value() and
> libinput_event_pointer_axis_get_value_discrete(). For wheel events, the
> former returns the rotation angle, the latter the number of logical clicks.
> Currently, this means you'd get e.g. 15/1 for most mice, or 20/1 for some
> others. With the kernel above, you now get 7 events with 2.5/0, one event
> with 2.5/1, i.e. the value must be accumulated if you want click-based
> scrolling (this is already the case for non-wheel scroll events).
>
> I tried integrating this into the xf86-input-libinput driver and it was...
> tricky. That driver needs to know everyhing ahead of time but with the
> current API you don't know the full click angle until you get the first
> discrete event. AFAICT, both mutter and weston would have similar issues
> when adding the above.
>
> The solution I came up with, see [2], is to forward the 120 value with a new
> API: libinput_pointer_axis_get_value_v120()

I wonder if normalizing the value between [0..1] would have any
drawbacks, or returning the inverse (eg. 8 for "this is an 8th of a
click") if you want to stick to integers. 120 is a smart value (many
multiples and whatnot), but seems strange to let a "magical number" to
sink this much deep in api.

>
> For the MX Anywhere 2S, each event thus now gives me three values:
> 7 events with 2.5/0/15 and 1 event with 2.5/1/15.
>
> For the caller, this means:
> - easy enough to calculate the click angle from the first event where needed
>   (no generic caller actually cares about this though, it's a rather
>   specialised case).
> - easy to do click-angle-independent pointer movement
>
> Seems to be easy to integrate into weston/mutter. There shouldn't be any
> need for wayland protocol updates either, we can just do the fraction of the
> movement so instead of 10 per event, we now send 10/120 * v120 value. So we
> need the compositors to handle a new API, but at least the wayland client
> side doesn't change.
>
> Any comments? Anything I've overlooked?

Semantics aside, I think the reasoning sounds good.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v2] unstable: add primary-selection protocol

[Carlos Garnacho]

rimary_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.
> +  
> +
> +  
> +
> +  The primary selection device manager is a singleton global object
> that
> +  provides access to the primary selection. It allows to create
> +  wp_primary_selection_source objects, as well as retrieving the
> per-seat
> +  wp_primary_selection_device objects.
> +
> +
> +
> +  
> +Create a new primary selection source.
> +  
> +   interface="zwp_primary_selection_source_v1"/>
> +
> +
> +
> +  
> +Create a new data device for a given seat.
> +  
> +   interface="zwp_primary_selection_device_v1"/>
> +  
> +
> +
> +
> +  
> +Destroy the primary selection device manager.
> +  
> +
> +  
> +
> +  
> +
> +  
> +Replaces the current selection. The previous owner of the primary
> +selection will receive a wp_primary_selection_source.cancelled
> event.
> +
> +To unset the selection, set the source to NULL.
> +  
> +   interface="zwp_primary_selection_source_v1" allow-null="true"/>
> +  
> +
> +
> +
> +  
> +Introduces a new wp_primary_selection_offer object that may be
> used
> +to receive the current primary selection. Immediately following
> this
> +event, the new wp_primary_selection_offer object will send
> +wp_primary_selection_offer.offer events to describe the offered
> mime
> +types.
> +  
> +   interface="zwp_primary_selection_offer_v1"/>
> +
> +
> +
> +  
> +The wp_primary_selection_device.selection event is sent to notify
> the
> +client of a new primary selection. This event is sent after the
> +wp_primary_selection.data_offer event introducing this object,
> and after
> +the offer has announced its mimetypes through
> +wp_primary_selection_offer.offer.
> +
> +The data_offer is valid until a new offer or NULL is received
> +or until the client loses keyboard focus. The client must destroy
> the
> +previous selection data_offer, if any, upon receiving this event.
> +  
> +   interface="zwp_primary_selection_offer_v1" allow-null="true"/>
> +
> +
> +
> +  
> +Destroy the primary selection device.
> +  
> +
> +  
> +
> +  
> +
> +  A wp_primary_selection_offer represents an offer to transfer the
> contents
> +  of the primary selection clipboard to the client. Similar to
> +  wl_data_offer, the offer also describes the mime types that the
> source
> +  will transferthat the
>

This is in the original protocol, so definitely more my fault than yours,
but would be nice not to drag this further :). I guess the original
intention was:

"...describes the mime types that the data can be converted to..."

Besides that, the patch is

Reviewed-by: Carlos Garnacho 

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol

[Carlos Garnacho]

On Thu, Aug 16, 2018 at 4:46 PM, Jonas Ådahl  wrote:
> On Thu, Aug 16, 2018 at 04:25:06PM +0200, Carlos Garnacho wrote:
>> Hi!,
>>
>> Thanks Simon for moving this forward. FTR this looks good to me. Had
>> some chat with Jonas on IRC about the suitability of xdg vs wp
>> prefixes, but I personally think your choice is fine. Either way, this
>> is
>
> To elaborate what the discussion was about:
>
> "xdg" shouldn't be seen as a "desktop" (device that sits on a desk)
> thing, but a place to put protocols that aims to "bridge" different
> environments, be they things running in devices placed on desks or in
> hands.

Making merits for my "captain obvious" award, I'll point out the 'd'
in xdg stands for "desktop" :). If we aim 'xdg' to be a form
factor-agnostic set of standards, I would say that even window
management is a bit of a stretch... Certainly not something you
usually see in tablets or mobile.

But times surely change, so I don't say we must attain to the original
meaning, AFAIR the 'x' was already switched to 'cross' at some point.

>
> For example, if someone plugs in a mouse to a smartphone or tablet, if
> that person has the middle-click-paste function on the actual desktop
> computer, I'd assume the same user would expect it also on the
> not-a-desktop-computer device.
>
> Personally I don't think clipboard really fall into this category of
> desktop environment interoperability, and "primary selection" is not
> really different from the regular clipboard and drag-n-drop
> functionality here I think.
>
> On the other hand, if we see clipboard as something that bridges
> environments (e.g. if gtk wants to have interoperable clipboard, it
> needs to use a bridging protocol), and with that in mind, primary
> selection *do* fall into this category (so does regular clipboard, but
> can't rename that so meh).

That is my line of thought, although I kind of agree this is being a
"historical artifact". This is about having heterogeneous clients have
a lingua franca. I ultimately think the prefix is least relevant for
that goal, the wayland-protocols blessing should be enough :)

>
> So, my personal opinion is that putting this inside a "xdg_" prefix is
> not entirely suitable, given that this is clipboard type plumbing that
> just happens to historically come from the traditional desktop Linux
> usage.
>
> Thoughts? If we ignore form factors (desktop vs hand held), where does
> it fall, you think?

I guess we are less likely to regret it in 10 years time if it's wp,
but just because it's such a big bucket :). But I see some pain going
that way with the xdg rubberstamp... the amount of form factors is not
going to decrease, anything can potentially get a bad idea in
retrospective if we aim for the lowest common denominator.

Or maybe should we acknowledge form-factor variety in xdg, so eg. a VR
headset protocol could be "xdg" just as we have xdg-shell for
desktop-style window management?

Cheers,
  Carlos

>
>
> Jonas
>
>
>>
>> Acked-by: Carlos Garnacho 
>>
>> On Sun, Jul 8, 2018 at 9:14 PM, Simon Ser  wrote:
>> > 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 its Yayland counterpart, and
>> > explicitly made consistent with it.
>> >
>> > Signed-off-by: Simon Ser 
>> > ---
>> > This is a continuation of [1]. This protocol was pretty close to being 
>> > accepted.
>> >
>> > I've chosen to put the xdg prefix because this primary selection is mostly 
>> > relevant
>> > to desktop compositors.
>> >
>> > I've added myself as maintainer, Carlos and Lyude let me know if you want 
>> > to replace
>> > me or be added to the list too.
>> >
>> > [1]: 
>> > https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html
>> >
>> >  Makefile.am   |   3 +-
>> >  unstable/xdg-primary-selection/README |   4 +
>> >  .../xdg-primary-selection-unstable-v1.xml | 225 ++
>> >  3 files changed, 231 insertions(+), 1 deletion(-)
>> >  create mode 100644 unstable/xdg-primary-selection/README
>> >  create mode 100644 
>> > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml
>> >
>> > diff --git a/Makefile.am b/Makefile.am
>> > index 2b59d34..66a65af 100644
>> > --- a/Makefile.am
>> > +++ b/Makefile.am
>> > 

Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol

[Carlos Garnacho]

Hi!,

Thanks Simon for moving this forward. FTR this looks good to me. Had
some chat with Jonas on IRC about the suitability of xdg vs wp
prefixes, but I personally think your choice is fine. Either way, this
is

Acked-by: Carlos Garnacho 

On Sun, Jul 8, 2018 at 9:14 PM, Simon Ser  wrote:
> 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 its Yayland counterpart, and
> explicitly made consistent with it.
>
> Signed-off-by: Simon Ser 
> ---
> This is a continuation of [1]. This protocol was pretty close to being 
> accepted.
>
> I've chosen to put the xdg prefix because this primary selection is mostly 
> relevant
> to desktop compositors.
>
> I've added myself as maintainer, Carlos and Lyude let me know if you want to 
> replace
> me or be added to the list too.
>
> [1]: 
> https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html
>
>  Makefile.am   |   3 +-
>  unstable/xdg-primary-selection/README |   4 +
>  .../xdg-primary-selection-unstable-v1.xml | 225 ++
>  3 files changed, 231 insertions(+), 1 deletion(-)
>  create mode 100644 unstable/xdg-primary-selection/README
>  create mode 100644 
> unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 2b59d34..66a65af 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -19,7 +19,8 @@ unstable_protocols =
>   \
> 
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
>  \
> unstable/xdg-output/xdg-output-unstable-v1.xml
>   \
> unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> -   unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
> +  unstable/xdg-decoration/xdg-decoration-unstable-v1.xml   \
> +   unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml  
>   \
> $(NULL)
>
>  stable_protocols =   
>   \
> diff --git a/unstable/xdg-primary-selection/README 
> b/unstable/xdg-primary-selection/README
> new file mode 100644
> index 000..ae0a402
> --- /dev/null
> +++ b/unstable/xdg-primary-selection/README
> @@ -0,0 +1,4 @@
> +Primary selection protocol
> +
> +Maintainers:
> +Simon Ser 
> diff --git 
> a/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml 
> b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml
> new file mode 100644
> index 000..eb97425
> --- /dev/null
> +++ b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml
> @@ -0,0 +1,225 @@
> +
> +
> +  
> +Copyright © 2015, 2016 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.
> +  
> +
> +  
> +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
> +xdg

Re: [PATCH v10 wayland_protocols] text-input: Add v3 of the text-input protocol

[Carlos Garnacho]

Hey,

With the serial number behavior cleared out, this all reads great to
me. Can't be part and judge though :), so no R-b label.

Cheers,
  Carlos

On Mon, Jul 30, 2018 at 4:14 PM, Dorota Czaplejewicz
 wrote:
> From: Carlos Garnacho 
>
> This new protocol description is an evolution of v2.
>
> - All pre-edit text styling is gone.
> - Pre-edit cursor can span characters.
> - No events regarding input panel (OSK) state nor covered rectangle.
>   Compositors are still free to handle situations where the keyboard
>   focus rectangle is covered by the input panel.
> - No set_preferred_language request for clients.
> - There is no event to send keysyms. Compositors can use wl_keyboard
>   interface instead.
> - All state is double-buffered, with specified defaults.
> - The compositor can be notified about external changes to the state.
> - The client can detect outdated requests.
>
> Signed-off-by: Dorota Czaplejewicz 
> Signed-off-by: Carlos Garnacho 
> ---
> Hi,
>
> this patch applies most recent advice from Jonas. The changes are in commit 
> and done messages and spelled out in my previous email.
>
> Cheers,
> Dorota
>
>  Makefile.am|   1 +
>  unstable/text-input/text-input-unstable-v3.xml | 435 
> +
>  2 files changed, 436 insertions(+)
>  create mode 100644 unstable/text-input/text-input-unstable-v3.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..86d7ca9 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3,6 +3,7 @@ unstable_protocols =  
>   \
> unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
>   \
> unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>   \
> unstable/text-input/text-input-unstable-v1.xml
>   \
> +   unstable/text-input/text-input-unstable-v3.xml
>   \
> unstable/input-method/input-method-unstable-v1.xml
>   \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml  
>   \
> unstable/xdg-shell/xdg-shell-unstable-v6.xml  
>   \
> diff --git a/unstable/text-input/text-input-unstable-v3.xml 
> b/unstable/text-input/text-input-unstable-v3.xml
> new file mode 100644
> index 000..acf5674
> --- /dev/null
> +++ b/unstable/text-input/text-input-unstable-v3.xml
> @@ -0,0 +1,435 @@
> +
> +
> +
> +  
> +Copyright © 2012, 2013 Intel Corporation
> +Copyright © 2015, 2016 Jan Arne Petersen
> +Copyright © 2017, 2018 Red Hat, Inc.
> +Copyright © 2018   Purism SPC
> +
> +Permission to use, copy, modify, distribute, and sell this
> +software and its documentation for any purpose is hereby granted
> +without fee, provided that the above copyright notice appear in
> +all copies and that both that copyright notice and this permission
> +notice appear in supporting documentation, and that the name of
> +the copyright holders not be used in advertising or publicity
> +pertaining to distribution of the software without specific,
> +written prior permission.  The copyright holders make no
> +representations about the suitability of this software for any
> +purpose.  It is provided "as is" without express or implied
> +warranty.
> +
> +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
> +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> +THIS SOFTWARE.
> +  
> +
> +  
> +
> +  The zwp_text_input_v3 interface represents text input and input methods
> +  associated with a seat. It provides enter/leave events to follow the
> +  text input focus for a seat.
> +
> +  Requests are used to enable/disable the text-input object and set
> +  state information like surrounding and selected text or the content 
> type.
> +  The information about the entered text is sent to the text-input object
> +  via the preedit_string and commit_string events.
> +
> +  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
> +  must not point to middle bytes inside a code point: they must either
> +  point to the first byte of a code point or to the end of the 

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Carlos Garnacho]

Hi!,

(Way way late, trying to revive the conversation...)

On Thu, May 3, 2018 at 9:22 PM, Dorota Czaplejewicz
 wrote:
> On Thu, 3 May 2018 20:47:27 +0200
> Silvan Jegen  wrote:
>
>> Hi Dorota
>>
>> Some comments and typo fixes below.
>>
>> On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz wrote:
>> > This new protocol description is a simplification over v2.
>> >
>> > - All pre-edit text styling is gone.
>> > - Pre-edit cursor can span characters.
>> > - No events regarding input panel (OSK) state nor covered rectangle.
>> >   Compositors are still free to handle situations where the keyboard
>> >   focus rectangle is covered by the input panel.
>> > - No set_preferred_language request for clients.
>> > - There is no event to send keysyms. Compositors can use wl_keyboard
>> >   interface instead.
>> > - All state is double-buffered, with specified state.
>> > - Use Unicode codepoints to measure strings.
>> >
>> > Signed-off-by: Dorota Czaplejewicz 
>> > Signed-off-by: Carlos Garnacho 
>> > ---
>> > This is the next update coming from Purism to perfect the text input 
>> > protocol.
>> >
>> > The following changes added on top of PATCHv3:
>> >
>> > - Fixed whitespaces.
>> > - Removed enable flags - the same information can be gathered from the 
>> > first requests after enter.
>> > - Changed offsets inside UTF-8 strings to use Unicode character counts in 
>> > order to remove the possibility of communicating invalid state.
>> > - Specified the exact lifetime of double-buffered state, and initial 
>> > values.
>> > - Made changes requested by the IM double-buffered.
>> >
>> > Some questions remain open. One is: how to specify how much text to 
>> > capture in set_surrounding_text, and how often to update?

IMHO the only reason to state it here is that it's more likely that a
lazy implementation will try to squeeze a full book here, than eg. an
application setting an insanely long title. But certainly other
messages across protocols may hit this limit (the long title issue
wasn't made up :).

As for how much, I think it ultimately depends on the IM behind. Text
correction probably just wants the current word, any sort of
prediction will probably require phrases to paragraphs, char
composition can probably do without. Sounds like this could be some
sort of hint, but I don't think IMs can tell you today how much text
do they want...

>> >
>> > A possible change that I decided against for now is to replace 
>> > enable/disable events by create/destroy of a new object, which would make 
>> > more state lifetimes encoded in the protocol.
>> >
>> > After reading a blog post on fcitx [0], I got the impression that letting 
>> > the compositor know some persistent ID of a text edit instance could be 
>> > useful, however I'm not sure what the use cases are.
>> >
>> > As always, I'm happy to hear feedback.
>> >
>> > Cheers,
>> > Dorota Czaplejewicz
>> >
>> > [0] 
>> > https://www.csslayer.info/wordpress/fcitx-dev/gaps-between-wayland-and-fcitx-or-all-input-methods/
>> >
>> >  Makefile.am|   1 +
>> >  unstable/text-input/text-input-unstable-v3.xml | 362 
>> > +
>> >  2 files changed, 363 insertions(+)
>> >  create mode 100644 unstable/text-input/text-input-unstable-v3.xml
>> >
>> > diff --git a/Makefile.am b/Makefile.am
>> > index 4b9a901..86d7ca9 100644
>> > --- a/Makefile.am
>> > +++ b/Makefile.am
>> > @@ -3,6 +3,7 @@ unstable_protocols =   
>> >  \
>> > unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml 
>> >  \
>> > unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml 
>> >  \
>> > unstable/text-input/text-input-unstable-v1.xml 
>> >  \
>> > +   unstable/text-input/text-input-unstable-v3.xml 
>> >  \
>> > unstable/input-method/input-method-unstable-v1.xml 
>> >  \
>> > unstable/xdg-shell/xdg-shell-unstable-v5.xml   
>> >  \
>> > unstable/xdg-shell/xdg-shell-unstable-v6.xml   
>> >  \
>> > diff --git a/unstable/text-input/text-input-unstable-v3.xml 
>> > b/unstable/text-input/text-

Re: [wayland-protocols] text-input: Add v3 of the text-input protocol

[Carlos Garnacho]

Hi!,

On Wed, Apr 11, 2018 at 8:52 PM, Weng Xuetian <wen...@gmail.com> wrote:
> (forgot to reply to the list)
>
> On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:
>> On Wed, 11 Apr 2018 11:26:22 -0700
>>
>> Weng Xuetian <wen...@gmail.com> wrote:
>> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
>> > > On Sun, 11 Mar 2018 20:30:14 +0100
>> > >
>> > > Carlos Garnacho <carl...@gnome.org> wrote:
>> > > > This new protocol description is a vast simplification over v2,
>> > > > highlights
>> > > > are:
>> > > > - All pre-edit text styling is gone, the protocol doesn't seem the
>> > > > place
>> > > >
>> > > >   to convey UI state. Clients are in better knowledge of how to make
>> > > >   the
>> > > >   pre-edit string distinguishable from regular text.
>> >
>> > As an long-time input method developer and CJK user, I'd prefer to keep
>> > the
>> > styling. In Chinese or Japanese, partially converted text are common and
>> > styling is useful to help user to distinguish which text is currently
>> > being
>> > converted. [1] But for the sake of in-app consistency, I'd say we don't
>> > need that much capability about styling though. Among all input methods
>> > supported by fcitx [2], only underline/highlight is being commonly used.
>> > Recently I started to use some strike style in only one single input
>> > method though, it can also be useful in certain cases.
>>
>> I think this use case is covered. For indicating what's currently being
>> changed, this protocol is using "preedit string". In GTK, the preedit text
>> is displayed with an underline, making is always clear what the suggestion
>> pertains to.
> I think you can take a closer look at [1].
>
> "葵あ" is the complete preedit text. The input method is converting "葵" and
> giving the candidates for it, the あ part is not yet handled by input method
> (but typed by user and appears in the preedit). That's why "葵" is being
> highlighted.

IIUC, is あ simply unhighlighted till handled by the IM (and the
suggestion menu changes accordingly)? do preedit text styles in other
fcitx IMs convey the same or different info?

I wonder if we are missing some on-the-wire state, rather than text
styling support per se. And given the can of worms styling brings in
(hard to know how to stand out from the IM side, a11y and color
blindness issues, ...), I would personally rather have a hint system
than let the IM meddle with a foreign UI.

>
> In a single CJK text composition, CJK people would type the full sentence
> ahead instead of word by word because this helps input method to understand
> the whole context and improve the prediction.

I'm no CJK expert, so this might not apply neatly, but note there is a
set_surrounding_text request to help IM get context outside the
preedit string. This may even be combined with
delete_surrounding_text+commit_string to alter text outside preedit,
too.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] text-input: Add v3 of the text-input protocol

[Carlos Garnacho]

Hi!,

Thanks for picking up on this Dorota, and sorry for catching up late,
initial discussion started on days off, and I still have a big pile of
"to go through" email.

On Wed, Apr 11, 2018 at 3:03 PM, Dorota Czaplejewicz
<dorota.czaplejew...@puri.sm> wrote:
> This new protocol description is a simplification over v2.
>
> - All pre-edit text styling is gone.
> - No events regarding input panel (OSK) state nor covered rectangle.
>   Compositors are still free to handle situations where the keyboard
>   focus rectangle is covered by the input panel.
> - No set_preferred_language request for clients.
> - There is no event to send keysyms. Compositors can use wl_keyboard
>   interface instead.
>
> Reviewed-by: Drew DeVault <s...@cmpwn.com>
> ---
>
> Hi,
>
> This patch follows the original proposal by Carlos Garnacho. It's the
> result of my work on behalf of Purism to get good on-screen keyboard
> support in Wayland. It incorporates changes coming from discussions
> with Sway/wlroots developers [0], as well as issues pointed out in
> response to the original proposal.
>
> Changes over the original:
> - typos, whitespace and naming as pointed out by Silvan Jegen

Cheers Silvan :).

> - an explicit description of what happens to state: it's conceptually
>   double-buffered, and is not altered between focus events

Thanks for spelling that out, quite an omission in my original
proposal... I have some comments below on this.

> - removed the serial number on enter/leave events, as it's unambiguous
>   which surface has focus

Right, I think that could be safely left out. However the checks for
untimely requests gets a bit more hairy (eg. checking that the
text_input client and the focus surface client are the same).
Something along the lines of "the compositor should ignore requests
from other clients than the focused surface's" could maybe be added on
docs, at least.

>
> This protocol has already been implemented: in wlroots [0], rootston
> [1], and GTK3 [2]. We're counting on more projects to upstream support
> in order to settle on a single protocol for text input in the long
> term. Help and feedback appreciated!
>
> Cheers,
> Dorota Czaplejewicz
>
> PS. Sorry about the misformatted email on Monday.
>
> [0] https://github.com/swaywm/wlroots/pull/776
> [1] https://code.puri.sm/dorota.czaplejewicz/gtk
> [2] https://code.puri.sm/dorota.czaplejewicz/wlroots/src/text_input_test
>
>  Makefile.am|   1 +
>  unstable/text-input/text-input-unstable-v3.xml | 308 
> +
>  2 files changed, 309 insertions(+)
>  create mode 100644 unstable/text-input/text-input-unstable-v3.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..86d7ca9 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3,6 +3,7 @@ unstable_protocols =  
>   \
> unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
>   \
> unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>   \
> unstable/text-input/text-input-unstable-v1.xml
>   \
> +   unstable/text-input/text-input-unstable-v3.xml
>   \
> unstable/input-method/input-method-unstable-v1.xml
>   \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml  
>   \
> unstable/xdg-shell/xdg-shell-unstable-v6.xml  
>   \
> diff --git a/unstable/text-input/text-input-unstable-v3.xml 
> b/unstable/text-input/text-input-unstable-v3.xml
> new file mode 100644
> index 000..f5d43e7
> --- /dev/null
> +++ b/unstable/text-input/text-input-unstable-v3.xml
> @@ -0,0 +1,308 @@
> +
> +
> +
> +  
> +Copyright © 2012, 2013 Intel Corporation
> +Copyright © 2015, 2016 Jan Arne Petersen
> +Copyright © 2017, 2018 Red Hat, Inc.
> +Copyright © 2018 Purism SPC
> +
> +Permission to use, copy, modify, distribute, and sell this
> +software and its documentation for any purpose is hereby granted
> +without fee, provided that the above copyright notice appear in
> +all copies and that both that copyright notice and this permission
> +notice appear in supporting documentation, and that the name of
> +the copyright holders not be used in advertising or publicity
> +pertaining to distribution of the software without specific,
> +written prior permission.  The copyright holders make no
> +representations about the suitability of this software for any
> +purpose.  It is provided "as is" without express or implied
> +warranty.
> +
> 

[PATCH wayland-protocols] text-input: Add v3 of the text-input protocol

[Carlos Garnacho]

This new protocol description is a vast simplification over v2, highlights
are:
- All pre-edit text styling is gone, the protocol doesn't seem the place
  to convey UI state. Clients are in better knowledge of how to make the
  pre-edit string distinguishable from regular text.
- No input panel (OSK) state nor covered rectangle events. This leaks
  assumptions about the coordinate space of windows, and clients aren't
  fully capable of handling all possible situations (eg. if the OSK fully
  covers the surface). At the very least it could be split into a generic
  protocol of its own, this version of the protocol simply doesn't get
  into this business, compositors are still free to handle situations where
  the keyboard focus rectangle is covered by the input panel.
- Less state is to be kept on compositors. Clients must now reissue all
  applying IM state whenever the surface gains focus (or internal focus
  changes), instead of state requests being independent from focus.
- No set_preferred_language request for clients, modern desktops have
  generally moved towards session-wide IM settings, it seems hard to
  conciliate this piece of information flowing in both directions.
- There is no event to send keysyms. The handling ought to be by all means
  identical to wl_keyboard's, compositors might just use that interface.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
---

Hey,

Belatedly, here's my proposed v3 of the text-input protocol, a rename of
what is implemented on gnome-shell/gtk+. It basically is a
(over?)simplification compared to v2, the main difference besides the
punted functionality is the simplified messaging flow, state is considered
reset after enter/leave, or on .disable requests from the client, all
new state must be submitted afterwards.

Some of the removed things are maybe debatable (eg. the keysym event,
or language preference request/signal, although I don't see that working
out of the box widely, highly toolkit specific at best). For stuff like
the old input_panel_state request to do client-side UI magic to keep
keyboard focus visible I'm personally more opinionated though :).

Comments?

Cheers,
  Carlos

 Makefile.am|   2 +
 unstable/text-input/text-input-unstable-v3.xml | 293 +
 2 files changed, 295 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..31a36fe 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,8 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v2.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..f8369b0
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,293 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a s

[PATCH] tests: Fix "new ID" type handling in argument_from_va_list test

[Carlos Garnacho]

New IDs are internally dealt with as objects, however this test
expected to deal with 'n' as the uint32_t type that's just seen
through the wire. We should give it an object instead, and
expect an object from it.

https://bugs.freedesktop.org/show_bug.cgi?id=99899

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
---
 tests/connection-test.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/connection-test.c b/tests/connection-test.c
index 1c688f1..8be6c38 100644
--- a/tests/connection-test.c
+++ b/tests/connection-test.c
@@ -142,7 +142,7 @@ va_list_wrapper(const char *signature, union wl_argument 
*args, int count, ...)
 TEST(argument_from_va_list)
 {
union wl_argument args[WL_CLOSURE_MAX_ARGS];
-   struct wl_object fake_object;
+   struct wl_object fake_object, fake_new_object;
struct wl_array fake_array;
 
va_list_wrapper("i", args, 1, 100);
@@ -154,13 +154,13 @@ TEST(argument_from_va_list)
 
va_list_wrapper("?iuf?sonah", args, 8,
102, 103, wl_fixed_from_int(104), "value",
-   _object, 105, _array, 106);
+   _object, _new_object, _array, 106);
assert(args[0].i == 102);
assert(args[1].u == 103);
assert(args[2].f == wl_fixed_from_int(104));
assert(strcmp(args[3].s, "value") == 0);
assert(args[4].o == _object);
-   assert(args[5].n == 105);
+   assert(args[5].o == _new_object);
assert(args[6].a == _array);
assert(args[7].h == 106);
 }
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland v4] protocol: Define further the behavior of input on the presence of grabs

[Carlos Garnacho]

The leave events in the respective device interfaces has been further
documented so those can convey the necessary info when input is being
redirected out of their currently focused surface.

Only wl_touch is missing something semantically similar, a wl_touch.leave
event has been added so the touch interface can cope with such input
redirection situations on individual touchpoints.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
---

 Changes since v3: Applied wording improvements from Yong Bakos, added
   the clarification suggested by Daniel, and made wl_touch.leave part of
   wl_touch.frame as suggested by Jonas (and that was the intended behavior).

   Also went ahead and bumped wl_seat version again to 7, since this is not
   1.13 material.

 protocol/wayland.xml | 68 ++--
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 29b63be..7be23ec 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1651,7 +1651,7 @@
 

 
-  
+  
 
   A seat is a group of keyboards, pointer and touch devices. This
   object is published as a global during start up, or when such a
@@ -1839,6 +1839,23 @@
 
The leave notification is sent before the enter notification
for the new focus.
+
+   While a pointer will not usually leave a surface while a button
+   is pressed, there are circumstances where this event may occur,
+   such as:
+
+   - When a popup is shown by this or another client.
+   - When a drag-and-drop operation is initiated from this or
+ any other surface.
+   - Other compositor-specific grabs, like pointer gestures.
+
+   In these situations, a leave event will be emitted with no
+   paired button release event on this surface, and clients must
+   undo their internal state related to the ongoing button presses.
+
+   Clients must either receive a release or a leave event in a
+   timely manner, and strictly before all other input events from
+   that seat.
   
   
   
@@ -1880,6 +1897,10 @@
kernel's event code list. All other button codes above 0x are
currently undefined but may be used in future versions of this
protocol.
+
+   Clients should note that pressed/released events may not be paired;
+   in some cases, a leave event will be sent in place of a released event.
+   See wl_pointer.leave for more details.
   
   
   
@@ -2127,6 +2148,17 @@
 
The leave notification is sent before the enter notification
for the new focus.
+
+   There may be circumstances that force the keyboard focus to be taken
+   away from a surface while there are pressed keys, for example:
+
+   - When a popup is shown by this or another client.
+   - When a drag-and-drop operation is initiated from this or
+ any other surface.
+
+   In these situations, a leave event will be emitted with no paired
+   key release events on this surface, and clients must undo their
+   internal state related to the ongoing key presses.
   
   
   
@@ -2145,6 +2177,10 @@
A key was pressed or released.
The time argument is a timestamp with millisecond
granularity, with an undefined base.
+
+   Clients should note that pressed/released events may not be paired;
+   in some cases, a leave event will be sent in place of a released event.
+   See wl_keyboard.leave for more details.
   
   
   
@@ -2194,7 +2230,7 @@
 
   
 
-  
+  
 
   The wl_touch interface represents a touchscreen
   associated with a seat.
@@ -2226,6 +2262,10 @@
The touch point has disappeared. No further events will be sent for
this touch point and the touch point's ID is released and may be
reused in a future touch down event.
+
+   Clients should note that down/up events may not be paired;
+   in some cases, a leave event will be sent in place of a wl_touch.up
+   event. See wl_touch.leave for more details.
   
   
   
@@ -2336,6 +2376,30 @@
   
   
 
+
+
+
+
+  
+   Notification that this touch point is no longer focused on a
+   certain surface. This event does not occur on its own. It is
+   sent before a wl_touch.frame event.
+
+   Note that, because touch points are always implicitly grabbed,
+   this event will only be emitted when the touch point is taken
+   away from this surface through explicit means, for example:
+
+   - When a popup is shown by this or another client.
+   - When a drag-and-drop operation is initiated from this or
+ any other surface.
+
+   This event will only be emitted on objects of version 6 or
+   higher, older clients will receive a wl_touch.up event per
+

[PATCH weston v5 3/4] clients: Add pointer gesture support to weston-eventdemo

[Carlos Garnacho]

Just print the output, as with the other events.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-by: Bryce Harrington <br...@osg.samsung.com>
---
 clients/eventdemo.c | 108 +++-
 1 file changed, 107 insertions(+), 1 deletion(-)

diff --git a/clients/eventdemo.c b/clients/eventdemo.c
index d8eef5b..415b28a 100644
--- a/clients/eventdemo.c
+++ b/clients/eventdemo.c
@@ -82,6 +82,12 @@ static int log_axis = 0;
 /** set to log motion events */
 static int log_motion = 0;
 
+/** set to log swipe gesture events */
+static int log_swipe_gesture = 0;
+
+/** set to log pinch gesture events */
+static int log_pinch_gesture = 0;
+
 /**
  * \struct eventdemo
  * \brief Holds all data the program needs per window
@@ -373,6 +379,89 @@ motion_handler(struct widget *widget, struct input *input, 
uint32_t time,
return CURSOR_LEFT_PTR;
 }
 
+static void
+gesture_swipe_begin_handler(struct widget *widget,
+   struct input *input,
+   uint32_t time,
+   uint32_t n_fingers,
+   void *data)
+{
+   if (log_swipe_gesture) {
+   printf("swipe gesture begin time: %d, fingers: %d\n",
+  time, n_fingers);
+   }
+}
+
+static void
+gesture_swipe_update_handler(struct widget *widget,
+struct input *input,
+uint32_t time,
+float dx,
+float dy,
+void *data)
+{
+   if (log_swipe_gesture) {
+   printf("swipe gesture update time: %d, dx: %f, dy: %f\n",
+  time, dx, dy);
+   }
+}
+
+static void
+gesture_swipe_end_handler(struct widget *widget,
+ struct input *input,
+ uint32_t time,
+ int32_t cancelled,
+ void *data)
+{
+   if (log_swipe_gesture) {
+   printf("swipe gesture end time: %d, cancelled: %d\n",
+  time, cancelled);
+   }
+}
+
+static void
+gesture_pinch_begin_handler(struct widget *widget,
+   struct input *input,
+   uint32_t time,
+   uint32_t n_fingers,
+   void *data)
+{
+   if (log_pinch_gesture) {
+   printf("pinch gesture begin time: %d, fingers: %d\n",
+  time, n_fingers);
+   }
+}
+
+static void
+gesture_pinch_update_handler(struct widget *widget,
+struct input *input,
+uint32_t time,
+float dx,
+float dy,
+float scale,
+float rotation_delta,
+void *data)
+{
+   if (log_pinch_gesture) {
+   printf("pinch gesture update time: %d, dx: %f, dy: %f, "
+  "scale: %f, rotation delta: %f\n",
+  time, dx, dy, scale, rotation_delta);
+   }
+}
+
+static void
+gesture_pinch_end_handler(struct widget *widget,
+ struct input *input,
+ uint32_t time,
+ int32_t cancelled,
+ void *data)
+{
+   if (log_pinch_gesture) {
+   printf("pinch gesture end time: %d, cancelled: %d\n",
+  time, cancelled);
+   }
+}
+
 /**
  * \brief Create and initialise a new eventdemo window.
  * The returned eventdemo instance should be destroyed using \c 
eventdemo_destroy().
@@ -441,6 +530,20 @@ eventdemo_create(struct display *d)
 axis_stop_handler,
 axis_discrete_handler);
 
+   /* Set gesture handlers for the window */
+   widget_set_pointer_gesture_swipe_begin_handler(e->widget,
+  
gesture_swipe_begin_handler);
+   widget_set_pointer_gesture_swipe_update_handler(e->widget,
+   
gesture_swipe_update_handler);
+   widget_set_pointer_gesture_swipe_end_handler(e->widget,
+gesture_swipe_end_handler);
+   widget_set_pointer_gesture_pinch_begin_handler(e->widget,
+  
gesture_pinch_begin_handler);
+   widget_set_pointer_gesture_pinch_update_handler(e->widget,
+   
gesture_pinch_update_handler);
+   widget_set_pointer_gesture_pinch_end_handler(e->widget,
+gesture_pinch_end_handler);
+
   

[PATCH weston v5 4/4] clients: Add pointer pinch gesture support to weston-image

[Carlos Garnacho]

It will allow zooming in/out the loaded image.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 clients/image.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/clients/image.c b/clients/image.c
index db9ccd6..5057d0a 100644
--- a/clients/image.c
+++ b/clients/image.c
@@ -61,6 +61,7 @@ struct image {
 
bool initialized;
cairo_matrix_t matrix;
+   float last_scale;
 };
 
 static double
@@ -330,6 +331,35 @@ axis_handler(struct widget *widget, struct input *input, 
uint32_t time,
 }
 
 static void
+pinch_begin_handler(struct widget *widget,
+   struct input *input,
+   uint32_t time,
+   uint32_t n_fingers,
+   void *data)
+{
+   struct image *image = data;
+
+   image->last_scale = 1;
+}
+
+static void
+pinch_update_handler(struct widget *widget,
+struct input *input,
+uint32_t time,
+float dx,
+float dy,
+float scale,
+float rotation_delta,
+void *data)
+{
+   struct image *image = data;
+
+   zoom(image, scale / image->last_scale);
+   window_schedule_redraw(image->window);
+   image->last_scale = scale;
+}
+
+static void
 fullscreen_handler(struct window *window, void *data)
 {
struct image *image = data;
@@ -400,6 +430,11 @@ image_create(struct display *display, const char *filename,
widget_set_button_handler(image->widget, button_handler);
widget_set_axis_handler(image->widget, axis_handler);
window_set_key_handler(image->window, key_handler);
+   widget_set_pointer_gesture_pinch_begin_handler(image->widget,
+  pinch_begin_handler);
+   widget_set_pointer_gesture_pinch_update_handler(image->widget,
+   pinch_update_handler);
+
widget_schedule_resize(image->widget, 500, 400);
 
return image;
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston v5 2/4] clients: Request the wl_pointer_gesture_swipe/pinch interfaces

[Carlos Garnacho]

This is accompanied by separate handlers for the different stages
of swipe/pinch gestures, so those can be set in demos.

v5: Update to zwp namespace
v4: Indenting fix.
v3: added null checks around pointer gesture interface destruction,
nullify afterwards.
v2: depend on standalone protocol xml.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-by: Bryce Harrington <br...@osg.samsung.com>
---
 Makefile.am  |   6 +-
 clients/window.c | 230 ++-
 clients/window.h |  54 +
 3 files changed, 288 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index d41acd6..6fd5552 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -652,6 +652,8 @@ libtoytoolkit_la_SOURCES =  \
shared/helpers.h
 
 nodist_libtoytoolkit_la_SOURCES =  \
+   protocol/pointer-gestures-protocol.c\
+   protocol/pointer-gestures-client-protocol.h \
protocol/text-cursor-position-protocol.c\
protocol/text-cursor-position-client-protocol.h \
protocol/viewporter-protocol.c  \
@@ -663,7 +665,9 @@ nodist_libtoytoolkit_la_SOURCES =   \
protocol/pointer-constraints-unstable-v1-protocol.c \
protocol/pointer-constraints-unstable-v1-client-protocol.h  \
protocol/relative-pointer-unstable-v1-protocol.c\
-   protocol/relative-pointer-unstable-v1-client-protocol.h
+   protocol/relative-pointer-unstable-v1-client-protocol.h \
+   protocol/pointer-gestures-unstable-v1-protocol.c\
+   protocol/pointer-gestures-unstable-v1-client-protocol.h
 
 BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES)
 
diff --git a/clients/window.c b/clients/window.c
index 59fc07e..248605f 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -78,6 +78,7 @@ typedef void *EGLContext;
 #include "text-cursor-position-client-protocol.h"
 #include "pointer-constraints-unstable-v1-client-protocol.h"
 #include "relative-pointer-unstable-v1-client-protocol.h"
+#include "pointer-gestures-unstable-v1-client-protocol.h"
 #include "shared/os-compatibility.h"
 
 #include "window.h"
@@ -110,6 +111,7 @@ struct display {
struct ivi_application *ivi_application; /* ivi style shell */
struct zwp_relative_pointer_manager_v1 *relative_pointer_manager;
struct zwp_pointer_constraints_v1 *pointer_constraints;
+   struct zwp_pointer_gestures_v1 *pointer_gestures;
EGLDisplay dpy;
EGLConfig argb_config;
EGLContext argb_ctx;
@@ -247,7 +249,6 @@ struct window {
 
int fullscreen;
int maximized;
-
enum preferred_format preferred_format;
 
window_key_handler_t key_handler;
@@ -316,6 +317,12 @@ struct widget {
widget_axis_source_handler_t axis_source_handler;
widget_axis_stop_handler_t axis_stop_handler;
widget_axis_discrete_handler_t axis_discrete_handler;
+   widget_pointer_gesture_swipe_begin_handler_t swipe_begin_handler;
+   widget_pointer_gesture_swipe_update_handler_t swipe_update_handler;
+   widget_pointer_gesture_swipe_end_handler_t swipe_end_handler;
+   widget_pointer_gesture_pinch_begin_handler_t pinch_begin_handler;
+   widget_pointer_gesture_pinch_update_handler_t pinch_update_handler;
+   widget_pointer_gesture_pinch_end_handler_t pinch_end_handler;
void *user_data;
int opaque;
int tooltip_count;
@@ -340,6 +347,8 @@ struct input {
struct wl_pointer *pointer;
struct wl_keyboard *keyboard;
struct wl_touch *touch;
+   struct zwp_pointer_gesture_pinch_v1 *pinch;
+   struct zwp_pointer_gesture_swipe_v1 *swipe;
struct wl_list touch_point_list;
struct window *pointer_focus;
struct window *keyboard_focus;
@@ -2006,6 +2015,48 @@ widget_set_axis_handlers(struct widget *widget,
widget->axis_discrete_handler = axis_discrete_handler;
 }
 
+void
+widget_set_pointer_gesture_swipe_begin_handler(struct widget *widget,
+  
widget_pointer_gesture_swipe_begin_handler_t handler)
+{
+   widget->swipe_begin_handler = handler;
+}
+
+void
+widget_set_pointer_gesture_swipe_update_handler(struct widget *widget,
+   
widget_pointer_gesture_swipe_update_handler_t handler)
+{
+   widget->swipe_update_handler = handler;
+}
+
+void
+widget_set_pointer_gesture_swipe_end_handler(struct widget *widget,
+
widget_pointer_gesture_swipe_end_handler_t handler)
+{
+   widget->swipe_end_handler = handler;
+}
+
+void
+widget_set_pointer_gesture_pinch_begin_handler(struct widget *widget,
+

Re: [PATCH libinput 0/5] Disable laptop touchpad on lid close

[Carlos Garnacho]

Hey,

Thanks James for these patches!

On Thu, Jan 5, 2017 at 11:02 AM, Peter Hutterer
 wrote:
> On Thu, Jan 05, 2017 at 05:11:24PM +1100, James Ye wrote:
>> Although a laptop touchpad is usually not accessible when the lid is closed,
>> some laptop models suffer from a hardware bug where the touchpad can be
>> activated even if the lid is closed.  This bug can be worked around by 
>> disabling
>> the touchpad when the lid is closed.
>>
>> This patch set adds:
>> 1: hwdb patch to mark switches as input devices (needs to go to systemd)
>> 2: switch interface[1]
>> 3: evdev dispatch interface for laptop lid switches
>> 4: mechanism for pairing touchpad with lid, and disabling the touchpad
>> 5: test cases
>>
>> Best regards,
>> James Ye
>
> thanks for picking this up, much appreciated. The patches look good bar a
> few minor nitpicks and a few test cases we should add. But the series even
> *has* test cases, so there's really very little I can complain about :)
>
> One thing I found missing when I reviewed the tests: we don't sync the
> status of the switch on startup. There are two options here (either can be a
> follow-up patch):
> * send a switch toggle event immediately after DEVICE_ADDED on startup.
>   That's in-line with the other events and iirc also what we do for
>   proximity if a tablet tool is already in proximity on device added.
> * add a libinput_device_switch_get_state() function for callers to query the
>   state if they need it and only send the actual changes after we have a
>   context initialised. That has a small potential for race conditions, so
>   I'm tending to the first option
>
> Carlos, Jonas, Hans, any opinions?

I tend to favor the first option as well, at least seems more
consistent. Another thing I'd maybe miss is separating toggle on/off
events, so it could be documented that you're always guaranteed to
receive the other event next without fiddling on the event contents
themselves (although you still need to lookup lid/tablet-mode...).

Other than that, the patches look correct to me.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v3] protocol: Define further the behavior of input on the presence of grabs

[Carlos Garnacho]

The leave events in the respective device interfaces has been further
documented so those can convey the necessary info when input is being
redirected out of their currently focused surface.

Only wl_touch is missing something semantically similar, a wl_touch.leave
event has been added so the touch interface can cope with such input
redirection situations on individual touchpoints.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
---

v2: Reuse leave events for this purpose. This meant one had to be added
on wl_touch.
v3: Improved wording (I hope!) largely inspired on the suggestions from
Daniel Stone. Bumped wl_seat version to 6 for wl_touch.leave.

 protocol/wayland.xml | 61 +++-
 1 file changed, 60 insertions(+), 1 deletion(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 6c6d078..16fc0b3 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1669,7 +1669,7 @@
 

 
-  
+  
 
   A seat is a group of keyboards, pointer and touch devices. This
   object is published as a global during start up, or when such a
@@ -1859,6 +1859,23 @@
 
The leave notification is sent before the enter notification
for the new focus.
+
+   Normally, a pointer will not leave a surface while there are
+   buttons pressed, there's however circumstances where this event
+   may be received in this situation, for example:
+
+   - When a popup is shown by this or other client.
+   - When a drag-and-drop operation is initiated from this or
+ any other surface.
+   - Other compositor-specific grabs, like pointer gestures.
+
+   In these situations, a leave event will be emitted with no
+   pairing button release events on this surface, clients must undo
+   their internal state related to the ongoing button presses.
+
+   Clients must either receive a release or a leave event in a
+   timely manner, and strictly before all other input events from
+   that seat.
   
   
   
@@ -1893,6 +1910,10 @@
enter event.
 The time argument is a timestamp with millisecond
 granularity, with an undefined base.
+
+   Clients should note that pressed/released events may not be paired;
+   in some cases, a leave event will be sent in place of a released event.
+   See wl_pointer.leave for more details.
   
 
   
@@ -2136,6 +2157,17 @@
 
The leave notification is sent before the enter notification
for the new focus.
+
+   There may be circumstances that force the keyboard focus to be taken
+   away from a surface while there are pressed keys, for example:
+
+   - When a popup is shown by this or other client.
+   - When a drag-and-drop operation is initiated from this or
+ any other surface.
+
+   In these situations, a leave event will be emitted with no pairing
+   key release events on this surface, clients must undo their internal
+   state related to the ongoing key presses.
   
   
   
@@ -2154,6 +2186,10 @@
A key was pressed or released.
 The time argument is a timestamp with millisecond
 granularity, with an undefined base.
+
+   Clients should note that pressed/released events may not be paired;
+   in some cases, a leave event will be sent in place of a released event.
+   See wl_keyboard.leave for more details.
   
 
   
@@ -2238,6 +2274,10 @@
The touch point has disappeared. No further events will be sent for
this touch point and the touch point's ID is released and may be
reused in a future touch down event.
+
+   Clients should note that down/up events may not be paired;
+   in some cases, a leave event will be sent in place of a wl_touch.up
+   event. See wl_touch.leave for more details.
   
   
   
@@ -2276,6 +2316,25 @@
 
   
 
+
+
+
+
+  
+   Notification that this touch point is no longer focused on a
+   certain surface.
+
+   Note that, because touch points are always implicitly grabbed,
+   this event will only be emitted when the touch point is taken
+   away from this surface through explicit means, for example:
+
+   - When a popup is shown by this or other client.
+   - When a drag-and-drop operation is initiated from this or
+ any other surface.
+  
+  
+  
+
   
 
   
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] protocol: Define further the behavior of input on the presence of grabs

[Carlos Garnacho]

Hey Daniel :),

On Tue, Nov 22, 2016 at 12:43 PM, Daniel Stone <dan...@fooishbar.org> wrote:
> Hi Carlos,
>
> On 12 November 2015 at 12:31, Carlos Garnacho <carl...@gnome.org> wrote:
>> The leave events in the respective device interfaces has been further
>> documented so those can convey the necessary info when input is being
>> redirected out of their currently focused surface.
>>
>> Only wl_touch is missing something semantically similar, a wl_touch.leave
>> event has been added so the touch interface can cope with such input
>> redirection situations.
>
> Just over a year later. :\ I think I'd put this message into a tab to
> review later, then at some point Chrome lost all my tabs and that was
> one of them ...

Oh well... you're not alone, it's been in my backlog for a while too :).

>
>> @@ -1665,6 +1665,19 @@
>>
>> The leave notification is sent before the enter notification
>> for the new focus.
>> +
>> +   Normally, a pointer will not leave a surface while there are
>> +   buttons pressed, there's however circumstances where this event
>> +   may be received in this situation, for example:
>> +
>> +   - When a popup is shown by this or other client.
>> +   - When a drag-and-drop operation is initiated from this or
>> + any other surface.
>> +   - Other compositor-specific grabs, like pointer gestures.
>> +
>> +   In these situations, the pairing button release will not be
>> +   emitted, clients should undo the effect of those pressed
>> +   buttons and forget about their state.
>
> The client _must_ either receive a release or a leave event in a
> timely manner, and strictly before all other input events from that
> seat.
>
>> @@ -1699,6 +1712,14 @@
>> enter event.
>>  The time argument is a timestamp with millisecond
>>  granularity, with an undefined base.
>> +
>> +Clients should note that pressed/released events may not be
>> +paired, most commonly due to input being actively taken away
>> +or being redirected into this surface (eg. popups), either
>> +state must be expected to be received separately. If no such
>> +input redirection happened in between, the same surface that
>> +received the "pressed" state is expected to receive the
>> +"released" state too.
>>
>
> Hm, to be honest, I'd just go with: 'Clients should note that
> pressed/released events may not be paired; in some cases, a leave
> event will be sent in lieu of a released event. See that event's
> documentation for more details'.

Indeed, just explaining it thoroughly in one of the 2 events make
sense. I actually wonder if it could be explained generically for all
keyboard/pointer/touch (eg. a separate section), but it's probably
better anyway to state the per-interface specifics.

>
>> @@ -1798,6 +1819,17 @@
>>
>> The leave notification is sent before the enter notification
>> for the new focus.
>> +
>> +   There are circumstances that force a focus switch, possibly
>> +   while there are pressed keys, for example:
>> +
>> +   - When a popup is shown by this or other client.
>> +   - When a drag-and-drop operation is initiated from this or
>> + any other surface.
>> +
>> +   In these situations, the pairing key release will not be
>> +   emitted, clients should undo the effect of those pressed
>> +   pressed and forget about their state.
>
> I'd probably avoid specifically mentioning focus switching here.

Yup, sounds wise, after all the client doesn't care that the focus
goes elsewhere, just about losing the focus itself.

>
>> @@ -1816,6 +1848,14 @@
>> A key was pressed or released.
>>  The time argument is a timestamp with millisecond
>>  granularity, with an undefined base.
>> +
>> +Clients should note that pressed/released events may not be
>> +paired, most commonly due to input being actively taken away
>> +or being redirected into this surface (eg. popups), either
>> +state must be expected to be received separately. If no such
>> +input redirection happened in between, the same surface that
>> +received the "pressed" state is expected to receive the
>> +"released" state too.
>>
>
> Same comment as with wl_pointer's leave.
>
>> @@ -1938,6 +1978,25 @@
>>  
>>
&

Re: Kinetic scroll in libinput Xorg driver

[Carlos Garnacho]

Hey Carsten!,

On Thu, Oct 27, 2016 at 4:11 AM, Carsten Haitzler  wrote:
> On Wed, 26 Oct 2016 06:57:53 + "Alexis BRENON @Wayland"  +wayl...@gmail.com> said:
>
>> Just to be sure that I understand clearly, what you call 'Toolkit' is
>> libraries like GTK, Qt, and co. that are used by developers to build their
>> apps, isn't it ?
>
> yes. toolkit == EFL, Qt, GTK+ and others (SDL is kind of a toolkit), FLTK, ...
> chromium/blink is basically a toolkit of its own etc.
>
> at least looking at gtk3 here it doesn't do momentum with wheel/axis scrolling
> (out of the box). maybe it needs enabling?

FWIW, that should happen out of the box whenever we got
wl_pointer.axis_stop on both axes:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n3399

The usual caveats apply, that doesn't help if the app plays smart and
tries to implement its own scroller widget.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-protocols v5 4/4] tablet: Add pad support to the tablet protocol

[Carlos Garnacho]

The pad's interface is similar to the tool interface, a client is notified of
the pad after the tablet_added event.

The pad has three functionalities: buttons, rings and strips.
Buttons are fairly straightforward, rings and strips are separate interfaces
with a pointer-axis-like source/value/frame events.
The two interfaces are effectively identical but for the actual value they
send (degrees vs normalized position).

Buttons are sequentially indexed starting with zero, unlike other protocols
where a linux/input.h-style semantic event code is used. Since we expect all
buttons to have client-specific functionality, an additional event tells the
client when a given button index is not available, usually because the
compositor assignes some function to it (e.g. mode switching, see below).

Specific to the pad device is the set_feedback request which enables a client
to set a user-defined string to display for an OSD on the current mappings.
This request is available for buttons, rings and strips.

Finally, the pad supports groups, effectively sets of button/ring/strip
configurations. Those groups may have multiple modes each, so that
users/clients may map several actions to a single element.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Jason Gerecke <jason.gere...@wacom.com>
---
 unstable/tablet/tablet-unstable-v2.xml | 540 +
 1 file changed, 540 insertions(+)

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index 77b185c..2cc3a92 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -172,6 +172,22 @@
   
   
 
+
+
+  
+   This event is sent whenever a new pad is known to the system. Typically,
+   pads are physically attached to tablets and a pad_added event is
+   sent immediately after the wp_tablet_seat.tablet_added.
+   However, some standalone pad devices logically attach to tablets at
+   runtime, and the client must wait for wp_tablet_pad.enter to know
+   the tablet a pad is attached to.
+
+   This event only provides the object id of the pad. All further
+   features (buttons, strips, rings) are sent through the wp_tablet_pad
+   interface.
+  
+  
+
   
 
   
@@ -636,4 +652,528 @@
 
   
 
+  
+
+  A circular interaction area, such as the touch ring on the Wacom Intuos
+  Pro series tablets.
+
+  Events on a ring are logically grouped by the wl_tablet_pad_ring.frame
+  event.
+
+
+
+  
+   Request that the compositor use the provided feedback string
+   associated with this ring. This request should be issued immediately
+   after a wp_tablet_pad_group.mode_switch event from the corresponding
+   group is received, or whenever the ring is mapped to a different
+   action. See wp_tablet_pad_group.mode_switch for more details.
+
+   Clients are encouraged to provide context-aware descriptions for
+   the actions associated with the ring; compositors may use this
+   information to offer visual feedback about the button layout
+   (eg. on-screen displays).
+
+   The provided string 'description' is a UTF-8 encoded string to be
+   associated with this ring, and is considered user-visible; general
+   internationalization rules apply.
+
+   The serial argument will be that of the last
+   wp_tablet_pad_group.mode_switch event received for the group of this
+   ring. Requests providing other serials than the most recent one will be
+   ignored.
+  
+  
+  
+
+
+
+  
+   This destroys the client's resource for this ring object.
+  
+
+
+
+  
+   Describes the source types for ring events. This indicates to the
+   client how a ring event was physically generated; a client may
+   adjust the user interface accordingly. For example, events
+   from a "finger" source may trigger kinetic scrolling.
+  
+  
+
+
+
+  
+   Source information for ring events.
+
+   This event does not occur on its own. It is sent before a
+   wp_tablet_pad_ring.frame event and carries the source information
+   for all events within that frame.
+
+   The source specifies how this event was generated. If the source is
+   wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event
+   will be sent when the user lifts the finger off the device.
+
+   This event is optional. If the source is unknown for an interaction,
+   no event is sent.
+  
+  
+
+
+
+  
+   Sent whenever the angle on a ring changes.
+
+   The angle is provided in degrees clockwise from the logical
+   north of the ring in the pad's current rotation.
+  
+  
+
+
+
+  
+   Stop 

[PATCH wayland-protocols v5 1/4] tablet: add v2 of the tablet protocol

[Carlos Garnacho]

From: Peter Hutterer <peter.hutte...@who-t.net>

This is a straightforward copy/paste with a _v1 -> _v2 rename. No functional
changes otherwise.

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Jason Gerecke <jason.gere...@wacom.com>
Reviewed-by: Carlos Garnacho <carl...@gnome.org>
---
 Makefile.am|   1 +
 unstable/tablet/tablet-unstable-v2.xml | 641 +
 2 files changed, 642 insertions(+)
 create mode 100644 unstable/tablet/tablet-unstable-v2.xml

diff --git a/Makefile.am b/Makefile.am
index 71d2632..9e2a029 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols =
\
unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
\
unstable/tablet/tablet-unstable-v1.xml  
\
+   unstable/tablet/tablet-unstable-v2.xml  
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
new file mode 100644
index 000..81e9835
--- /dev/null
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -0,0 +1,641 @@
+
+
+
+  
+Copyright 2014 © Stephen "Lyude" Chandler Paul
+Copyright 2015-2016 © Red Hat, Inc.
+
+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.
+  
+
+  
+This description provides a high-level overview of the interplay between
+the interfaces defined this protocol. For details, see the protocol
+specification.
+
+More than one tablet may exist, and device-specifics matter. Tablets are
+not represented by a single virtual device like wl_pointer. A client
+binds to the tablet manager object which is just a proxy object. From
+that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
+and that returns the actual interface that has all the tablets. With
+this indirection, we can avoid merging wp_tablet into the actual Wayland
+protocol, a long-term benefit.
+
+The wp_tablet_seat sends a "tablet added" event for each tablet
+connected. That event is followed by descriptive events about the
+hardware; currently that includes events for name, vid/pid and
+a wp_tablet.path event that describes a local path. This path can be
+used to uniquely identify a tablet or get more information through
+libwacom. Emulated or nested tablets can skip any of those, e.g. a
+virtual tablet may not have a vid/pid. The sequence of descriptive
+events is terminated by a wp_tablet.done event to signal that a client
+may now finalize any initialization for that tablet.
+
+Events from tablets require a tool in proximity. Tools are also managed
+by the tablet seat; a "tool added" event is sent whenever a tool is new
+to the compositor. That event is followed by a number of descriptive
+events about the hardware; currently that includes capabilities,
+hardware id and serial number, and tool type. Similar to the tablet
+interface, a wp_tablet_tool.done event is sent to terminate that initial
+sequence.
+
+Any event from a tool happens on the wp_tablet_tool interface. When the
+tool gets into proximity of the tablet, a proximity_in event is sent on
+the wp_tablet_tool interface, listing the tablet and the surface. That
+event is followed by a motion event with the coordinates. After that,
+it's the usual motion, axis, button, etc. events. The protocol's
+serialisation means events are grouped by wp_tablet_tool.frame events.
+
+Two special events (that don't exist in X) are down 

[PATCH wayland-protocols v5 3/4] tablet: restrict the cursor surface to one per tool

[Carlos Garnacho]

From: Peter Hutterer <peter.hutte...@who-t.net>

The initial approach was to allow one surface to be re-used between tools,
seats and even used together as wl_pointer cursor surface. This has a few
drawbacks, most of which are related to managing the surface correctly in the
compositor. For example, the same cursor surface could have two different
hotspots. Animated cursors should animate independently rather than update at
the same time.

Furthermore: a client cannot know when a surface will cease being used as a
cursor surface. The basic assumption of "after focus out" is an implementation
detail in the compositor and unless the client unsets the cursor it is not
guaranteed that the surface is released. This again makes sharing a surface
less obvious - you cannot know if the wl_pointer surface is still in use when
you set it for a new wp_tablet_tool.

Avoid these headaches (and push some of them to the client) by simply
restricting a wl_surface to be assigned to a single tool. For the 99% use case
where we have one tablet with two tools (pen + eraser) this means we merely
get two extra surfaces, and the two don't usually share the same cursor shape
anyway. If sharing is absolutely necessary, a client may still opt to share
the underlying wl_buffer.

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Jason Gerecke <jason.gere...@wacom.com>
Reviewed-by: Carlos Garnacho <carl...@gnome.org>
---
 unstable/tablet/tablet-unstable-v2.xml | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index de9217b..77b185c 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -225,13 +225,11 @@
and pending input regions become undefined, and the wl_surface is
unmapped.
 
-   This request gives the surface the role of a cursor. The role
-   assigned by this request is the same as assigned by
-   wl_pointer.set_cursor meaning the same surface can be
-   used both as a wl_pointer cursor and a wp_tablet cursor. If the
-   surface already has another role, it raises a protocol error.
-   The surface may be used on multiple tablets and across multiple
-   seats.
+   This request gives the surface the role of a wp_tablet_tool cursor. A
+   surface may only ever be used as the cursor surface for one
+   wp_tablet_tool. If the surface already has another role or has
+   previously been used as cursor surface for a different tool, a
+   protocol error is raised.
   
   
   
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-protocols v5 2/4] tablet: change all degree values from int to wl_fixed

[Carlos Garnacho]

From: Peter Hutterer <peter.hutte...@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Jason Gerecke <jason.gere...@wacom.com>
Reviewed-by: Carlos Garnacho <carl...@gnome.org>
---
 unstable/tablet/tablet-unstable-v2.xml | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index 81e9835..de9217b 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -478,21 +478,21 @@
 
   
Sent whenever one or both of the tilt axes on a tool change. Each tilt
-   value is in 0.01 of a degree, relative to the z-axis of the tablet.
+   value is in degrees, relative to the z-axis of the tablet.
The angle is positive when the top of a tool tilts along the
positive x or y axis.
   
-  
-  
+  
+  
 
 
 
   
Sent whenever the z-rotation axis on the tool changes. The
-   rotation value is in 0.01 of a degree clockwise from the tool's
+   rotation value is in degrees clockwise from the tool's
logical neutral position.
   
-  
+  
 
 
 
@@ -510,10 +510,10 @@
   
Sent whenever the wheel on the tool emits an event. This event
contains two values for the same axis change. The degrees value is
-   in 0.01 of a degree in the same orientation as the
-   wl_pointer.vertical_scroll axis. The clicks value is in discrete
-   logical clicks of the mouse wheel. This value may be zero if the
-   movement of the wheel was less than one logical click.
+   in the same orientation as the wl_pointer.vertical_scroll axis. The
+   clicks value is in discrete logical clicks of the mouse wheel. This
+   value may be zero if the movement of the wheel was less
+   than one logical click.
 
Clients should choose either value and avoid mixing degrees and
clicks. The compositor may accumulate values smaller than a logical
@@ -521,7 +521,7 @@
Thus, wl_tablet_tool.wheel events with non-zero clicks values may
have different degrees values.
   
-  
+  
   
 
 
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v4 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Carlos Garnacho]

Hi!,

On Thu, Jul 7, 2016 at 11:30 PM, Jason Gerecke <killert...@gmail.com> wrote:
> On 06/30/2016 05:16 AM, Jonas Ådahl wrote:
>> On Thu, Jun 30, 2016 at 01:10:33PM +0200, Carlos Garnacho wrote:
>>> Hi!,
>>>
>>> On Thu, Jun 30, 2016 at 6:27 AM, Jonas Ådahl <jad...@gmail.com> wrote:
>>>> On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote:
>>>>> The pad's interface is similar to the tool interface, a client is 
>>>>> notified of
>>>>> the pad after the tablet_added event.
>>>>>
>>>>> The pad has three functionalities: buttons, rings and strips.
>>>>> Buttons are fairly straightforward, rings and strips are separate 
>>>>> interfaces
>>>>> with a pointer-axis-like source/value/frame events.
>>>>> The two interfaces are effectively identical but for the actual value they
>>>>> send (degrees vs normalized position).
>>>>>
>>>>> Buttons are sequentially indexed starting with zero, unlike other 
>>>>> protocols
>>>>> where a linux/input.h-style semantic event code is used. Since we expect 
>>>>> all
>>>>> buttons to have client-specific functionality, an additional event tells 
>>>>> the
>>>>> client when a given button index is not available, usually because the
>>>>> compositor assignes some function to it (e.g. mode switching, see below).
>>>>>
>>>>> Specific to the pad device is the set_feedback request which enables a 
>>>>> client
>>>>> to set a user-defined string to display for an OSD on the current 
>>>>> mappings.
>>>>> This request is available for buttons, rings and strips.
>>>>>
>>>>> Finally, the pad supports groups, effectively sets of button/ring/strip
>>>>> configurations. Those groups may have multiple modes each, so that
>>>>> users/clients may map several actions to a single element.
>>>>>
>>>>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>>>>> Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
>>>>> Reviewed-by: Jason Gerecke <jason.gere...@wacom.com>
>>>>> ---
>>>>>
>>
>> ... snip ...
>>
>>>>> +
>>>>> +
>>>>> +  
>>>>> + Sent on wp_tablet_pad_group initialization to announce available 
>>>>> rings.
>>>>> + One event is sent for each ring available on this pad group.
>>>>> +
>>>>> + This event is sent in the initial burst of events before the
>>>>> + wp_tablet_pad_group.done event. This event is only sent when at 
>>>>> least
>>>>> + one ring is available.
>>>>
>>>> The last sentence is redundant. It already says that there'll be one
>>>> event per ring, thus no rings, no events. It also makes it slightly
>>>> unclear (by the description alone) whethere multiple rings will result
>>>> in multiple events.
>>>
>>> Agreed, removed. As for the last part... I guess the "One event is
>>> sent for each ring available..." bit makes it clear enough already?
>>
>> Yes, I think that part makes it clear. It was only the part you now
>> removed that made it possible to doubt the first part for a second.
>>
>>>
>>
>> ... snip ...
>>
>>>>> +
>>>>> +
>>>>> +  
>>>>> + Notification that the mode was switched.
>>>>> +
>>>>> + A mode applies to all buttons, rings and strips in a group
>>>>> + simultaneously, but a client is not required to assign different 
>>>>> actions
>>>>> + for each mode. For example, a client may have mode-specific button
>>>>> + mappings but map the ring to vertical scrolling in all modes. Mode
>>>>> + indices start at 0.
>>>>> +
>>>>> + Switching modes is compositor-dependent. The compositor may provide
>>>>> + visual cues to the client about the mode, e.g. by toggling LEDs on
>>>>> + the tablet device. Mode-switching may be software-controlled or
>>>>> + controlled by one or more physical buttons. For example, on a Wacom
>>>>> + Intuos Pro, the button inside the ring may be assigned to switch
>>>>&g

Re: [PATCH v2 libinput 00/10] pad: add a mode toggle API

[Carlos Garnacho]

Hey!,

On Tue, Jun 21, 2016 at 8:25 PM, Jason Gerecke  wrote:
> On 06/14/2016 11:37 PM, Peter Hutterer wrote:
>>
>> Updated patchset adds EKR support and fixes a bunch of issues pointed out in
>> v1. Patch 04 is intentionally missing, that's the SVG being added which
>> wouldn't make it past the mailman filters.
>>
>> The branch is available on
>> https://github.com/whot/libinput/tree/wip/tablet-pad-modes-v2
>>
>> One important thing of note: Benjamin and I discussed the kernel side of
>> things and we'll be aiming for handling the LED toggling in the kernel
>> through the LED class interface. This means that libinput won't need write
>> support to sysfs and that libinput doesn't actually have to update the mode,
>> merely read the changed mode.
>>
>> this also means that patch 06 and 07 will change significantly though the
>> public API will remain the same. once the kernel patches are on track to be
>> in an upstream kernel I'll update the implementation, for now we go with
>> this one.
>>
>> Cheers,
>>   Peter
>
> Aside from the small comments on two of the patches, this looks good to
> me. Testing also seems to look good aside from the not-yet-implemented
> direct mode switching on my 24HD.

This got me thinking... it would also be great to know the mode those
direct-mode buttons switch to. Although this is just useful for
labeling purposes (eg. setting "Switch to mode 1/2/3" labels instead
of a generic "Switch mode" on all three), so having this in libinput
is dubious in the first place. To be resolved through a different call
than libinput_tablet_pad_mode_group_button_is_toggle at the very
least.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 libinput 00/10] pad: add a mode toggle API

[Carlos Garnacho]

Hi!,

On Wed, Jun 15, 2016 at 8:37 AM, Peter Hutterer
<peter.hutte...@who-t.net> wrote:
>
> Updated patchset adds EKR support and fixes a bunch of issues pointed out in
> v1. Patch 04 is intentionally missing, that's the SVG being added which
> wouldn't make it past the mailman filters.
>
> The branch is available on
> https://github.com/whot/libinput/tree/wip/tablet-pad-modes-v2

After going through
https://github.com/whot/libinput/tree/wip/tablet-pad-modes-v3, the
whole series looks good to me and is,

Reviewed-by: Carlos Garnacho <carl...@gnome.org>

I take it 7/10 and 9/10 from the former v2 series are now off the table, right?

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v4 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Carlos Garnacho]

Hi!,

On Thu, Jun 30, 2016 at 6:27 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote:
>> The pad's interface is similar to the tool interface, a client is notified of
>> the pad after the tablet_added event.
>>
>> The pad has three functionalities: buttons, rings and strips.
>> Buttons are fairly straightforward, rings and strips are separate interfaces
>> with a pointer-axis-like source/value/frame events.
>> The two interfaces are effectively identical but for the actual value they
>> send (degrees vs normalized position).
>>
>> Buttons are sequentially indexed starting with zero, unlike other protocols
>> where a linux/input.h-style semantic event code is used. Since we expect all
>> buttons to have client-specific functionality, an additional event tells the
>> client when a given button index is not available, usually because the
>> compositor assignes some function to it (e.g. mode switching, see below).
>>
>> Specific to the pad device is the set_feedback request which enables a client
>> to set a user-defined string to display for an OSD on the current mappings.
>> This request is available for buttons, rings and strips.
>>
>> Finally, the pad supports groups, effectively sets of button/ring/strip
>> configurations. Those groups may have multiple modes each, so that
>> users/clients may map several actions to a single element.
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
>> Reviewed-by: Jason Gerecke <jason.gere...@wacom.com>
>> ---
>>
>> Changes since v3:
>>
>> - Added wp_tablet_pad_group, this divides buttons/strips/rings into subsets,
>>   groups may have separate modes which are announced through a mode_switch
>>   event.
>> - Added serial argument to the set_feedback requests, to be obtained from
>>   the wp_tablet_pad_group.mode_switch events.
>> - Now that groups announce the buttons belonging to those, the
>>   wp_tablet_pad.buttons_reserved event has been removed in favor of implicit
>>   information (i.e. buttons not belonging to any group are reserved by the
>>   compositor).
>> - Added wp_tablet_pad.path event, similar to wp_tablet.path
>> - Button indices are now explicitly mentioned in docs where relevant
>> - Fixed several typos and improved docs here and there
>>
>>  unstable/tablet/tablet-unstable-v2.xml | 546 
>> -
>>  1 file changed, 543 insertions(+), 3 deletions(-)
>>
>> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
>> b/unstable/tablet/tablet-unstable-v2.xml
>> index 5248c64..63172e2 100644
>> --- a/unstable/tablet/tablet-unstable-v2.xml
>> +++ b/unstable/tablet/tablet-unstable-v2.xml
>> @@ -172,6 +172,22 @@
>>
>>> summary="the newly added tablet tool"/>
>>  
>> +
>> +
>> +  
>> + This event is sent whenever a new pad is known to the system. 
>> Typically,
>> + pads are physically attached to tablets and a pad_added event is
>> + sent immediately after the wp_tablet_seat.tablet_added.
>> + However, some standalone pad devices logically attach to tablets at
>> + runtime, and the client must wait for wp_tablet_pad.enter to know
>> + the tablet a pad is attached to.
>> +
>> + This event only provides the object id of the pad. All further
>> + features (buttons, strips, rings) are sent through the wp_tablet_pad
>> + interface.
>> +  
>> +  > summary="the newly added pad"/>
>> +
>>
>>
>>
>> @@ -508,9 +524,9 @@
>>
>>   Sent whenever the wheel on the tool emits an event. This event
>>   contains two values for the same axis change. The degrees value is
>> - in degrees in the same orientation as the wl_pointer.vertical_scroll
>> - axis. The clicks value is in discrete logical clicks of the mouse
>> - wheel. This value may be zero if the movement of the wheel was less
>> + in the same orientation as the wl_pointer.vertical_scroll axis. The
>> + clicks value is in discrete logical clicks of the mouse wheel. This
>> + value may be zero if the movement of the wheel was less
>
> This change seems unrelated.

It indeed is...

>
>>   than one logical click.
>>
>>   Clients should choose either value and avoid mixing degrees and
>> @@ -636,4 +652,528 @@
>>  
>>
>>
&g

Re: [PATCH v4 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Carlos Garnacho]

Hi!,

On Thu, Jun 30, 2016 at 5:27 AM, Peter Hutterer
<peter.hutte...@who-t.net> wrote:
> On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote:
>> The pad's interface is similar to the tool interface, a client is notified of
>> the pad after the tablet_added event.
>>
>> The pad has three functionalities: buttons, rings and strips.
>> Buttons are fairly straightforward, rings and strips are separate interfaces
>> with a pointer-axis-like source/value/frame events.
>> The two interfaces are effectively identical but for the actual value they
>> send (degrees vs normalized position).
>>
>> Buttons are sequentially indexed starting with zero, unlike other protocols
>> where a linux/input.h-style semantic event code is used. Since we expect all
>> buttons to have client-specific functionality, an additional event tells the
>> client when a given button index is not available, usually because the
>> compositor assignes some function to it (e.g. mode switching, see below).
>>
>> Specific to the pad device is the set_feedback request which enables a client
>> to set a user-defined string to display for an OSD on the current mappings.
>> This request is available for buttons, rings and strips.
>>
>> Finally, the pad supports groups, effectively sets of button/ring/strip
>> configurations. Those groups may have multiple modes each, so that
>> users/clients may map several actions to a single element.
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
>> Reviewed-by: Jason Gerecke <jason.gere...@wacom.com>
>> ---
>>
>> Changes since v3:
>>
>> - Added wp_tablet_pad_group, this divides buttons/strips/rings into subsets,
>>   groups may have separate modes which are announced through a mode_switch
>>   event.
>> - Added serial argument to the set_feedback requests, to be obtained from
>>   the wp_tablet_pad_group.mode_switch events.
>> - Now that groups announce the buttons belonging to those, the
>>   wp_tablet_pad.buttons_reserved event has been removed in favor of implicit
>>   information (i.e. buttons not belonging to any group are reserved by the
>>   compositor).
>> - Added wp_tablet_pad.path event, similar to wp_tablet.path
>> - Button indices are now explicitly mentioned in docs where relevant
>> - Fixed several typos and improved docs here and there
>>
>>  unstable/tablet/tablet-unstable-v2.xml | 546 
>> -
>>  1 file changed, 543 insertions(+), 3 deletions(-)
>>
>> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
>> b/unstable/tablet/tablet-unstable-v2.xml
>> index 5248c64..63172e2 100644
>> --- a/unstable/tablet/tablet-unstable-v2.xml
>> +++ b/unstable/tablet/tablet-unstable-v2.xml
>> @@ -172,6 +172,22 @@
>>
>>> summary="the newly added tablet tool"/>
>>  
>> +
>> +
>> +  
>> + This event is sent whenever a new pad is known to the system. 
>> Typically,
>> + pads are physically attached to tablets and a pad_added event is
>> + sent immediately after the wp_tablet_seat.tablet_added.
>> + However, some standalone pad devices logically attach to tablets at
>> + runtime, and the client must wait for wp_tablet_pad.enter to know
>> + the tablet a pad is attached to.
>> +
>> + This event only provides the object id of the pad. All further
>> + features (buttons, strips, rings) are sent through the wp_tablet_pad
>> + interface.
>> +  
>> +  > summary="the newly added pad"/>
>> +
>>
>>
>>
>> @@ -508,9 +524,9 @@
>>
>>   Sent whenever the wheel on the tool emits an event. This event
>>   contains two values for the same axis change. The degrees value is
>> - in degrees in the same orientation as the wl_pointer.vertical_scroll
>> - axis. The clicks value is in discrete logical clicks of the mouse
>> - wheel. This value may be zero if the movement of the wheel was less
>> + in the same orientation as the wl_pointer.vertical_scroll axis. The
>> + clicks value is in discrete logical clicks of the mouse wheel. This
>> + value may be zero if the movement of the wheel was less
>>   than one logical click.
>
> this hunk looks like rebase detritus

Oops, it indeed is. Now I wonder which of your earlier patches this
belonged to...

>>
>>   Clients should choose either value and avoid mixing degrees a

[PATCH v4 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Carlos Garnacho]

The pad's interface is similar to the tool interface, a client is notified of
the pad after the tablet_added event.

The pad has three functionalities: buttons, rings and strips.
Buttons are fairly straightforward, rings and strips are separate interfaces
with a pointer-axis-like source/value/frame events.
The two interfaces are effectively identical but for the actual value they
send (degrees vs normalized position).

Buttons are sequentially indexed starting with zero, unlike other protocols
where a linux/input.h-style semantic event code is used. Since we expect all
buttons to have client-specific functionality, an additional event tells the
client when a given button index is not available, usually because the
compositor assignes some function to it (e.g. mode switching, see below).

Specific to the pad device is the set_feedback request which enables a client
to set a user-defined string to display for an OSD on the current mappings.
This request is available for buttons, rings and strips.

Finally, the pad supports groups, effectively sets of button/ring/strip
configurations. Those groups may have multiple modes each, so that
users/clients may map several actions to a single element.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Jason Gerecke <jason.gere...@wacom.com>
---

Changes since v3:

- Added wp_tablet_pad_group, this divides buttons/strips/rings into subsets,
  groups may have separate modes which are announced through a mode_switch
  event.
- Added serial argument to the set_feedback requests, to be obtained from
  the wp_tablet_pad_group.mode_switch events.
- Now that groups announce the buttons belonging to those, the
  wp_tablet_pad.buttons_reserved event has been removed in favor of implicit
  information (i.e. buttons not belonging to any group are reserved by the
  compositor).
- Added wp_tablet_pad.path event, similar to wp_tablet.path
- Button indices are now explicitly mentioned in docs where relevant
- Fixed several typos and improved docs here and there

 unstable/tablet/tablet-unstable-v2.xml | 546 -
 1 file changed, 543 insertions(+), 3 deletions(-)

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index 5248c64..63172e2 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -172,6 +172,22 @@
   
   
 
+
+
+  
+   This event is sent whenever a new pad is known to the system. Typically,
+   pads are physically attached to tablets and a pad_added event is
+   sent immediately after the wp_tablet_seat.tablet_added.
+   However, some standalone pad devices logically attach to tablets at
+   runtime, and the client must wait for wp_tablet_pad.enter to know
+   the tablet a pad is attached to.
+
+   This event only provides the object id of the pad. All further
+   features (buttons, strips, rings) are sent through the wp_tablet_pad
+   interface.
+  
+  
+
   
 
   
@@ -508,9 +524,9 @@
   
Sent whenever the wheel on the tool emits an event. This event
contains two values for the same axis change. The degrees value is
-   in degrees in the same orientation as the wl_pointer.vertical_scroll
-   axis. The clicks value is in discrete logical clicks of the mouse
-   wheel. This value may be zero if the movement of the wheel was less
+   in the same orientation as the wl_pointer.vertical_scroll axis. The
+   clicks value is in discrete logical clicks of the mouse wheel. This
+   value may be zero if the movement of the wheel was less
than one logical click.
 
Clients should choose either value and avoid mixing degrees and
@@ -636,4 +652,528 @@
 
   
 
+  
+
+  A circular interaction area.
+
+  Events on a ring are logically grouped by the wl_tablet_pad_ring.frame
+  event.
+
+
+
+  
+   Request that the compositor use the provided feedback string
+   associated with this ring. This request should be issued immediately
+   after a wp_tablet_pad.enter, or whenever the ring is mapped to a
+   different action.
+
+   Clients are encouraged to provide context-aware descriptions for
+   the actions associated with the ring; compositors may use this
+   information to offer visual feedback about the button layout
+   (eg. on-screen displays).
+
+   The provided string 'description' is a UTF-8 encoded string to be
+   associated with this ring, and is considered user-visible; general
+   internationalization rules apply.
+
+   The serial argument will be that of the last
+   wp_tablet_pad_group.mode_switch event received for the group of this
+   ring. Requests providing other serials than the most recent one will 

Re: [PATCH wayland-protocols v7] text: Create second version of text input protocol

[Carlos Garnacho]

Hi Jan Arne!,

Chiming in, and kinda late at that... hopefully we'll get this moving :).

First of all, I'm aware that some of my comments are directed towards
stuff that's unchanged between v1 and v2, so please bear with me, I
hope the feedback is useful.

On Mon, May 30, 2016 at 11:41 AM, Jan Arne Petersen  wrote:
> There were some shortcomings in the first version of the protocol which
> makes it not really useful in real world applications. It is not really
> possible to fix them in a compatible way so introduce a new v2 of the
> protocol.
>
> Fixes some shortcomings of the first version:
>
> * Use only one wp_text_input per wl_seat (client side should be
>   handled by client toolkit)
> * Allow focus tracking without wl_keyboard present
> * Improve update state handling and better define state handling
> ---
> Changes to v6:
> * Fix some typos
>
>  Makefile.am|   1 +
>  unstable/text-input/text-input-unstable-v2.xml | 480 
> +
>  2 files changed, 481 insertions(+)
>  create mode 100644 unstable/text-input/text-input-unstable-v2.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 71d2632..cc8d531 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3,6 +3,7 @@ unstable_protocols =  
>   \
> unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
>   \
> unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>   \
> unstable/text-input/text-input-unstable-v1.xml
>   \
> +   unstable/text-input/text-input-unstable-v2.xml
>   \
> unstable/input-method/input-method-unstable-v1.xml
>   \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml  
>   \
> unstable/relative-pointer/relative-pointer-unstable-v1.xml
>   \
> diff --git a/unstable/text-input/text-input-unstable-v2.xml 
> b/unstable/text-input/text-input-unstable-v2.xml
> new file mode 100644
> index 000..ea35d9b
> --- /dev/null
> +++ b/unstable/text-input/text-input-unstable-v2.xml
> @@ -0,0 +1,480 @@
> +
> +
> +
> +  
> +Copyright © 2012, 2013 Intel Corporation
> +Copyright © 2015, 2016 Jan Arne Petersen
> +
> +Permission to use, copy, modify, distribute, and sell this
> +software and its documentation for any purpose is hereby granted
> +without fee, provided that the above copyright notice appear in
> +all copies and that both that copyright notice and this permission
> +notice appear in supporting documentation, and that the name of
> +the copyright holders not be used in advertising or publicity
> +pertaining to distribution of the software without specific,
> +written prior permission.  The copyright holders make no
> +representations about the suitability of this software for any
> +purpose.  It is provided "as is" without express or implied
> +warranty.
> +
> +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
> +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> +THIS SOFTWARE.
> +  
> +
> +  
> +
> +  The zwp_text_input_v2 interface represents text input and input methods
> +  associated with a seat. It provides enter/leave events to follow the
> +  text input focus for a seat.
> +
> +  Requests are used to enable/disable the text-input object and set
> +  state information like surrounding and selected text or the content 
> type.
> +  The information about the entered text is sent to the text-input object
> +  via the pre-edit and commit events. Using this interface removes the 
> need
> +  for applications to directly process hardware key events and compose 
> text
> +  out of them.
> +
> +  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
> +  have to always point to the first byte of an UTF-8 encoded code point.
> +  Lengths are not allowed to contain just a part of an UTF-8 encoded code
> +  point.
> +
> +  State is sent by the state requests (set_surrounding_text,
> +  set_content_type, set_cursor_rectangle and set_preferred_language) and
> +  an update_state request. After an enter or an input_method_change event
> +  all state information is invalidated and needs to be resent from the
> +  client. A reset or entering a new widget on client side also
> +  invalidates all current state information.
> +
> +
> +
> +  
> +   Destroy the wp_text_input object. Also 

Re: [PATCH v3 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Carlos Garnacho]

Hey :),

On Wed, May 11, 2016 at 4:51 AM, Peter Hutterer
<peter.hutte...@who-t.net> wrote:
> From: Carlos Garnacho <carl...@gnome.org>
>
> The pad's interface is similar to the tool interface, a client is notified of
> the pad after the tablet_added event.
>
> The pad has three functionalities: buttons, rings and strips.
> Buttons are fairly straightforward, rings and strips are separate interfaces
> with a pointer-axis-like source/value/frame events.
> The two interfaces are effectively identical but for the actual value they
> send (degrees vs normalized position).
>
> Buttons are sequentially indexed starting with zero, unlike other protocols
> where a linux/input.h-style semantic event code is used. Since we expect all
> buttons to have client-specific functionality, an additional event tells the
> client when a given button index is not available, usually because the
> compositor assignes some function to it (e.g. mode switching, see below).
>
> Specific to the pad device is the set_feedback request which enables a client
> to set a user-defined string to display for an OSD on the current mappings.
> This request is available for buttons, rings and strips.
>
> Finally, the pad supports "modes", effectively sets of button/ring/strip
> configurations.
>
> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
> Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
> ---
> Changes to v2:
> - change to v2 of the protocol
> - various comments and suggestions for improved wording incorporated
> - ring is in wl_fixed degrees now (was int, in 0.01 of a degree)
> - button events changed to sequential indices
> - new buttons_reserved event
>
>  unstable/tablet/tablet-unstable-v2.xml | 436 
> +
>  1 file changed, 436 insertions(+)
>
> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
> b/unstable/tablet/tablet-unstable-v2.xml
> index d3f57ff..388b4d2 100644
> --- a/unstable/tablet/tablet-unstable-v2.xml
> +++ b/unstable/tablet/tablet-unstable-v2.xml
> @@ -172,6 +172,22 @@
>
> summary="the newly added tablet tool"/>
>  
> +
> +
> +  
> +   This event is sent whenever a new pad is known to the system. 
> Typically,
> +   pads are physically attached to tablets and a pad_added event is
> +   sent immediately after the wp_tablet_seat.tablet_added.
> +   However, some standalone pad devices logically attach to tablets at
> +   runtime, and the client must wait for wp_tablet_pad.enter to know
> +   the tablet a pad is attached to.
> +
> +   This event only provides the object id of the pad; and all further
> +   features (buttons, strips, rings) are sent through the wp_tablet_pad
> +   interface.
> +  
> +   summary="the newly added pad"/>
> +
>
>
>
> @@ -636,4 +652,424 @@
>  
>
>
> +  
> +
> +  A circular interaction area.
> +
> +  Events on a ring are logically grouped by the wl_tablet_pad_ring.frame
> +  event.
> +
> +
> +
> +  
> +   Request that the compositor use the provided feedback string
> +   associated with this ring. This request should be issued immediately
> +   after a wp_tablet_pad.enter, or whenever the ring is mapped to a
> +   different action.
> +
> +   Clients are encouraged to provide context-aware descriptions for
> +   the actions associated with the ring; compositors may use this
> +   information to offer visual feedback about the button layout
> +   (eg. on-screen displays).
> +
> +   The provided string 'description' is an UTF-8 encoded string to be
> +   associated with this ring, and is considered user visible; general
> +   internationalization rules apply.
> +  
> +  
> +
> +
> +
> +  
> +   This destroys the client's resource for this ring object.
> +  
> +
> +
> +
> +  
> +   Describes the source types for ring events. This indicates to the
> +   client how a ring event was physically generated; a client may
> +   adjust the user interface accordingly. For example, events
> +   from a "finger" source may trigger kinetic scrolling.
> +  
> +  
> +
> +
> +
> +  
> +   Source information for ring events.
> +
> +   This event does not occur on its own. It is sent before a
> +   wp_tablet_pad_ring.frame event and carries the source information
> +   for all events within that frame.
> +
> +   The source specifies how this event was generated. If the sour

Re: [PATCH v2 wayland-protocols] Add pad support to the tablet protocol

[Carlos Garnacho]

Hi!,

On Fri, Apr 22, 2016 at 4:02 AM, Peter Hutterer
<peter.hutte...@who-t.net> wrote:
> On Thu, Apr 21, 2016 at 05:46:24PM -0700, Jason Gerecke wrote:
>> On Mon, Apr 18, 2016 at 10:00 PM, Peter Hutterer
>> <peter.hutte...@who-t.net> wrote:
>> > From: Carlos Garnacho <carl...@gnome.org>
>> >
>> > The pad's interface is similar to the tool interface, a client is notified 
>> > of
>> > the pad after the tablet_added event.
>> >
>> > The pad has three functionalities: buttons, rings and strips.
>> > Buttons are fairly straightforward, rings and strips are separate 
>> > interfaces
>> > with a pointer-axis-like source/value/frame events.
>> > The two interfaces are effectively identical but for the actual value they
>> > send (degrees vs normalized position).
>> >
>> > Specific to the pad device is the set_feedback request which enables a 
>> > client
>> > to set a user-defined string to display for an OSD on the current mappings.
>> > This request is available for buttons, rings and strips.
>> >
>> > Finally, the pad supports "modes", effectively sets of button/ring/strip
>> > configurations.
>> >
>> > Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> > Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
>> > ---
>> > Changes to v1:
>> > - typos fixed
>> >
>> >  unstable/tablet/tablet-unstable-v1.xml | 423 
>> > -
>> >  1 file changed, 421 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/unstable/tablet/tablet-unstable-v1.xml 
>> > b/unstable/tablet/tablet-unstable-v1.xml
>> > index 907126c..36b9ae8 100644
>> > --- a/unstable/tablet/tablet-unstable-v1.xml
>> > +++ b/unstable/tablet/tablet-unstable-v1.xml
>> > @@ -115,7 +115,7 @@
>> >  interface version number is reset.
>> >
>> >
>> > -  
>> > +  
>> >  
>> >An object that provides access to the graphics tablets available on 
>> > this
>> >system. All tablets are associated with a seat, to get access to the
>> > @@ -139,7 +139,7 @@
>> >  
>> >
>> >
>> > -  
>> > +  
>> >  
>> >An object that provides access to the graphics tablets available on 
>> > this
>> >seat. After binding to this interface, the compositor sends a set of
>> > @@ -172,6 +172,23 @@
>> >
>> >> > summary="the newly added tablet tool"/>
>> >  
>> > +
>> > +
>> > +
>> > +
>> > +  
>> > +   This event is sent whenever a new pad is known to the system. 
>> > Typically,
>> > +   pads are physically attached to tablets and a pad_added event is
>> > +   sent immediately after the wp_tablet_seat.tablet_added.
>> > +   However, some standalone pad devices logically attach to tablets at
>> > +   runtime, the client must wait for wp_tablet_pad.enter to know the
>> > +   tablet a pad is attached to.
>> > +
>>
>> If a compositor wanted to support "bare" pad devices, I'm assuming
>> they'd have to fake one or more wp_tablet objects for that use,
>> correct?
>
> yeah, I think so. but there is the question of what a standalone pad (I
> assume you're talking about the EKR) would do in a wacom/tablet context?
> and whether the EKR would just be better off as a buttonset device when it's
> not connected to a tablet.
>
>> > +
>> > +  
>> > +   Source information for ring events.
>> > +
>> > +   This event does not occur on its own. It is sent before a
>> > +   wp_tablet_pad_ring.frame event and carries the source information
>> > +   for all events within that frame.
>> > +
>> > +   The source specifies how this event was generated. If the source is
>> > +   wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event
>> > +   will be sent when the user lifts the finger off the device.
>> > +
>> > +   This event is optional. If the source is unknown for an 
>> > interaction,
>> > +   no event is sent.
>> > +  
>> > +  
>> > +
>> > +
>> > +
>> > +  
>> > +   Sent whenever the angle on a ring changes.
>> > +
>

Re: [PATCH weston 3/4] data-device: Update current action even if source version is old

[Carlos Garnacho]

Hi!,

On Thu, Apr 21, 2016 at 5:09 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> If the version of the source object is old enough to not have
> wl_data_source.set_actions() the current action would never be updated
> since source->set_actions would never be set.
>
> To fix this, instead of checking whether source->set_actions before
> proceeding with updating the current action, just always update the
> action when we know all parts are valid dnd data device objects.

Totally makes sense.

Reviewed-by: Carlos Garnacho <carl...@gnome.org>

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 libinput 0/5] Add tablet pad support

[Carlos Garnacho]

Hi!,

On Mon, Apr 11, 2016 at 5:15 AM, Peter Hutterer
<peter.hutte...@who-t.net> wrote:
>
> Second version of the tablet pad support patches. The main change is
> switching from button codes to simple button numbers. This is motivated
> by the fact that most buttons don't have any actual meaning and the only
> reason we have something other than BTN_0, BTN_1 etc is that we run out of
> space in the kernel's event code range. What a button does is defined
> largely by the client anyway.
>
> This also caused the removal of the seat button count and a change from
> libinput_event_tablet_pad_get_button() to the more explicitly named
> libinput_event_tablet_pad_get_button_number(). Just to drive the point home.

The whole series look great to me, just the small glitch I pointed out
in 1/5. Other than that, the whole series is:

Reviewed-by: Carlos Garnacho <carl...@gnome.org>

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 libinput 1/5] tablet: move the libwacom check for left-handed-ness into a helper function

[Carlos Garnacho]

Hey!,

On Mon, Apr 11, 2016 at 5:15 AM, Peter Hutterer
 wrote:
> Signed-off-by: Peter Hutterer 
> ---
> Changes since v1:
> - new in this version
>
>  src/evdev-tablet.c | 38 +-
>  src/evdev.c| 52 
>  src/evdev.h|  3 +++
>  3 files changed, 56 insertions(+), 37 deletions(-)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 9a1ac52..3c3ebcf 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -1571,45 +1571,9 @@ tablet_init_accel(struct tablet_dispatch *tablet, 
> struct evdev_device *device)
>  static void
>  tablet_init_left_handed(struct evdev_device *device)
>  {
> -#if HAVE_LIBWACOM
> -   struct libinput *libinput = device->base.seat->libinput;
> -   WacomDeviceDatabase *db;
> -   WacomDevice *d = NULL;
> -   WacomError *error;
> -   const char *devnode;
> -
> -   db = libwacom_database_new();
> -   if (!db) {
> -   log_info(libinput,
> -"Failed to initialize libwacom context.\n");
> -   return;
> -   }
> -   error = libwacom_error_new();
> -   devnode = udev_device_get_devnode(device->udev_device);
> -
> -   d = libwacom_new_from_path(db,
> -  devnode,
> -  WFALLBACK_NONE,
> -  error);
> -
> -   if (d) {
> -   if (libwacom_is_reversible(d))
> +   if (evdev_tablet_has_left_handed(device))
> evdev_init_left_handed(device,
>tablet_change_to_left_handed);
> -   } else if (libwacom_error_get_code(error) == WERROR_UNKNOWN_MODEL) {
> -   log_info(libinput, "Tablet unknown to libwacom\n");
> -   } else {
> -   log_error(libinput,
> - "libwacom error: %s\n",
> - libwacom_error_get_message(error));
> -   }
> -
> -   if (error)
> -   libwacom_error_free();
> -   if (d)
> -   libwacom_destroy(d);
> -   libwacom_database_destroy(db);
> -#endif
>  }
>
>  static int
> diff --git a/src/evdev.c b/src/evdev.c
> index 6bb8986..a5511c5 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -43,6 +43,10 @@
>  #include "filter.h"
>  #include "libinput-private.h"
>
> +#if HAVE_LIBWACOM
> +#include 
> +#endif
> +
>  #define DEFAULT_WHEEL_CLICK_ANGLE 15
>  #define DEFAULT_MIDDLE_BUTTON_SCROLL_TIMEOUT ms2us(200)
>
> @@ -2858,3 +2862,51 @@ evdev_device_destroy(struct evdev_device *device)
> free(device->mt.slots);
> free(device);
>  }
> +
> +bool
> +evdev_tablet_has_left_handed(struct evdev_device *device)
> +{
> +#if HAVE_LIBWACOM
> +   struct libinput *libinput = device->base.seat->libinput;
> +   WacomDeviceDatabase *db;
> +   WacomDevice *d = NULL;
> +   WacomError *error;
> +   const char *devnode;
> +   bool has_left_handed = false;
> +
> +   db = libwacom_database_new();
> +   if (!db) {
> +   log_info(libinput,
> +"Failed to initialize libwacom context.\n");
> +   goto out;
> +   }
> +
> +   error = libwacom_error_new();
> +   devnode = udev_device_get_devnode(device->udev_device);
> +
> +   d = libwacom_new_from_path(db,
> +  devnode,
> +  WFALLBACK_NONE,
> +  error);
> +
> +   if (d) {
> +   if (libwacom_is_reversible(d))
> +   has_left_handed = true;
> +   } else if (libwacom_error_get_code(error) == WERROR_UNKNOWN_MODEL) {
> +   log_info(libinput, "Tablet unknown to libwacom\n");
> +   } else {
> +   log_error(libinput,
> + "libwacom error: %s\n",
> + libwacom_error_get_message(error));
> +   }
> +
> +   if (error)
> +   libwacom_error_free();
> +   if (d)
> +   libwacom_destroy(d);
> +   libwacom_database_destroy(db);
> +
> +out:
> +   return has_left_handed;
> +#endif
> +}

This function should have a return value (I guess false is safe?) if
HAVE_LIBWACOM is not defined.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] tablet: fix the airbrush slider range

[Carlos Garnacho]

Hey!,

On Mon, Apr 11, 2016 at 1:32 AM, Peter Hutterer
<peter.hutte...@who-t.net> wrote:
> Supposed to be [-1, 1] but we only generated [0, 1]
>
> Reported-by: Carlos Garnacho <carl...@gnome.org>
> Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>

Also:
Tested-by: Carlos Garnacho <carl...@gnome.org>

Thanks :),
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v7 wayland-protocols] Add the tablet protocol

[Carlos Garnacho]

Hey :),

On Thu, Mar 31, 2016 at 9:32 AM, Peter Hutterer
 wrote:
> sorry about the delay, this one slipped through
>
> On Fri, Mar 11, 2016 at 04:12:55PM -0800, Jason Gerecke wrote:
>> On 03/08/2016 10:10 PM, Peter Hutterer wrote:
>> > Signed-off-by: Peter Hutterer 
>> > Reviewed-by: Daniel Stone 
>> > Reviewed-by: Jonas Ådahl 
>> > ---
>> > Changes to v6:
>> > - a bunch of typos/grammar fixes
>> > - clarified the "down" event on enter
>> > - clarified the "up" event, specifically: the up event isn't sent when the
>> >   tool leaves the input region but rather when the compositor deems it's up
>> >
>
> [...]
>
>> > +
>> > +   Clients should choose either value and avoid mixing degrees and
>> > +   clicks. The compositor may accumulate values smaller than a logical
>> > +   click and emulate click events when a certain threshold is met.
>> > +   Thus, wl_tablet_tool.wheel events with non-zero clicks values may
>> > +   have different degrees values.
>> > +  
>> > +  
>> > +  
>> > +
>>
>> I just noticed this while working on the Xwayland implementation -- is
>> there a reason the angles (in tilt, rotation, and here in wheel) aren't
>> just using the "fixed" type? If its a wart, it might be one to remove
>> before too long now that v1 has made it upstream...
>
> hmm, good point, not sure why I didn't use wl_fixed other than "i didn't
> think of it". It has finer granularity and provides the required range, so
> it would be the better choice. This is something to fix in a new version
> though :(
>
> Carlos, any yay/nay comments for the GTK side?

It indeed makes sense, I also missed this after we started using
angles for those. I guess this just means v2 will get its own file to
keep ahead with the incompatible change, so be it...

Cheers,
  Carlos

>
> Cheers,
>Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] xdg-shell: Add startup notification

[Carlos Garnacho]

Hey :),

On Fri, Feb 26, 2016 at 1:54 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Mon, 15 Feb 2016 16:59:02 +0800
> Jonas Ådahl <jad...@gmail.com> wrote:
>
>> On Thu, Feb 11, 2016 at 01:52:36PM +0100, Carlos Garnacho wrote:
>> > The xdg_launcher interface is added for the launcher, it's used
>> > to notify of the startup ID to be transmitted to the launchee,
>> > plus notifications about the startup success/failure.
>> >
>> > On the launchee side, we now have xdg_shell.set_startup_id,
>> > which will notify the compositor of startup finalization.
>> >
>> > This has been made to be compatible with the XDG Startup
>> > Notification spec available for X11, the startup ID is
>> > transmitted from the launcher to the launchee in the same
>> > ways, so we can launch x11 from wayland applications and
>> > viceversa. The notable difference is that wayland launchers
>> > receive startup IDs that are guaranteed to be unique, whereas
>> > in X11 this is a best effort of the launcher client.
>> >
>> > Some notes have also been added about focus stealing prevention,
>> > although that's mostly up for compositors to implement.
>> >
>> > Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> > ---
>> >
>> > I've got no full implementations yet, so this is mostly an RFC at the
>> > moment. I mainly wonder, should we add a "serial" argument to the
>> > create_launcher request? that'd at least ensure the launcher application
>> > has some sort of focus, although nothing prevents an application from
>> > being a fork bomb otherwise.
>>
>> Hey,
>>
>> I assume the compositor would have to limit to one startup per event
>> or something like that if you add the serial? Doesn't seem to prevent
>> fork bombs anyhow, the client can still fork as much as it wants. What
>> it does limit is, say, opening an application as a response to not-user
>> interaction. I don't have any reasonable use cases except remote
>> controlled clients not being able to do this properly.

Yeah, and the extent is kind of limited, the compositor should time
out requests at some point anyway for legit reasons from its
perspective (eg. the launched app crashing, a bogus file in execvpe(),
...). One might argue that this is a way to trigger extra activity in
a compositor though...

>>
>> Overall, I'd like to see this being added as a separate extension. The
>> reason is that I don't think this belongs in a "core" xdg shell
>> interface, which we should try to keep as minimal as reasonable. It
>> could for example be a "xdg_startup_notification" global (well,
>> zxdg_startup_notification_v1 until later), which contains the requests
>> you added to xdg_shell.
>>
>> >
>> >  unstable/xdg-shell/xdg-shell-unstable-v5.xml | 71 
>> > +++-
>> >  1 file changed, 70 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml 
>> > b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> > index 542491f..1c4ef54 100644
>> > --- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> > @@ -27,7 +27,7 @@
>> >  DEALINGS IN THE SOFTWARE.
>> >
>> >
>> > -  
>> > +  
>> >  
>> >xdg_shell allows clients to turn a wl_surface into a "real window"
>> >which can be dragged, resized, stacked, and moved around by the
>> > @@ -135,6 +135,35 @@
>> >
>> >
>> >  
>> > +
>> > +
>> > +
>> > +  
>> > +Creates a new launcher context.
>> > +
>> > +The surface argument is the toplevel where the application
>> > +was launched from, compositors may want to place the launched
>> > +application relative to the launcher surface.
>> > +
>> > +Compositors that desire to implement focus stealing prevention
>> > +can mark the time this request is received as the "startup" time.
>>
>> Not sure paragraph this belongs here. Compositors may do more things,
>> and doesn't seem to be useful to list those things here. Maybe it would
>> be good to add some high level blurb about how focus stealing prevention
>> could be done in some generic place (for example  in
>>  if it's its own extension protocol).
>>
>> > +

Re: [PATCH wayland-protocols] xdg-shell: Add startup notification

[Carlos Garnacho]

Hey :),

On Mon, Feb 15, 2016 at 9:59 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Thu, Feb 11, 2016 at 01:52:36PM +0100, Carlos Garnacho wrote:
>> The xdg_launcher interface is added for the launcher, it's used
>> to notify of the startup ID to be transmitted to the launchee,
>> plus notifications about the startup success/failure.
>>
>> On the launchee side, we now have xdg_shell.set_startup_id,
>> which will notify the compositor of startup finalization.
>>
>> This has been made to be compatible with the XDG Startup
>> Notification spec available for X11, the startup ID is
>> transmitted from the launcher to the launchee in the same
>> ways, so we can launch x11 from wayland applications and
>> viceversa. The notable difference is that wayland launchers
>> receive startup IDs that are guaranteed to be unique, whereas
>> in X11 this is a best effort of the launcher client.
>>
>> Some notes have also been added about focus stealing prevention,
>> although that's mostly up for compositors to implement.
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> ---
>>
>> I've got no full implementations yet, so this is mostly an RFC at the
>> moment. I mainly wonder, should we add a "serial" argument to the
>> create_launcher request? that'd at least ensure the launcher application
>> has some sort of focus, although nothing prevents an application from
>> being a fork bomb otherwise.
>
> Hey,
>
> I assume the compositor would have to limit to one startup per event
> or something like that if you add the serial? Doesn't seem to prevent
> fork bombs anyhow, the client can still fork as much as it wants. What
> it does limit is, say, opening an application as a response to not-user
> interaction. I don't have any reasonable use cases except remote
> controlled clients not being able to do this properly.

Right, I guessed that'd prevent processes from being "fake startup"
bombs, but that seems somewhat light compared to the real thing :).

>
> Overall, I'd like to see this being added as a separate extension. The
> reason is that I don't think this belongs in a "core" xdg shell
> interface, which we should try to keep as minimal as reasonable. It
> could for example be a "xdg_startup_notification" global (well,
> zxdg_startup_notification_v1 until later), which contains the requests
> you added to xdg_shell.

Yeah, probably makes sense to have this as a separate protocol. I
guess it's safe to keep using xdg_surface in arguments, and rely that
this protocol shall be used together with xdg-shell?

>
>>
>>  unstable/xdg-shell/xdg-shell-unstable-v5.xml | 71 
>> +++-
>>  1 file changed, 70 insertions(+), 1 deletion(-)
>>
>> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml 
>> b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> index 542491f..1c4ef54 100644
>> --- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> +++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> @@ -27,7 +27,7 @@
>>  DEALINGS IN THE SOFTWARE.
>>
>>
>> -  
>> +  
>>  
>>xdg_shell allows clients to turn a wl_surface into a "real window"
>>which can be dragged, resized, stacked, and moved around by the
>> @@ -135,6 +135,35 @@
>>
>>
>>  
>> +
>> +
>> +
>> +  
>> +Creates a new launcher context.
>> +
>> +The surface argument is the toplevel where the application
>> +was launched from, compositors may want to place the launched
>> +application relative to the launcher surface.
>> +
>> +Compositors that desire to implement focus stealing prevention
>> +can mark the time this request is received as the "startup" time.
>
> Not sure paragraph this belongs here. Compositors may do more things,
> and doesn't seem to be useful to list those things here. Maybe it would
> be good to add some high level blurb about how focus stealing prevention
> could be done in some generic place (for example  in
>  if it's its own extension protocol).

Right.

>
>> +  
>> +  
>> +  
>> +
>> +
>> +
>> +  
>> +Notifies the compositor of the startup ID of this launched 
>> application.
>> +Applications will typically receive this through the 
>> DESKTOP_STARTUP_ID
>> +environment variable as set by its launcher, and should unset the
>> +environment variable right after this request, in order to avoid

[PATCH weston] xwayland: Create the drag-and-drop window in weston_wm_dnd_init

[Carlos Garnacho]

Just to keep it hidden so far... A lot of the plumbing necessary to
handle x11->wayland drag and drop is missing, and the current
partial handling gets in the middle for X11 drag-and-drop itself
to work.

The approach is well directed, but needs some further work, till
then, just keep our fake drag-and-drop target hidden. This allows
drag-and-drop to work between X11 clients in Xwayland, and avoids
a crash with (currently unhandled) wl_resource-less data sources.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=94218

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
---

I'm sending this patch with the promise to look into improving the
drag-and-drop interoperation situation at some point before 1.11.

My intention is copying what mutter is doing currently, and works
nicely there:
* Set up an special pointer grab that still relays pointer and
  keyboard events to the DnD X11 source client, needed as it's
  still driving DnD as X11 expects of it.
* Hook to motion events in that grab so we resize/move/map the
  fake DnD target window to have the same position than the
  wayland app the pointer is above. That'll make the X11 source
  side see  something consistent. This is why keeping
  wm->dnd_window around makes sense IMO.
* Reply appropriately to XdndPosition/XdndLeave/XdndDrop
  and translate those to the wayland side.

But at the moment, I'm doing just the minimals to avoid the crash,
and allow X11<->X11 drag-and-drop to work.

 xwayland/dnd.c | 70 --
 1 file changed, 24 insertions(+), 46 deletions(-)

diff --git a/xwayland/dnd.c b/xwayland/dnd.c
index f17e4cd..1130f56 100644
--- a/xwayland/dnd.c
+++ b/xwayland/dnd.c
@@ -42,45 +42,6 @@
 #include "compositor.h"
 #include "hash.h"
 
-static void
-weston_dnd_start(struct weston_wm *wm, xcb_window_t owner)
-{
-   uint32_t values[1], version = 4;
-
-   wm->dnd_window = xcb_generate_id(wm->conn);
-   values[0] =
-   XCB_EVENT_MASK_SUBSTRUCTURE_NOTIFY |
-   XCB_EVENT_MASK_PROPERTY_CHANGE;
-
-   xcb_create_window(wm->conn,
- XCB_COPY_FROM_PARENT,
- wm->dnd_window,
- wm->screen->root,
- 0, 0,
- 8192, 8192,
- 0,
- XCB_WINDOW_CLASS_INPUT_ONLY,
- wm->screen->root_visual,
- XCB_CW_EVENT_MASK, values);
-   xcb_change_property(wm->conn,
-   XCB_PROP_MODE_REPLACE,
-   wm->dnd_window,
-   wm->atom.xdnd_aware,
-   XCB_ATOM_ATOM,
-   32, /* format */
-   1, );
-
-   xcb_map_window(wm->conn, wm->dnd_window);
-   wm->dnd_owner = owner;
-}
-
-static void
-weston_dnd_stop(struct weston_wm *wm)
-{
-   xcb_destroy_window(wm->conn, wm->dnd_window);
-   wm->dnd_window = XCB_WINDOW_NONE;
-}
-
 struct dnd_data_source {
struct weston_data_source base;
struct weston_wm *wm;
@@ -233,12 +194,6 @@ weston_wm_handle_dnd_event(struct weston_wm *wm,
 
weston_log("XdndSelection owner: %d!\n",
   xfixes_selection_notify->owner);
-
-   if (xfixes_selection_notify->owner != XCB_WINDOW_NONE)
-   weston_dnd_start(wm, xfixes_selection_notify->owner);
-   else
-   weston_dnd_stop(wm);
-
return 1;
}
 
@@ -266,7 +221,7 @@ weston_wm_handle_dnd_event(struct weston_wm *wm,
 void
 weston_wm_dnd_init(struct weston_wm *wm)
 {
-   uint32_t mask;
+   uint32_t values[1], version = 4, mask;
 
mask =
XCB_XFIXES_SELECTION_EVENT_MASK_SET_SELECTION_OWNER |
@@ -274,4 +229,27 @@ weston_wm_dnd_init(struct weston_wm *wm)
XCB_XFIXES_SELECTION_EVENT_MASK_SELECTION_CLIENT_CLOSE;
xcb_xfixes_select_selection_input(wm->conn, wm->selection_window,
  wm->atom.xdnd_selection, mask);
+
+   wm->dnd_window = xcb_generate_id(wm->conn);
+   values[0] =
+   XCB_EVENT_MASK_SUBSTRUCTURE_NOTIFY |
+   XCB_EVENT_MASK_PROPERTY_CHANGE;
+
+   xcb_create_window(wm->conn,
+ XCB_COPY_FROM_PARENT,
+ wm->dnd_window,
+ wm->screen->root,
+ 0, 0,
+ 8192, 8192,
+ 0,
+ XCB_WINDOW_CLASS_INPUT_ONLY,
+ wm->screen->root_visual,
+ XCB_CW_EVENT_MASK, values);
+   xcb_change_property(wm->conn,
+   XCB_PROP_MODE

Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1

[Carlos Garnacho]

Hi Michal,

On Mon, Feb 22, 2016 at 4:53 PM, Michal Suchanek <hramr...@gmail.com> wrote:
> On 22 February 2016 at 15:57, Carlos Garnacho <carl...@gnome.org> wrote:
>> Hi Michal,
>>
>> On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek <hramr...@gmail.com> wrote:
>>> Hello,
>>>
>>> On 20 February 2016 at 01:31, Carlos Garnacho <carl...@gnome.org> wrote:
>>>
>>>> +
>>>> +  
>>>> +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
>>>
>>> Why keyboard focus?
>>>
>>> Since paste is done mainly using mouse this has nothing to do with
>>> keyboard focus.
>>
>> Doing this so allows us to behave just the same than we do with the
>> core protocol selection, slightly divergent protocols make sharing
>> code harder.
>>
>> Conceptually, it also makes some sense to me. I argue that a logical
>> "key" focus is needed in compositors, even on lack of wl_keyboard
>> capabilities. Things that IMO make sense to tie together in this
>> focus, per-seat are:
>> - wl_keyboard focus
>> - wp_text_input focus
>> - focus por (possibly several) pads/buttonsets
>> - clipboard selection
>> - primary selection
>>
>> Of course these are only guidelines, and compositors may attempt to
>> implement split foci for these. But still, selection should be tied to
>> some definite focus, the other option is broadcasting, and I'd very
>> much prefer not to do that.
>>
>> I may try to change the wording just to suggest it's loosely attached
>> to keyboard focus though.
>
> If you put an Insert sticker on your pad button and bind pasting to
> that pad button and the pad focus is not tied to keyboard focus you
> have potentially a problem there.

Right, that's why I suggest having those reunited in a single logical
focus. Anything else is plagued of corner cases.

>
>>
>>>
>>>> +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
>>>
>>> Why press event when it has an offer event to base the request on?
>>>
>>> There is no need to involve other unrelated events.
>>
>> IIRC The first protocol drafts attempted to limit the circumstances in
>> which a client could read the primary selection. This is a change of
>> approach.
>>
>>>
>>> IMHO the fact that the application receives ANY input event suffices.
>>> eg. a pointer entry event.
>>
>> Do you mean wl_pointer.enter should be enough to have the application
>> read the primary selection? seems open to data leaks to me.
>&g

Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1

[Carlos Garnacho]

Hi Michal,

On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek <hramr...@gmail.com> wrote:
> Hello,
>
> On 20 February 2016 at 01:31, Carlos Garnacho <carl...@gnome.org> wrote:
>
>> +
>> +  
>> +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
>
> Why keyboard focus?
>
> Since paste is done mainly using mouse this has nothing to do with
> keyboard focus.

Doing this so allows us to behave just the same than we do with the
core protocol selection, slightly divergent protocols make sharing
code harder.

Conceptually, it also makes some sense to me. I argue that a logical
"key" focus is needed in compositors, even on lack of wl_keyboard
capabilities. Things that IMO make sense to tie together in this
focus, per-seat are:
- wl_keyboard focus
- wp_text_input focus
- focus por (possibly several) pads/buttonsets
- clipboard selection
- primary selection

Of course these are only guidelines, and compositors may attempt to
implement split foci for these. But still, selection should be tied to
some definite focus, the other option is broadcasting, and I'd very
much prefer not to do that.

I may try to change the wording just to suggest it's loosely attached
to keyboard focus though.

>
>> +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
>
> Why press event when it has an offer event to base the request on?
>
> There is no need to involve other unrelated events.

IIRC The first protocol drafts attempted to limit the circumstances in
which a client could read the primary selection. This is a change of
approach.

>
> IMHO the fact that the application receives ANY input event suffices.
> eg. a pointer entry event.

Do you mean wl_pointer.enter should be enough to have the application
read the primary selection? seems open to data leaks to me.

This serial event is meant to check for user interaction rather than
"any input event", so just focusing a client is not enough to have it
retrieve the primary selection.

>
> Otherwise you are going to have very fragile protocol that often fails
> because the application did not happen to receive whatever even is
> requested by the protocol.

Note that it just mentions a press event, but does no mention of the
interface/device it comes from. It can be the serial received on
wl_pointer.button, wl_keyboard.key, wl_touch.down,
wp_tablet_tool.down, ...  compositors should ideally check all input
interfaces.

>
> It's even worse with the keyboard focus. If the event that triggers
> the paste also triggers getting keyboard focus you are going to have
> protocol open to all kind of ugly race conditions. If it does not
> trigger getting the keyboard focus the paste just fails.

Where do you see race conditions? Because focus is handled by the
compositor before event emission, AFAICT the client would receive the
following event sequence:

-->
wl_keyboard.enter
wl_data_device.data_offer
wl_data_offer.offer
[...]
wl_data_device.selection
zwp_primary_selection_device_v1.data_offer
zwp_primary_selection_off

[RFC wayland-protocols v4] Add Primary Selection Protocol Version 1

[Carlos Garnacho]

From: Lyude <cp...@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 <cp...@redhat.com>
Signed-off-by: Carlos Garnacho <carl...@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 000..6d8c0c6
--- /dev/null
+++ b/unstable/primary-selection/README
@@ -0,0 +1,4 @@
+Primary selection protocol
+
+Maintainers:
+Lyude 
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 000..a3618d5
--- /dev/null
+++ b/unstable/primary-selection/primary-selection-unstable-v1.xml
@@ -0,0 +1,229 @@
+
+
+  
+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.
+  
+
+  
+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 

Re: [PATCH weston v2 1/5] protocol: Add _wl_pointer_gestures (swipe/pinch) protocol

[Carlos Garnacho]

Hey Daniel :),

I see Jonas replied, I'll try to give some more detail.

On Thu, Feb 18, 2016 at 11:03 AM, Daniel Stone <dan...@fooishbar.org> wrote:
> Hi,
>
> On 31 July 2015 at 14:53, Carlos Garnacho <carl...@gnome.org> wrote:
>> On Wed, Jul 29, 2015 at 4:52 AM, Jonas Ådahl <jad...@gmail.com> wrote:
>>> On Thu, Jul 23, 2015 at 07:00:27PM +0200, Carlos Garnacho wrote:
>>>> +
>>>> +  
>>>> +
>>>> +  A global interface to provide semantic touchpad gestures for a given
>>>> +  pointer.
>>>> +
>>>> +  Two gestures are currently supported: swipe and zoom/rotate.
>>>> +  All gestures follow a three-stage cycle: begin, update, end and
>>>> +  are identified by a unique id.
>>>> +
>>>> +  Warning! The protocol described in this file is experimental. Each
>>>> +  version of this protocol should be considered incompatible with any
>>>> +  other version, and a client binding to a version different to the 
>>>> one
>>>> +  advertised will be terminated. Once the protocol is declared stable,
>>>> +  compatibility is guaranteed, the '_' prefix will be removed from the
>>>> +  name and the version will be reset to 1.
>>>> +
>>>> +
>>>> +
>>>> +  
>>>> + Create a swipe gesture object. See the
>>>> + wl_pointer_gesture_swipe interface for details.
>>>> +  
>>>> +  
>>>> +  
>>>> +
>>>> +
>>>> +
>>>> +  
>>>> + Create a pinch gesture object. See the
>>>> + wl_pointer_gesture_pinch interface for details.
>>>> +  
>>>> +  
>>>> +  
>>>> +
>>>> +  
>
> One suggestion I'd have is to register surfaces explicitly, i.e.:
> 
>   
> Adds the surface to the list of surfaces which will receive
> gesture events. Each surface may only be registered on one
> wl_gesture_manager object.
>   
>   
>   
> 
>
>>>> +  
>>>> +
>>>> +  A swipe gesture object notifies a client about a multi-finger swipe
>>>> +  gesture detected on an indirect input device such as a touchpad.
>>>> +  The gesture is usually initiated by multiple fingers moving in the
>>>> +  same direction but once initiated the direction may change.
>>>> +  The precise conditions of when such a gesture is detected are
>>>> +  implementation-dependent.
>>>> +
>>>> +  A gesture consists of three stages: begin, update (optional) and 
>>>> end.
>>>> +  There cannot be multiple simultaneous pinch or swipe gestures, how
>>>> +  compositors prevent these situations is implementation-dependent.
>>>
>>> There cannot be multiple simultaneous gestures one one seat. There can
>>> be multiple gestures but that means they are on different seats.
>>
>> Right, that's the idea. On multi-seat, there would be several
>> wl_pointers, and each could be able to perform gestures individually.
>> I reworded the docs blurb to be more specific there.
>
> That works for touchpads (what I assume this was designed against),
> but breaks for multitouch touchscreens: there you could be
> pinching/zooming/scrolling/etc in multiple areas at the same time. I'd
> prefer to see the individual gestures (swipe/etc) come in as new_id
> events, which would allow multiple simultaneous gestures.

As you point out in touchscreens you could be interacting with
multiple areas at the same time, to the point that 2 nearby touches on
a same surface might be happening on different widgets, and thus those
should be interpreted separately. Only if these happened on the same
widget should be interpreted as a 2-finger gesture, but it's something
the compositor just doesn't have enough context for.

So here I'm aiming for touchpad gestures only indeed, those are
directed to a single point (the pointer position), so can be sent
as-is to the client. The approach I took in gtk+ is wrapping these
touchpad gesture events with the same GtkGestureZoom/Rotate/Swipe
gestures that interpret touchscreen events, so the client-side end
result is that it doesn't matter the device the gesture is coming
from.

But you raise an interesting point though, I may have several
touchpads (eg. wacom tablets that handle touch also appear as giant
touchpads), and I could attempt to perform gestures simultaneously.
Anyhow, I think the compositor should prevent this 

[PATCH wayland-protocols] xdg-shell: Add startup notification

[Carlos Garnacho]

The xdg_launcher interface is added for the launcher, it's used
to notify of the startup ID to be transmitted to the launchee,
plus notifications about the startup success/failure.

On the launchee side, we now have xdg_shell.set_startup_id,
which will notify the compositor of startup finalization.

This has been made to be compatible with the XDG Startup
Notification spec available for X11, the startup ID is
transmitted from the launcher to the launchee in the same
ways, so we can launch x11 from wayland applications and
viceversa. The notable difference is that wayland launchers
receive startup IDs that are guaranteed to be unique, whereas
in X11 this is a best effort of the launcher client.

Some notes have also been added about focus stealing prevention,
although that's mostly up for compositors to implement.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
---

I've got no full implementations yet, so this is mostly an RFC at the
moment. I mainly wonder, should we add a "serial" argument to the
create_launcher request? that'd at least ensure the launcher application
has some sort of focus, although nothing prevents an application from
being a fork bomb otherwise.

 unstable/xdg-shell/xdg-shell-unstable-v5.xml | 71 +++-
 1 file changed, 70 insertions(+), 1 deletion(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
index 542491f..1c4ef54 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
@@ -27,7 +27,7 @@
 DEALINGS IN THE SOFTWARE.
   
 
-  
+  
 
   xdg_shell allows clients to turn a wl_surface into a "real window"
   which can be dragged, resized, stacked, and moved around by the
@@ -135,6 +135,35 @@
   
   
 
+
+
+
+  
+Creates a new launcher context.
+
+The surface argument is the toplevel where the application
+was launched from, compositors may want to place the launched
+application relative to the launcher surface.
+
+Compositors that desire to implement focus stealing prevention
+can mark the time this request is received as the "startup" time.
+  
+  
+  
+
+
+
+  
+Notifies the compositor of the startup ID of this launched application.
+Applications will typically receive this through the DESKTOP_STARTUP_ID
+environment variable as set by its launcher, and should unset the
+environment variable right after this request, in order to avoid
+propagating it to child processes.
+
+Compositors will ignore unknown startup IDs.
+  
+  
+
   
 
   
@@ -622,4 +651,44 @@
 
 
   
+
+  
+
+  xdg_launcher allows clients to get the necessary context to launch
+  applications, so the compositor can provide feedback about the
+  application being launched.
+
+
+
+  
+Destroys this xdg_launcher object.
+  
+
+
+
+  
+Notifies of an unique startup_id (eg. UUIDs) to be used for the
+application about to be launched.
+
+In order to guarantee interoperation with the XDG Startup Notification
+spec, this startup_id is recommended to be transmitted to the launched
+application through the DESKTOP_STARTUP_ID environment variable.
+  
+  
+
+
+
+  
+Notifies that the compositor is no longer watching this launched
+application.
+  
+
+
+
+  
+Notifies that the launched application successfully called
+xdg_shell.set_startup_id after startup.
+  
+
+  
 
-- 
2.5.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] test: add tablet test for out-of-bounds motion coordinates

[Carlos Garnacho]

Hey :),

On Thu, Feb 11, 2016 at 8:31 AM, Peter Hutterer
 wrote:
> The newer Cintiqs have a minimum value of 400/400 advertised by the kernel but
> the actual sensor goes past the 0/0 origin. Test this, make sure that a value
> outside the boundaries generates negative mm values.
>
> Signed-off-by: Peter Hutterer 
> ---
> Mostly just documenting this and adding a test. The behaviour is that any
> out-of-bounds motion may provide negative coordinates, when transformed may
> provide something outside the [0, max-range].
>
> Now, this is documenting the API behaviour. For the Cintiq I think it might
> be better to put a device-specific quirk in to simply supress those events
> since we don't have anything outside of these boundaries. Jason, Carlos, any
> comments?

I agree, reporting those would mean that such tablets could move
"outside" the crtc they're mapped to, even if not too far around the
borders. Although that same thought comes from any other tablet that
happens to behave the same. Not that we can preemptively add quirks
for these, but we probably should too when we know of these.

Cheers,
  Carlos

>
>  doc/svg/tablet-out-of-bounds.svg | 271 
> +++
>  doc/tablet-support.dox   |  22 
>  src/libinput.h   |  12 ++
>  test/tablet.c|  58 +
>  4 files changed, 363 insertions(+)
>  create mode 100644 doc/svg/tablet-out-of-bounds.svg
>
> diff --git a/doc/svg/tablet-out-of-bounds.svg 
> b/doc/svg/tablet-out-of-bounds.svg
> new file mode 100644
> index 000..83e5021
> --- /dev/null
> +++ b/doc/svg/tablet-out-of-bounds.svg
> @@ -0,0 +1,271 @@
> +
> +
> +
> + +   xmlns:dc="http://purl.org/dc/elements/1.1/;
> +   xmlns:cc="http://creativecommons.org/ns#;
> +   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
> +   xmlns:svg="http://www.w3.org/2000/svg;
> +   xmlns="http://www.w3.org/2000/svg;
> +   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
> +   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape;
> +   width="134.12477mm"
> +   height="73.121971mm"
> +   viewBox="0 0 475.24525 259.0936"
> +   id="svg2"
> +   version="1.1"
> +   inkscape:version="0.91 r13725"
> +   sodipodi:docname="tablet-out-of-bounds.svg">
> +   + id="defs4" />
> +   + id="base"
> + pagecolor="#ff"
> + bordercolor="#66"
> + borderopacity="1.0"
> + inkscape:pageopacity="0.0"
> + inkscape:pageshadow="2"
> + inkscape:zoom="5.6"
> + inkscape:cx="105.43109"
> + inkscape:cy="265.46934"
> + inkscape:document-units="px"
> + inkscape:current-layer="layer1"
> + showgrid="false"
> + showguides="true"
> + inkscape:guide-bbox="true"
> + inkscape:window-width="1920"
> + inkscape:window-height="1136"
> + inkscape:window-x="0"
> + inkscape:window-y="27"
> + inkscape:window-maximized="1"
> + fit-margin-top="0"
> + fit-margin-left="0"
> + fit-margin-right="0"
> + fit-margin-bottom="0">
> + +   position="63.6133,240.91614"
> +   orientation="0,1"
> +   id="guide4164" />
> + +   position="61.08792,13.126743"
> +   orientation="0,1"
> +   id="guide4166" />
> +  
> +   + id="metadata7">
> +
> +   + rdf:about="">
> +image/svg+xml
> + +   rdf:resource="http://purl.org/dc/dcmitype/StillImage; />
> +
> +  
> +
> +  
> +   + inkscape:label="tablet"
> + inkscape:groupmode="layer"
> + id="layer1"
> + style="display:inline"
> + transform="translate(-139.42736,-156.36219)">
> + +   
> style="opacity:0.9202;fill:#4d4d4d;fill-opacity:1;stroke:#4d4d4d;stroke-width:0.9201867;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:3.68074643,
>  0.92018661;stroke-dashoffset:0;stroke-opacity:1"
> +   id="rect4136"
> +   width="474.32504"
> +   height="258.1734"
> +   x="139.88745"
> +   y="156.82228"
> +   rx="5" />
> + +   y="175.42407"
> +   x="199.33878"
> +   height="226.52563"
> +   width="357.34042"
> +   id="rect4140"
> +   
> style="opacity:0.9202;fill:#a44d4d;fill-opacity:1;stroke:#4d4d4d;stroke-width:0.7483;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
>  />
> + +   id="g7041"
> +   transform="translate(12,0)">
> +   + transform="matrix(0.53265351,0,0,0.53265351,92.308091,96.440418)"
> + id="g7023">
> + +   
> style="opacity:0.9202;fill:#4d4d4d;fill-opacity:1;stroke:#4d4d4d;stroke-width:0.9892;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:3.956,
>  0.989;stroke-dashoffset:0;stroke-opacity:1"
> +   id="path4158"
> +   cx="135.61298"
> +   cy="287.06125"
> +   r="22.98097" />
> + +   cy="287.06125"
> +   cx="135.61298"
> +   

Re: [PATCH weston] xwm: Don't clear the selection if it has no text type available

[Carlos Garnacho]

Hi!,

On Mon, Feb 1, 2016 at 9:36 PM, Derek Foreman <der...@osg.samsung.com> wrote:
> weston maintains a copy of the most recently selected "thing" - it picks
> the first available type when it copies, and saves that one only.
>
> When an application quits weston will make the saved selection active.
>
> When xwm sees the selection set it will check if any of the offered types
> are text.  If no text type is offered it will clear the selection.
>
> weston then interprets this in the same way as an application exiting and
> causing the selection to be unset, and we get caught in a live lock with
> both weston and xwayland consuming as much cpu as they can.
>
> The simple fix is to just remove the test for text presence.
>
> Signed-off-by: Derek Foreman <der...@osg.samsung.com>
> ---
>
> This is kind of an alternate solution to the problem fixed in
> http://patchwork.freedesktop.org/patch/70435
>
> I don't understand why offers with no text type are cleared here,
> and couldn't find why with git blame either.  Anyone know why
> we've been doing this?

No idea myself, seems a rather arbitrary check. there shouldn't be any
reason this shouldn't work for other mimetypes offered.

>
> With this patch we can get somewhat odd behaviour - if terminology
> exits with a selection it can only be pasted into another terminology
> not a weston-terminal, because text wasn't the first offer and weston
> only saves the first offer.
>
> That seems better than a livelock though.  Maybe we can grab all available
> offers when cloning the selection instead of just the first (but that should
> be done in addition to this patch, I think, because we could have an app that
> doesn't offer text at all exit with a selection set and cause the same lock)

Reviewed-by: Carlos Garnacho <carl...@gnome.org>

I agree with the conclusion and the approach in this patch. As you say
the next step is storing all offers, but I guess it depends on how
deep we want weston to get into the clipboard manager role. AFAICS
that'd be most similar to how toolkits/apps used to behave wrt
SAVE_TARGETS as defined in the clipboard manager spec [1], where
simply all mimetypes would be stored (see eg. gtk_clipboard_store())

Cheers,
  Carlos

[1] http://www.freedesktop.org/wiki/ClipboardManager/

>
>
>  xwayland/selection.c | 28 
>  1 file changed, 4 insertions(+), 24 deletions(-)
>
> diff --git a/xwayland/selection.c b/xwayland/selection.c
> index 25ec848..24aa324 100644
> --- a/xwayland/selection.c
> +++ b/xwayland/selection.c
> @@ -655,8 +655,6 @@ weston_wm_set_selection(struct wl_listener *listener, 
> void *data)
> struct weston_wm *wm =
> container_of(listener, struct weston_wm, selection_listener);
> struct weston_data_source *source = seat->selection_data_source;
> -   const char **p, **end;
> -   int has_text_plain = 0;
>
> if (source == NULL) {
> if (wm->selection_owner == wm->selection_window)
> @@ -670,28 +668,10 @@ weston_wm_set_selection(struct wl_listener *listener, 
> void *data)
> if (source->send == data_source_send)
> return;
>
> -   p = source->mime_types.data;
> -   end = (const char **)
> -   ((char *) source->mime_types.data + source->mime_types.size);
> -   while (p < end) {
> -   weston_log("  %s\n", *p);
> -   if (strcmp(*p, "text/plain") == 0 ||
> -   strcmp(*p, "text/plain;charset=utf-8") == 0)
> -   has_text_plain = 1;
> -   p++;
> -   }
> -
> -   if (has_text_plain) {
> -   xcb_set_selection_owner(wm->conn,
> -   wm->selection_window,
> -   wm->atom.clipboard,
> -   XCB_TIME_CURRENT_TIME);
> -   } else {
> -   xcb_set_selection_owner(wm->conn,
> -   XCB_ATOM_NONE,
> -   wm->atom.clipboard,
> -   XCB_TIME_CURRENT_TIME);
> -   }
> +   xcb_set_selection_owner(wm->conn,
> +   wm->selection_window,
> +   wm->atom.clipboard,
> +   XCB_TIME_CURRENT_TIME);
>  }
>
>  void
> --
> 2.7.0
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols V3] Add Primary Selection Protocol Version 1

[Carlos Garnacho]

Hi!,

Chiming in late...

On Thu, Jan 7, 2016 at 3:50 AM, Lyude  wrote:
> Signed-off-by: Lyude 
> ---
>
> Notes:
> Changes since V2
> * Bunch of grammatical/wording fixes from whot
> * Addition of wp_primary_selection_offer::end_offers, for marking the end 
> of a
>   list of mime type offers
> * selection_offers are no longer sent before an input event, and are sent 
> at the
>   first opportunity a client has to do a primary selection paste. This 
> decision
>   comes from a discussion with Jasper, where a couple of clients (such as 
> emacs)
>   were brought up that have their own bindings for primary selection 
> pasting.
>   Eventually I will probably work on adding some sort of paste_hint event 
> to
>   this so that the compositor can decide what keybinding triggers a 
> primary
>   selection paste, I agree with Jasper that it would be best to solve the 
> issue
>   of rebinding primary selection pastes after we have the basic protocol 
> for
>   primary selection worked out.
>
>  Makefile.am|   1 +
>  unstable/primary-selection/README  |   4 +
>  .../primary-selection-unstable-v1.xml  | 176 
> +
>  3 files changed, 181 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 5926a41..582a49e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -5,6 +5,7 @@ unstable_protocols =  
>   \
> unstable/text-input/text-input-unstable-v1.xml
>   \
> unstable/input-method/input-method-unstable-v1.xml
>   \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml  
>   \
> +   unstable/primary-selection/primary-selection-unstable-v1.xml  
>   \
> $(NULL)
>
>  nobase_dist_pkgdata_DATA =   
>   \
> diff --git a/unstable/primary-selection/README 
> b/unstable/primary-selection/README
> new file mode 100644
> index 000..2dfce3d
> --- /dev/null
> +++ b/unstable/primary-selection/README
> @@ -0,0 +1,4 @@
> +Primary selection protocol
> +
> +Maintainers:
> +Lyude 
> 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 000..057ba38
> --- /dev/null
> +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml
> @@ -0,0 +1,176 @@
> +
> +
> +
> +  
> +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.
> +  
> +
> +  
> +
> +  Provides the ability to have a primary selection device to match that 
> of
> +  the X server. This allows users to select bodies of text, and then 
> paste
> +  them in another buffer without having to do the initial copy.
> +
> +  The primary selection device manager is also in charge of handling
> +  client's requests to indicate that text has been selected, along with
> +  handling clients access to selected text.
> +
> +
> +
> +  
> +Create a new primary selection source.
> +  
> +   interface="zwp_primary_selection_source_v1"/>
> +
> +
> +
> +  
> +Singleton global object that manages the 
> zwp_primary_selection_device_v1
> +objects for each wl_seat.
> +  
> +   interface="zwp_primary_selection_device_v1"/>
> +  
> +

The name of these two requests feel a bit redundant, they end up in:

[PATCH weston 2/3] xwayland: zalloc the x11_data_sources

[Carlos Garnacho]

The wrapped weston_data_source struct has new fields which were left
uninitialized, so its access is unreliable.

The data source in xwayland/dnd.c should be eventually setting the
drag-and-drop actions, but it is a lot more incomplete than that
(read: completely), so falls out of the scope of this patch.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
---
 xwayland/dnd.c   | 2 +-
 xwayland/selection.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xwayland/dnd.c b/xwayland/dnd.c
index a036b30..f17e4cd 100644
--- a/xwayland/dnd.c
+++ b/xwayland/dnd.c
@@ -162,7 +162,7 @@ handle_enter(struct weston_wm *wm, 
xcb_client_message_event_t *client_message)
xcb_get_property_cookie_t cookie;
xcb_get_property_reply_t *reply;
 
-   source = malloc(sizeof *source);
+   source = zalloc(sizeof *source);
if (source == NULL)
return;
 
diff --git a/xwayland/selection.c b/xwayland/selection.c
index 25ec848..3fcd578 100644
--- a/xwayland/selection.c
+++ b/xwayland/selection.c
@@ -197,7 +197,7 @@ weston_wm_get_selection_targets(struct weston_wm *wm)
return;
}
 
-   source = malloc(sizeof *source);
+   source = zalloc(sizeof *source);
if (source == NULL) {
free(reply);
return;
-- 
2.5.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 1/3] clipboard: zalloc the clipboard_source

[Carlos Garnacho]

The wrapped weston_data_source struct has new fields which were left
uninitialized, so its access is unreliable.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
---
 src/clipboard.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/clipboard.c b/src/clipboard.c
index da7dbb6..54a578f 100644
--- a/src/clipboard.c
+++ b/src/clipboard.c
@@ -141,7 +141,7 @@ clipboard_source_create(struct clipboard *clipboard,
struct clipboard_source *source;
char **s;
 
-   source = malloc(sizeof *source);
+   source = zalloc(sizeof *source);
if (source == NULL)
return NULL;
 
-- 
2.5.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 3/3] data-device: Check harder for selection/non-wayland sources

[Carlos Garnacho]

We're not always dealing with weston_data_sources that have a
wl_resource, or data_sources that belong to drag-and-drop. Check
harder for these on the drag-and-drop code paths triggered from
common code.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
---
 src/data-device.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/data-device.c b/src/data-device.c
index 2cfdcfe..862a4e0 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -100,6 +100,9 @@ data_offer_destroy(struct wl_client *client, struct 
wl_resource *resource)
 static void
 data_source_notify_finish(struct weston_data_source *source)
 {
+   if (!source->actions_set)
+   return;
+
if (source->offer->in_ask &&
wl_resource_get_version(source->resource) >=
WL_DATA_SOURCE_ACTION_SINCE_VERSION) {
@@ -157,7 +160,7 @@ data_offer_update_action(struct weston_data_offer *offer)
 {
uint32_t action;
 
-   if (!offer->source)
+   if (!offer->source || !offer->source->actions_set)
return;
 
action = data_offer_choose_action(offer);
@@ -268,7 +271,8 @@ destroy_data_offer(struct wl_resource *resource)
if (wl_resource_get_version(offer->resource) <
WL_DATA_OFFER_ACTION_SINCE_VERSION) {
data_source_notify_finish(offer->source);
-   } else if (wl_resource_get_version(offer->source->resource) >=
+   } else if (offer->source->resource &&
+  wl_resource_get_version(offer->source->resource) >=
   WL_DATA_SOURCE_DND_FINISHED_SINCE_VERSION) {
wl_data_source_send_cancelled(offer->source->resource);
}
-- 
2.5.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] protocol: Add note about per version requirements to wl_data_device_manager

[Carlos Garnacho]

Hey Jonas,

On Mon, Jan 18, 2016 at 11:18 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> Add a note to the wl_data_device_manager global interface about the
> different requirements for operating the objects created from the bound
> global.
>
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>
> Pekka suggested we should add a note about the per version requirements
> (wl_data_source.set_actions, wl_data_offer.accept and wl_data_offer.finish
> during DND), see here is such a paragraph.

Oh indeed. Makes sense to mention this in wl_data_device_manager docs,

Reviewed-by: Carlos Garnacho <carl...@gnome.org>

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston v9] data-device: Implement DnD actions

[Carlos Garnacho]

The policy in weston in order to determine the chosen DnD action is
deliberately simple, and is probably the minimals that any compositor
should be doing here.

Besides honoring the set_actions requests on both wl_data_source and
wl_data_offer, weston now will emit the newly added "action" events
notifying both source and dest of the chosen action.

The "dnd" client has been updated too (although minimally), so it
notifies the compositor of a "move" action on both sides.

Changes since v8:
  - Add back wl_data_offer.source_actions emission, gone during last
code shuffling. Fix nits found in review.

Changes since v7:
  - Fixes spotted during review. Add client-side version checks.
Implement .action emission as specified in protocol patch v11.

Changes since v6:
  - Emit errors as defined in DnD actions patch v10.

Changes since v5:
  - Use enum types and values for not-a-bitfield stored values.
handle errors when finding unexpected dnd_actions values.

Changes since v4:
  - Added compositor-side version checks. Spaces vs tabs fixes.
Fixed resource versioning. Initialized new weston_data_source/offer
fields.

Changes since v3:
  - Put data_source.action to use in the dnd client, now updates
the dnd surface like data_source.target events do.

Changes since v2:
  - Split from DnD progress notification changes.

Changes since v1:
  - Updated to v2 of DnD actions protocol changes, implement
wl_data_offer.source_actions.
  - Fixed coding style issues.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 clients/dnd.c |  36 +--
 clients/window.c  |  34 ++
 clients/window.h  |   3 +
 src/compositor.h  |   6 ++
 src/data-device.c | 182 --
 5 files changed, 252 insertions(+), 9 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index 974429b..d32655d 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -72,6 +72,7 @@ struct dnd_drag {
struct item *item;
int x_offset, y_offset;
int width, height;
+   uint32_t dnd_action;
const char *mime_type;
 
struct wl_surface *drag_surface;
@@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
 }
 
 static void
-data_source_target(void *data,
-  struct wl_data_source *source, const char *mime_type)
+dnd_drag_update_surface(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
struct dnd *dnd = dnd_drag->dnd;
cairo_surface_t *surface;
struct wl_buffer *buffer;
 
-   dnd_drag->mime_type = mime_type;
-   if (mime_type)
+   if (dnd_drag->mime_type && dnd_drag->dnd_action)
surface = dnd_drag->opaque;
else
surface = dnd_drag->translucent;
@@ -288,6 +286,16 @@ data_source_target(void *data,
 }
 
 static void
+data_source_target(void *data,
+  struct wl_data_source *source, const char *mime_type)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->mime_type = mime_type;
+   dnd_drag_update_surface(dnd_drag);
+}
+
+static void
 data_source_send(void *data, struct wl_data_source *source,
 const char *mime_type, int32_t fd)
 {
@@ -360,12 +368,22 @@ data_source_dnd_finished(void *data, struct 
wl_data_source *source)
dnd_drag_destroy(dnd_drag);
 }
 
+static void
+data_source_action(void *data, struct wl_data_source *source, uint32_t 
dnd_action)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->dnd_action = dnd_action;
+   dnd_drag_update_surface(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
data_source_cancelled,
data_source_dnd_drop_performed,
data_source_dnd_finished,
+   data_source_action,
 };
 
 static cairo_surface_t *
@@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
dnd_drag->item = item;
dnd_drag->x_offset = x - item->x;
dnd_drag->y_offset = y - item->y;
+   dnd_drag->dnd_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
+   dnd_drag->mime_type = NULL;
 
for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
if (item == dnd->items[i]){
@@ -456,6 +476,12 @@ create_drag_source(struct dnd *dnd,
 text_mime_type);
}
 
+   if (display_get_data_device_manager_version(display) >=
+   WL_DATA_SOURCE_SET_ACTIONS_SINCE_VERSION) {
+   wl_data_source_set_actions(dnd_drag->data_source,
+  
WL_DATA_DEVICE

Re: [PATCH wayland 2/2] protocol: Add DnD actions

[Carlos Garnacho]

Hi Jonas!

On Sat, Jan 16, 2016 at 9:37 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Fri, Jan 15, 2016 at 02:49:33PM -0800, Bryce Harrington wrote:
>> On Fri, Jan 15, 2016 at 09:11:40PM +0100, Carlos Garnacho wrote:
>> > These 2 requests have been added:
>> >
>> > - wl_data_source.set_actions: Notifies the compositor of the available
>> >   actions on the data source.
>> > - wl_data_offer.set_actions: Notifies the compositor of the available
>> >   actions on the destination side, plus the preferred action.
>> >
>> > Out of the data from these requests, the compositor can determine the 
>> > action
>> > both parts agree on (and let the user play a role through eg. keyboard
>> > modifiers). The chosen option will be notified to both parties
>> > through the following two requests:
>> >
>> > - wl_data_source.action
>> > - wl_data_offer.action
>> >
>> > In addition, the destination side can peek the source side actions through
>> > wl_data_offer.source_actions.
>> >
>> > Compared to the XDND protocol, there's two notable changes:
>> >
>> > - XDND lets the source suggest an action, whereas wl_data_device lets
>> >   the destination prefer a given action. The difference is subtle here,
>> >   it comes off as convenience because it is the drag destination which
>> >   receives the motion events (unlike in X) and can perform action updates.
>> >
>> >   The drag destination seems also in a better position to update the
>> >   preferred action based on things like the data being transferred, the
>> >   place being dropped, and whether the drag is client-local.
>> >
>> > - That same source-side preferred action is used in XDND to convey the
>> >   modifier-induced action to the drag destination, which would then ack
>> >   it, or reply with another action that's accepted (or none), this makes
>> >   the XdndPosition/XdndStatus messaging very verbose, and synchronous
>> >   because the drag source always needs to know the latest status/action
>> >   for every position+action sent.
>> >
>> >   Here it's the compositor which takes care of modifiers and matching
>> >   available/accepted actions, this allows for the signaling to happen
>> >   only whenever the actions/modifiers change for real.
>> >
>> > Roughly based on previous work by Giulio Camuffo <giuliocamu...@gmail.com>
>> >
>> > Changes since v10:
>> > - Narrow down the situations where wl_data_source/offer.accept requests
>> >   are supposed to happen.
>> >
>> > Changes since v9:
>> > - Deferred the protocol errors to .finish after some IRC chat with Jonas,
>> >   added further errors if actions API is used on selection sources/offers.
>> >
>> > Changes since v8:
>> > - Defined further the expected behavior on "ask", described the protocol
>> >   errors that may happen. Fix more spaces vs tabs issues.
>> >
>> > Changes since v7:
>> > - Misc changes after updating the progress notification patch.
>> >
>> > Changes since v6:
>> > - Further explanations on wl_data_source/offer.set_actions, including a
>> >   description of "ask" actions. Added protocol errors for unknown action
>> >   values.
>> >
>> > Changes since v5:
>> > - Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
>> >   scheme for actions. Fixed indentation and other minor formatting issues.
>> >
>> > Changes since v4:
>> > - Minor rewording.
>> >
>> > Changes since v3:
>> > - Splitted from DnD progress notification changes.
>> > - Further rationales in commit log.
>> >
>> > Changes since v2:
>> > - Renamed notify_actions to set_actions on both sides, seems more 
>> > consistent
>> >   with the rest of the protocol.
>> > - Spelled out better which events may be triggered on the compositor side
>> >   by the requests, the circumstances in which events are emitted, and
>> >   what are events useful for in clients.
>> > - Defined a minimal common ground wrt compositor-side action picking and
>> >   keybindings.
>> > - Acknowledge the possibility of compositor/toolkit defined actions, even
>> >   though none are used at the moment.
>> > Changes since v1:
>> > - Added wl_data_offer.source_actions to let know of the actions offered
>> >   by a data source.
&g

Re: [PATCH weston v6 1/5] data-device: Implement DnD progress notification

[Carlos Garnacho]

Hey Jonas,

On Fri, Jan 15, 2016 at 6:32 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Thu, Jan 14, 2016 at 11:43:39PM +0100, Carlos Garnacho wrote:
>> Weston now sends wl_data_source.dnd_drop_performed and .dnd_finished in
>> order to notify about the different phases of DnD.
>>
>> wl_data_source.cancelled is also used as mentioned in the docs, being
>> emitted also on DnD when the operation is meant to fail (eg. source
>> and dest didn't agree on a mimetype).
>>
>> The dnd demo is also fixed so the struct dnd_drag isn't leaked.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=91943
>> https://bugs.freedesktop.org/show_bug.cgi?id=91944
>>
>> Changes since v5:
>>   - Dissociate source and offer after cancel. Updated to
>> apply on top of c9f8f8a7f.
>>
>> Changes since v4:
>>   - Make wl_data_offer.finish with the wrong state an error.
>>
>> Changes since v3:
>>   - Fixed wl_data_source.dnd_finished vs cancelled emission on
>> when interoperating with version < 3 drag destinations.
>>
>> Changes since v2:
>>   - Handle wl_data_offer.finish. Fixed commit log inconsistencies.
>> Added version checks. Spaces vs tabs fixes. Fixed resource
>> versioning.
>>
>> Changes since v1:
>>   - Updated to protocol v2.
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
>
> Mostly looks good to me. I have a couple of minor requests though. See
> inline comments. With those fixed, this is Reviewed-by: Jonas Ådahl
> <jad...@gmail.com>.
>
>> ---
>>  clients/dnd.c |  39 +++-
>>  clients/window.c  |   3 +-
>>  src/compositor.h  |   3 ++
>>  src/data-device.c | 105 
>> +-
>>  4 files changed, 132 insertions(+), 18 deletions(-)
>>
>> diff --git a/clients/dnd.c b/clients/dnd.c
>> index e6a0c39..48111d9 100644
>> --- a/clients/dnd.c
>> +++ b/clients/dnd.c
>> @@ -318,14 +318,8 @@ data_source_send(void *data, struct wl_data_source 
>> *source,
>>  }
>>
>>  static void
>> -data_source_cancelled(void *data, struct wl_data_source *source)
>> +dnd_drag_destroy(struct dnd_drag *dnd_drag)
>>  {
>> - struct dnd_drag *dnd_drag = data;
>> -
>> - /* The 'cancelled' event means that the source is no longer in
>> -  * use by the drag (or current selection).  We need to clean
>> -  * up the drag object created and the local state. */
>> -
>>   wl_data_source_destroy(dnd_drag->data_source);
>>
>>   /* Destroy the item that has been dragged out */
>> @@ -339,10 +333,39 @@ data_source_cancelled(void *data, struct 
>> wl_data_source *source)
>>   free(dnd_drag);
>>  }
>>
>> +static void
>> +data_source_cancelled(void *data, struct wl_data_source *source)
>> +{
>> + struct dnd_drag *dnd_drag = data;
>> +
>> + /* The 'cancelled' event means that the source is no longer in
>> +  * use by the drag (or current selection).  We need to clean
>> +  * up the drag object created and the local state. */
>> + dnd_drag_destroy(dnd_drag);
>> +}
>> +
>> +static void
>> +data_source_drop_performed(void *data, struct wl_data_source *source)
>> +{
>> +}
>> +
>> +static void
>> +data_source_drag_finished(void *data, struct wl_data_source *source)
>> +{
>> + struct dnd_drag *dnd_drag = data;
>> +
>> + /* The operation is already finished, we can destroy all
>> +  * related data.
>> +  */
>> + dnd_drag_destroy(dnd_drag);
>> +}
>> +
>>  static const struct wl_data_source_listener data_source_listener = {
>>   data_source_target,
>>   data_source_send,
>> - data_source_cancelled
>> + data_source_cancelled,
>> + data_source_drop_performed,
>> + data_source_drag_finished,
>
> nit: These should be data_source_dnd_drop_performed and
> data_source_dnd_finished.

Indeed.

>
>>  };
>>
>>  static cairo_surface_t *
>> diff --git a/clients/window.c b/clients/window.c
>> index 5d69116..c93edb1 100644
>> --- a/clients/window.c
>> +++ b/clients/window.c
>> @@ -3726,6 +3726,7 @@ offer_io_func(struct task *task, uint32_t events)
>>
>>   if (len == 0) {
>>   close(offer->fd);
>> + wl_data_offer_finish(offer->offer);
>>   data_offer_destroy(offer);
>>

[PATCH weston 3/5] client: Add DnD cursors to the managed cursors list

[Carlos Garnacho]

That way we'll be able to set the corresponding pointer surface to
a current DnD operation.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 clients/window.c | 16 
 clients/window.h |  3 +++
 2 files changed, 19 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index 3e5885e..e9e8de9 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -1261,6 +1261,19 @@ static const char *watches[] = {
"0426c94ea35c87780ff01dc239897213"
 };
 
+static const char *move_draggings[] = {
+   "dnd-move"
+};
+
+static const char *copy_draggings[] = {
+   "dnd-copy"
+};
+
+static const char *forbidden_draggings[] = {
+   "dnd-none",
+   "dnd-no-drop"
+};
+
 struct cursor_alternatives {
const char **names;
size_t count;
@@ -1280,6 +1293,9 @@ static const struct cursor_alternatives cursors[] = {
{xterms, ARRAY_LENGTH(xterms)},
{hand1s, ARRAY_LENGTH(hand1s)},
{watches, ARRAY_LENGTH(watches)},
+   {move_draggings, ARRAY_LENGTH(move_draggings)},
+   {copy_draggings, ARRAY_LENGTH(copy_draggings)},
+   {forbidden_draggings, ARRAY_LENGTH(forbidden_draggings)},
 };
 
 static void
diff --git a/clients/window.h b/clients/window.h
index 74a2c72..d54bf79 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -192,6 +192,9 @@ enum cursor_type {
CURSOR_IBEAM,
CURSOR_HAND1,
CURSOR_WATCH,
+   CURSOR_DND_MOVE,
+   CURSOR_DND_COPY,
+   CURSOR_DND_FORBIDDEN,
 
CURSOR_BLANK
 };
-- 
2.5.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 1/5] data-device: Implement DnD progress notification

[Carlos Garnacho]

Weston now sends wl_data_source.dnd_drop_performed and .dnd_finished in
order to notify about the different phases of DnD.

wl_data_source.cancelled is also used as mentioned in the docs, being
emitted also on DnD when the operation is meant to fail (eg. source
and dest didn't agree on a mimetype).

The dnd demo is also fixed so the struct dnd_drag isn't leaked.

https://bugs.freedesktop.org/show_bug.cgi?id=91943
https://bugs.freedesktop.org/show_bug.cgi?id=91944

Changes since v6:
  - Add client-side version checks. Minor code shuffling.

Changes since v5:
  - Dissociate source and offer after cancel. Updated to
apply on top of c9f8f8a7f.

Changes since v4:
  - Make wl_data_offer.finish with the wrong state an error.

Changes since v3:
  - Fixed wl_data_source.dnd_finished vs cancelled emission on
when interoperating with version < 3 drag destinations.

Changes since v2:
  - Handle wl_data_offer.finish. Fixed commit log inconsistencies.
Added version checks. Spaces vs tabs fixes. Fixed resource
versioning.

Changes since v1:
  - Updated to protocol v2.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 clients/dnd.c |  39 +
 clients/window.c  |   6 ++-
 src/compositor.h  |   3 ++
 src/data-device.c | 125 +++---
 4 files changed, 148 insertions(+), 25 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index e6a0c39..974429b 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -318,14 +318,8 @@ data_source_send(void *data, struct wl_data_source *source,
 }
 
 static void
-data_source_cancelled(void *data, struct wl_data_source *source)
+dnd_drag_destroy(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
-
-   /* The 'cancelled' event means that the source is no longer in
-* use by the drag (or current selection).  We need to clean
-* up the drag object created and the local state. */
-
wl_data_source_destroy(dnd_drag->data_source);
 
/* Destroy the item that has been dragged out */
@@ -339,10 +333,39 @@ data_source_cancelled(void *data, struct wl_data_source 
*source)
free(dnd_drag);
 }
 
+static void
+data_source_cancelled(void *data, struct wl_data_source *source)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   /* The 'cancelled' event means that the source is no longer in
+* use by the drag (or current selection).  We need to clean
+* up the drag object created and the local state. */
+   dnd_drag_destroy(dnd_drag);
+}
+
+static void
+data_source_dnd_drop_performed(void *data, struct wl_data_source *source)
+{
+}
+
+static void
+data_source_dnd_finished(void *data, struct wl_data_source *source)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   /* The operation is already finished, we can destroy all
+* related data.
+*/
+   dnd_drag_destroy(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
-   data_source_cancelled
+   data_source_cancelled,
+   data_source_dnd_drop_performed,
+   data_source_dnd_finished,
 };
 
 static cairo_surface_t *
diff --git a/clients/window.c b/clients/window.c
index 5d69116..2baf9ea 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3717,6 +3717,7 @@ offer_io_func(struct task *task, uint32_t events)
 {
struct data_offer *offer =
container_of(task, struct data_offer, io_task);
+   struct display *display = offer->input->display;
unsigned int len;
char buffer[4096];
 
@@ -3725,6 +3726,9 @@ offer_io_func(struct task *task, uint32_t events)
offer->x, offer->y, offer->user_data);
 
if (len == 0) {
+   if (display->data_device_manager_version >=
+   WL_DATA_OFFER_FINISH_SINCE_VERSION)
+   wl_data_offer_finish(offer->offer);
close(offer->fd);
data_offer_destroy(offer);
}
@@ -5318,7 +5322,7 @@ registry_handle_global(void *data, struct wl_registry 
*registry, uint32_t id,
d->shm = wl_registry_bind(registry, id, _shm_interface, 1);
wl_shm_add_listener(d->shm, _listener, d);
} else if (strcmp(interface, "wl_data_device_manager") == 0) {
-   d->data_device_manager_version = MIN(version, 2);
+   d->data_device_manager_version = MIN(version, 3);
d->data_device_manager =
wl_registry_bind(registry, id,
 _data_device_manager_interface,
diff --git a/src/compositor.h b/src/compositor.h
index 130b258..8d6b051 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -317,6 +317,9 @@ struct weston_data_source {
 

[PATCH weston 4/5] data-device: Implement compositor-chosen actions

[Carlos Garnacho]

Set up a keyboard grab during drag-and-drop, so we can translate
modifiers into preferred actions. The compositor chosen action
is stored in the current weston_data_source in order to make it
accessible to the source/offer at the time of calculating the new
action, but would conceptually be part of weston_drag.

The mapping has been made similar to what GTK+/QT usually do, the
shift key defaults to "move" and ctrl defaults to "copy".

Changes since v2:
  - Use enum types and values for the compositor action. Fix
code formatting issues.

Changes since v1:
  - Handle the keyboard grab being cancelled. Initialize new
wl_data_source fields.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 src/compositor.h  |  1 +
 src/data-device.c | 76 +++
 2 files changed, 77 insertions(+)

diff --git a/src/compositor.h b/src/compositor.h
index e07179f..b4e3cc2 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -326,6 +326,7 @@ struct weston_data_source {
bool actions_set;
uint32_t dnd_actions;
enum wl_data_device_manager_dnd_action current_dnd_action;
+   enum wl_data_device_manager_dnd_action compositor_action;
 
void (*accept)(struct weston_data_source *source,
   uint32_t serial, const char *mime_type);
diff --git a/src/data-device.c b/src/data-device.c
index 8820c93..80c9e70 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -44,6 +44,7 @@ struct weston_drag {
struct weston_view *icon;
struct wl_listener icon_destroy_listener;
int32_t dx, dy;
+   struct weston_keyboard_grab keyboard_grab;
 };
 
 struct weston_pointer_drag {
@@ -139,6 +140,10 @@ data_offer_choose_action(struct weston_data_offer *offer)
if (!available_actions)
return WL_DATA_DEVICE_MANAGER_DND_ACTION_NONE;
 
+   if (offer->source->seat &&
+   offer->source->compositor_action & available_actions)
+   return offer->source->compositor_action;
+
/* If the dest side has a preferred DnD action, use it */
if ((preferred_action & available_actions) != 0)
return preferred_action;
@@ -601,9 +606,11 @@ static void
 data_device_end_pointer_drag_grab(struct weston_pointer_drag *drag)
 {
struct weston_pointer *pointer = drag->grab.pointer;
+   struct weston_keyboard *keyboard = drag->base.keyboard_grab.keyboard;
 
data_device_end_drag_grab(>base, pointer->seat);
weston_pointer_end_grab(pointer);
+   weston_keyboard_end_grab(keyboard);
free(drag);
 }
 
@@ -684,9 +691,11 @@ static void
 data_device_end_touch_drag_grab(struct weston_touch_drag *drag)
 {
struct weston_touch *touch = drag->grab.touch;
+   struct weston_keyboard *keyboard = drag->base.keyboard_grab.keyboard;
 
data_device_end_drag_grab(>base, touch->seat);
weston_touch_end_grab(touch);
+   weston_keyboard_end_grab(keyboard);
free(drag);
 }
 
@@ -778,6 +787,61 @@ static const struct weston_touch_grab_interface 
touch_drag_grab_interface = {
 };
 
 static void
+drag_grab_keyboard_key(struct weston_keyboard_grab *grab,
+  uint32_t time, uint32_t key, uint32_t state)
+{
+}
+
+static void
+drag_grab_keyboard_modifiers(struct weston_keyboard_grab *grab,
+uint32_t serial, uint32_t mods_depressed,
+uint32_t mods_latched,
+uint32_t mods_locked, uint32_t group)
+{
+   struct weston_keyboard *keyboard = grab->keyboard;
+   struct weston_drag *drag =
+   container_of(grab, struct weston_drag, keyboard_grab);
+   uint32_t compositor_action;
+
+   if (mods_depressed & (1 << keyboard->xkb_info->shift_mod))
+   compositor_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
+   else if (mods_depressed & (1 << keyboard->xkb_info->ctrl_mod))
+   compositor_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY;
+   else
+   compositor_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_NONE;
+
+   drag->data_source->compositor_action = compositor_action;
+
+   if (drag->data_source->offer)
+   data_offer_update_action(drag->data_source->offer);
+}
+
+static void
+drag_grab_keyboard_cancel(struct weston_keyboard_grab *grab)
+{
+   struct weston_drag *drag =
+   container_of(grab, struct weston_drag, keyboard_grab);
+   struct weston_pointer *pointer = grab->keyboard->seat->pointer_state;
+   struct weston_touch *touch = grab->keyboard->seat->touch_state;
+
+   if (pointer && pointer->grab->interface == 
_drag_grab_interface) {
+   struct weston_touch_drag *touch_drag =
+   

Re: [PATCH weston v7 2/5] data-device: Implement DnD actions

[Carlos Garnacho]

Hey Jonas,

On Fri, Jan 15, 2016 at 7:10 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Thu, Jan 14, 2016 at 11:46:34PM +0100, Carlos Garnacho wrote:
>> The policy in weston in order to determine the chosen DnD action is
>> deliberately simple, and is probably the minimals that any compositor
>> should be doing here.
>>
>> Besides honoring the set_actions requests on both wl_data_source and
>> wl_data_offer, weston now will emit the newly added "action" events
>> notifying both source and dest of the chosen action.
>>
>> The "dnd" client has been updated too (although minimally), so it
>> notifies the compositor of a "move" action on both sides.
>>
>> Changes since v6:
>>   - Emit errors as defined in DnD actions patch v10.
>>
>> Changes since v5:
>>   - Use enum types and values for not-a-bitfield stored values.
>> handle errors when finding unexpected dnd_actions values.
>>
>> Changes since v4:
>>   - Added compositor-side version checks. Spaces vs tabs fixes.
>> Fixed resource versioning. Initialized new weston_data_source/offer
>> fields.
>>
>> Changes since v3:
>>   - Put data_source.action to use in the dnd client, now updates
>> the dnd surface like data_source.target events do.
>>
>> Changes since v2:
>>   - Split from DnD progress notification changes.
>>
>> Changes since v1:
>>   - Updated to v2 of DnD actions protocol changes, implement
>> wl_data_offer.source_actions.
>>   - Fixed coding style issues.
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
>
> Mostly looks good, except for one part regarding the order of
> wl_data_source.set_actions and wl_data_device.start_drag. I also have a
> question regarding what to do with events during "ask". See the comments
> inline.
>
>> ---
>>  clients/dnd.c |  32 +--
>>  clients/window.c  |  25 
>>  src/compositor.h  |   5 ++
>>  src/data-device.c | 169 
>> --
>>  4 files changed, 221 insertions(+), 10 deletions(-)
>>
>> diff --git a/clients/dnd.c b/clients/dnd.c
>> index 48111d9..ddf3fcc 100644
>> --- a/clients/dnd.c
>> +++ b/clients/dnd.c
>> @@ -72,6 +72,7 @@ struct dnd_drag {
>>   struct item *item;
>>   int x_offset, y_offset;
>>   int width, height;
>> + uint32_t dnd_action;
>>   const char *mime_type;
>>
>>   struct wl_surface *drag_surface;
>> @@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
>>  }
>>
>>  static void
>> -data_source_target(void *data,
>> -struct wl_data_source *source, const char *mime_type)
>> +dnd_drag_update_surface(struct dnd_drag *dnd_drag)
>>  {
>> - struct dnd_drag *dnd_drag = data;
>>   struct dnd *dnd = dnd_drag->dnd;
>>   cairo_surface_t *surface;
>>   struct wl_buffer *buffer;
>>
>> - dnd_drag->mime_type = mime_type;
>> - if (mime_type)
>> + if (dnd_drag->mime_type && dnd_drag->dnd_action)
>>   surface = dnd_drag->opaque;
>>   else
>>   surface = dnd_drag->translucent;
>> @@ -288,6 +286,16 @@ data_source_target(void *data,
>>  }
>>
>>  static void
>> +data_source_target(void *data,
>> +struct wl_data_source *source, const char *mime_type)
>> +{
>> + struct dnd_drag *dnd_drag = data;
>> +
>> + dnd_drag->mime_type = mime_type;
>> + dnd_drag_update_surface(dnd_drag);
>> +}
>> +
>> +static void
>>  data_source_send(void *data, struct wl_data_source *source,
>>const char *mime_type, int32_t fd)
>>  {
>> @@ -360,12 +368,22 @@ data_source_drag_finished(void *data, struct 
>> wl_data_source *source)
>>   dnd_drag_destroy(dnd_drag);
>>  }
>>
>> +static void
>> +data_source_action(void *data, struct wl_data_source *source, uint32_t 
>> dnd_action)
>> +{
>> + struct dnd_drag *dnd_drag = data;
>> +
>> + dnd_drag->dnd_action = dnd_action;
>> + dnd_drag_update_surface(dnd_drag);
>> +}
>> +
>>  static const struct wl_data_source_listener data_source_listener = {
>>   data_source_target,
>>   data_source_send,
>>   data_source_cancelled,
>>   data_source_drop_performed,
>>   da

[PATCH wayland 1/2] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

Currently, there's no means for the DnD origin to know whether the
destination is actually finished with the DnD transaction, short of
finalizing it after the first transfer finishes, or leaking it forever.

But this poses other interoperation problems, drag destinations might
be requesting several mimetypes at once, might be just poking to find
out the most suitable format, might want to defer the action to a popup,
might be poking contents early before the selection was dropped...

In addition, data_source.cancelled is suitable for the situations where
the DnD operation fails (not on a drop target, no matching mimetypes,
etc..), but seems undocumented for that use (and unused in weston's DnD).

In order to improve the situation, the drag source should be notified
of all stages of DnD. In addition to documenting the "cancelled" event
for DnD purposes, The following 2 events have been added:

- wl_data_source.dnd_drop_performed: Happens when the operation has been
  physically finished (eg. the button is released), it could be the right
  place to reset the pointer cursor back and undo any other state resulting
  from the initial button press.
- wl_data_source.dnd_finished: Happens when the destination side destroys
  the wl_data_offer, at this point the source can just forget all data
  related to the DnD selection as well, plus optionally deleting the data
  on move operations.

Changes since v6:
  - Turned wl_data_offer.finish calls with 0/NULL state/mimetype an
error, made it explicit that it will only result in
wl_data_offer.dnd_finished being sent if successful.

Changes since v5:
  - Further rewording of wl_data_offer.finish and wl_data_offer.accept.
Added error for untimely wl_data_offer.finish requests.

Changes since v4:
  - Applied rewording suggestions from Jonas Ådahl. Added new
wl_data_offer.finish request to allow explicit finalization on the
destination side.

Changes since v3:
  - Renamed dnd_performed to a more descriptive dnd_drop_performed,
documented backwards compatible behavior on wl_data_offer.accept and
wl_data_source.cancelled.

Changes since v2:
  - Minor rewording.

Changes since v1:
  - Renamed events to have a common "dnd" namespace. Made dnd_performed to
happen invariably, data_device.cancelled may still happen afterwards.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
---
 protocol/wayland.xml | 87 
 1 file changed, 81 insertions(+), 6 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 8a62190..dc05993 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -408,7 +408,7 @@
   
 
 
-  
+  
 
   A wl_data_offer represents a piece of data offered for transfer
   by another client (the source client).  It is used by the
@@ -418,12 +418,27 @@
   data directly from the source client.
 
 
+
+  
+
+
 
   
Indicate that the client can accept the given mime type, or
NULL for not accepted.
 
-   Used for feedback during drag-and-drop.
+   For objects of version 2 or older, this request is used by the
+   client to give feedback whether the client can receive the given
+   mime type, or NULL if none is accepted; the feedback does not
+   determine whether drag-and-drop operation succeeds or not.
+
+   For objects of version 3 or newer, this request determines the
+   final result of the drag-and-drop operation. If the end result
+   is that no mime types was accepted, the drag-and-drop operation
+   will be cancelled and the corresponding drag source will receive
+   wl_data_source.cancelled. Clients may still use this event in
+   conjunction with wl_data_source.action for feedback.
   
 
   
@@ -442,6 +457,11 @@
The receiving client reads from the read end of the pipe until
EOF and then closes its end, at which point the transfer is
complete.
+
+   This request may happen multiple times for different mimetypes,
+   both before and after wl_data_device.drop. Drag-and-drop destination
+   clients may preemptively fetch data or examine it more closely to
+   determine acceptance.
   
   
   
@@ -461,9 +481,26 @@
 
   
 
+
+
+
+
+  
+   Notifies the compositor that the drag destination successfully
+   finished the drag-and-drop operation.
+
+   Upon receiving this request, the compositor will emit
+   wl_data_source.dnd_finished on the drag source client.
+
+   It is a client error to perform other requests than
+   wl_data_offer.destroy after this one. It is also an error to perform
+   this request after a NULL mime type 

[PATCH wayland 2/2] protocol: Add DnD actions

[Carlos Garnacho]

These 2 requests have been added:

- wl_data_source.set_actions: Notifies the compositor of the available
  actions on the data source.
- wl_data_offer.set_actions: Notifies the compositor of the available
  actions on the destination side, plus the preferred action.

Out of the data from these requests, the compositor can determine the action
both parts agree on (and let the user play a role through eg. keyboard
modifiers). The chosen option will be notified to both parties
through the following two requests:

- wl_data_source.action
- wl_data_offer.action

In addition, the destination side can peek the source side actions through
wl_data_offer.source_actions.

Compared to the XDND protocol, there's two notable changes:

- XDND lets the source suggest an action, whereas wl_data_device lets
  the destination prefer a given action. The difference is subtle here,
  it comes off as convenience because it is the drag destination which
  receives the motion events (unlike in X) and can perform action updates.

  The drag destination seems also in a better position to update the
  preferred action based on things like the data being transferred, the
  place being dropped, and whether the drag is client-local.

- That same source-side preferred action is used in XDND to convey the
  modifier-induced action to the drag destination, which would then ack
  it, or reply with another action that's accepted (or none), this makes
  the XdndPosition/XdndStatus messaging very verbose, and synchronous
  because the drag source always needs to know the latest status/action
  for every position+action sent.

  Here it's the compositor which takes care of modifiers and matching
  available/accepted actions, this allows for the signaling to happen
  only whenever the actions/modifiers change for real.

Roughly based on previous work by Giulio Camuffo <giuliocamu...@gmail.com>

Changes since v10:
- Narrow down the situations where wl_data_source/offer.accept requests
  are supposed to happen.

Changes since v9:
- Deferred the protocol errors to .finish after some IRC chat with Jonas,
  added further errors if actions API is used on selection sources/offers.

Changes since v8:
- Defined further the expected behavior on "ask", described the protocol
  errors that may happen. Fix more spaces vs tabs issues.

Changes since v7:
- Misc changes after updating the progress notification patch.

Changes since v6:
- Further explanations on wl_data_source/offer.set_actions, including a
  description of "ask" actions. Added protocol errors for unknown action
  values.

Changes since v5:
- Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
  scheme for actions. Fixed indentation and other minor formatting issues.

Changes since v4:
- Minor rewording.

Changes since v3:
- Splitted from DnD progress notification changes.
- Further rationales in commit log.

Changes since v2:
- Renamed notify_actions to set_actions on both sides, seems more consistent
  with the rest of the protocol.
- Spelled out better which events may be triggered on the compositor side
  by the requests, the circumstances in which events are emitted, and
  what are events useful for in clients.
- Defined a minimal common ground wrt compositor-side action picking and
  keybindings.
- Acknowledge the possibility of compositor/toolkit defined actions, even
  though none are used at the moment.
Changes since v1:
- Added wl_data_offer.source_actions to let know of the actions offered
  by a data source.
- Renamed wl_data_source.finished to "drag_finished" for clarity
- Improved wording as suggested by Bryce

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 protocol/wayland.xml | 205 ++-
 1 file changed, 204 insertions(+), 1 deletion(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index dc05993..cea65e9 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -421,6 +421,12 @@
 
   
+  
+  
+  
 
 
 
@@ -495,9 +501,98 @@
It is a client error to perform other requests than
wl_data_offer.destroy after this one. It is also an error to perform
this request after a NULL mime type has been set in
-   wl_data_offer.accept.
+   wl_data_offer.accept or no action was received through
+   wl_data_offer.action.
   
 
+
+
+  
+   Sets the actions that the destination side client supports for
+   this operation. This request may trigger the emission of
+   wl_data_source.action and wl_data_offer.action events if the compositor
+   needs changing the selected action.
+
+   This request can be called multiple times throughout the
+   drag-and-drop operation, typically in response to 

[PATCH weston 2/5] data-device: Implement DnD actions

[Carlos Garnacho]

The policy in weston in order to determine the chosen DnD action is
deliberately simple, and is probably the minimals that any compositor
should be doing here.

Besides honoring the set_actions requests on both wl_data_source and
wl_data_offer, weston now will emit the newly added "action" events
notifying both source and dest of the chosen action.

The "dnd" client has been updated too (although minimally), so it
notifies the compositor of a "move" action on both sides.

Changes since v7:
  - Fixes spotted during review. Add client-side version checks.
Implement .action emission as specified in protocol patch v11.

Changes since v6:
  - Emit errors as defined in DnD actions patch v10.

Changes since v5:
  - Use enum types and values for not-a-bitfield stored values.
handle errors when finding unexpected dnd_actions values.

Changes since v4:
  - Added compositor-side version checks. Spaces vs tabs fixes.
Fixed resource versioning. Initialized new weston_data_source/offer
fields.

Changes since v3:
  - Put data_source.action to use in the dnd client, now updates
the dnd surface like data_source.target events do.

Changes since v2:
  - Split from DnD progress notification changes.

Changes since v1:
  - Updated to v2 of DnD actions protocol changes, implement
wl_data_offer.source_actions.
  - Fixed coding style issues.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
---
 clients/dnd.c |  36 ++--
 clients/window.c  |  34 +++
 clients/window.h  |   3 +
 src/compositor.h  |   6 ++
 src/data-device.c | 172 --
 5 files changed, 242 insertions(+), 9 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index 974429b..d32655d 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -72,6 +72,7 @@ struct dnd_drag {
struct item *item;
int x_offset, y_offset;
int width, height;
+   uint32_t dnd_action;
const char *mime_type;
 
struct wl_surface *drag_surface;
@@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
 }
 
 static void
-data_source_target(void *data,
-  struct wl_data_source *source, const char *mime_type)
+dnd_drag_update_surface(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
struct dnd *dnd = dnd_drag->dnd;
cairo_surface_t *surface;
struct wl_buffer *buffer;
 
-   dnd_drag->mime_type = mime_type;
-   if (mime_type)
+   if (dnd_drag->mime_type && dnd_drag->dnd_action)
surface = dnd_drag->opaque;
else
surface = dnd_drag->translucent;
@@ -288,6 +286,16 @@ data_source_target(void *data,
 }
 
 static void
+data_source_target(void *data,
+  struct wl_data_source *source, const char *mime_type)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->mime_type = mime_type;
+   dnd_drag_update_surface(dnd_drag);
+}
+
+static void
 data_source_send(void *data, struct wl_data_source *source,
 const char *mime_type, int32_t fd)
 {
@@ -360,12 +368,22 @@ data_source_dnd_finished(void *data, struct 
wl_data_source *source)
dnd_drag_destroy(dnd_drag);
 }
 
+static void
+data_source_action(void *data, struct wl_data_source *source, uint32_t 
dnd_action)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->dnd_action = dnd_action;
+   dnd_drag_update_surface(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
data_source_cancelled,
data_source_dnd_drop_performed,
data_source_dnd_finished,
+   data_source_action,
 };
 
 static cairo_surface_t *
@@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
dnd_drag->item = item;
dnd_drag->x_offset = x - item->x;
dnd_drag->y_offset = y - item->y;
+   dnd_drag->dnd_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
+   dnd_drag->mime_type = NULL;
 
for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
if (item == dnd->items[i]){
@@ -456,6 +476,12 @@ create_drag_source(struct dnd *dnd,
 text_mime_type);
}
 
+   if (display_get_data_device_manager_version(display) >=
+   WL_DATA_SOURCE_SET_ACTIONS_SINCE_VERSION) {
+   wl_data_source_set_actions(dnd_drag->data_source,
+  
WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE);
+   }
+
wl_data_device_start_drag(input_get_data_device(input),
  dnd_drag->data_source,
  w

[PATCH weston 5/5] dnd: Turn into a full blown example

[Carlos Garnacho]

In order to keep things simple, weston-dnd made a few choices that
turn out to be unrealistic, a few tweaks have been done to make it
less of a playground demo:

- It now caters for copy/move operations, instead of just move,
  which still remains the default nonetheless.
- As "move" operations are no longer assumed, the item isn't removed
  on start_drag, instead it is made translucent until the drag
  operation finishes (and we know whether the item is to be
  removed after transfer or left as is)
- For the same reasons, "Drop nowhere to delete item" no longer
  happens. Drag-and-drop is a failable operation and must not result
  in data loss.
- As multiple actions are now allowed, we set the pointer icon
  surface accordingly to the current operation.

This makes weston-dnd a better example of what applications usually
want to do here.

Changes since v2:
  - Updated to behave alright-ish with version < 3.

Changes since v1:
  - Remove unneeded include. Remove extra newlines. Other minor
code fixes.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 clients/dnd.c | 106 ++
 1 file changed, 84 insertions(+), 22 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index d32655d..e6c3147 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -190,7 +190,7 @@ dnd_redraw_handler(struct widget *widget, void *data)
struct dnd *dnd = data;
struct rectangle allocation;
cairo_t *cr;
-   cairo_surface_t *surface;
+   cairo_surface_t *surface, *item_surface;
unsigned int i;
 
surface = window_get_surface(dnd->window);
@@ -210,7 +210,13 @@ dnd_redraw_handler(struct widget *widget, void *data)
for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
if (!dnd->items[i])
continue;
-   cairo_set_source_surface(cr, dnd->items[i]->surface,
+
+   if (dnd->current_drag && dnd->items[i] == 
dnd->current_drag->item)
+   item_surface = dnd->current_drag->translucent;
+   else
+   item_surface = dnd->items[i]->surface;
+
+   cairo_set_source_surface(cr, item_surface,
 dnd->items[i]->x + allocation.x,
 dnd->items[i]->y + allocation.y);
cairo_paint(cr);
@@ -266,6 +272,30 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
return NULL;
 }
 
+static int
+lookup_dnd_cursor(uint32_t dnd_action)
+{
+   if (dnd_action == WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE)
+   return CURSOR_DND_MOVE;
+   else if (dnd_action == WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY)
+   return CURSOR_DND_COPY;
+
+   return CURSOR_DND_FORBIDDEN;
+}
+
+static void
+dnd_drag_update_cursor(struct dnd_drag *dnd_drag)
+{
+   int cursor;
+
+   if (dnd_drag->mime_type == NULL)
+   cursor = CURSOR_DND_FORBIDDEN;
+   else
+   cursor = lookup_dnd_cursor(dnd_drag->dnd_action);
+
+   input_set_pointer_image(dnd_drag->input, cursor);
+}
+
 static void
 dnd_drag_update_surface(struct dnd_drag *dnd_drag)
 {
@@ -293,6 +323,7 @@ data_source_target(void *data,
 
dnd_drag->mime_type = mime_type;
dnd_drag_update_surface(dnd_drag);
+   dnd_drag_update_cursor(dnd_drag);
 }
 
 static void
@@ -326,13 +357,27 @@ data_source_send(void *data, struct wl_data_source 
*source,
 }
 
 static void
-dnd_drag_destroy(struct dnd_drag *dnd_drag)
+dnd_drag_destroy(struct dnd_drag *dnd_drag, bool delete_item)
 {
+   struct dnd *dnd = dnd_drag->dnd;
+   unsigned int i;
+
wl_data_source_destroy(dnd_drag->data_source);
 
-   /* Destroy the item that has been dragged out */
-   cairo_surface_destroy(dnd_drag->item->surface);
-   free(dnd_drag->item);
+   if (delete_item) {
+   for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
+   if (dnd_drag->item == dnd->items[i]) {
+   dnd->items[i] = NULL;
+   break;
+   }
+   }
+
+   /* Destroy the item that has been dragged out */
+   cairo_surface_destroy(dnd_drag->item->surface);
+   free(dnd_drag->item);
+   }
+
+   dnd->current_drag = NULL;
 
wl_surface_destroy(dnd_drag->drag_surface);
 
@@ -345,11 +390,13 @@ static void
 data_source_cancelled(void *data, struct wl_data_source *source)
 {
struct dnd_drag *dnd_drag = data;
+   struct dnd *dnd = dnd_drag->dnd;
 
/* The 'cancelled' event means that the source is no longer in
 * use by the drag (or current selection).  We need to clean
 * up the 

Re: [PATCH weston 3/5] client: Add DnD cursors to the managed cursors list

[Carlos Garnacho]

Hey Bryce :),

On Sat, Jan 16, 2016 at 12:13 AM, Bryce Harrington
<br...@osg.samsung.com> wrote:
> On Fri, Jan 15, 2016 at 09:14:25PM +0100, Carlos Garnacho wrote:
>> That way we'll be able to set the corresponding pointer surface to
>> a current DnD operation.
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> Reviewed-by: Jonas Ådahl <jad...@gmail.com>
>> ---
>>  clients/window.c | 16 
>>  clients/window.h |  3 +++
>>  2 files changed, 19 insertions(+)
>>
>> diff --git a/clients/window.c b/clients/window.c
>> index 3e5885e..e9e8de9 100644
>> --- a/clients/window.c
>> +++ b/clients/window.c
>> @@ -1261,6 +1261,19 @@ static const char *watches[] = {
>>   "0426c94ea35c87780ff01dc239897213"
>>  };
>>
>> +static const char *move_draggings[] = {
>> + "dnd-move"
>> +};
>
> Any reason this must be 'draggings' rather than 'drags'?

Maybe not a big one, "drags" sounded too much like ongoing
action/state to me. The naming scheme for these arrays is somewhat
unfortunate, it feels more natural to invert the name here, but
"drag_moves" or "dnd_moves" sounds equally awkward. Suffixing
"_cursors" in these would make for better names IMO, like
dnd_move_cursors.

Cheers,
  Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston v6 1/5] data-device: Implement DnD progress notification

[Carlos Garnacho]

Weston now sends wl_data_source.dnd_drop_performed and .dnd_finished in
order to notify about the different phases of DnD.

wl_data_source.cancelled is also used as mentioned in the docs, being
emitted also on DnD when the operation is meant to fail (eg. source
and dest didn't agree on a mimetype).

The dnd demo is also fixed so the struct dnd_drag isn't leaked.

https://bugs.freedesktop.org/show_bug.cgi?id=91943
https://bugs.freedesktop.org/show_bug.cgi?id=91944

Changes since v5:
  - Dissociate source and offer after cancel. Updated to
apply on top of c9f8f8a7f.

Changes since v4:
  - Make wl_data_offer.finish with the wrong state an error.

Changes since v3:
  - Fixed wl_data_source.dnd_finished vs cancelled emission on
when interoperating with version < 3 drag destinations.

Changes since v2:
  - Handle wl_data_offer.finish. Fixed commit log inconsistencies.
Added version checks. Spaces vs tabs fixes. Fixed resource
versioning.

Changes since v1:
  - Updated to protocol v2.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
---
 clients/dnd.c |  39 +++-
 clients/window.c  |   3 +-
 src/compositor.h  |   3 ++
 src/data-device.c | 105 +-
 4 files changed, 132 insertions(+), 18 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index e6a0c39..48111d9 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -318,14 +318,8 @@ data_source_send(void *data, struct wl_data_source *source,
 }
 
 static void
-data_source_cancelled(void *data, struct wl_data_source *source)
+dnd_drag_destroy(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
-
-   /* The 'cancelled' event means that the source is no longer in
-* use by the drag (or current selection).  We need to clean
-* up the drag object created and the local state. */
-
wl_data_source_destroy(dnd_drag->data_source);
 
/* Destroy the item that has been dragged out */
@@ -339,10 +333,39 @@ data_source_cancelled(void *data, struct wl_data_source 
*source)
free(dnd_drag);
 }
 
+static void
+data_source_cancelled(void *data, struct wl_data_source *source)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   /* The 'cancelled' event means that the source is no longer in
+* use by the drag (or current selection).  We need to clean
+* up the drag object created and the local state. */
+   dnd_drag_destroy(dnd_drag);
+}
+
+static void
+data_source_drop_performed(void *data, struct wl_data_source *source)
+{
+}
+
+static void
+data_source_drag_finished(void *data, struct wl_data_source *source)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   /* The operation is already finished, we can destroy all
+* related data.
+*/
+   dnd_drag_destroy(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
-   data_source_cancelled
+   data_source_cancelled,
+   data_source_drop_performed,
+   data_source_drag_finished,
 };
 
 static cairo_surface_t *
diff --git a/clients/window.c b/clients/window.c
index 5d69116..c93edb1 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3726,6 +3726,7 @@ offer_io_func(struct task *task, uint32_t events)
 
if (len == 0) {
close(offer->fd);
+   wl_data_offer_finish(offer->offer);
data_offer_destroy(offer);
}
 }
@@ -5318,7 +5319,7 @@ registry_handle_global(void *data, struct wl_registry 
*registry, uint32_t id,
d->shm = wl_registry_bind(registry, id, _shm_interface, 1);
wl_shm_add_listener(d->shm, _listener, d);
} else if (strcmp(interface, "wl_data_device_manager") == 0) {
-   d->data_device_manager_version = MIN(version, 2);
+   d->data_device_manager_version = MIN(version, 3);
d->data_device_manager =
wl_registry_bind(registry, id,
 _data_device_manager_interface,
diff --git a/src/compositor.h b/src/compositor.h
index 130b258..8d6b051 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -317,6 +317,9 @@ struct weston_data_source {
struct wl_resource *resource;
struct wl_signal destroy_signal;
struct wl_array mime_types;
+   struct weston_data_offer *offer;
+   struct weston_seat *seat;
+   bool accepted;
 
void (*accept)(struct weston_data_source *source,
   uint32_t serial, const char *mime_type);
diff --git a/src/data-device.c b/src/data-device.c
index 54541b3..d2b89bb 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -62,12 +62,16 @@ data_offer_accept(struct wl_client *client, struct 
wl_resource *resource,
 {
struct weston_data_offer *offer = wl_resou

[PATCH weston v7 2/5] data-device: Implement DnD actions

[Carlos Garnacho]

The policy in weston in order to determine the chosen DnD action is
deliberately simple, and is probably the minimals that any compositor
should be doing here.

Besides honoring the set_actions requests on both wl_data_source and
wl_data_offer, weston now will emit the newly added "action" events
notifying both source and dest of the chosen action.

The "dnd" client has been updated too (although minimally), so it
notifies the compositor of a "move" action on both sides.

Changes since v6:
  - Emit errors as defined in DnD actions patch v10.

Changes since v5:
  - Use enum types and values for not-a-bitfield stored values.
handle errors when finding unexpected dnd_actions values.

Changes since v4:
  - Added compositor-side version checks. Spaces vs tabs fixes.
Fixed resource versioning. Initialized new weston_data_source/offer
fields.

Changes since v3:
  - Put data_source.action to use in the dnd client, now updates
the dnd surface like data_source.target events do.

Changes since v2:
  - Split from DnD progress notification changes.

Changes since v1:
  - Updated to v2 of DnD actions protocol changes, implement
wl_data_offer.source_actions.
  - Fixed coding style issues.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
---
 clients/dnd.c |  32 +--
 clients/window.c  |  25 
 src/compositor.h  |   5 ++
 src/data-device.c | 169 --
 4 files changed, 221 insertions(+), 10 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index 48111d9..ddf3fcc 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -72,6 +72,7 @@ struct dnd_drag {
struct item *item;
int x_offset, y_offset;
int width, height;
+   uint32_t dnd_action;
const char *mime_type;
 
struct wl_surface *drag_surface;
@@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
 }
 
 static void
-data_source_target(void *data,
-  struct wl_data_source *source, const char *mime_type)
+dnd_drag_update_surface(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
struct dnd *dnd = dnd_drag->dnd;
cairo_surface_t *surface;
struct wl_buffer *buffer;
 
-   dnd_drag->mime_type = mime_type;
-   if (mime_type)
+   if (dnd_drag->mime_type && dnd_drag->dnd_action)
surface = dnd_drag->opaque;
else
surface = dnd_drag->translucent;
@@ -288,6 +286,16 @@ data_source_target(void *data,
 }
 
 static void
+data_source_target(void *data,
+  struct wl_data_source *source, const char *mime_type)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->mime_type = mime_type;
+   dnd_drag_update_surface(dnd_drag);
+}
+
+static void
 data_source_send(void *data, struct wl_data_source *source,
 const char *mime_type, int32_t fd)
 {
@@ -360,12 +368,22 @@ data_source_drag_finished(void *data, struct 
wl_data_source *source)
dnd_drag_destroy(dnd_drag);
 }
 
+static void
+data_source_action(void *data, struct wl_data_source *source, uint32_t 
dnd_action)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->dnd_action = dnd_action;
+   dnd_drag_update_surface(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
data_source_cancelled,
data_source_drop_performed,
data_source_drag_finished,
+   data_source_action,
 };
 
 static cairo_surface_t *
@@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
dnd_drag->item = item;
dnd_drag->x_offset = x - item->x;
dnd_drag->y_offset = y - item->y;
+   dnd_drag->dnd_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
+   dnd_drag->mime_type = NULL;
 
for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
if (item == dnd->items[i]){
@@ -461,6 +481,8 @@ create_drag_source(struct dnd *dnd,
  window_get_wl_surface(dnd->window),
  dnd_drag->drag_surface,
  serial);
+   wl_data_source_set_actions(dnd_drag->data_source,
+  
WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE);
 
dnd_drag->opaque =
create_drag_icon(dnd_drag, item, x, y, 1);
diff --git a/clients/window.c b/clients/window.c
index c93edb1..db1fe57 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3323,6 +3323,8 @@ struct data_offer {
int fd;
data_func_t func;
int32_t x, y;
+   uint32_t dnd_action;
+   uint32_t source_actions;
void *user_

Re: [PATCH wayland 1/2] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

Hey,

On Wed, Dec 23, 2015 at 5:47 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> Hi again,
>
> I was reading an E-mail in another thread that brought up different
> types of backward compatibility promises, and it made me think of a
> potential issue. I'm commenting inline close to the relevant change this
> patch introduces.
>
> On Tue, Dec 22, 2015 at 02:33:32AM +0100, Carlos Garnacho wrote:
>> Currently, there's no means for the DnD origin to know whether the
>> destination is actually finished with the DnD transaction, short of
>> finalizing it after the first transfer finishes, or leaking it forever.
>>
>> But this poses other interoperation problems, drag destinations might
>> be requesting several mimetypes at once, might be just poking to find
>> out the most suitable format, might want to defer the action to a popup,
>> might be poking contents early before the selection was dropped...
>>
>> In addition, data_source.cancelled is suitable for the situations where
>> the DnD operation fails (not on a drop target, no matching mimetypes,
>> etc..), but seems undocumented for that use (and unused in weston's DnD).
>>
>> In order to improve the situation, the drag source should be notified
>> of all stages of DnD. In addition to documenting the "cancelled" event
>> for DnD purposes, The following 2 events have been added:
>>
>> - wl_data_source.dnd_drop_performed: Happens when the operation has been
>>   physically finished (eg. the button is released), it could be the right
>>   place to reset the pointer cursor back and undo any other state resulting
>>   from the initial button press.
>> - wl_data_source.dnd_finished: Happens when the destination side destroys
>>   the wl_data_offer, at this point the source can just forget all data
>>   related to the DnD selection as well, plus optionally deleting the data
>>   on move operations.
>>
>> Changes since v4:
>>   - Applied rewording suggestions from Jonas Ådahl. Added new
>> wl_data_offer.finish request to allow explicit finalization on the
>> destination side.
>>
>> Changes since v3:
>>   - Renamed dnd_performed to a more descriptive dnd_drop_performed,
>> documented backwards compatible behavior on wl_data_offer.accept and
>> wl_data_source.cancelled.
>>
>> Changes since v2:
>>   - Minor rewording.
>>
>> Changes since v1:
>>   - Renamed events to have a common "dnd" namespace. Made dnd_performed to
>> happen invariably, data_device.cancelled may still happen afterwards.
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
>> Reviewed-by: Jonas Ådahl <jad...@gmail.com>
>> Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
>> ---
>>  protocol/wayland.xml | 75 
>> +++-
>>  1 file changed, 69 insertions(+), 6 deletions(-)
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index df8ed19..ae5ef21 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -408,7 +408,7 @@
>>
>>
>>
>> -  
>> +  
>>  
>>A wl_data_offer represents a piece of data offered for transfer
>>by another client (the source client).  It is used by the
>> @@ -423,7 +423,17 @@
>>   Indicate that the client can accept the given mime type, or
>>   NULL for not accepted.
>>
>> - Used for feedback during drag-and-drop.
>> + For objects of version 2 or older, this request is used by the
>> + client to give feedback whether the client can receive the given
>> + mime type, or NULL if none is accepted; the feedback does not
>> + determine whether drag-and-drop operation succeeds or not.
>> +
>> + For objects of version 3 or newer, this request determines the
>> + final result of the drag-and-drop operation. If the end result
>> + is that no mime types was accepted, the drag-and-drop operation
>> + will be cancelled and the corresponding drag source will receive
>> + wl_data_source.cancelled. Clients may still use this event in
>> + conjunction with wl_data_source.action for feedback.
>
> As Pekka (CC:ed) wrote in a reply to the proxy version tracking thread
> [0], the kind of change that is introduced above is not really backward
> compatible. The possible issue would be, if I understand things
> correctly, that if we have a client split up into two separate parts (an
> application and a third pa

[PATCH weston 4/5] data-device: Implement compositor-chosen actions

[Carlos Garnacho]

Set up a keyboard grab during drag-and-drop, so we can translate
modifiers into preferred actions. The compositor chosen action
is stored in the current weston_data_source in order to make it
accessible to the source/offer at the time of calculating the new
action, but would conceptually be part of weston_drag.

The mapping has been made similar to what GTK+/QT usually do, the
shift key defaults to "move" and ctrl defaults to "copy".

Changes since v2:
  - Use enum types and values for the compositor action. Fix
code formatting issues.

Changes since v1:
  - Handle the keyboard grab being cancelled. Initialize new
wl_data_source fields.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 src/compositor.h  |  1 +
 src/data-device.c | 75 +++
 2 files changed, 76 insertions(+)

diff --git a/src/compositor.h b/src/compositor.h
index 2956f98..c5f9710 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -311,6 +311,7 @@ struct weston_data_source {
bool accepted;
uint32_t dnd_actions;
enum wl_data_device_manager_dnd_action current_dnd_action;
+   enum wl_data_device_manager_dnd_action compositor_action;
 
void (*accept)(struct weston_data_source *source,
   uint32_t serial, const char *mime_type);
diff --git a/src/data-device.c b/src/data-device.c
index ab81ba9..a304e91 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -44,6 +44,7 @@ struct weston_drag {
struct weston_view *icon;
struct wl_listener icon_destroy_listener;
int32_t dx, dy;
+   struct weston_keyboard_grab keyboard_grab;
 };
 
 struct weston_pointer_drag {
@@ -140,6 +141,9 @@ data_offer_choose_action(struct weston_data_offer *offer)
if (!available_actions)
return WL_DATA_DEVICE_MANAGER_DND_ACTION_NONE;
 
+   if (offer->source->compositor_action & available_actions)
+   return offer->source->compositor_action;
+
/* If the dest side has a preferred DnD action, use it */
if ((preferred_action & available_actions) != 0)
return preferred_action;
@@ -560,9 +564,11 @@ static void
 data_device_end_pointer_drag_grab(struct weston_pointer_drag *drag)
 {
struct weston_pointer *pointer = drag->grab.pointer;
+   struct weston_keyboard *keyboard = drag->base.keyboard_grab.keyboard;
 
data_device_end_drag_grab(>base, pointer->seat);
weston_pointer_end_grab(pointer);
+   weston_keyboard_end_grab(keyboard);
free(drag);
 }
 
@@ -629,9 +635,11 @@ static void
 data_device_end_touch_drag_grab(struct weston_touch_drag *drag)
 {
struct weston_touch *touch = drag->grab.touch;
+   struct weston_keyboard *keyboard = drag->base.keyboard_grab.keyboard;
 
data_device_end_drag_grab(>base, touch->seat);
weston_touch_end_grab(touch);
+   weston_keyboard_end_grab(keyboard);
free(drag);
 }
 
@@ -723,6 +731,61 @@ static const struct weston_touch_grab_interface 
touch_drag_grab_interface = {
 };
 
 static void
+drag_grab_keyboard_key(struct weston_keyboard_grab *grab,
+  uint32_t time, uint32_t key, uint32_t state)
+{
+}
+
+static void
+drag_grab_keyboard_modifiers(struct weston_keyboard_grab *grab,
+uint32_t serial, uint32_t mods_depressed,
+uint32_t mods_latched,
+uint32_t mods_locked, uint32_t group)
+{
+   struct weston_keyboard *keyboard = grab->keyboard;
+   struct weston_drag *drag =
+   container_of(grab, struct weston_drag, keyboard_grab);
+   uint32_t compositor_action;
+
+   if (mods_depressed & (1 << keyboard->xkb_info->shift_mod))
+   compositor_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
+   else if (mods_depressed & (1 << keyboard->xkb_info->ctrl_mod))
+   compositor_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY;
+   else
+   compositor_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_NONE;
+
+   drag->data_source->compositor_action = compositor_action;
+
+   if (drag->data_source->offer)
+   data_offer_update_action(drag->data_source->offer);
+}
+
+static void
+drag_grab_keyboard_cancel(struct weston_keyboard_grab *grab)
+{
+   struct weston_drag *drag =
+   container_of(grab, struct weston_drag, keyboard_grab);
+   struct weston_pointer *pointer = grab->keyboard->seat->pointer_state;
+   struct weston_touch *touch = grab->keyboard->seat->touch_state;
+
+   if (pointer && pointer->grab->interface == 
_drag_grab_interface) {
+   struct weston_touch_drag *touch_drag =
+   (struct weston_touch_drag *)

[PATCH wayland v8 1/2] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

Currently, there's no means for the DnD origin to know whether the
destination is actually finished with the DnD transaction, short of
finalizing it after the first transfer finishes, or leaking it forever.

But this poses other interoperation problems, drag destinations might
be requesting several mimetypes at once, might be just poking to find
out the most suitable format, might want to defer the action to a popup,
might be poking contents early before the selection was dropped...

In addition, data_source.cancelled is suitable for the situations where
the DnD operation fails (not on a drop target, no matching mimetypes,
etc..), but seems undocumented for that use (and unused in weston's DnD).

In order to improve the situation, the drag source should be notified
of all stages of DnD. In addition to documenting the "cancelled" event
for DnD purposes, The following 2 events have been added:

- wl_data_source.dnd_drop_performed: Happens when the operation has been
  physically finished (eg. the button is released), it could be the right
  place to reset the pointer cursor back and undo any other state resulting
  from the initial button press.
- wl_data_source.dnd_finished: Happens when the destination side destroys
  the wl_data_offer, at this point the source can just forget all data
  related to the DnD selection as well, plus optionally deleting the data
  on move operations.

Changes since v6:
  - Turned wl_data_offer.finish calls with 0/NULL state/mimetype an
error, made it explicit that it will only result in
wl_data_offer.dnd_finished being sent if successful.

Changes since v5:
  - Further rewording of wl_data_offer.finish and wl_data_offer.accept.
Added error for untimely wl_data_offer.finish requests.

Changes since v4:
  - Applied rewording suggestions from Jonas Ådahl. Added new
wl_data_offer.finish request to allow explicit finalization on the
destination side.

Changes since v3:
  - Renamed dnd_performed to a more descriptive dnd_drop_performed,
documented backwards compatible behavior on wl_data_offer.accept and
wl_data_source.cancelled.

Changes since v2:
  - Minor rewording.

Changes since v1:
  - Renamed events to have a common "dnd" namespace. Made dnd_performed to
happen invariably, data_device.cancelled may still happen afterwards.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
---
 protocol/wayland.xml | 87 
 1 file changed, 81 insertions(+), 6 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index df8ed19..fb81542 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -408,7 +408,7 @@
   
 
 
-  
+  
 
   A wl_data_offer represents a piece of data offered for transfer
   by another client (the source client).  It is used by the
@@ -418,12 +418,27 @@
   data directly from the source client.
 
 
+
+  
+
+
 
   
Indicate that the client can accept the given mime type, or
NULL for not accepted.
 
-   Used for feedback during drag-and-drop.
+   For objects of version 2 or older, this request is used by the
+   client to give feedback whether the client can receive the given
+   mime type, or NULL if none is accepted; the feedback does not
+   determine whether drag-and-drop operation succeeds or not.
+
+   For objects of version 3 or newer, this request determines the
+   final result of the drag-and-drop operation. If the end result
+   is that no mime types was accepted, the drag-and-drop operation
+   will be cancelled and the corresponding drag source will receive
+   wl_data_source.cancelled. Clients may still use this event in
+   conjunction with wl_data_source.action for feedback.
   
 
   
@@ -442,6 +457,11 @@
The receiving client reads from the read end of the pipe until
EOF and then closes its end, at which point the transfer is
complete.
+
+   This request may happen multiple times for different mimetypes,
+   both before and after wl_data_device.drop. Drag-and-drop destination
+   clients may preemptively fetch data or examine it more closely to
+   determine acceptance.
   
   
   
@@ -461,9 +481,26 @@
 
   
 
+
+
+
+
+  
+   Notifies the compositor that the drag destination successfully
+   finished the drag-and-drop operation.
+
+   Upon receiving this request, the compositor will emit
+   wl_data_source.dnd_finished on the drag source client.
+
+   It is a client error to perform other requests than
+   wl_data_offer.destroy after this one. It is also an error to perform
+   this request after a NULL mime type 

[PATCH wayland v8 2/2] protocol: Add DnD actions

[Carlos Garnacho]

These 2 requests have been added:

- wl_data_source.set_actions: Notifies the compositor of the available
  actions on the data source.
- wl_data_offer.set_actions: Notifies the compositor of the available
  actions on the destination side, plus the preferred action.

Out of the data from these requests, the compositor can determine the action
both parts agree on (and let the user play a role through eg. keyboard
modifiers). The chosen option will be notified to both parties
through the following two requests:

- wl_data_source.action
- wl_data_offer.action

In addition, the destination side can peek the source side actions through
wl_data_offer.source_actions.

Compared to the XDND protocol, there's two notable changes:

- XDND lets the source suggest an action, whereas wl_data_device lets
  the destination prefer a given action. The difference is subtle here,
  it comes off as convenience because it is the drag destination which
  receives the motion events (unlike in X) and can perform action updates.

  The drag destination seems also in a better position to update the
  preferred action based on things like the data being transferred, the
  place being dropped, and whether the drag is client-local.

- That same source-side preferred action is used in XDND to convey the
  modifier-induced action to the drag destination, which would then ack
  it, or reply with another action that's accepted (or none), this makes
  the XdndPosition/XdndStatus messaging very verbose, and synchronous
  because the drag source always needs to know the latest status/action
  for every position+action sent.

  Here it's the compositor which takes care of modifiers and matching
  available/accepted actions, this allows for the signaling to happen
  only whenever the actions/modifiers change for real.

Roughly based on previous work by Giulio Camuffo <giuliocamu...@gmail.com>

Changes since v7:
- Misc changes after updating the progress notification patch.

Changes since v6:
- Further explanations on wl_data_source/offer.set_actions, including a
  description of "ask" actions. Added protocol errors for unknown action
  values.

Changes since v5:
- Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
  scheme for actions. Fixed indentation and other minor formatting issues.

Changes since v4:
- Minor rewording.

Changes since v3:
- Splitted from DnD progress notification changes.
- Further rationales in commit log.

Changes since v2:
- Renamed notify_actions to set_actions on both sides, seems more consistent
  with the rest of the protocol.
- Spelled out better which events may be triggered on the compositor side
  by the requests, the circumstances in which events are emitted, and
  what are events useful for in clients.
- Defined a minimal common ground wrt compositor-side action picking and
  keybindings.
- Acknowledge the possibility of compositor/toolkit defined actions, even
  though none are used at the moment.
Changes since v1:
- Added wl_data_offer.source_actions to let know of the actions offered
  by a data source.
- Renamed wl_data_source.finished to "drag_finished" for clarity
- Improved wording as suggested by Bryce

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
---
 protocol/wayland.xml | 163 ++-
 1 file changed, 162 insertions(+), 1 deletion(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index fb81542..4690e0e 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -421,6 +421,10 @@
 
   
+  
+  
 
 
 
@@ -495,9 +499,81 @@
It is a client error to perform other requests than
wl_data_offer.destroy after this one. It is also an error to perform
this request after a NULL mime type has been set in
-   wl_data_offer.accept.
+   wl_data_offer.accept or no action was received through
+   wl_data_offer.action.
   
 
+
+
+  
+   Sets the actions that the destination side client supports for
+   this operation. This request may trigger the emission of
+   wl_data_source.action and wl_data_offer.action events if the compositor
+   needs changing the selected action.
+
+   This request can be called multiple times throughout the
+   drag-and-drop operation, typically in response to wl_data_device.enter
+   or wl_data_device.motion events.
+
+   This request determines the final result of the drag-and-drop
+   operation. If the end result is that no action is accepted,
+   the drag source will receive wl_drag_source.cancelled.
+
+   The dnd_actions argument must contain only values expressed in the
+   wl_data_device_manager.dnd_actions enum, and the preferred_action
+   argument must only contain one of those values set, otherwis

[PATCH weston v7 2/5] data-device: Implement DnD actions

[Carlos Garnacho]

The policy in weston in order to determine the chosen DnD action is
deliberately simple, and is probably the minimals that any compositor
should be doing here.

Besides honoring the set_actions requests on both wl_data_source and
wl_data_offer, weston now will emit the newly added "action" events
notifying both source and dest of the chosen action.

The "dnd" client has been updated too (although minimally), so it
notifies the compositor of a "move" action on both sides.

Changes since v6:
  - Misc changes after updating the previous patch to make
wl_data_offer.finish with the wrong state an error.

Changes since v5:
  - Use enum types and values for not-a-bitfield stored values.
handle errors when finding unexpected dnd_actions values.

Changes since v4:
  - Added compositor-side version checks. Spaces vs tabs fixes.
Fixed resource versioning. Initialized new weston_data_source/offer
fields.

Changes since v3:
  - Put data_source.action to use in the dnd client, now updates
the dnd surface like data_source.target events do.

Changes since v2:
  - Split from DnD progress notification changes.

Changes since v1:
  - Updated to v2 of DnD actions protocol changes, implement
wl_data_offer.source_actions.
  - Fixed coding style issues.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
---
 clients/dnd.c |  32 ++---
 clients/window.c  |  25 +++
 src/compositor.h  |   4 ++
 src/data-device.c | 131 --
 4 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index 48111d9..ddf3fcc 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -72,6 +72,7 @@ struct dnd_drag {
struct item *item;
int x_offset, y_offset;
int width, height;
+   uint32_t dnd_action;
const char *mime_type;
 
struct wl_surface *drag_surface;
@@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
 }
 
 static void
-data_source_target(void *data,
-  struct wl_data_source *source, const char *mime_type)
+dnd_drag_update_surface(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
struct dnd *dnd = dnd_drag->dnd;
cairo_surface_t *surface;
struct wl_buffer *buffer;
 
-   dnd_drag->mime_type = mime_type;
-   if (mime_type)
+   if (dnd_drag->mime_type && dnd_drag->dnd_action)
surface = dnd_drag->opaque;
else
surface = dnd_drag->translucent;
@@ -288,6 +286,16 @@ data_source_target(void *data,
 }
 
 static void
+data_source_target(void *data,
+  struct wl_data_source *source, const char *mime_type)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->mime_type = mime_type;
+   dnd_drag_update_surface(dnd_drag);
+}
+
+static void
 data_source_send(void *data, struct wl_data_source *source,
 const char *mime_type, int32_t fd)
 {
@@ -360,12 +368,22 @@ data_source_drag_finished(void *data, struct 
wl_data_source *source)
dnd_drag_destroy(dnd_drag);
 }
 
+static void
+data_source_action(void *data, struct wl_data_source *source, uint32_t 
dnd_action)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->dnd_action = dnd_action;
+   dnd_drag_update_surface(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
data_source_cancelled,
data_source_drop_performed,
data_source_drag_finished,
+   data_source_action,
 };
 
 static cairo_surface_t *
@@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
dnd_drag->item = item;
dnd_drag->x_offset = x - item->x;
dnd_drag->y_offset = y - item->y;
+   dnd_drag->dnd_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
+   dnd_drag->mime_type = NULL;
 
for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
if (item == dnd->items[i]){
@@ -461,6 +481,8 @@ create_drag_source(struct dnd *dnd,
  window_get_wl_surface(dnd->window),
  dnd_drag->drag_surface,
  serial);
+   wl_data_source_set_actions(dnd_drag->data_source,
+  
WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE);
 
dnd_drag->opaque =
create_drag_icon(dnd_drag, item, x, y, 1);
diff --git a/clients/window.c b/clients/window.c
index db96185..9c67b91 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3362,6 +3362,8 @@ struct data_offer {
int fd;
data_func_t func;
int32_t x, y;
+   uint32_t

[PATCH weston v5 1/5] data-device: Implement DnD progress notification

[Carlos Garnacho]

Weston now sends wl_data_source.dnd_drop_performed and .dnd_finished in
order to notify about the different phases of DnD.

wl_data_source.cancelled is also used as mentioned in the docs, being
emitted also on DnD when the operation is meant to fail (eg. source
and dest didn't agree on a mimetype).

The dnd demo is also fixed so the struct dnd_drag isn't leaked.

https://bugs.freedesktop.org/show_bug.cgi?id=91943
https://bugs.freedesktop.org/show_bug.cgi?id=91944

Changes since v4:
  - Make wl_data_offer.finish with the wrong state an error.

Changes since v3:
  - Fixed wl_data_source.dnd_finished vs cancelled emission on
when interoperating with version < 3 drag destinations.

Changes since v2:
  - Handle wl_data_offer.finish. Fixed commit log inconsistencies.
Added version checks. Spaces vs tabs fixes. Fixed resource
versioning.

Changes since v1:
  - Updated to protocol v2.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
---
 clients/dnd.c |  39 -
 clients/window.c  |   3 +-
 src/compositor.h  |   3 ++
 src/data-device.c | 102 +-
 4 files changed, 129 insertions(+), 18 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index e6a0c39..48111d9 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -318,14 +318,8 @@ data_source_send(void *data, struct wl_data_source *source,
 }
 
 static void
-data_source_cancelled(void *data, struct wl_data_source *source)
+dnd_drag_destroy(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
-
-   /* The 'cancelled' event means that the source is no longer in
-* use by the drag (or current selection).  We need to clean
-* up the drag object created and the local state. */
-
wl_data_source_destroy(dnd_drag->data_source);
 
/* Destroy the item that has been dragged out */
@@ -339,10 +333,39 @@ data_source_cancelled(void *data, struct wl_data_source 
*source)
free(dnd_drag);
 }
 
+static void
+data_source_cancelled(void *data, struct wl_data_source *source)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   /* The 'cancelled' event means that the source is no longer in
+* use by the drag (or current selection).  We need to clean
+* up the drag object created and the local state. */
+   dnd_drag_destroy(dnd_drag);
+}
+
+static void
+data_source_drop_performed(void *data, struct wl_data_source *source)
+{
+}
+
+static void
+data_source_drag_finished(void *data, struct wl_data_source *source)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   /* The operation is already finished, we can destroy all
+* related data.
+*/
+   dnd_drag_destroy(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
-   data_source_cancelled
+   data_source_cancelled,
+   data_source_drop_performed,
+   data_source_drag_finished,
 };
 
 static cairo_surface_t *
diff --git a/clients/window.c b/clients/window.c
index 47628de..db96185 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3765,6 +3765,7 @@ offer_io_func(struct task *task, uint32_t events)
 
if (len == 0) {
close(offer->fd);
+   wl_data_offer_finish(offer->offer);
data_offer_destroy(offer);
}
 }
@@ -5376,7 +5377,7 @@ registry_handle_global(void *data, struct wl_registry 
*registry, uint32_t id,
d->shm = wl_registry_bind(registry, id, _shm_interface, 1);
wl_shm_add_listener(d->shm, _listener, d);
} else if (strcmp(interface, "wl_data_device_manager") == 0) {
-   d->data_device_manager_version = MIN(version, 2);
+   d->data_device_manager_version = MIN(version, 3);
d->data_device_manager =
wl_registry_bind(registry, id,
 _data_device_manager_interface,
diff --git a/src/compositor.h b/src/compositor.h
index 4443c72..83d6f7f 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -304,6 +304,9 @@ struct weston_data_source {
struct wl_resource *resource;
struct wl_signal destroy_signal;
struct wl_array mime_types;
+   struct weston_data_offer *offer;
+   struct weston_seat *seat;
+   bool accepted;
 
void (*accept)(struct weston_data_source *source,
   uint32_t serial, const char *mime_type);
diff --git a/src/data-device.c b/src/data-device.c
index 1612091..01b19e1 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -62,12 +62,16 @@ data_offer_accept(struct wl_client *client, struct 
wl_resource *resource,
 {
struct weston_data_offer *offer = wl_resource_get_user_data(resource);
 
+   /* Protect against untimely calls from older data offers */
+   if

[PATCH weston 2/5] data-device: Implement DnD actions

[Carlos Garnacho]

The policy in weston in order to determine the chosen DnD action is
deliberately simple, and is probably the minimals that any compositor
should be doing here.

Besides honoring the set_actions requests on both wl_data_source and
wl_data_offer, weston now will emit the newly added "action" events
notifying both source and dest of the chosen action.

The "dnd" client has been updated too (although minimally), so it
notifies the compositor of a "move" action on both sides.

Changes since v5:
  - Use enum types and values for not-a-bitfield stored values.
handle errors when finding unexpected dnd_actions values.

Changes since v4:
  - Added compositor-side version checks. Spaces vs tabs fixes.
Fixed resource versioning. Initialized new weston_data_source/offer
fields.

Changes since v3:
  - Put data_source.action to use in the dnd client, now updates
the dnd surface like data_source.target events do.

Changes since v2:
  - Split from DnD progress notification changes.

Changes since v1:
  - Updated to v2 of DnD actions protocol changes, implement
wl_data_offer.source_actions.
  - Fixed coding style issues.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
---
 clients/dnd.c |  32 ++---
 clients/window.c  |  25 +++
 src/compositor.h  |   4 ++
 src/data-device.c | 131 --
 4 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index 48111d9..ddf3fcc 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -72,6 +72,7 @@ struct dnd_drag {
struct item *item;
int x_offset, y_offset;
int width, height;
+   uint32_t dnd_action;
const char *mime_type;
 
struct wl_surface *drag_surface;
@@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
 }
 
 static void
-data_source_target(void *data,
-  struct wl_data_source *source, const char *mime_type)
+dnd_drag_update_surface(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
struct dnd *dnd = dnd_drag->dnd;
cairo_surface_t *surface;
struct wl_buffer *buffer;
 
-   dnd_drag->mime_type = mime_type;
-   if (mime_type)
+   if (dnd_drag->mime_type && dnd_drag->dnd_action)
surface = dnd_drag->opaque;
else
surface = dnd_drag->translucent;
@@ -288,6 +286,16 @@ data_source_target(void *data,
 }
 
 static void
+data_source_target(void *data,
+  struct wl_data_source *source, const char *mime_type)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->mime_type = mime_type;
+   dnd_drag_update_surface(dnd_drag);
+}
+
+static void
 data_source_send(void *data, struct wl_data_source *source,
 const char *mime_type, int32_t fd)
 {
@@ -360,12 +368,22 @@ data_source_drag_finished(void *data, struct 
wl_data_source *source)
dnd_drag_destroy(dnd_drag);
 }
 
+static void
+data_source_action(void *data, struct wl_data_source *source, uint32_t 
dnd_action)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->dnd_action = dnd_action;
+   dnd_drag_update_surface(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
data_source_cancelled,
data_source_drop_performed,
data_source_drag_finished,
+   data_source_action,
 };
 
 static cairo_surface_t *
@@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
dnd_drag->item = item;
dnd_drag->x_offset = x - item->x;
dnd_drag->y_offset = y - item->y;
+   dnd_drag->dnd_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
+   dnd_drag->mime_type = NULL;
 
for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
if (item == dnd->items[i]){
@@ -461,6 +481,8 @@ create_drag_source(struct dnd *dnd,
  window_get_wl_surface(dnd->window),
  dnd_drag->drag_surface,
  serial);
+   wl_data_source_set_actions(dnd_drag->data_source,
+  
WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE);
 
dnd_drag->opaque =
create_drag_icon(dnd_drag, item, x, y, 1);
diff --git a/clients/window.c b/clients/window.c
index db96185..9c67b91 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3362,6 +3362,8 @@ struct data_offer {
int fd;
data_func_t func;
int32_t x, y;
+   uint32_t dnd_action;
+   uint32_t source_actions;
void *user_data;
 };
 
@@ -3375,8 +3377,26 @@ data_offer_offer(void *data, struct w

[PATCH weston 5/5] dnd: Turn into a full blown example

[Carlos Garnacho]

In order to keep things simple, weston-dnd made a few choices that
turn out to be unrealistic, a few tweaks have been done to make it
less of a playground demo:

- It now caters for copy/move operations, instead of just move,
  which still remains the default nonetheless.
- As "move" operations are no longer assumed, the item isn't removed
  on start_drag, instead it is made translucent until the drag
  operation finishes (and we know whether the item is to be
  removed after transfer or left as is)
- For the same reasons, "Drop nowhere to delete item" no longer
  happens. Drag-and-drop is a failable operation and must not result
  in data loss.
- As multiple actions are now allowed, we set the pointer icon
  surface accordingly to the current operation.

This makes weston-dnd a better example of what applications usually
want to do here.

Changes since v1:
  - Remove unneeded include. Remove extra newlines. Other minor
code fixes.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 clients/dnd.c | 92 ---
 1 file changed, 69 insertions(+), 23 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index ddf3fcc..4b32be5 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -190,7 +190,7 @@ dnd_redraw_handler(struct widget *widget, void *data)
struct dnd *dnd = data;
struct rectangle allocation;
cairo_t *cr;
-   cairo_surface_t *surface;
+   cairo_surface_t *surface, *item_surface;
unsigned int i;
 
surface = window_get_surface(dnd->window);
@@ -210,7 +210,13 @@ dnd_redraw_handler(struct widget *widget, void *data)
for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
if (!dnd->items[i])
continue;
-   cairo_set_source_surface(cr, dnd->items[i]->surface,
+
+   if (dnd->current_drag && dnd->items[i] == 
dnd->current_drag->item)
+   item_surface = dnd->current_drag->translucent;
+   else
+   item_surface = dnd->items[i]->surface;
+
+   cairo_set_source_surface(cr, item_surface,
 dnd->items[i]->x + allocation.x,
 dnd->items[i]->y + allocation.y);
cairo_paint(cr);
@@ -266,6 +272,30 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
return NULL;
 }
 
+static int
+lookup_dnd_cursor(uint32_t dnd_action)
+{
+   if (dnd_action == WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE)
+   return CURSOR_DND_MOVE;
+   else if (dnd_action == WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY)
+   return CURSOR_DND_COPY;
+
+   return CURSOR_DND_FORBIDDEN;
+}
+
+static void
+dnd_drag_update_cursor(struct dnd_drag *dnd_drag)
+{
+   int cursor;
+
+   if (dnd_drag->mime_type == NULL)
+   cursor = CURSOR_DND_FORBIDDEN;
+   else
+   cursor = lookup_dnd_cursor(dnd_drag->dnd_action);
+
+   input_set_pointer_image(dnd_drag->input, cursor);
+}
+
 static void
 dnd_drag_update_surface(struct dnd_drag *dnd_drag)
 {
@@ -293,6 +323,7 @@ data_source_target(void *data,
 
dnd_drag->mime_type = mime_type;
dnd_drag_update_surface(dnd_drag);
+   dnd_drag_update_cursor(dnd_drag);
 }
 
 static void
@@ -326,13 +357,27 @@ data_source_send(void *data, struct wl_data_source 
*source,
 }
 
 static void
-dnd_drag_destroy(struct dnd_drag *dnd_drag)
+dnd_drag_destroy(struct dnd_drag *dnd_drag, bool delete_item)
 {
+   struct dnd *dnd = dnd_drag->dnd;
+   unsigned int i;
+
wl_data_source_destroy(dnd_drag->data_source);
 
-   /* Destroy the item that has been dragged out */
-   cairo_surface_destroy(dnd_drag->item->surface);
-   free(dnd_drag->item);
+   if (delete_item) {
+   for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
+   if (dnd_drag->item == dnd->items[i]) {
+   dnd->items[i] = NULL;
+   break;
+   }
+   }
+
+   /* Destroy the item that has been dragged out */
+   cairo_surface_destroy(dnd_drag->item->surface);
+   free(dnd_drag->item);
+   }
+
+   dnd->current_drag = NULL;
 
wl_surface_destroy(dnd_drag->drag_surface);
 
@@ -345,11 +390,13 @@ static void
 data_source_cancelled(void *data, struct wl_data_source *source)
 {
struct dnd_drag *dnd_drag = data;
+   struct dnd *dnd = dnd_drag->dnd;
 
/* The 'cancelled' event means that the source is no longer in
 * use by the drag (or current selection).  We need to clean
 * up the drag object created and the local state. */
-   dnd_drag_dest

[PATCH weston 1/5] data-device: Implement DnD progress notification

[Carlos Garnacho]

Weston now sends wl_data_source.dnd_drop_performed and .dnd_finished in
order to notify about the different phases of DnD.

wl_data_source.cancelled is also used as mentioned in the docs, being
emitted also on DnD when the operation is meant to fail (eg. source
and dest didn't agree on a mimetype).

The dnd demo is also fixed so the struct dnd_drag isn't leaked.

https://bugs.freedesktop.org/show_bug.cgi?id=91943
https://bugs.freedesktop.org/show_bug.cgi?id=91944

Changes since v3:
  - Fixed wl_data_source.dnd_finished vs cancelled emission on
when interoperating with version < 3 drag destinations.

Changes since v2:
  - Handle wl_data_offer.finish. Fixed commit log inconsistencies.
Added version checks. Spaces vs tabs fixes. Fixed resource
versioning.

Changes since v1:
  - Updated to protocol v2.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
---
 clients/dnd.c | 39 ++-
 clients/window.c  |  3 +-
 src/compositor.h  |  3 ++
 src/data-device.c | 92 +--
 4 files changed, 119 insertions(+), 18 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index e6a0c39..48111d9 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -318,14 +318,8 @@ data_source_send(void *data, struct wl_data_source *source,
 }
 
 static void
-data_source_cancelled(void *data, struct wl_data_source *source)
+dnd_drag_destroy(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
-
-   /* The 'cancelled' event means that the source is no longer in
-* use by the drag (or current selection).  We need to clean
-* up the drag object created and the local state. */
-
wl_data_source_destroy(dnd_drag->data_source);
 
/* Destroy the item that has been dragged out */
@@ -339,10 +333,39 @@ data_source_cancelled(void *data, struct wl_data_source 
*source)
free(dnd_drag);
 }
 
+static void
+data_source_cancelled(void *data, struct wl_data_source *source)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   /* The 'cancelled' event means that the source is no longer in
+* use by the drag (or current selection).  We need to clean
+* up the drag object created and the local state. */
+   dnd_drag_destroy(dnd_drag);
+}
+
+static void
+data_source_drop_performed(void *data, struct wl_data_source *source)
+{
+}
+
+static void
+data_source_drag_finished(void *data, struct wl_data_source *source)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   /* The operation is already finished, we can destroy all
+* related data.
+*/
+   dnd_drag_destroy(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
-   data_source_cancelled
+   data_source_cancelled,
+   data_source_drop_performed,
+   data_source_drag_finished,
 };
 
 static cairo_surface_t *
diff --git a/clients/window.c b/clients/window.c
index 47628de..db96185 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3765,6 +3765,7 @@ offer_io_func(struct task *task, uint32_t events)
 
if (len == 0) {
close(offer->fd);
+   wl_data_offer_finish(offer->offer);
data_offer_destroy(offer);
}
 }
@@ -5376,7 +5377,7 @@ registry_handle_global(void *data, struct wl_registry 
*registry, uint32_t id,
d->shm = wl_registry_bind(registry, id, _shm_interface, 1);
wl_shm_add_listener(d->shm, _listener, d);
} else if (strcmp(interface, "wl_data_device_manager") == 0) {
-   d->data_device_manager_version = MIN(version, 2);
+   d->data_device_manager_version = MIN(version, 3);
d->data_device_manager =
wl_registry_bind(registry, id,
 _data_device_manager_interface,
diff --git a/src/compositor.h b/src/compositor.h
index 4443c72..83d6f7f 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -304,6 +304,9 @@ struct weston_data_source {
struct wl_resource *resource;
struct wl_signal destroy_signal;
struct wl_array mime_types;
+   struct weston_data_offer *offer;
+   struct weston_seat *seat;
+   bool accepted;
 
void (*accept)(struct weston_data_source *source,
   uint32_t serial, const char *mime_type);
diff --git a/src/data-device.c b/src/data-device.c
index 1612091..9942a66 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -62,12 +62,16 @@ data_offer_accept(struct wl_client *client, struct 
wl_resource *resource,
 {
struct weston_data_offer *offer = wl_resource_get_user_data(resource);
 
+   /* Protect against untimely calls from older data offers */
+   if (!offer->source || offer != offer->source->offer)
+   return;

[PATCH weston 3/5] client: Add DnD cursors to the managed cursors list

[Carlos Garnacho]

That way we'll be able to set the corresponding pointer surface to
a current DnD operation.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 clients/window.c | 16 
 clients/window.h |  3 +++
 2 files changed, 19 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index 9c67b91..4666bb9 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -1266,6 +1266,19 @@ static const char *watches[] = {
"0426c94ea35c87780ff01dc239897213"
 };
 
+static const char *move_draggings[] = {
+   "dnd-move"
+};
+
+static const char *copy_draggings[] = {
+   "dnd-copy"
+};
+
+static const char *forbidden_draggings[] = {
+   "dnd-none",
+   "dnd-no-drop"
+};
+
 struct cursor_alternatives {
const char **names;
size_t count;
@@ -1285,6 +1298,9 @@ static const struct cursor_alternatives cursors[] = {
{xterms, ARRAY_LENGTH(xterms)},
{hand1s, ARRAY_LENGTH(hand1s)},
{watches, ARRAY_LENGTH(watches)},
+   {move_draggings, ARRAY_LENGTH(move_draggings)},
+   {copy_draggings, ARRAY_LENGTH(copy_draggings)},
+   {forbidden_draggings, ARRAY_LENGTH(forbidden_draggings)},
 };
 
 static void
diff --git a/clients/window.h b/clients/window.h
index b61a62a..1200f01 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -189,6 +189,9 @@ enum cursor_type {
CURSOR_IBEAM,
CURSOR_HAND1,
CURSOR_WATCH,
+   CURSOR_DND_MOVE,
+   CURSOR_DND_COPY,
+   CURSOR_DND_FORBIDDEN,
 
CURSOR_BLANK
 };
-- 
2.5.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland 2/2] protocol: Add DnD actions

[Carlos Garnacho]

These 2 requests have been added:

- wl_data_source.set_actions: Notifies the compositor of the available
  actions on the data source.
- wl_data_offer.set_actions: Notifies the compositor of the available
  actions on the destination side, plus the preferred action.

Out of the data from these requests, the compositor can determine the action
both parts agree on (and let the user play a role through eg. keyboard
modifiers). The chosen option will be notified to both parties
through the following two requests:

- wl_data_source.action
- wl_data_offer.action

In addition, the destination side can peek the source side actions through
wl_data_offer.source_actions.

Compared to the XDND protocol, there's two notable changes:

- XDND lets the source suggest an action, whereas wl_data_device lets
  the destination prefer a given action. The difference is subtle here,
  it comes off as convenience because it is the drag destination which
  receives the motion events (unlike in X) and can perform action updates.

  The drag destination seems also in a better position to update the
  preferred action based on things like the data being transferred, the
  place being dropped, and whether the drag is client-local.

- That same source-side preferred action is used in XDND to convey the
  modifier-induced action to the drag destination, which would then ack
  it, or reply with another action that's accepted (or none), this makes
  the XdndPosition/XdndStatus messaging very verbose, and synchronous
  because the drag source always needs to know the latest status/action
  for every position+action sent.

  Here it's the compositor which takes care of modifiers and matching
  available/accepted actions, this allows for the signaling to happen
  only whenever the actions/modifiers change for real.

Roughly based on previous work by Giulio Camuffo <giuliocamu...@gmail.com>

Changes since v6:
- Further explanations on wl_data_source/offer.set_actions, including a
  description of "ask" actions. Added protocol errors for unknown action
  values.

Changes since v5:
- Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
  scheme for actions. Fixed indentation and other minor formatting issues.

Changes since v4:
- Minor rewording.

Changes since v3:
- Splitted from DnD progress notification changes.
- Further rationales in commit log.

Changes since v2:
- Renamed notify_actions to set_actions on both sides, seems more consistent
  with the rest of the protocol.
- Spelled out better which events may be triggered on the compositor side
  by the requests, the circumstances in which events are emitted, and
  what are events useful for in clients.
- Defined a minimal common ground wrt compositor-side action picking and
  keybindings.
- Acknowledge the possibility of compositor/toolkit defined actions, even
  though none are used at the moment.
Changes since v1:
- Added wl_data_offer.source_actions to let know of the actions offered
  by a data source.
- Renamed wl_data_source.finished to "drag_finished" for clarity
- Improved wording as suggested by Bryce

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
---
 protocol/wayland.xml | 164 ++-
 1 file changed, 162 insertions(+), 2 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 98e2148..45fbec5 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -421,6 +421,10 @@
 
   
+  
+  
 
 
 
@@ -491,13 +495,84 @@
 
Upon receiving this request, the compositor will emit
wl_data_source.drag_finished or wl_data_source.cancelled on the drag
-   source client depending on the most recent wl_data_offer.accept
-   request received from this offer.
+   source client depending on the most recent wl_data_offer.accept and
+   wl_data_offer.set_actions requests received from this offer.
 
It is a client error to perform other requests than
wl_data_offer.destroy after this one.
   
 
+
+
+  
+   Sets the actions that the destination side client supports for
+   this operation. This request may trigger the emission of
+   wl_data_source.action and wl_data_offer.action events if the compositor
+   needs changing the selected action.
+
+   This request can be called multiple times throughout the
+   drag-and-drop operation, typically in response to wl_data_device.enter
+   or wl_data_device.motion events.
+
+   This request determines the final result of the drag-and-drop
+   operation. If the end result is that no action is accepted,
+   the drag source will receive wl_drag_source.cancelled.
+
+   The dnd_actions argument must contain only values expressed in the
+   wl_data_device_manager.dnd_actions enum, and the

[PATCH wayland 1/2] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

Currently, there's no means for the DnD origin to know whether the
destination is actually finished with the DnD transaction, short of
finalizing it after the first transfer finishes, or leaking it forever.

But this poses other interoperation problems, drag destinations might
be requesting several mimetypes at once, might be just poking to find
out the most suitable format, might want to defer the action to a popup,
might be poking contents early before the selection was dropped...

In addition, data_source.cancelled is suitable for the situations where
the DnD operation fails (not on a drop target, no matching mimetypes,
etc..), but seems undocumented for that use (and unused in weston's DnD).

In order to improve the situation, the drag source should be notified
of all stages of DnD. In addition to documenting the "cancelled" event
for DnD purposes, The following 2 events have been added:

- wl_data_source.dnd_drop_performed: Happens when the operation has been
  physically finished (eg. the button is released), it could be the right
  place to reset the pointer cursor back and undo any other state resulting
  from the initial button press.
- wl_data_source.dnd_finished: Happens when the destination side destroys
  the wl_data_offer, at this point the source can just forget all data
  related to the DnD selection as well, plus optionally deleting the data
  on move operations.

Changes since v5:
  - Further rewording of wl_data_offer.finish and wl_data_offer.accept.
Added error for untimely wl_data_offer.finish requests.

Changes since v4:
  - Applied rewording suggestions from Jonas Ådahl. Added new
wl_data_offer.finish request to allow explicit finalization on the
destination side.

Changes since v3:
  - Renamed dnd_performed to a more descriptive dnd_drop_performed,
documented backwards compatible behavior on wl_data_offer.accept and
wl_data_source.cancelled.

Changes since v2:
  - Minor rewording.

Changes since v1:
  - Renamed events to have a common "dnd" namespace. Made dnd_performed to
happen invariably, data_device.cancelled may still happen afterwards.

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
---
 protocol/wayland.xml | 87 
 1 file changed, 81 insertions(+), 6 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index df8ed19..98e2148 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -408,7 +408,7 @@
   
 
 
-  
+  
 
   A wl_data_offer represents a piece of data offered for transfer
   by another client (the source client).  It is used by the
@@ -418,12 +418,27 @@
   data directly from the source client.
 
 
+
+  
+
+
 
   
Indicate that the client can accept the given mime type, or
NULL for not accepted.
 
-   Used for feedback during drag-and-drop.
+   For objects of version 2 or older, this request is used by the
+   client to give feedback whether the client can receive the given
+   mime type, or NULL if none is accepted; the feedback does not
+   determine whether drag-and-drop operation succeeds or not.
+
+   For objects of version 3 or newer, this request determines the
+   final result of the drag-and-drop operation. If the end result
+   is that no mime types was accepted, the drag-and-drop operation
+   will be cancelled and the corresponding drag source will receive
+   wl_data_source.cancelled. Clients may still use this event in
+   conjunction with wl_data_source.action for feedback.
   
 
   
@@ -442,6 +457,11 @@
The receiving client reads from the read end of the pipe until
EOF and then closes its end, at which point the transfer is
complete.
+
+   This request may happen multiple times for different mimetypes,
+   both before and after wl_data_device.drop. Drag-and-drop destination
+   clients may preemptively fetch data or examine it more closely to
+   determine acceptance.
   
   
   
@@ -461,9 +481,26 @@
 
   
 
+
+
+
+
+  
+   Notifies the compositor that the drag destination finished retrieving
+   all needed data and considers the drag-and-drop operation complete.
+
+   Upon receiving this request, the compositor will emit
+   wl_data_source.drag_finished or wl_data_source.cancelled on the drag
+   source client depending on the most recent wl_data_offer.accept
+   request received from this offer.
+
+   It is a client error to perform other requests than
+   wl_data_offer.destroy after this one.
+  
+
   
 
-  
+  
 
   The wl_data_source object is the source side of a wl_data_offer.
   It is created by the source clie

Re: [PATCH wayland 1/2] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

Hey,

On Wed, Dec 23, 2015 at 3:07 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Tue, Dec 22, 2015 at 04:46:37PM +0100, Carlos Garnacho wrote:
>> Hey,
>>
>> On Tue, Dec 22, 2015 at 2:55 PM, Jonas Ådahl <jad...@gmail.com> wrote:
>> > On Tue, Dec 22, 2015 at 01:33:08PM +0100, Carlos Garnacho wrote:
>> >> Hey!,
>> >>
>> >> On Tue, Dec 22, 2015 at 3:26 AM, Jonas Ådahl <jad...@gmail.com> wrote:
>> >> > On Tue, Dec 22, 2015 at 02:33:32AM +0100, Carlos Garnacho wrote:
>> >> >> Currently, there's no means for the DnD origin to know whether the
>> >> >> destination is actually finished with the DnD transaction, short of
>> >> >> finalizing it after the first transfer finishes, or leaking it forever.
>> >> >>
>> >> >> But this poses other interoperation problems, drag destinations might
>> >> >> be requesting several mimetypes at once, might be just poking to find
>> >> >> out the most suitable format, might want to defer the action to a 
>> >> >> popup,
>> >> >> might be poking contents early before the selection was dropped...
>> >> >>
>> >> >> In addition, data_source.cancelled is suitable for the situations where
>> >> >> the DnD operation fails (not on a drop target, no matching mimetypes,
>> >> >> etc..), but seems undocumented for that use (and unused in weston's 
>> >> >> DnD).
>> >> >>
>> >> >> In order to improve the situation, the drag source should be notified
>> >> >> of all stages of DnD. In addition to documenting the "cancelled" event
>> >> >> for DnD purposes, The following 2 events have been added:
>> >> >>
>> >> >> - wl_data_source.dnd_drop_performed: Happens when the operation has 
>> >> >> been
>> >> >>   physically finished (eg. the button is released), it could be the 
>> >> >> right
>> >> >>   place to reset the pointer cursor back and undo any other state 
>> >> >> resulting
>> >> >>   from the initial button press.
>> >> >> - wl_data_source.dnd_finished: Happens when the destination side 
>> >> >> destroys
>> >> >>   the wl_data_offer, at this point the source can just forget all data
>> >> >>   related to the DnD selection as well, plus optionally deleting the 
>> >> >> data
>> >> >>   on move operations.
>> >> >>
>> >> >> Changes since v4:
>> >> >>   - Applied rewording suggestions from Jonas Ådahl. Added new
>> >> >> wl_data_offer.finish request to allow explicit finalization on the
>> >> >> destination side.
>> >> >>
>> >> >> Changes since v3:
>> >> >>   - Renamed dnd_performed to a more descriptive dnd_drop_performed,
>> >> >> documented backwards compatible behavior on wl_data_offer.accept 
>> >> >> and
>> >> >> wl_data_source.cancelled.
>> >> >>
>> >> >> Changes since v2:
>> >> >>   - Minor rewording.
>> >> >>
>> >> >> Changes since v1:
>> >> >>   - Renamed events to have a common "dnd" namespace. Made 
>> >> >> dnd_performed to
>> >> >> happen invariably, data_device.cancelled may still happen 
>> >> >> afterwards.
>> >> >>
>> >> >> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> >> >> Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
>> >> >> Reviewed-by: Jonas Ådahl <jad...@gmail.com>
>> >> >> Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
>> >> >
>> >> > Looks pretty good now. Btw, if you put the "Changes since ..."
>> >> > underneath the "---" below after doing git-format-patch you don't have
>> >> > to keep the patch change log in the actual commit message.
>> >>
>> >> Ah sure, I thought the kernel style of keeping patch changelog for
>> >> posteriority was preferred.
>> >
>> > Actually I don't know what is preferred. Personally I put the changelog
>> > outside of the commit message and thought that was what was preferred
>> > but I might b

Re: [PATCH wayland 1/2] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

Hey,

On Tue, Dec 22, 2015 at 2:55 PM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Tue, Dec 22, 2015 at 01:33:08PM +0100, Carlos Garnacho wrote:
>> Hey!,
>>
>> On Tue, Dec 22, 2015 at 3:26 AM, Jonas Ådahl <jad...@gmail.com> wrote:
>> > On Tue, Dec 22, 2015 at 02:33:32AM +0100, Carlos Garnacho wrote:
>> >> Currently, there's no means for the DnD origin to know whether the
>> >> destination is actually finished with the DnD transaction, short of
>> >> finalizing it after the first transfer finishes, or leaking it forever.
>> >>
>> >> But this poses other interoperation problems, drag destinations might
>> >> be requesting several mimetypes at once, might be just poking to find
>> >> out the most suitable format, might want to defer the action to a popup,
>> >> might be poking contents early before the selection was dropped...
>> >>
>> >> In addition, data_source.cancelled is suitable for the situations where
>> >> the DnD operation fails (not on a drop target, no matching mimetypes,
>> >> etc..), but seems undocumented for that use (and unused in weston's DnD).
>> >>
>> >> In order to improve the situation, the drag source should be notified
>> >> of all stages of DnD. In addition to documenting the "cancelled" event
>> >> for DnD purposes, The following 2 events have been added:
>> >>
>> >> - wl_data_source.dnd_drop_performed: Happens when the operation has been
>> >>   physically finished (eg. the button is released), it could be the right
>> >>   place to reset the pointer cursor back and undo any other state 
>> >> resulting
>> >>   from the initial button press.
>> >> - wl_data_source.dnd_finished: Happens when the destination side destroys
>> >>   the wl_data_offer, at this point the source can just forget all data
>> >>   related to the DnD selection as well, plus optionally deleting the data
>> >>   on move operations.
>> >>
>> >> Changes since v4:
>> >>   - Applied rewording suggestions from Jonas Ådahl. Added new
>> >> wl_data_offer.finish request to allow explicit finalization on the
>> >> destination side.
>> >>
>> >> Changes since v3:
>> >>   - Renamed dnd_performed to a more descriptive dnd_drop_performed,
>> >> documented backwards compatible behavior on wl_data_offer.accept and
>> >> wl_data_source.cancelled.
>> >>
>> >> Changes since v2:
>> >>   - Minor rewording.
>> >>
>> >> Changes since v1:
>> >>   - Renamed events to have a common "dnd" namespace. Made dnd_performed to
>> >> happen invariably, data_device.cancelled may still happen afterwards.
>> >>
>> >> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> >> Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
>> >> Reviewed-by: Jonas Ådahl <jad...@gmail.com>
>> >> Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
>> >
>> > Looks pretty good now. Btw, if you put the "Changes since ..."
>> > underneath the "---" below after doing git-format-patch you don't have
>> > to keep the patch change log in the actual commit message.
>>
>> Ah sure, I thought the kernel style of keeping patch changelog for
>> posteriority was preferred.
>
> Actually I don't know what is preferred. Personally I put the changelog
> outside of the commit message and thought that was what was preferred
> but I might be wrong.
>
>>
>> >
>> > One comment and a couple of nits below.
>> >
>> >> ---
>> >>  protocol/wayland.xml | 75 
>> >> +++-
>> >>  1 file changed, 69 insertions(+), 6 deletions(-)
>> >>
>> >> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> >> index df8ed19..ae5ef21 100644
>> >> --- a/protocol/wayland.xml
>> >> +++ b/protocol/wayland.xml
>> >> @@ -408,7 +408,7 @@
>> >>
>> >>
>> >>
>> >> -  
>> >> +  
>> >>  
>> >>A wl_data_offer represents a piece of data offered for transfer
>> >>by another client (the source client).  It is used by the
>> >> @@ -423,7 +423,17 @@
>> >>   Indicate that the client can accept the given mime type, o

Re: [PATCH wayland 2/2] protocol: Add DnD actions

[Carlos Garnacho]

Hey,

On Tue, Dec 22, 2015 at 1:36 PM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Tue, Dec 22, 2015 at 12:20:35PM +0100, Carlos Garnacho wrote:
>> Hey!,
>>
>> On Tue, Dec 22, 2015 at 4:12 AM, Jonas Ådahl <jad...@gmail.com> wrote:
>> > On Tue, Dec 22, 2015 at 02:33:33AM +0100, Carlos Garnacho wrote:
>> >> These 2 requests have been added:
>> >>
>> >> - wl_data_source.set_actions: Notifies the compositor of the available
>> >>   actions on the data source.
>> >> - wl_data_offer.set_actions: Notifies the compositor of the available
>> >>   actions on the destination side, plus the preferred action.
>> >>
>> >> Out of the data from these requests, the compositor can determine the 
>> >> action
>> >> both parts agree on (and let the user play a role through eg. keyboard
>> >> modifiers). The chosen option will be notified to both parties
>> >> through the following two requests:
>> >>
>> >> - wl_data_source.action
>> >> - wl_data_offer.action
>> >>
>> >> In addition, the destination side can peek the source side actions through
>> >> wl_data_offer.source_actions.
>> >>
>> >> Compared to the XDND protocol, there's two notable changes:
>> >>
>> >> - XDND lets the source suggest an action, whereas wl_data_device lets
>> >>   the destination prefer a given action. The difference is subtle here,
>> >>   it comes off as convenience because it is the drag destination which
>> >>   receives the motion events (unlike in X) and can perform action updates.
>> >>
>> >>   The drag destination seems also in a better position to update the
>> >>   preferred action based on things like the data being transferred, the
>> >>   place being dropped, and whether the drag is client-local.
>> >>
>> >> - That same source-side preferred action is used in XDND to convey the
>> >>   modifier-induced action to the drag destination, which would then ack
>> >>   it, or reply with another action that's accepted (or none), this makes
>> >>   the XdndPosition/XdndStatus messaging very verbose, and synchronous
>> >>   because the drag source always needs to know the latest status/action
>> >>   for every position+action sent.
>> >>
>> >>   Here it's the compositor which takes care of modifiers and matching
>> >>   available/accepted actions, this allows for the signaling to happen
>> >>   only whenever the actions/modifiers change for real.
>> >>
>> >> Roughly based on previous work by Giulio Camuffo <giuliocamu...@gmail.com>
>> >>
>> >> Changes since v5:
>> >> - Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
>> >>   scheme for actions. Fixed indentation and other minor formatting issues.
>> >>
>> >> Changes since v4:
>> >> - Minor rewording.
>> >>
>> >> Changes since v3:
>> >> - Splitted from DnD progress notification changes.
>> >> - Further rationales in commit log.
>> >>
>> >> Changes since v2:
>> >> - Renamed notify_actions to set_actions on both sides, seems more 
>> >> consistent
>> >>   with the rest of the protocol.
>> >> - Spelled out better which events may be triggered on the compositor side
>> >>   by the requests, the circumstances in which events are emitted, and
>> >>   what are events useful for in clients.
>> >> - Defined a minimal common ground wrt compositor-side action picking and
>> >>   keybindings.
>> >> - Acknowledge the possibility of compositor/toolkit defined actions, even
>> >>   though none are used at the moment.
>> >> Changes since v1:
>> >> - Added wl_data_offer.source_actions to let know of the actions offered
>> >>   by a data source.
>> >> - Renamed wl_data_source.finished to "drag_finished" for clarity
>> >> - Improved wording as suggested by Bryce
>> >>
>> >> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> >> Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
>> >> Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
>> >
>> >
>> >
>> >> ---
>> >>  protocol/wayland.xml | 122 
>> >> +++
>> &g

Re: [PATCH wayland 2/2] protocol: Add DnD actions

[Carlos Garnacho]

Hey!,

On Tue, Dec 22, 2015 at 4:12 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Tue, Dec 22, 2015 at 02:33:33AM +0100, Carlos Garnacho wrote:
>> These 2 requests have been added:
>>
>> - wl_data_source.set_actions: Notifies the compositor of the available
>>   actions on the data source.
>> - wl_data_offer.set_actions: Notifies the compositor of the available
>>   actions on the destination side, plus the preferred action.
>>
>> Out of the data from these requests, the compositor can determine the action
>> both parts agree on (and let the user play a role through eg. keyboard
>> modifiers). The chosen option will be notified to both parties
>> through the following two requests:
>>
>> - wl_data_source.action
>> - wl_data_offer.action
>>
>> In addition, the destination side can peek the source side actions through
>> wl_data_offer.source_actions.
>>
>> Compared to the XDND protocol, there's two notable changes:
>>
>> - XDND lets the source suggest an action, whereas wl_data_device lets
>>   the destination prefer a given action. The difference is subtle here,
>>   it comes off as convenience because it is the drag destination which
>>   receives the motion events (unlike in X) and can perform action updates.
>>
>>   The drag destination seems also in a better position to update the
>>   preferred action based on things like the data being transferred, the
>>   place being dropped, and whether the drag is client-local.
>>
>> - That same source-side preferred action is used in XDND to convey the
>>   modifier-induced action to the drag destination, which would then ack
>>   it, or reply with another action that's accepted (or none), this makes
>>   the XdndPosition/XdndStatus messaging very verbose, and synchronous
>>   because the drag source always needs to know the latest status/action
>>   for every position+action sent.
>>
>>   Here it's the compositor which takes care of modifiers and matching
>>   available/accepted actions, this allows for the signaling to happen
>>   only whenever the actions/modifiers change for real.
>>
>> Roughly based on previous work by Giulio Camuffo <giuliocamu...@gmail.com>
>>
>> Changes since v5:
>> - Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
>>   scheme for actions. Fixed indentation and other minor formatting issues.
>>
>> Changes since v4:
>> - Minor rewording.
>>
>> Changes since v3:
>> - Splitted from DnD progress notification changes.
>> - Further rationales in commit log.
>>
>> Changes since v2:
>> - Renamed notify_actions to set_actions on both sides, seems more consistent
>>   with the rest of the protocol.
>> - Spelled out better which events may be triggered on the compositor side
>>   by the requests, the circumstances in which events are emitted, and
>>   what are events useful for in clients.
>> - Defined a minimal common ground wrt compositor-side action picking and
>>   keybindings.
>> - Acknowledge the possibility of compositor/toolkit defined actions, even
>>   though none are used at the moment.
>> Changes since v1:
>> - Added wl_data_offer.source_actions to let know of the actions offered
>>   by a data source.
>> - Renamed wl_data_source.finished to "drag_finished" for clarity
>> - Improved wording as suggested by Bryce
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
>> Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
>
>
>
>> ---
>>  protocol/wayland.xml | 122 
>> +++
>>  1 file changed, 122 insertions(+)
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index ae5ef21..001d811 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -486,6 +486,55 @@
>>   wl_data_offer.destroy after this one.
>>
>>  
>> +
>> +
>> +  
>> + Sets the actions that the destination side client supports for
>> + this operation. This request may trigger the emission of
>> + wl_data_source.action and wl_data_offer.action events if the compositor
>> + needs changing the selected action.
>> +
>> + This request can be called multiple times throughout the
>> + drag-and-drop operation, typically in response to wl_data_device.enter
>> + or wl_data_device.motion events.
>> +
>> + This request determines the final result

Re: [PATCH wayland 1/2] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

Hey!,

On Tue, Dec 22, 2015 at 3:26 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Tue, Dec 22, 2015 at 02:33:32AM +0100, Carlos Garnacho wrote:
>> Currently, there's no means for the DnD origin to know whether the
>> destination is actually finished with the DnD transaction, short of
>> finalizing it after the first transfer finishes, or leaking it forever.
>>
>> But this poses other interoperation problems, drag destinations might
>> be requesting several mimetypes at once, might be just poking to find
>> out the most suitable format, might want to defer the action to a popup,
>> might be poking contents early before the selection was dropped...
>>
>> In addition, data_source.cancelled is suitable for the situations where
>> the DnD operation fails (not on a drop target, no matching mimetypes,
>> etc..), but seems undocumented for that use (and unused in weston's DnD).
>>
>> In order to improve the situation, the drag source should be notified
>> of all stages of DnD. In addition to documenting the "cancelled" event
>> for DnD purposes, The following 2 events have been added:
>>
>> - wl_data_source.dnd_drop_performed: Happens when the operation has been
>>   physically finished (eg. the button is released), it could be the right
>>   place to reset the pointer cursor back and undo any other state resulting
>>   from the initial button press.
>> - wl_data_source.dnd_finished: Happens when the destination side destroys
>>   the wl_data_offer, at this point the source can just forget all data
>>   related to the DnD selection as well, plus optionally deleting the data
>>   on move operations.
>>
>> Changes since v4:
>>   - Applied rewording suggestions from Jonas Ådahl. Added new
>> wl_data_offer.finish request to allow explicit finalization on the
>> destination side.
>>
>> Changes since v3:
>>   - Renamed dnd_performed to a more descriptive dnd_drop_performed,
>> documented backwards compatible behavior on wl_data_offer.accept and
>> wl_data_source.cancelled.
>>
>> Changes since v2:
>>   - Minor rewording.
>>
>> Changes since v1:
>>   - Renamed events to have a common "dnd" namespace. Made dnd_performed to
>> happen invariably, data_device.cancelled may still happen afterwards.
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
>> Reviewed-by: Jonas Ådahl <jad...@gmail.com>
>> Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
>
> Looks pretty good now. Btw, if you put the "Changes since ..."
> underneath the "---" below after doing git-format-patch you don't have
> to keep the patch change log in the actual commit message.

Ah sure, I thought the kernel style of keeping patch changelog for
posteriority was preferred.

>
> One comment and a couple of nits below.
>
>> ---
>>  protocol/wayland.xml | 75 
>> +++-
>>  1 file changed, 69 insertions(+), 6 deletions(-)
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index df8ed19..ae5ef21 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -408,7 +408,7 @@
>>
>>
>>
>> -  
>> +  
>>  
>>A wl_data_offer represents a piece of data offered for transfer
>>by another client (the source client).  It is used by the
>> @@ -423,7 +423,17 @@
>>   Indicate that the client can accept the given mime type, or
>>   NULL for not accepted.
>>
>> - Used for feedback during drag-and-drop.
>> + For objects of version 2 or older, this request is used by the
>> + client to give feedback whether the client can receive the given
>> + mime type, or NULL if none is accepted; the feedback does not
>> + determine whether drag-and-drop operation succeeds or not.
>> +
>> + For objects of version 3 or newer, this request determines the
>> + final result of the drag-and-drop operation. If the end result
>> + is that no mime types was accepted, the drag-and-drop operation
>> + will be cancelled and the corresponding drag source will receive
>> + wl_data_source.cancelled. Clients may still use this event in
>> + conjunction with wl_data_source.action for feedback.
>>
>>
>>
>> @@ -461,9 +471,24 @@
>>
>>
>>  
>> +
>> +
>> +
>> +
>> +  
>> + Notifies the composito

Re: [PATCH weston 2/5] data-device: Implement DnD actions

[Carlos Garnacho]

Hey!,

On Tue, Dec 22, 2015 at 5:25 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Tue, Dec 22, 2015 at 02:33:28AM +0100, Carlos Garnacho wrote:
>> The policy in weston in order to determine the chosen DnD action is
>> deliberately simple, and is probably the minimals that any compositor
>> should be doing here.
>>
>> Besides honoring the set_actions requests on both wl_data_source and
>> wl_data_offer, weston now will emit the newly added "action" events
>> notifying both source and dest of the chosen action.
>>
>> The "dnd" client has been updated too (although minimally), so it
>> notifies the compositor of a "move" action on both sides.
>
> dnd.c needs to be updated to require version 3 to function, since you
> now depend on it.

Right

>
>>
>> Changes since v4:
>>   - Added compositor-side version checks. Spaces vs tabs fixes.
>> Fixed resource versioning. Initialized new weston_data_source/offer
>> fields.
>>
>> Changes since v3:
>>   - Put data_source.action to use in the dnd client, now updates
>> the dnd surface like data_source.target events do.
>>
>> Changes since v2:
>>   - Split from DnD progress notification changes.
>>
>> Changes since v1:
>>   - Updated to v2 of DnD actions protocol changes, implement
>> wl_data_offer.source_actions.
>>   - Fixed coding style issues.
>>
>> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
>> Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
>
> Mostly looks good, with a few nits below and one above. I suspect some
> changes are needed depending on how the "ask" action should be
> interpeted, so I'll give my RB when that has been cleared out.
>
>> ---
>>  clients/dnd.c |  32 ++---
>>  clients/window.c  |  25 +
>>  src/compositor.h  |   4 +++
>>  src/data-device.c | 104 
>> --
>>  4 files changed, 157 insertions(+), 8 deletions(-)
>>
>> diff --git a/clients/dnd.c b/clients/dnd.c
>> index 48111d9..ddf3fcc 100644
>> --- a/clients/dnd.c
>> +++ b/clients/dnd.c
>> @@ -72,6 +72,7 @@ struct dnd_drag {
>>   struct item *item;
>>   int x_offset, y_offset;
>>   int width, height;
>> + uint32_t dnd_action;
>>   const char *mime_type;
>>
>>   struct wl_surface *drag_surface;
>> @@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
>>  }
>>
>>  static void
>> -data_source_target(void *data,
>> -struct wl_data_source *source, const char *mime_type)
>> +dnd_drag_update_surface(struct dnd_drag *dnd_drag)
>>  {
>> - struct dnd_drag *dnd_drag = data;
>>   struct dnd *dnd = dnd_drag->dnd;
>>   cairo_surface_t *surface;
>>   struct wl_buffer *buffer;
>>
>> - dnd_drag->mime_type = mime_type;
>> - if (mime_type)
>> + if (dnd_drag->mime_type && dnd_drag->dnd_action)
>>   surface = dnd_drag->opaque;
>>   else
>>   surface = dnd_drag->translucent;
>> @@ -288,6 +286,16 @@ data_source_target(void *data,
>>  }
>>
>>  static void
>> +data_source_target(void *data,
>> +struct wl_data_source *source, const char *mime_type)
>> +{
>> + struct dnd_drag *dnd_drag = data;
>> +
>> + dnd_drag->mime_type = mime_type;
>> + dnd_drag_update_surface(dnd_drag);
>> +}
>> +
>> +static void
>>  data_source_send(void *data, struct wl_data_source *source,
>>const char *mime_type, int32_t fd)
>>  {
>> @@ -360,12 +368,22 @@ data_source_drag_finished(void *data, struct 
>> wl_data_source *source)
>>   dnd_drag_destroy(dnd_drag);
>>  }
>>
>> +static void
>> +data_source_action(void *data, struct wl_data_source *source, uint32_t 
>> dnd_action)
>> +{
>> + struct dnd_drag *dnd_drag = data;
>> +
>> + dnd_drag->dnd_action = dnd_action;
>> + dnd_drag_update_surface(dnd_drag);
>> +}
>> +
>>  static const struct wl_data_source_listener data_source_listener = {
>>   data_source_target,
>>   data_source_send,
>>   data_source_cancelled,
>>   data_source_drop_performed,
>>   data_source_drag_finished,
>> + data_source_action,
>>  };
>>
>>  static cairo_surface_t *
>> @@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
>>

[PATCH wayland 2/2] protocol: Add DnD actions

[Carlos Garnacho]

These 2 requests have been added:

- wl_data_source.set_actions: Notifies the compositor of the available
  actions on the data source.
- wl_data_offer.set_actions: Notifies the compositor of the available
  actions on the destination side, plus the preferred action.

Out of the data from these requests, the compositor can determine the action
both parts agree on (and let the user play a role through eg. keyboard
modifiers). The chosen option will be notified to both parties
through the following two requests:

- wl_data_source.action
- wl_data_offer.action

In addition, the destination side can peek the source side actions through
wl_data_offer.source_actions.

Compared to the XDND protocol, there's two notable changes:

- XDND lets the source suggest an action, whereas wl_data_device lets
  the destination prefer a given action. The difference is subtle here,
  it comes off as convenience because it is the drag destination which
  receives the motion events (unlike in X) and can perform action updates.

  The drag destination seems also in a better position to update the
  preferred action based on things like the data being transferred, the
  place being dropped, and whether the drag is client-local.

- That same source-side preferred action is used in XDND to convey the
  modifier-induced action to the drag destination, which would then ack
  it, or reply with another action that's accepted (or none), this makes
  the XdndPosition/XdndStatus messaging very verbose, and synchronous
  because the drag source always needs to know the latest status/action
  for every position+action sent.

  Here it's the compositor which takes care of modifiers and matching
  available/accepted actions, this allows for the signaling to happen
  only whenever the actions/modifiers change for real.

Roughly based on previous work by Giulio Camuffo <giuliocamu...@gmail.com>

Changes since v5:
- Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
  scheme for actions. Fixed indentation and other minor formatting issues.

Changes since v4:
- Minor rewording.

Changes since v3:
- Splitted from DnD progress notification changes.
- Further rationales in commit log.

Changes since v2:
- Renamed notify_actions to set_actions on both sides, seems more consistent
  with the rest of the protocol.
- Spelled out better which events may be triggered on the compositor side
  by the requests, the circumstances in which events are emitted, and
  what are events useful for in clients.
- Defined a minimal common ground wrt compositor-side action picking and
  keybindings.
- Acknowledge the possibility of compositor/toolkit defined actions, even
  though none are used at the moment.
Changes since v1:
- Added wl_data_offer.source_actions to let know of the actions offered
  by a data source.
- Renamed wl_data_source.finished to "drag_finished" for clarity
- Improved wording as suggested by Bryce

Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com>
Reviewed-by: Mike Blumenkrantz <zm...@samsung.com>
---
 protocol/wayland.xml | 122 +++
 1 file changed, 122 insertions(+)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index ae5ef21..001d811 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -486,6 +486,55 @@
wl_data_offer.destroy after this one.
   
 
+
+
+  
+   Sets the actions that the destination side client supports for
+   this operation. This request may trigger the emission of
+   wl_data_source.action and wl_data_offer.action events if the compositor
+   needs changing the selected action.
+
+   This request can be called multiple times throughout the
+   drag-and-drop operation, typically in response to wl_data_device.enter
+   or wl_data_device.motion events.
+
+   This request determines the final result of the drag-and-drop
+   operation. If the end result is that no action is accepted,
+   the drag source will receive wl_drag_source.cancelled.
+  
+  
+  
+
+
+
+  
+   This event indicates the actions offered by the data source. It
+   will be sent right after wl_data_device.enter, or anytime the source
+   side changes its offered actions through wl_data_source.set_actions.
+  
+  
+
+
+
+  
+   This event indicates the action selected by the compositor after
+   matching the source/destination side actions. Only one action (or
+   none) will be offered here.
+
+   This event can be emitted multiple times during the drag-and-drop
+   operation, mainly in response to source side changes (through
+   wl_data_source.set_actions), destination side changes (through
+   wl_data_offer.set_actions), and as the pointer enters/leaves
+   surfaces.
+
+   Compositors may also change the selected action on t