Re: [PATCH weston 10/10] Remove workspaces protocol

[Pekka Paalanen]

On Wed,  4 Nov 2015 16:49:59 +0800
Jonas Ådahl  wrote:

> It doesn't fill a useful function and is not intended to be continued.
> If there is need for workspace manipulation from clients a protocol
> based on those future needs need to be properly designed.
> workspaces.xml is probably not very relevant since it did the bare
> minimum.
> 
> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am |   7 ---
>  clients/window.c|  57 +---
>  desktop-shell/shell.c   | 113 
> 
>  protocol/workspaces.xml |  27 
>  4 files changed, 1 insertion(+), 203 deletions(-)
>  delete mode 100644 protocol/workspaces.xml

Acked-by: Pekka Paalanen 

Are we left with any way to move a window from a workspace to another?

Should we have multiple workspaces in vanilla Weston/desktop at all?

Do we have any Weston core features that would be left unused in
vanilla Weston with this patch or with the removal of workspaces?

This is mostly food for thought for potentially simplifying desktop
shell in future.


Thanks,
pq


pgpEXiGOO7xI0.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 10/10] Remove workspaces protocol

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 10:28:53AM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:59 +0800
> Jonas Ådahl  wrote:
> 
> > It doesn't fill a useful function and is not intended to be continued.
> > If there is need for workspace manipulation from clients a protocol
> > based on those future needs need to be properly designed.
> > workspaces.xml is probably not very relevant since it did the bare
> > minimum.
> > 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  Makefile.am |   7 ---
> >  clients/window.c|  57 +---
> >  desktop-shell/shell.c   | 113 
> > 
> >  protocol/workspaces.xml |  27 
> >  4 files changed, 1 insertion(+), 203 deletions(-)
> >  delete mode 100644 protocol/workspaces.xml
> 
> Acked-by: Pekka Paalanen 
> 
> Are we left with any way to move a window from a workspace to another?

Yes, there are keybindings for that still left.

> 
> Should we have multiple workspaces in vanilla Weston/desktop at all?
> 
> Do we have any Weston core features that would be left unused in
> vanilla Weston with this patch or with the removal of workspaces?
> 
> This is mostly food for thought for potentially simplifying desktop
> shell in future.

I have no objections to someone removing it.


Jonas

> 
> 
> Thanks,
> pq


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

Re: [PATCH weston 08/10] desktop-shell: Rename protocol weston_desktop_shell

[Pekka Paalanen]

On Wed,  4 Nov 2015 16:49:57 +0800
Jonas Ådahl  wrote:

> In the effort of going away from generic names of protocols only
> relevant for weston, rename the weston desktop shell
> weston_desktop_shell.
> 
> This also resets the version to 1, as there will be no prior versions
> to weston_desktop_shell.
> 
> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am   |  20 +++---
>  clients/desktop-shell.c   |  79 +++---
>  desktop-shell/input-panel.c   |   2 +-
>  desktop-shell/shell.c |  70 ++-
>  desktop-shell/shell.h |   4 +-
>  protocol/desktop-shell.xml| 138 
> --
>  protocol/weston-desktop-shell.xml | 134 
>  7 files changed, 224 insertions(+), 223 deletions(-)
>  delete mode 100644 protocol/desktop-shell.xml
>  create mode 100644 protocol/weston-desktop-shell.xml

This renaming will break Maynard:
https://github.com/raspberrypi/maynard.git

This is not a blocker for this patch, just something we should be aware
of. The fix should be pretty easy if anyone cares.

> diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
> index f5342aa..6619e4c 100644
> --- a/desktop-shell/input-panel.c
> +++ b/desktop-shell/input-panel.c
> @@ -30,7 +30,7 @@
>  #include 
>  
>  #include "shell.h"
> -#include "desktop-shell-server-protocol.h"
> +#include "weston-desktop-shell-server-protocol.h"
>  #include "input-method-unstable-v1-server-protocol.h"
>  #include "shared/helpers.h"

And no other changes in this file, that's odd. Maybe the header is not
needed at all?

Acked-by: Pekka Paalanen 


Thanks,
pq


pgpZmTjTV_NjX.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 09/10] Rename screenshooter protocol to weston_screenshooter

[Pekka Paalanen]

On Wed,  4 Nov 2015 16:49:58 +0800
Jonas Ådahl  wrote:

> Due to the effort of moving a way from non-prefixed protocols, rename
> the weston specific screenshooter protocol to weston_screenshooter.
> 
> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am   | 14 +++---
>  clients/screenshot.c  | 21 +
>  protocol/screenshooter.xml| 12 
>  protocol/weston-screenshooter.xml | 12 
>  src/screenshooter.c   | 12 ++--
>  5 files changed, 38 insertions(+), 33 deletions(-)
>  delete mode 100644 protocol/screenshooter.xml
>  create mode 100644 protocol/weston-screenshooter.xml

> diff --git a/src/screenshooter.c b/src/screenshooter.c
> index 6e1af65..d0ec00e 100644
> --- a/src/screenshooter.c
> +++ b/src/screenshooter.c

> @@ -622,9 +622,9 @@ screenshooter_create(struct weston_compositor *ec)
>   shooter->client = NULL;
>  
>   shooter->global = wl_global_create(ec->wl_display,
> -_interface, 1,
> +_screenshooter_interface, 1,
>  shooter, bind_shooter);
> - weston_compositor_add_key_binding(ec, KEY_S, MODIFIER_SUPER,
> + weston_compositor_add_key_binding(ec, KEY_S, MODIFIER_CTRL,

Oops? :-)

Otherwise
Acked-by: Pekka Paalanen 


Thanks,
pq


pgpJnH1nOv5xb.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 01/10] Use fullscreen-shell.xml from wayland-protocols

[Pekka Paalanen]

On Wed,  4 Nov 2015 16:49:50 +0800
Jonas Ådahl  wrote:

> Use the fullscreen-shell protocol XML from the wayland-protocols
> installation, and remove the one we provide ourself.
> 
> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am |  44 +---
>  clients/fullscreen.c|  60 +--
>  clients/simple-damage.c |  18 ++--
>  clients/simple-dmabuf.c |  18 ++--
>  clients/simple-shm.c|  18 ++--
>  configure.ac|   7 ++
>  fullscreen-shell/fullscreen-shell.c |  54 +-
>  protocol/fullscreen-shell.xml   | 206 
> 
>  src/compositor-wayland.c|  48 -
>  src/screen-share.c  |  34 +++---
>  10 files changed, 159 insertions(+), 348 deletions(-)
>  delete mode 100644 protocol/fullscreen-shell.xml

Hi Jonas,

I'm looking at this just to see how you hooked up the build. Nothing
too important here. The general idea of the patch is good.

> 
> diff --git a/Makefile.am b/Makefile.am
> index 55e3bcb..2524591 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -309,8 +309,8 @@ wayland_backend_la_SOURCES =  \
>   src/compositor-wayland.c\
>   shared/helpers.h
>  nodist_wayland_backend_la_SOURCES =  \
> - protocol/fullscreen-shell-protocol.c\
> - protocol/fullscreen-shell-client-protocol.h
> + protocol/fullscreen-shell-unstable-v1-protocol.c\
> + protocol/fullscreen-shell-unstable-v1-client-protocol.h
>  endif
>  
>  if ENABLE_RPI_COMPOSITOR
> @@ -475,8 +475,8 @@ weston_simple_shm_SOURCES = clients/simple-shm.c
>  nodist_weston_simple_shm_SOURCES =   \
>   protocol/xdg-shell-protocol.c   \
>   protocol/xdg-shell-client-protocol.h\
> - protocol/fullscreen-shell-protocol.c\
> - protocol/fullscreen-shell-client-protocol.h \
> + protocol/fullscreen-shell-unstable-v1-protocol.c\
> + protocol/fullscreen-shell-unstable-v1-client-protocol.h \
>   protocol/ivi-application-protocol.c \
>   protocol/ivi-application-client-protocol.h
>  weston_simple_shm_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS)
> @@ -488,8 +488,8 @@ nodist_weston_simple_damage_SOURCES = \
>   protocol/scaler-client-protocol.h   \
>   protocol/xdg-shell-protocol.c   \
>   protocol/xdg-shell-client-protocol.h\
> - protocol/fullscreen-shell-protocol.c\
> - protocol/fullscreen-shell-client-protocol.h
> + protocol/fullscreen-shell-unstable-v1-protocol.c\
> + protocol/fullscreen-shell-unstable-v1-client-protocol.h
>  weston_simple_damage_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS)
>  weston_simple_damage_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la
>  
> @@ -531,8 +531,8 @@ weston_simple_dmabuf_SOURCES = clients/simple-dmabuf.c
>  nodist_weston_simple_dmabuf_SOURCES =\
>   protocol/xdg-shell-protocol.c   \
>   protocol/xdg-shell-client-protocol.h\
> - protocol/fullscreen-shell-protocol.c\
> - protocol/fullscreen-shell-client-protocol.h \
> + protocol/fullscreen-shell-unstable-v1-protocol.c\
> + protocol/fullscreen-shell-unstable-v1-client-protocol.h \
>   protocol/linux-dmabuf-protocol.c \
>   protocol/linux-dmabuf-client-protocol.h
>  weston_simple_dmabuf_CFLAGS = $(AM_CFLAGS) $(SIMPLE_DMABUF_CLIENT_CFLAGS)
> @@ -649,8 +649,8 @@ weston_transformed_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  
>  weston_fullscreen_SOURCES = clients/fullscreen.c
>  nodist_weston_fullscreen_SOURCES =   \
> - protocol/fullscreen-shell-protocol.c\
> - protocol/fullscreen-shell-client-protocol.h
> + protocol/fullscreen-shell-unstable-v1-protocol.c\
> + protocol/fullscreen-shell-unstable-v1-client-protocol.h
>  weston_fullscreen_LDADD = libtoytoolkit.la
>  weston_fullscreen_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  
> @@ -763,8 +763,8 @@ BUILT_SOURCES +=  \
>   protocol/scaler-protocol.c  \
>   protocol/workspaces-client-protocol.h   \
>   protocol/workspaces-protocol.c  \
> - protocol/fullscreen-shell-protocol.c\
> - protocol/fullscreen-shell-client-protocol.h \
> + protocol/fullscreen-shell-unstable-v1-protocol.c\
> + protocol/fullscreen-shell-unstable-v1-client-protocol.h \
>   protocol/xdg-shell-protocol.c   \
>   protocol/xdg-shell-client-protocol.h\
>   protocol/ivi-hmi-controller-protocol.c  \
> @@ -865,8 +865,8 @@ fullscreen_shell_la_SOURCES = \
>   fullscreen-shell/fullscreen-shell.c \
>   shared/helpers.h
>  nodist_fullscreen_shell_la_SOURCES = \
> - 

Re: [PATCH weston 03/10] Use presentation timing protocol from wayland-protocols

[Pekka Paalanen]

On Wed,  4 Nov 2015 16:49:52 +0800
Jonas Ådahl  wrote:

> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am  |  21 ++-
>  clients/presentation-shm.c   |  65 +-
>  clients/weston-info.c|  19 +--
>  protocol/presentation_timing.xml | 274 
> ---
>  src/compositor-drm.c |  14 +-
>  src/compositor-fbdev.c   |   2 +-
>  src/compositor-headless.c|   2 +-
>  src/compositor-rpi.c |   6 +-
>  src/compositor-wayland.c |   2 +-
>  src/compositor-x11.c |   2 +-
>  src/compositor.c |  29 +++--
>  tests/presentation-test.c|  34 ++---
>  12 files changed, 101 insertions(+), 369 deletions(-)
>  delete mode 100644 protocol/presentation_timing.xml

> diff --git a/clients/presentation-shm.c b/clients/presentation-shm.c
> index 120c40c..9083d8e 100644
> --- a/clients/presentation-shm.c
> +++ b/clients/presentation-shm.c
> @@ -38,7 +38,7 @@
>  #include 
>  #include "shared/helpers.h"
>  #include "shared/os-compatibility.h"
> -#include "presentation_timing-client-protocol.h"
> +#include "presentation-timing-unstable-v1-client-protocol.h"
>  
>  enum run_mode {
>   RUN_MODE_FEEDBACK,
> @@ -67,7 +67,7 @@ struct display {
>   struct wl_shm *shm;
>   uint32_t formats;
>  
> - struct presentation *presentation;
> + struct zwl_presentation1 *presentation;

Hi Jonas,

I see you added the prefix wl_ here. I think this is good, it is aiming
to be a standard, generic extension usable everywhere where Wayland is.

What I am not so sure about is whether keeping it unstable is still necessary.
https://phabricator.freedesktop.org/T43

Maybe we should just promote it stable while we are moving it, and
avoid one round of renames. I don't know of anything that would need
fixing or reconsidering in it, apart maybe from names (presentation?).

Hmm, maybe if someone makes the case that one really *really* does
not need 64 bits for seconds value, it could use a break. However,
64-bit nanoseconds value does not necessarily fit in a 32-bit seconds +
32-bit nsecs value when nsec is limited to [0, 9], so I think
it's good as is. (And the code is already written and been out there
for a long time.)

What if we skipped this one with the unstable move?


Thanks,
pq


pgpoFp9IkauYn.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 00/10] weston wayland-protocols migration

[Pekka Paalanen]

On Wed,  4 Nov 2015 16:49:49 +0800
Jonas Ådahl  wrote:

> Hi,
> 
> This series changes weston to depend on wayland-protocols for the
> majority of the protocols previously in the protocols/ directory. The
> protocols moved are also renamed to comply with the unstable naming
> conventions of wayland-protocols, with the exception of xdg_shell which
> will use the current name until the next version.
> 
> I'd appreciate if maintainers of given protocols could at least Ack the
> patch changing their protocol implementation, as a semi formal stamp of
> approval of the name change.

Hi Jonas,

I'll give any detailed feedback as replies to the patches, here are some
overall comments.

> Other than that, the workspaces protocol is removed, mostly because it
> wasn't a significant enough proof of concept needed for any particular
> feature. text-cursor-position.xml however I have left intact, because
> without it the zoom accessibility feature proof of concept becomes
> a bit too useless. I'd prefer to prefix it with something like toy_ or
> weston_, but would like to hear input on this one. Given that it is
> completely undocumented it is quite far from a real attempt, but it
> seems like something that will be needed sooner or later for
> accessibility reasons, so not sure what to do with it right now.
> 
> Things that seemed more weston specific was weston_ prefixed. The
> screenshooter protocol and the desktop shell protocol fell into this
> category.

Speaking of prefixes, do we have an idea what protocols should use the
wl_ prefix and what shouldn't?

I have had the feeling that wl_ is only Wayland core. But what does
Wayland core mean? And wl_shell is an exception already.

Should we restrict wl_ to only for things in wayland.xml? Probably not,
as I think wl_ in e.g. wl_scaler is justified since it's a "low-level"
generic feature, and yet wl_scaler will not be added into wayland.xml.

Perhaps wl_ prefix should be reserved for extensions that are usable
regardless of a shell or environment. I'm not sure if the input method
extensions would be eligible for wl_ or not, or what to do with
fullscreen shell.

xdg_shell is setting a precedent for using xdg_ prefix for all
desktoppy but still DE-agnostic extensions, and I think that is fine.

> Another protocol left to migrate is scalar.xml. I didn't do this yet
> because Pekka had plans on renaming it, and I'll simply wait until he
> has a name for it before migrating anything.

Yeah, inventing a new name for it is hard, but I'll try to come up with
something. Something that implies both scaling and clipping...
something used to create viewport objects...

> Other than that, the wayland-protocols have shaped up some, with the
> pointer gestures protocol as well as the protocols of this series
> migrated there. I wouldn't mind if people went and had a look to see if
> there are any opinions of how things should work before we make an
> initial release. The procedures and some details are explained in the
> README file in the toplevel directory.

The README looks fine to me on the whole, I sent you some trivial typo
fixes for your consideration.

This puzzles me a bit:

"Each release of wayland-protocols finalizes the version of the
protocols to their state they had at that time. Between each
release, backward incompatible changes can be made to both
stable and major unstable protocol versions as long as the
requirements are held upon release."

It says backward-incompatible changes could be made to also stable
protocols as long as stability is maintained from release to release.
Essentially it means that such changes have to be reverted before the
next release. Is that just to account for accidents?

If wayland-protocols is intended to be released often and as-needed, we
should make sure we don't need such reverts to begin with. Otherwise
the release engineer will have a big review burden. IOW, we should keep
the repo in an always releasable state.

In short, I wouldn't mention the stable protocols in this paragraph.


I looked at the Presentation (feedback) extension in wayland-protocols,
and I saw that you renamed both global and non-global interfaces.

Do we need to rename also non-global interfaces according to the
unstable naming convention?

I assumed renaming the globals would be enough, because it is enough to
bring the runtime discoverability. Renaming also non-global interfaces
seems needless churn on one hand, but it does make it painfully clear
to a developer upgrading to a new major version which places he needs
to review in the code for changes.

> One current inconvenience that would be nice with some opinions is what
> to do with unstable protocol files after a protocol has been declared
> stable. Currently specified to work by having one directory containing
> the stable XML file together with a README in the stable/ toplevel
> directory, and yet another directory containing the unstable 

Re: [PATCH weston 02/10] Use linux-dmabuf protocol from wayland-protocols

[Pekka Paalanen]

On Wed,  4 Nov 2015 16:49:51 +0800
Jonas Ådahl  wrote:

> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am   |  13 +--
>  clients/simple-dmabuf.c   |  56 +-
>  protocol/linux-dmabuf.xml | 274 
> --
>  src/gl-renderer.c |   6 +-
>  src/linux-dmabuf.c|  40 +++
>  5 files changed, 57 insertions(+), 332 deletions(-)
>  delete mode 100644 protocol/linux-dmabuf.xml

Acked-by: Pekka Paalanen 

Subject to the question of whether non-global interfaces should have
the renaming treatment. The non-global interface in this extension did
have the 'z' prefix already, but I don't think it was thought through
much.


Thanks,
pq


pgpDaHQXtDFfP.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Jon A. Cruz]

On 11/05/2015 10:17 AM, Pekka Paalanen wrote:
> On Fri, 16 Oct 2015 12:23:47 -0700
> "Jon A. Cruz"  wrote:
> 
>> On 10/15/2015 01:51 AM, Pekka Paalanen wrote:
>>> I think it's better to land this stuff in pieces than massage a
>>> humongous replace-the-world patch series, if we can tell the pieces are
>>> going in the right direction. The bits here are mostly just following
>>> the existing weston-test-client-helper.c (which the commit message
>>> forgot to mention).
>>>
>>> But yeah, probably makes sense to see how hooking even this stuff up to
>>> 'make check' would happen before landing this. That will be one of the
>>> most interesting things here. This patch as is does not add anything to
>>> 'make check' which is a little awkward for a series adding new test
>>> code.
>>>
>>> As for writing tests in the mean time, people should just ignore the
>>> new framework for now, and write tests as if it didn't exist as long as
>>> it doesn't support what the old framework does.
>>>
>>> This way we can incrementally advance on both fronts at the same time.
>>
>> So, the immediate question would now be as to how I should stage things.
>> Should the changes that will go into 'make check' be a separate patch
>> set or should it be an additional patch in this set?
>>
>> I'd say that running it as a separate set might make juggling git a
>> little easier on me. But not to a degree to outweigh what would make
>> reviewing things easier.
> 
> Hi Jon,
> 
> as I'm not sure how you are going to hook things up to Weston and it
> will be interesting to see how you do it, I would like to have it as a
> part of this series adding waycheck. In my view, you can't even
> demonstrate one without the other: waycheck needs a compositor, and
> seeing how 'make check' starts a compositor for a test needs the test
> client.
> 
> I would very much like to see both pieces at the same time, in case one
> requires changes in the other. It would be nice to keep in mind all the
> various test styles (client, module, ...) we listed in the past, so
> that adding a new case later shouldn't cause a huge refactoring.
> 
> By test styles I mean basically the different cases in
> tests/weston-tests-env script.
> 

One aspect for waycheck is that it could be run against most any
compositor at any time, so allowing for those uses makes it less of a
driving factor and more of a client.

The other tests, however, do need to start weston and with different
configurations. Those then fall into the potential white-box testing
world, while waycheck is more for black-box validation.


I've been going through some general cleanup, but will include the some
of the current 'make check' tests conversions also. Might take a little
bit more, but we definitely want to keep things easiest to review.


-- 
Jon A. Cruz - Senior Open Source Developer
Samsung Open Source Group
j...@osg.samsung.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete

[Derek Foreman]

On 04/11/15 07:24 PM, Jonas Ådahl wrote:
> On Thu, Nov 05, 2015 at 08:44:57AM +1000, Peter Hutterer wrote:
>> On Wed, Nov 04, 2015 at 09:57:35AM +0800, Jonas Ådahl wrote:
>>> On Wed, Oct 28, 2015 at 03:34:31PM +1000, Peter Hutterer wrote:
>> [...]
 +
 +  
 +  Indicates the end of a set of events that logically belong together.
 +  A client is expected to accumulate the data in all events events
 +  within the frame before proceeding.
 +
 +  All wl_pointer events before a wl_pointer.frame event belong
 +  logically together. For example, in a diagonal scroll motion the
 +  compositor will send an optional wl_pointer.axis_source event, two
 +  wl_pointer.axis events (horizontal and vertical) and finally a
 +  wl_pointer.frame event. The client may use this information to
 +  calculate a diagonal vector for scrolling.
 +
 +  When multiple wl_pointer.axis events occur within the same frame,
 +  the motion vector is the combined motion of all events.
 +  When a wl_pointer.axis and a wl_pointer.axis_stop event occur within
 +  the same frame, this indicates that axis movement in one axis has
 +  stopped but continues in the other axis.
 +  When multiple wl_pointer.axis_stop events occur within in the same
 +  frame, this indicates that these axes stopped in the same instance.
 +
 +  A wl_pointer.frame event is sent for every logical event group,
 +  even if the group only contains a single wl_pointer event.
 +  Specifically, a client may get a sequence: motion, frame, button,
 +  frame, axis, frame, axis_stop, frame.
 +
 +  The wl_pointer.enter and wl_pointer.leave events are logical events
 +  generated by the compositor and not the hardware. These events are
 +  also grouped by a wl_pointer.frame.
>>>
>>> I like the idea of wl_pointer.frame in general, but I don't like this
>>> part, because enter/leave really shouldn't be seen as pointer events at
>>> all. For example a window closing because of whatever reason will result
>>> in a wl_pointer.enter on the window that happened to be below. This has
>>> nothing to do with the pointer device, it is just about the pointer
>>> focus.
>>>
>>> The reason you have made the enter/leave events be dispatched state
>>> events to the frame event is, as you wrote above, to make it possible
>>> for extensions to extend the enter/leave events, but they can already do
>>> so by making those extensions latched events appending state to the
>>> enter or leave events. If we need to make some extension that adds
>>> something to receiving or loosing focus, I think they'd be worth their
>>> own events with their own semantics.
>>
>> I understand it's not pretty for the enter/leave semantics, but I'd argue
>> that it's potentially more confusing to have it to apply to all wl_pointer
>> events except enter/leave than just apply to all.
> 
> I disagree. I see wl_pointer.frame to be the grouping of pointer events.
> The enter/leave are pointer *focus* events, and have nothing in
> particular to do with actual events from the pointer, making them
> different enough to make me feel they have very little in common with
> the rest of the events, thus are not suitable to be framed by
> wl_pointer.frame.

They're quite similar in that they're coming from the same protocol
object.  What's the benefit in having a separate frame mechanism for
enter/leave should they need extension later?

To me the focus events feel more like "seat" events than pointer events,
but they're still coming from the pointer object...

FWIW I agree with Peter on this one.  I think it'll just be more
complicated (and potentially confusing to compositor/toolkit authors?)
to have some wl_pointer events framed by one frame event, and others
possibly by another should we choose to extend them later.

AIUI, pointer frame was born out of wanting to be more general than axis
frame.  If we're going to draw the line at "just some wl_pointer events
are managed by this frame" I think I'd rather see it go back to axis_frame.

>>
>> This way it's also a catchall event that we don't have to worry about later
>> down the road. Latching events is possible but again there is the
>> inconsistency of "everything is grouped by frame, except enter/leave which
>> is latched to enter/leave". And the version handling if we later need it
>> after all ("latch to enter until v7, otherwise use frame")
> 
> I think instead we'll have to start worrying about what events can be
> put inside a frame, if another conflicting event will be there, and what
> events actually mean if they are part of receiving focus.

I think we should just state that leave/enter can't share with "input"
events and be done with it...

> If there will ever be a latched state to enter/leave, I expect it to
> either be exclusive to those, or have a big "this either extends a focus
> event meaning this, or it is a pointer event/extends a pointer event
> 

Re: [PATCH weston 01/10] Use fullscreen-shell.xml from wayland-protocols

[Bryce Harrington]

On Thu, Nov 05, 2015 at 01:19:27PM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:50 +0800
> Jonas Ådahl  wrote:
> 
> > Use the fullscreen-shell protocol XML from the wayland-protocols
> > installation, and remove the one we provide ourself.
> > 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  Makefile.am |  44 +---
> >  clients/fullscreen.c|  60 +--
> >  clients/simple-damage.c |  18 ++--
> >  clients/simple-dmabuf.c |  18 ++--
> >  clients/simple-shm.c|  18 ++--
> >  configure.ac|   7 ++
> >  fullscreen-shell/fullscreen-shell.c |  54 +-
> >  protocol/fullscreen-shell.xml   | 206 
> > 
> >  src/compositor-wayland.c|  48 -
> >  src/screen-share.c  |  34 +++---
> >  10 files changed, 159 insertions(+), 348 deletions(-)
> >  delete mode 100644 protocol/fullscreen-shell.xml
> 
> Hi Jonas,
> 
> I'm looking at this just to see how you hooked up the build. Nothing
> too important here. The general idea of the patch is good.
> 
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 55e3bcb..2524591 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -309,8 +309,8 @@ wayland_backend_la_SOURCES =\
> > src/compositor-wayland.c\
> > shared/helpers.h
> >  nodist_wayland_backend_la_SOURCES =\
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h
> >  endif
> >  
> >  if ENABLE_RPI_COMPOSITOR
> > @@ -475,8 +475,8 @@ weston_simple_shm_SOURCES = clients/simple-shm.c
> >  nodist_weston_simple_shm_SOURCES = \
> > protocol/xdg-shell-protocol.c   \
> > protocol/xdg-shell-client-protocol.h\
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h \
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h \
> > protocol/ivi-application-protocol.c \
> > protocol/ivi-application-client-protocol.h
> >  weston_simple_shm_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS)
> > @@ -488,8 +488,8 @@ nodist_weston_simple_damage_SOURCES =   \
> > protocol/scaler-client-protocol.h   \
> > protocol/xdg-shell-protocol.c   \
> > protocol/xdg-shell-client-protocol.h\
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h
> >  weston_simple_damage_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS)
> >  weston_simple_damage_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la
> >  
> > @@ -531,8 +531,8 @@ weston_simple_dmabuf_SOURCES = clients/simple-dmabuf.c
> >  nodist_weston_simple_dmabuf_SOURCES =  \
> > protocol/xdg-shell-protocol.c   \
> > protocol/xdg-shell-client-protocol.h\
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h \
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h \
> > protocol/linux-dmabuf-protocol.c \
> > protocol/linux-dmabuf-client-protocol.h
> >  weston_simple_dmabuf_CFLAGS = $(AM_CFLAGS) $(SIMPLE_DMABUF_CLIENT_CFLAGS)
> > @@ -649,8 +649,8 @@ weston_transformed_CFLAGS = $(AM_CFLAGS) 
> > $(CLIENT_CFLAGS)
> >  
> >  weston_fullscreen_SOURCES = clients/fullscreen.c
> >  nodist_weston_fullscreen_SOURCES = \
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h
> >  weston_fullscreen_LDADD = libtoytoolkit.la
> >  weston_fullscreen_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
> >  
> > @@ -763,8 +763,8 @@ BUILT_SOURCES +=
> > \
> > protocol/scaler-protocol.c  \
> > protocol/workspaces-client-protocol.h   \
> > protocol/workspaces-protocol.c  \
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h \
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h \
> > protocol/xdg-shell-protocol.c   \
> > protocol/xdg-shell-client-protocol.h\
> > protocol/ivi-hmi-controller-protocol.c  \
> > @@ -865,8 +865,8 @@ 

Re: [PATCH weston 00/10] weston wayland-protocols migration

[Bryce Harrington]

On Thu, Nov 05, 2015 at 12:21:21PM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:49 +0800
> Jonas Ådahl  wrote:
> 
> > Hi,
> > 
> > This series changes weston to depend on wayland-protocols for the
> > majority of the protocols previously in the protocols/ directory. The
> > protocols moved are also renamed to comply with the unstable naming
> > conventions of wayland-protocols, with the exception of xdg_shell which
> > will use the current name until the next version.
> > 
> > I'd appreciate if maintainers of given protocols could at least Ack the
> > patch changing their protocol implementation, as a semi formal stamp of
> > approval of the name change.
> 
> Hi Jonas,
> 
> I'll give any detailed feedback as replies to the patches, here are some
> overall comments.
> 
> > Other than that, the workspaces protocol is removed, mostly because it
> > wasn't a significant enough proof of concept needed for any particular
> > feature. text-cursor-position.xml however I have left intact, because
> > without it the zoom accessibility feature proof of concept becomes
> > a bit too useless. I'd prefer to prefix it with something like toy_ or
> > weston_, but would like to hear input on this one. Given that it is
> > completely undocumented it is quite far from a real attempt, but it
> > seems like something that will be needed sooner or later for
> > accessibility reasons, so not sure what to do with it right now.
> > 
> > Things that seemed more weston specific was weston_ prefixed. The
> > screenshooter protocol and the desktop shell protocol fell into this
> > category.
> 
> Speaking of prefixes, do we have an idea what protocols should use the
> wl_ prefix and what shouldn't?
> 
> I have had the feeling that wl_ is only Wayland core. But what does
> Wayland core mean? And wl_shell is an exception already.
> 
> Should we restrict wl_ to only for things in wayland.xml? Probably not,
> as I think wl_ in e.g. wl_scaler is justified since it's a "low-level"
> generic feature, and yet wl_scaler will not be added into wayland.xml.
> 
> Perhaps wl_ prefix should be reserved for extensions that are usable
> regardless of a shell or environment. I'm not sure if the input method
> extensions would be eligible for wl_ or not, or what to do with
> fullscreen shell.

That sounds like a good rule of thumb.  I should think it further should
be limited to stuff that we (the Wayland project) intend to provide
stability guarantees for and to maintain as an official interface for
the project.

> This puzzles me a bit:
> 
>   "Each release of wayland-protocols finalizes the version of the
>   protocols to their state they had at that time. Between each
>   release, backward incompatible changes can be made to both
>   stable and major unstable protocol versions as long as the
>   requirements are held upon release."
> 
> It says backward-incompatible changes could be made to also stable
> protocols as long as stability is maintained from release to release.
> Essentially it means that such changes have to be reverted before the
> next release. Is that just to account for accidents?
>
> If wayland-protocols is intended to be released often and as-needed, we
> should make sure we don't need such reverts to begin with. Otherwise
> the release engineer will have a big review burden. IOW, we should keep
> the repo in an always releasable state.
>
> In short, I wouldn't mention the stable protocols in this paragraph.

Agreed.  It's also not unlikely people will be using snapshots of the
git tree from between releases.

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

Re: [PATCH weston 01/10] Use fullscreen-shell.xml from wayland-protocols

[Bryce Harrington]

On Wed, Nov 04, 2015 at 04:49:50PM +0800, Jonas Ådahl wrote:
> Use the fullscreen-shell protocol XML from the wayland-protocols
> installation, and remove the one we provide ourself.
> 
> Signed-off-by: Jonas Ådahl 
>
> diff --git a/clients/fullscreen.c b/clients/fullscreen.c
> index 4fcca3d..be316d0 100644
> --- a/clients/fullscreen.c
> +++ b/clients/fullscreen.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  #include "window.h"
> -#include "fullscreen-shell-client-protocol.h"
> +#include "fullscreen-shell-unstable-v1-client-protocol.h"

Angle brackets should be used here and elsewhere, since with this change
the header file now is located externally from the system rather than
being locally present in the codebase.

  #include 
  
>  struct fs_output {
>   struct wl_list link;
> @@ -46,8 +46,8 @@ struct fullscreen {
>   struct display *display;
>   struct window *window;
>   struct widget *widget;
> - struct _wl_fullscreen_shell *fshell;
> - enum _wl_fullscreen_shell_present_method present_method;
> + struct zwl_fullscreen_shell1 *fshell;
> + enum zwl_fullscreen_shell1_present_method present_method;
>   int width, height;
>   int fullscreen;
>   float pointer_x, pointer_y;
> @@ -293,10 +293,10 @@ key_handler(struct window *window, struct input *input, 
> uint32_t time,
>   if (fullscreen->current_output)
>   wl_output = 
> output_get_wl_output(fullscreen->current_output->output);
>   fullscreen->present_method = (fullscreen->present_method + 1) % 
> 5;
> - _wl_fullscreen_shell_present_surface(fullscreen->fshell,
> -  
> window_get_wl_surface(fullscreen->window),
> -  fullscreen->present_method,
> -  wl_output);
> + zwl_fullscreen_shell1_present_surface(fullscreen->fshell,
> +   
> window_get_wl_surface(fullscreen->window),
> +   
> fullscreen->present_method,
> +   wl_output);
>   window_schedule_redraw(window);
>   break;
>  
> @@ -308,8 +308,8 @@ key_handler(struct window *window, struct input *input, 
> uint32_t time,
>   wl_output = fsout ? output_get_wl_output(fsout->output) : NULL;
>  
>   /* Clear the current presentation */
> - _wl_fullscreen_shell_present_surface(fullscreen->fshell, NULL,
> -  0, wl_output);
> + zwl_fullscreen_shell1_present_surface(fullscreen->fshell, NULL,
> +   0, wl_output);

Hmm.  With l's and 1's looking so similar in certain fonts, "shell1" is
going to look like a typo to some users.  IMO it would be better to
distinguish this version number with at least an underscore.
"_shell_v1_" would feel more consistent with the scheme being used in
the header file name, protocol file name, macro definitions, etc.

> diff --git a/configure.ac b/configure.ac
> index e5afbc0..cfac579 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -181,6 +181,13 @@ fi
>  PKG_CHECK_MODULES(LIBINPUT_BACKEND, [libinput >= 0.8.0])
>  PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])
>  
> +PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, [wayland-protocols >= 0.1.0],

Please also update RELEASING with a sentence or two about needing to
check and update this protocol package version number.

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

[PATCH v2 wayland 1/3] shm: Deprecate wl_shm_buffer_create()

[Derek Foreman]

From irc:
 it creates a wl_buffer object in a way that no client can ever
 access the storage.

So, let's replace it with return NULL; and mark it with attribute
deprecated in the header.

Reviewed-by: Pekka Paalanen 
Signed-off-by: Derek Foreman 
---

Change from v1: return NULL instead of abort()ing

 src/wayland-server-core.h |  2 +-
 src/wayland-shm.c | 29 +
 2 files changed, 2 insertions(+), 29 deletions(-)

diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
index 73f2dd2..85b4b9e 100644
--- a/src/wayland-server-core.h
+++ b/src/wayland-server-core.h
@@ -472,7 +472,7 @@ wl_display_add_shm_format(struct wl_display *display, 
uint32_t format);
 struct wl_shm_buffer *
 wl_shm_buffer_create(struct wl_client *client,
 uint32_t id, int32_t width, int32_t height,
-int32_t stride, uint32_t format);
+int32_t stride, uint32_t format) WL_DEPRECATED;
 
 void wl_log_set_handler_server(wl_log_func_t handler);
 
diff --git a/src/wayland-shm.c b/src/wayland-shm.c
index 1ab8f89..a05a8a0 100644
--- a/src/wayland-shm.c
+++ b/src/wayland-shm.c
@@ -319,34 +319,7 @@ wl_shm_buffer_create(struct wl_client *client,
 uint32_t id, int32_t width, int32_t height,
 int32_t stride, uint32_t format)
 {
-   struct wl_shm_buffer *buffer;
-
-   if (!format_is_supported(client, format))
-   return NULL;
-
-   buffer = malloc(sizeof *buffer + stride * height);
-   if (buffer == NULL)
-   return NULL;
-
-   buffer->width = width;
-   buffer->height = height;
-   buffer->format = format;
-   buffer->stride = stride;
-   buffer->offset = 0;
-   buffer->pool = NULL;
-
-   buffer->resource =
-   wl_resource_create(client, _buffer_interface, 1, id);
-   if (buffer->resource == NULL) {
-   free(buffer);
-   return NULL;
-   }
-
-   wl_resource_set_implementation(buffer->resource,
-  _buffer_interface,
-  buffer, destroy_buffer);
-
-   return buffer;
+   return NULL;
 }
 
 WL_EXPORT struct wl_shm_buffer *
-- 
2.6.1

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

[PATCH v2 wayland 3/3] shm: wl_shm_buffer_get_data() requires a valid pool.

[Derek Foreman]

There's no situation where a shm buffer without a pool makes sense,
so we enforce the pool's existence a little more rigidly.

Acked-by: Pekka Paalanen 
Signed-off-by: Derek Foreman 
---
 src/wayland-shm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/wayland-shm.c b/src/wayland-shm.c
index db23909..0cd8c11 100644
--- a/src/wayland-shm.c
+++ b/src/wayland-shm.c
@@ -353,10 +353,12 @@ wl_shm_buffer_get_stride(struct wl_shm_buffer *buffer)
 WL_EXPORT void *
 wl_shm_buffer_get_data(struct wl_shm_buffer *buffer)
 {
-   if (buffer->pool)
-   return buffer->pool->data + buffer->offset;
-   else
-   return buffer + 1;
+   assert(buffer->pool);
+
+   if (!buffer->pool)
+   return NULL;
+
+   return buffer->pool->data + buffer->offset;
 }
 
 WL_EXPORT uint32_t
-- 
2.6.1

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

[PATCH v2 wayland 2/3] shm: Move deprecated function to the bottom of the file

[Derek Foreman]

In wayland-server.c we group the deprecated functions and
disable doxygen for them.  Do that here too.

Acked-by: Pekka Paalanen 
Signed-off-by: Derek Foreman 
---
Change from v1: return NULL instead of abort()ing

 src/wayland-shm.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/src/wayland-shm.c b/src/wayland-shm.c
index a05a8a0..db23909 100644
--- a/src/wayland-shm.c
+++ b/src/wayland-shm.c
@@ -315,14 +315,6 @@ wl_display_init_shm(struct wl_display *display)
 }
 
 WL_EXPORT struct wl_shm_buffer *
-wl_shm_buffer_create(struct wl_client *client,
-uint32_t id, int32_t width, int32_t height,
-int32_t stride, uint32_t format)
-{
-   return NULL;
-}
-
-WL_EXPORT struct wl_shm_buffer *
 wl_shm_buffer_get(struct wl_resource *resource)
 {
if (resource == NULL)
@@ -588,3 +580,20 @@ wl_shm_buffer_end_access(struct wl_shm_buffer *buffer)
sigbus_data->current_pool = NULL;
}
 }
+
+/** \cond */ /* Deprecated functions below. */
+
+WL_EXPORT struct wl_shm_buffer *
+wl_shm_buffer_create(struct wl_client *client,
+uint32_t id, int32_t width, int32_t height,
+int32_t stride, uint32_t format)
+{
+   return NULL;
+}
+
+/** \endcond */
+
+/* Functions at the end of this file are deprecated.  Instead of adding new
+ * code here, add it before the comment above that states:
+ * Deprecated functions below.
+ */
-- 
2.6.1

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

Re: [PATCH weston] Support axis source, axis discreet, axis frame and axis stop events

[Derek Foreman]

On 15/10/15 09:39 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer 
> ---
> The client-side is the simplest implementation here, and I went the easy
> route since most clients won't care to register a multitude of handlers for
> axis events.
> 
> The eventdemo client merely prints the events, it doesn't accumulate them as
> they should be. That'd be the job of a slightly more sophisticated toolkit.
> 
> Possibly contentious: there's no notify_axis_stop(), it's folded into
> notify_axis(). Easy fix if needed.
> 
> Also, I recommend not merging this one until we have a test implementation
> in mutter + GTK to make sure the protocol is sane enough to use from complex
> clients.
> 
>  clients/eventdemo.c  | 55 -
>  clients/window.c | 91 
> +++-
>  clients/window.h | 28 +++
>  src/compositor-wayland.c | 39 +
>  src/compositor-x11.c | 16 ++---
>  src/compositor.h | 10 ++
>  src/input.c  | 74 ++-
>  src/libinput-device.c| 63 +++--
>  8 files changed, 360 insertions(+), 16 deletions(-)
> 
> diff --git a/clients/eventdemo.c b/clients/eventdemo.c
> index bdad6fd..f520233 100644
> --- a/clients/eventdemo.c
> +++ b/clients/eventdemo.c
> @@ -259,6 +259,54 @@ axis_handler(struct widget *widget, struct input *input, 
> uint32_t time,
>  wl_fixed_to_double(value));
>  }
>  
> +static void
> +axis_frame_handler(struct widget *widget, struct input *input, void *data)
> +{
> + printf("axis frame\n");
> +}
> +
> +static void
> +axis_source_handler(struct widget *widget, struct input *input,
> + uint32_t source, void *data)
> +{
> + const char *axis_source;
> +
> + switch (source) {
> + case WL_POINTER_AXIS_SOURCE_WHEEL:
> + axis_source = "wheel";
> + break;
> + case WL_POINTER_AXIS_SOURCE_FINGER:
> + axis_source = "finger";
> + break;
> + case WL_POINTER_AXIS_SOURCE_CONTINUOUS:
> + axis_source = "continuous";
> + break;
> + default:
> + axis_source = "";
> + break;
> + }
> +
> + printf("axis source: %s\n", axis_source);
> +}
> +
> +static void
> +axis_stop_handler(struct widget *widget, struct input *input,
> +   uint32_t time, uint32_t axis,
> +   void *data)
> +{
> + printf("axis stop time: %d, axis: %s\n",
> +time,
> +axis == WL_POINTER_AXIS_VERTICAL_SCROLL ? "vertical" :
> +  "horizontal");
> +}
> +
> +static void
> +axis_discrete_handler(struct widget *widget, struct input *input,
> +   int32_t discrete, void *data)
> +{
> + printf("axis discrete value: %d\n", discrete);
> +}
> +
>  /**
>   * \brief CALLBACK function, Waylands informs about pointer motion
>   * \param widget widget
> @@ -348,7 +396,12 @@ eventdemo_create(struct display *d)
>   widget_set_motion_handler(e->widget, motion_handler);
>  
>   /* Set the callback axis handler for the window */
> - widget_set_axis_handler(e->widget, axis_handler);
> + widget_set_axis_handlers(e->widget,
> +  axis_handler,
> +  axis_frame_handler,
> +  axis_source_handler,
> +  axis_stop_handler,
> +  axis_discrete_handler);
>  
>   /* Initial drawing of the window */
>   window_schedule_resize(e->window, width, height);
> diff --git a/clients/window.c b/clients/window.c
> index 6d3e944..121037b 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -288,6 +288,10 @@ struct widget {
>   widget_touch_frame_handler_t touch_frame_handler;
>   widget_touch_cancel_handler_t touch_cancel_handler;
>   widget_axis_handler_t axis_handler;
> + widget_axis_frame_handler_t axis_frame_handler;
> + widget_axis_source_handler_t axis_source_handler;
> + widget_axis_stop_handler_t axis_stop_handler;
> + widget_axis_discrete_handler_t axis_discrete_handler;
>   void *user_data;
>   int opaque;
>   int tooltip_count;
> @@ -1935,6 +1939,21 @@ widget_set_axis_handler(struct widget *widget,
>   widget->axis_handler = handler;
>  }
>  
> +void
> +widget_set_axis_handlers(struct widget *widget,
> + widget_axis_handler_t axis_handler,
> + widget_axis_frame_handler_t axis_frame_handler,
> + 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->axis_handler = axis_handler;
> + widget->axis_frame_handler = axis_frame_handler;
> + 

Re: [PATCH weston 10/10] Remove workspaces protocol

[Bryce Harrington]

On Thu, Nov 05, 2015 at 10:28:53AM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:59 +0800
> Jonas Ådahl  wrote:
> 
> > It doesn't fill a useful function and is not intended to be continued.
> > If there is need for workspace manipulation from clients a protocol
> > based on those future needs need to be properly designed.
> > workspaces.xml is probably not very relevant since it did the bare
> > minimum.
> > 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  Makefile.am |   7 ---
> >  clients/window.c|  57 +---
> >  desktop-shell/shell.c   | 113 
> > 
> >  protocol/workspaces.xml |  27 
> >  4 files changed, 1 insertion(+), 203 deletions(-)
> >  delete mode 100644 protocol/workspaces.xml
> 
> Acked-by: Pekka Paalanen 
> 
> Are we left with any way to move a window from a workspace to another?
> 
> Should we have multiple workspaces in vanilla Weston/desktop at all?

I don't think we should shut the door to having multiple workspaces (or
other analogous concepts) in the future, but am ok dropping this
particular attempt.

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

Re: [PATCH wayland v2] Remove protocol/wayland.dtd

[Peter Hutterer]

On Thu, Nov 05, 2015 at 03:40:27PM +, Auke Booij wrote:
> On 5 November 2015 at 14:58, Pekka Paalanen  wrote:
> > On Mon, 19 Oct 2015 11:30:47 +1000
> > Peter Hutterer  wrote:
> >
> >> On Fri, Oct 16, 2015 at 11:42:21AM +0300, Pekka Paalanen wrote:
> >> > On Fri, 16 Oct 2015 12:29:11 +1000
> >> > Peter Hutterer  wrote:
> >> >
> >> > > On Fri, Oct 09, 2015 at 01:16:49PM +0200, Nils Chr. Brause wrote:
> >> > > > Hi,
> >> > > >
> >> > > > Reviewed-by: Nils Christopher Brause 
> >> > > >
> >> > > > I ran distcheck and it worked. :)
> >> > >
> >> > > a bit late, but I would like to register my disagreement with this 
> >> > > patch :)
> >> > >
> >> > > Having the DTD is a much simpler and less bug-prone description of 
> >> > > what the
> >> > > protocol should look like. Having the scanner define the protocol 
> >> > > means the
> >> > > protocol is whatever the current version of the scanner supports, 
> >> > > which is
> >> > > not a good contract.
> >> >
> >> > Hi Peter,
> >> >
> >> > can't argue with that. It's just that the DTD was unused since
> >> > 6292fe2af6a45decb7fd39090e74dd87bc4e22b2, Feb 2014.
> >> >
> >> > > I'd argue for reverting this and fixing any mismatch if there is one. 
> >> > > And
> >> > > using the DTD to validate before the scanner even runs.
> >> >
> >> > We talked in IRC about this, and came to the conclusion that maybe we
> >> > could have wayland-scanner invoke a validity checker against a DTD or
> >> > an XSD.
> >>
> >> I played around with that. As a quick basic solution we can hook validation
> >> with libxml2 into the scanner and print a warning if the xml doesn't
> >> validate. That's less than 50 LOC and won't break things since it doesn't
> >> touch the actual parsing. and it won't break existing protocols that use
> >> "creative" tags, all it will do is warn, not fail. See the diff below 
> >> (after
> >> reverting 06fb8bd37.
> >>
> >> it's an ugly solution though, but without scanner tests probably the best
> >> thing we can do.
> >
> > Yeah, I agree. I think I'd be ok going forward with this. The patch
> > looks like a good start if we can solve the DTD file loading.
> >
> > Libxml2 dependency should probably be build-time optional so far.
> >
> >> > If the original objection to a DTD was because it required manually
> >> > writing a lint phase in every project build system using the XML files,
> >> > then having wayland-scanner invoke the check automatically solves that.
> >>
> >> the question that remains though is: the dtd must be an external file for
> >> extensions to be validated. Which means we need to either pass the dtd as
> >> argument to the scanner (requires makefile changes everywhere), or we
> >> hardcode the path into wayland-scanner (issues with running the scanner 
> >> from
> >> within the source tree) or we add it as variable to pkgconfig (requires
> >> makefile changes again). any other solutions to fix this are welcome.
> >> even if all we do is call out to xmllint we still run into that issue.
> >
> > Or, hopefully we can embed the DTD file into the scanner binary - is
> > there no way to let libxml2 read it as a plain string?
> >
> > I used the following trick to embed some files in Wesgr:
> > https://github.com/ppaalanen/wesgr/commit/02a840cb7db7eeb80071a353f66865d729738ae5
> >
> >
> > Thanks,
> > pq
> 
> 
> If I understand correctly, you want to require the scanner to read the
> DTD. Hence, since the scanner defines the protocol, the DTD is now
> officially part of the protocol. So you might as well require that
> wayland.dtd can be found in the same directory as the protocol XML
> file itself.

unfortunately that doesn't work for external protocol files that rely on the
scanner, but not the wayland.xml protocol file

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

Re: [PATCH wayland v2] Remove protocol/wayland.dtd

[Peter Hutterer]

On Thu, Nov 05, 2015 at 04:58:09PM +0200, Pekka Paalanen wrote:
> On Mon, 19 Oct 2015 11:30:47 +1000
> Peter Hutterer  wrote:
> 
> > On Fri, Oct 16, 2015 at 11:42:21AM +0300, Pekka Paalanen wrote:
> > > On Fri, 16 Oct 2015 12:29:11 +1000
> > > Peter Hutterer  wrote:
> > > 
> > > > On Fri, Oct 09, 2015 at 01:16:49PM +0200, Nils Chr. Brause wrote:
> > > > > Hi,
> > > > > 
> > > > > Reviewed-by: Nils Christopher Brause 
> > > > > 
> > > > > I ran distcheck and it worked. :)
> > > > 
> > > > a bit late, but I would like to register my disagreement with this 
> > > > patch :)
> > > > 
> > > > Having the DTD is a much simpler and less bug-prone description of what 
> > > > the
> > > > protocol should look like. Having the scanner define the protocol means 
> > > > the
> > > > protocol is whatever the current version of the scanner supports, which 
> > > > is
> > > > not a good contract.
> > > 
> > > Hi Peter,
> > > 
> > > can't argue with that. It's just that the DTD was unused since
> > > 6292fe2af6a45decb7fd39090e74dd87bc4e22b2, Feb 2014.
> > > 
> > > > I'd argue for reverting this and fixing any mismatch if there is one. 
> > > > And
> > > > using the DTD to validate before the scanner even runs.
> > > 
> > > We talked in IRC about this, and came to the conclusion that maybe we
> > > could have wayland-scanner invoke a validity checker against a DTD or
> > > an XSD.
> > 
> > I played around with that. As a quick basic solution we can hook validation
> > with libxml2 into the scanner and print a warning if the xml doesn't
> > validate. That's less than 50 LOC and won't break things since it doesn't
> > touch the actual parsing. and it won't break existing protocols that use
> > "creative" tags, all it will do is warn, not fail. See the diff below (after
> > reverting 06fb8bd37.
> > 
> > it's an ugly solution though, but without scanner tests probably the best
> > thing we can do.
> 
> Yeah, I agree. I think I'd be ok going forward with this. The patch
> looks like a good start if we can solve the DTD file loading.
> 
> Libxml2 dependency should probably be build-time optional so far.
> 
> > > If the original objection to a DTD was because it required manually
> > > writing a lint phase in every project build system using the XML files,
> > > then having wayland-scanner invoke the check automatically solves that.
> > 
> > the question that remains though is: the dtd must be an external file for
> > extensions to be validated. Which means we need to either pass the dtd as
> > argument to the scanner (requires makefile changes everywhere), or we
> > hardcode the path into wayland-scanner (issues with running the scanner from
> > within the source tree) or we add it as variable to pkgconfig (requires
> > makefile changes again). any other solutions to fix this are welcome.
> > even if all we do is call out to xmllint we still run into that issue.
> 
> Or, hopefully we can embed the DTD file into the scanner binary - is
> there no way to let libxml2 read it as a plain string?

yep, just tested it here, it's a 3-line change to the patch to load from a
string.

> I used the following trick to embed some files in Wesgr:
> https://github.com/ppaalanen/wesgr/commit/02a840cb7db7eeb80071a353f66865d729738ae5

nice one. though if we're going for the embedded route anyway, we could just
have it a const char in the scanner.c file. The dtd isn't really expected to
change and when it does, the scanner needs to change too. Maybe we should
just go for the easy route?

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

Re: [RFC wayland] doc: generate doxygen html output from the scanner

[Tiago Vignatti]

On 11/04/2015 09:44 PM, Peter Hutterer wrote:

On Wed, Nov 04, 2015 at 03:30:29PM -0800, Bryce Harrington wrote:

On Mon, Nov 02, 2015 at 10:27:54AM +1000, Peter Hutterer wrote:

On Fri, Oct 30, 2015 at 03:40:33PM -0700, Bryce Harrington wrote:
but: the current API docs in publican are useless. look at appendix B, the
"client API". http://wayland.freedesktop.org/docs/html/apb.html
it's technically the client API but it's lacking anything that's not core
libwayland API. it doesn't describe protocol interfaces at all. That's only
in the protocol spec (Appendix A) and that is generated straight from the
xml without doxygen's involvement.

The doxygen output in this patch only does the protocol interfaces. so there
isn't even an overlap between these new ones and the current ones, but the
new ones could be made to include the core libwayland bits too.


Yeah I agree, and that's a good point.  I wouldn't be at all opposed to
dropping this.  If we can do that as a follow up patch, then it'd make
it easier to get wider visibility on the change, in case anyone has
reservations about it.

Do you know why the API docs were added to the publican doc in the first
place?  Was it simply to make sure the docs existed somewhere, or was
there a specific need e.g. like being able to have them in a more easily
printed format?  Or...?


the publican doc was the one doc source, both for the PDF and the website.
I suspect Tiago's intent (e2db4cf) was simply to add more useful stuff to
it, at the cost of a doxygen run and an xsl transformation.
And it works, the server/client library both are there and documented, we're
just missing the actual protocol bits :)


right on!

Tiago

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

Re: [PATCH wayland 2/3] doc: make the doxygen output dependent on scanner.c

[Bryce Harrington]

On Fri, Nov 06, 2015 at 08:02:00AM +1000, Peter Hutterer wrote:
> When the scanner changes, we need to rebuild
> 
> Signed-off-by: Peter Hutterer 

Reviewed-by: Bryce Harrington 
> ---
>  doc/doxygen/Makefile.am | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am
> index 5520d39..a8bb95f 100644
> --- a/doc/doxygen/Makefile.am
> +++ b/doc/doxygen/Makefile.am
> @@ -44,14 +44,14 @@ $(diagrams): $(diagramssrc)
>  
>  $(diagram_maps):  $(diagramssrc)
>  
> -xml/%/index.xml: $(scanned_src_files_%) wayland.doxygen $(diagrams) 
> $(diagram_maps) | xml/%
> +xml/%/index.xml: $(top_srcdir)/src/scanner.c $(scanned_src_files_%) 
> wayland.doxygen $(diagrams) $(diagram_maps) | xml/%
>   $(AM_V_GEN)(cat wayland.doxygen; \
>echo "GENERATE_XML=YES"; \
>echo "XML_OUTPUT=xml/$*"; \
>echo "INPUT= $(scanned_src_files_$*)"; \
>) | $(DOXYGEN) -
>  
> -man/man3/wl_display.3: $(scanned_src_files_man) wayland.doxygen | man/man3
> +man/man3/wl_display.3: $(top_srcdir)/src/scanner.c $(scanned_src_files_man) 
> wayland.doxygen | man/man3
>   $(AM_V_GEN)(cat wayland.doxygen; \
>echo "GENERATE_MAN=YES"; \
>echo "MAN_OUTPUT=man"; \
> -- 
> 2.4.3
> 
> ___
> 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: [PATCH wayland 1/3] scanner: don't print trailing whitespaces

[Bryce Harrington]

On Fri, Nov 06, 2015 at 08:01:59AM +1000, Peter Hutterer wrote:
> If we're printing a zero-length string, we end up printing " * " and that
> makes anything unhappy that doesn't handle trailing whitespaces.
> 
> Signed-off-by: Peter Hutterer 

Easy enough.

Reviewed-by: Bryce Harrington 
> ---
>  src/scanner.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/scanner.c b/src/scanner.c
> index f456aa5..7b0f482 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -1141,8 +1141,9 @@ format_copyright(const char *copyright)
>   }
>  
>   if (copyright[i] == '\n' || copyright[i] == '\0') {
> - printf("%s %.*s\n",
> + printf("%s%s%.*s\n",
>  i == 0 ? "/*" : " *",
> +(i - start) == 0 ? "" : " ",
>  i - start, copyright + start);
>   bol = 1;
>   }
> -- 
> 2.4.3
> 
> ___
> 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

[PATCH wayland 1/3] scanner: don't print trailing whitespaces

[Peter Hutterer]

If we're printing a zero-length string, we end up printing " * " and that
makes anything unhappy that doesn't handle trailing whitespaces.

Signed-off-by: Peter Hutterer 
---
 src/scanner.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/scanner.c b/src/scanner.c
index f456aa5..7b0f482 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1141,8 +1141,9 @@ format_copyright(const char *copyright)
}
 
if (copyright[i] == '\n' || copyright[i] == '\0') {
-   printf("%s %.*s\n",
+   printf("%s%s%.*s\n",
   i == 0 ? "/*" : " *",
+  (i - start) == 0 ? "" : " ",
   i - start, copyright + start);
bol = 1;
}
-- 
2.4.3

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

[PATCH wayland 3/3] doc: generate doxygen html output from the scanner

[Peter Hutterer]

This switches the scanner to generate doxygen-compatible tags for the
generated protocol headers, and hooks up the doxygen build to generate server
and client-side API documentation.

Each protocol is a separate doxygen @page, with each interface a @subpage.
Wayland only has one protocol, wayland-protocols will have these nested.
Each protocol page has a list of interfaces and the copyright and description
where available.
All interfaces are grouped by doxygen @defgroup and @ingroups and appear in
"Modules" in the generated output. Each interface subpage has the description
and a link to the actual API doc.
Function, struct and #defines are documented in doxygen style and associated
with the matching interface.

Note that pages and groups have fixed HTML file names and are directly
linkable/bookmark-able.

The @mainpage is a separate file that's included at build time. It doesn't
contain much other than links to where the interesting bits are. It's a static
file though that supports markdown, so we can extend it easily in the future.

For doxygen we need the new options EXTRACT_ALL and OPTIMIZE_OUTPUT_FOR_C so
it scans C code properly. WARN_IF_DOC_ERROR is required to silence the
warnings when some parameters are documented but others aren't.

Signed-off-by: Peter Hutterer 
---
Generated output for wayland and wayland-protocols is here:
http://people.freedesktop.org/~whot/wayland-doxygen/

* as discussed in the other thread, this doesn't touch the current generated
  xml files, the current doc doesn't actually include the protocol API
  anyway.
* mainpage is separate because it's easier this way for wayland-protocols
* the generated code contains a lot of comment now but is still readable.
  Only duplication is the copyright (once at file level, once as protocol
  section), but that shouldn't hurt anyone.
* we should start including  tags at the  level. the
  scanner supports it and it provides extra info (see the tablet
  protocol in wayland-protocols)

 doc/doxygen/Makefile.am|  27 +-
 doc/doxygen/mainpage.dox   |  13 +++
 doc/doxygen/wayland.doxygen.in |   4 +-
 src/scanner.c  | 207 +++--
 4 files changed, 176 insertions(+), 75 deletions(-)
 create mode 100644 doc/doxygen/mainpage.dox

diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am
index a8bb95f..e80c401 100644
--- a/doc/doxygen/Makefile.am
+++ b/doc/doxygen/Makefile.am
@@ -1,7 +1,11 @@
 
 .SUFFIXES = .gv .png .map
 
-noinst_DATA = xml/Client/index.xml xml/Server/index.xml
+noinst_DATA = \
+  xml/Client/index.xml \
+  xml/Server/index.xml \
+  html/Client/index.html \
+  html/Server/index.html
 dist_noinst_DATA = wayland.doxygen.in
 
 scanned_src_files_shared = \
@@ -27,6 +31,17 @@ scanned_src_files_man =  
\
$(top_srcdir)/src/wayland-client.h  \
$(top_srcdir)/src/wayland-client-core.h
 
+extra_doxygen = \
+   mainpage.dox
+
+extra_doxygen_Server = \
+   $(top_builddir)/protocol/wayland-server-protocol.h \
+   $(extra_doxygen)
+
+extra_doxygen_Client = \
+   $(top_builddir)/protocol/wayland-client-protocol.h \
+   $(extra_doxygen)
+
 diagramsdir := $(srcdir)/dot
 diagramssrc := $(wildcard $(diagramsdir)/*.gv)
 diagrams := $(patsubst $(diagramsdir)/%,xml/%,$(diagramssrc:.gv=.png))
@@ -38,7 +53,7 @@ diagram_maps := $(patsubst 
$(diagramsdir)/%,xml/%,$(diagramssrc:.gv=.map))
 dist_man3_MANS = $(shell test -d man && find man/man3 -name "wl_*.3" -printf 
"man/man3/%P\n")
 
 # Listing various directories that might need to be created.
-alldirs := xml xml/Client xml/Server man/man3
+alldirs := xml xml/Client xml/Server man/man3 html/Client html/Server
 
 $(diagrams): $(diagramssrc)
 
@@ -51,6 +66,13 @@ xml/%/index.xml: $(top_srcdir)/src/scanner.c 
$(scanned_src_files_%) wayland.doxy
   echo "INPUT= $(scanned_src_files_$*)"; \
   ) | $(DOXYGEN) -
 
+html/%/index.html: $(scanned_src_files_%) wayland.doxygen $(diagrams) 
$(diagram_maps) | html/%
+   $(AM_V_GEN)(cat wayland.doxygen; \
+  echo "GENERATE_HTML=YES"; \
+  echo "HTML_OUTPUT=html/$*"; \
+  echo "INPUT= $(scanned_src_files_$*) $(extra_doxygen_$*)"; \
+  ) | $(DOXYGEN) -
+
 man/man3/wl_display.3: $(top_srcdir)/src/scanner.c $(scanned_src_files_man) 
wayland.doxygen | man/man3
$(AM_V_GEN)(cat wayland.doxygen; \
   echo "GENERATE_MAN=YES"; \
@@ -74,6 +96,7 @@ all-local: man/man3/wl_display.3
 
 clean-local:
rm -rf xml/
+   rm -rf html/
rm -rf man/
 
 EXTRA_DIST = $(diagramssrc)
diff --git a/doc/doxygen/mainpage.dox b/doc/doxygen/mainpage.dox
new file mode 100644
index 000..8f9bf03
--- /dev/null
+++ b/doc/doxygen/mainpage.dox
@@ -0,0 +1,13 @@
+/**
+ * @mainpage
+ * Wayland protocol API documentation.
+ *
+ * @section ifaces Interfaces
+ * For the list of 

[PATCH wayland 2/3] doc: make the doxygen output dependent on scanner.c

[Peter Hutterer]

When the scanner changes, we need to rebuild

Signed-off-by: Peter Hutterer 
---
 doc/doxygen/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am
index 5520d39..a8bb95f 100644
--- a/doc/doxygen/Makefile.am
+++ b/doc/doxygen/Makefile.am
@@ -44,14 +44,14 @@ $(diagrams): $(diagramssrc)
 
 $(diagram_maps):  $(diagramssrc)
 
-xml/%/index.xml: $(scanned_src_files_%) wayland.doxygen $(diagrams) 
$(diagram_maps) | xml/%
+xml/%/index.xml: $(top_srcdir)/src/scanner.c $(scanned_src_files_%) 
wayland.doxygen $(diagrams) $(diagram_maps) | xml/%
$(AM_V_GEN)(cat wayland.doxygen; \
   echo "GENERATE_XML=YES"; \
   echo "XML_OUTPUT=xml/$*"; \
   echo "INPUT= $(scanned_src_files_$*)"; \
   ) | $(DOXYGEN) -
 
-man/man3/wl_display.3: $(scanned_src_files_man) wayland.doxygen | man/man3
+man/man3/wl_display.3: $(top_srcdir)/src/scanner.c $(scanned_src_files_man) 
wayland.doxygen | man/man3
$(AM_V_GEN)(cat wayland.doxygen; \
   echo "GENERATE_MAN=YES"; \
   echo "MAN_OUTPUT=man"; \
-- 
2.4.3

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

[PATCH libinput 3/6] tablet: restrict tablet_axis_has_changed to axis/proximity events

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/libinput.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/libinput.c b/src/libinput.c
index c1f2700..e384d8d 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -914,6 +914,12 @@ LIBINPUT_EXPORT int
 libinput_event_tablet_axis_has_changed(struct libinput_event_tablet *event,
   enum libinput_tablet_axis axis)
 {
+   require_event_type(libinput_event_get_context(>base),
+  event->base.type,
+  0,
+  LIBINPUT_EVENT_TABLET_AXIS,
+  LIBINPUT_EVENT_TABLET_PROXIMITY);
+
return (NCHARS(axis) <= sizeof(event->changed_axes)) ?
bit_is_set(event->changed_axes, axis) : 0;
 }
-- 
2.4.3

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

[PATCH libinput 4/6] tablet: allow tablet_get_x/y_transformed for proximity events as well

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/libinput.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/libinput.c b/src/libinput.c
index e384d8d..a05148f 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1027,7 +1027,8 @@ libinput_event_tablet_get_x_transformed(struct 
libinput_event_tablet *event,
require_event_type(libinput_event_get_context(>base),
   event->base.type,
   0,
-  LIBINPUT_EVENT_TABLET_AXIS);
+  LIBINPUT_EVENT_TABLET_AXIS,
+  LIBINPUT_EVENT_TABLET_PROXIMITY);
 
return evdev_device_transform_x(device,
event->axes[LIBINPUT_TABLET_AXIS_X],
@@ -1044,7 +1045,8 @@ libinput_event_tablet_get_y_transformed(struct 
libinput_event_tablet *event,
require_event_type(libinput_event_get_context(>base),
   event->base.type,
   0,
-  LIBINPUT_EVENT_TABLET_AXIS);
+  LIBINPUT_EVENT_TABLET_AXIS,
+  LIBINPUT_EVENT_TABLET_PROXIMITY);
 
return evdev_device_transform_y(device,
event->axes[LIBINPUT_TABLET_AXIS_Y],
-- 
2.4.3

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

Re: [PATCH weston 01/10] Use fullscreen-shell.xml from wayland-protocols

[Bryce Harrington]

On Fri, Nov 06, 2015 at 10:51:09AM +0800, Jonas Ådahl wrote:
> On Thu, Nov 05, 2015 at 11:46:46AM -0800, Bryce Harrington wrote:
> > On Wed, Nov 04, 2015 at 04:49:50PM +0800, Jonas Ådahl wrote:
> > > Use the fullscreen-shell protocol XML from the wayland-protocols
> > > installation, and remove the one we provide ourself.
> > > 
> > > Signed-off-by: Jonas Ådahl 
> > >
> > > diff --git a/clients/fullscreen.c b/clients/fullscreen.c
> > > index 4fcca3d..be316d0 100644
> > > --- a/clients/fullscreen.c
> > > +++ b/clients/fullscreen.c
> > > @@ -35,7 +35,7 @@
> > >  #include 
> > >  #include 
> > >  #include "window.h"
> > > -#include "fullscreen-shell-client-protocol.h"
> > > +#include "fullscreen-shell-unstable-v1-client-protocol.h"
> > 
> > Angle brackets should be used here and elsewhere, since with this change
> > the header file now is located externally from the system rather than
> > being locally present in the codebase.
> > 
> >   #include 
> 
> Good point.
> 
> >   
> > >  struct fs_output {
> > >   struct wl_list link;
> > > @@ -46,8 +46,8 @@ struct fullscreen {
> > >   struct display *display;
> > >   struct window *window;
> > >   struct widget *widget;
> > > - struct _wl_fullscreen_shell *fshell;
> > > - enum _wl_fullscreen_shell_present_method present_method;
> > > + struct zwl_fullscreen_shell1 *fshell;
> > > + enum zwl_fullscreen_shell1_present_method present_method;
> > >   int width, height;
> > >   int fullscreen;
> > >   float pointer_x, pointer_y;
> > > @@ -293,10 +293,10 @@ key_handler(struct window *window, struct input 
> > > *input, uint32_t time,
> > >   if (fullscreen->current_output)
> > >   wl_output = 
> > > output_get_wl_output(fullscreen->current_output->output);
> > >   fullscreen->present_method = (fullscreen->present_method + 1) % 
> > > 5;
> > > - _wl_fullscreen_shell_present_surface(fullscreen->fshell,
> > > -  
> > > window_get_wl_surface(fullscreen->window),
> > > -  fullscreen->present_method,
> > > -  wl_output);
> > > + zwl_fullscreen_shell1_present_surface(fullscreen->fshell,
> > > +   
> > > window_get_wl_surface(fullscreen->window),
> > > +   
> > > fullscreen->present_method,
> > > +   wl_output);
> > >   window_schedule_redraw(window);
> > >   break;
> > >  
> > > @@ -308,8 +308,8 @@ key_handler(struct window *window, struct input 
> > > *input, uint32_t time,
> > >   wl_output = fsout ? output_get_wl_output(fsout->output) : NULL;
> > >  
> > >   /* Clear the current presentation */
> > > - _wl_fullscreen_shell_present_surface(fullscreen->fshell, NULL,
> > > -  0, wl_output);
> > > + zwl_fullscreen_shell1_present_surface(fullscreen->fshell, NULL,
> > > +   0, wl_output);
> > 
> > Hmm.  With l's and 1's looking so similar in certain fonts, "shell1" is
> > going to look like a typo to some users.  IMO it would be better to
> > distinguish this version number with at least an underscore.
> > "_shell_v1_" would feel more consistent with the scheme being used in
> > the header file name, protocol file name, macro definitions, etc.
> 
> A slight implicit point of it is to make it a bit awkward, so that it's
> ever so slightly more obvious that this is intended to be temporary.
> 
> The other more important reason is I think we already have very long
> names, and I tried to minimize the extra name length needed.

Being intentionally awkward seems like an anti-pattern to me.  But I
would point out that if it is a goal, then making the names overly long
certainly would achieve that.

Increasing the length of the names does seem like a valid problem,
though.  I almost mentioned it but in thinking it out, I figure: a) the
symbols are intentionally temporary, and making them intentionally
longer might even encourage making the base names slightly shorter,
which is in everyone's interest; b) the scheme is already adding 2
characters, we'd be adding 4 instead, which doesn't seem *that*
excessive; c) clarity is more important to me than brevity; d) making
the names more consistent with header, macro names, etc. seems way more
important than typing convenience.

If increasing the length is still considered a problem, Bill's
suggestion to move the version to the prefix might be worth further
consideration.  It addresses making things clearer without increasing
character count, although I'm uncertain about its usability since it'll
impact name searching and sorting.
 
> I guess I can be convinced otherwise, but personally I prefer the way it
> is.

Well, we all are going to have to live with the scheme...

> > > diff --git 

Re: [PATCH weston 00/10] weston wayland-protocols migration

[Bryce Harrington]

On Fri, Nov 06, 2015 at 10:39:12AM +0800, Jonas Ådahl wrote:
> On Thu, Nov 05, 2015 at 12:21:21PM +0200, Pekka Paalanen wrote:
> > On Wed,  4 Nov 2015 16:49:49 +0800
> > Jonas Ådahl  wrote:
> > > Things that seemed more weston specific was weston_ prefixed. The
> > > screenshooter protocol and the desktop shell protocol fell into this
> > > category.
> > 
> > Speaking of prefixes, do we have an idea what protocols should use the
> > wl_ prefix and what shouldn't?
> > 
> > I have had the feeling that wl_ is only Wayland core. But what does
> > Wayland core mean? And wl_shell is an exception already.
> > 
> > Should we restrict wl_ to only for things in wayland.xml? Probably not,
> > as I think wl_ in e.g. wl_scaler is justified since it's a "low-level"
> > generic feature, and yet wl_scaler will not be added into wayland.xml.
> > 
> > Perhaps wl_ prefix should be reserved for extensions that are usable
> > regardless of a shell or environment. I'm not sure if the input method
> > extensions would be eligible for wl_ or not, or what to do with
> > fullscreen shell.
> > 
> > xdg_shell is setting a precedent for using xdg_ prefix for all
> > desktoppy but still DE-agnostic extensions, and I think that is fine.
> 
> We discussed this last night on IRC and you expressed that you thought
> that the wl_ prefix should be limited to only libwayland-client and
> libwayland-server and nothing else.
> 
> The resulting idea after that discussion was to use the wp_ prefix
> instead of wl_ prefix for future protocols with the exception of the
> rare cases where new interfaces actually have to be added to
> wayland.xml. I don't know of any examples or plans where this is needed
> yet.
> 
> This means wl_scaler would become wp_scaler, wl_fullscreen would become
> wp_fullscreen, wl_presentation wp_presentation, etc.

I can live with that, although I suspect I'll always read it as Word
Perfect rather than Wayland Protocol...
 
> We also somewhat concluded that generic sounding name (linux_) should
> also be prefixed, meaning linux_dmabuf will become wp_linux_dmabuf, but
> maybe we should really use some other prefix for non-generic protocols?
> I'm not sure.

Agreed on prefixing these.

> Regarding the xdg_ prefix, nothing in particular was concluded. I'm not
> sure wp_xdg_ is desirable, but maybe its not that bad. We'll have to
> bite this bullet the next time xdg_shell changes, or if some other
> protocol depending on xdg_shell is introduced. Opinions? Stay with xdg_?
> wp_xdg_? wpxdg? wxdg? wp_desktop_shell? Something else?

This is probably going to require some debate... which is why I
suggested leaving it as a special case so as not to derail the rest of
the effort.  But, I do think it too should be renamed, and I feel fairly
strongly that in doing so we should just discard "xdg" from the name.
Here's my thinking:

1.  "xdg" is a prefix used by an actual real open source project which
isn't us.  We're not using it inappropriately or anything, but still.
We wouldn't name a protocol kde_foo_thingee to make it more acceptable
to kde folks.

2.  As a corollary to #1, using it might suggest the protocol is
something *external* to wayland and not sanctioned by us.  Just as if we
prefixed it kde_ people would reasonably assume it was a KDE thing, not
wayland.

3.  While there is I guess you could say "marketing" value in including
"XDG" in the name as a way to promote cross-desktop adoption, if it did
have any such value in the past, we're beyond that point now.

4.  Many people probably won't know what "XDG" stands for anyway.  We
would do as well to just call it wp_common_desktop_shell and it'd be
more comprehensible to the average person and no less cross-desktoppy.

5.  I don't think it's really that important that we especially label a
protocol as cross-desktop.  After all, the implication is that all
Wayland protocols are intended to be widely usable.  I don't think we'd
push a protocol that is usable by only one desktop environment, so in
that sense xdg_ is kind of redundant with wl_ (or wp_).

6.  As this is a protocol we want to be standardized, that we want to
actively maintain, and that we want used broadly by Wayland-based
projects, it seems right to give it a simple, prominent name like
wp_desktop_shell.

Anyway, that's my long-winded +1 vote for renaming xdg-shell to
wp_desktop_shell.

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

[PATCH libinput 5/6] tools: add tablet support to event-gui

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 tools/event-gui.c | 69 +++
 1 file changed, 69 insertions(+)

diff --git a/tools/event-gui.c b/tools/event-gui.c
index 19324a3..c07213f 100644
--- a/tools/event-gui.c
+++ b/tools/event-gui.c
@@ -85,6 +85,14 @@ struct window {
double x, y;
} pinch;
 
+   struct {
+   double x, y;
+   double x_in, y_in;
+   double pressure;
+   double distance;
+   double tilt_x, tilt_y;
+   } tool;
+
struct libinput_device *devices[50];
 };
 
@@ -216,6 +224,27 @@ draw(GtkWidget *widget, cairo_t *cr, gpointer data)
cairo_stroke(cr);
cairo_restore(cr);
 
+   /* tablet tool, square for prox-in location */
+   cairo_save(cr);
+   cairo_set_source_rgb(cr, .8, .8, .8);
+   if (w->tool.x_in && w->tool.y_in) {
+   cairo_rectangle(cr, w->tool.x_in - 15, w->tool.y_in - 15, 30, 
30);
+   cairo_stroke(cr);
+   cairo_restore(cr);
+   cairo_save(cr);
+   }
+
+   if (w->tool.pressure)
+   cairo_set_source_rgb(cr, .8, .8, .2);
+
+   cairo_translate(cr, w->tool.x, w->tool.y);
+   cairo_scale(cr, 1.0 + w->tool.tilt_x, 1.0 + w->tool.tilt_y);
+   cairo_arc(cr, 0, 0,
+ 1 + 10 * max(w->tool.pressure, w->tool.distance),
+ 0, 2 * M_PI);
+   cairo_fill(cr);
+   cairo_restore(cr);
+
return TRUE;
 }
 
@@ -551,6 +580,45 @@ handle_event_pinch(struct libinput_event *ev, struct 
window *w)
}
 }
 
+static void
+handle_event_tablet(struct libinput_event *ev, struct window *w)
+{
+   struct libinput_event_tablet *t = libinput_event_get_tablet_event(ev);
+
+   switch (libinput_event_get_type(ev)) {
+   case LIBINPUT_EVENT_TABLET_PROXIMITY:
+   if (libinput_event_tablet_get_proximity_state(t) ==
+   LIBINPUT_TOOL_PROXIMITY_OUT) {
+   w->tool.x_in = 0;
+   w->tool.y_in = 0;
+   } else {
+   w->tool.x_in = 
libinput_event_tablet_get_x_transformed(t,
+  
w->width);
+   w->tool.y_in = 
libinput_event_tablet_get_y_transformed(t,
+  
w->height);
+   }
+   break;
+   case LIBINPUT_EVENT_TABLET_AXIS:
+   w->tool.x = libinput_event_tablet_get_x_transformed(t,
+   w->width);
+   w->tool.y = libinput_event_tablet_get_y_transformed(t,
+   w->height);
+   w->tool.pressure = libinput_event_tablet_get_axis_value(t,
+   
LIBINPUT_TABLET_AXIS_PRESSURE);
+   w->tool.distance = libinput_event_tablet_get_axis_value(t,
+   
LIBINPUT_TABLET_AXIS_DISTANCE);
+   w->tool.tilt_x = libinput_event_tablet_get_axis_value(t,
+   
LIBINPUT_TABLET_AXIS_TILT_X);
+   w->tool.tilt_y = libinput_event_tablet_get_axis_value(t,
+   
LIBINPUT_TABLET_AXIS_TILT_Y);
+   break;
+   case LIBINPUT_EVENT_TABLET_BUTTON:
+   break;
+   default:
+   abort();
+   }
+}
+
 static gboolean
 handle_event_libinput(GIOChannel *source, GIOCondition condition, gpointer 
data)
 {
@@ -609,6 +677,7 @@ handle_event_libinput(GIOChannel *source, GIOCondition 
condition, gpointer data)
case LIBINPUT_EVENT_TABLET_AXIS:
case LIBINPUT_EVENT_TABLET_PROXIMITY:
case LIBINPUT_EVENT_TABLET_BUTTON:
+   handle_event_tablet(ev, w);
break;
}
 
-- 
2.4.3

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

[PATCH libinput 2/6] tablet: use require_event_type instead of direct type check

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/libinput.c | 36 +++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/src/libinput.c b/src/libinput.c
index 65dd0d9..c1f2700 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -925,9 +925,11 @@ libinput_event_tablet_get_axis_value(struct 
libinput_event_tablet *event,
struct evdev_device *device =
(struct evdev_device *) event->base.device;
 
-   if (event->base.type != LIBINPUT_EVENT_TABLET_AXIS &&
-   event->base.type != LIBINPUT_EVENT_TABLET_PROXIMITY)
-   return 0;
+   require_event_type(libinput_event_get_context(>base),
+  event->base.type,
+  0,
+  LIBINPUT_EVENT_TABLET_AXIS,
+  LIBINPUT_EVENT_TABLET_PROXIMITY);
 
switch(axis) {
case LIBINPUT_TABLET_AXIS_X:
@@ -956,9 +958,11 @@ libinput_event_tablet_get_axis_delta(struct 
libinput_event_tablet *event,
struct evdev_device *device =
(struct evdev_device *) event->base.device;
 
-   if (event->base.type != LIBINPUT_EVENT_TABLET_AXIS &&
-   event->base.type != LIBINPUT_EVENT_TABLET_PROXIMITY)
-   return 0;
+   require_event_type(libinput_event_get_context(>base),
+  event->base.type,
+  0,
+  LIBINPUT_EVENT_TABLET_AXIS,
+  LIBINPUT_EVENT_TABLET_PROXIMITY);
 
switch(axis) {
case LIBINPUT_TABLET_AXIS_X:
@@ -985,9 +989,11 @@ libinput_event_tablet_get_axis_delta_discrete(
  struct libinput_event_tablet *event,
  enum libinput_tablet_axis axis)
 {
-   if (event->base.type != LIBINPUT_EVENT_TABLET_AXIS &&
-   event->base.type != LIBINPUT_EVENT_TABLET_PROXIMITY)
-   return 0;
+   require_event_type(libinput_event_get_context(>base),
+  event->base.type,
+  0,
+  LIBINPUT_EVENT_TABLET_AXIS,
+  LIBINPUT_EVENT_TABLET_PROXIMITY);
 
switch(axis) {
case LIBINPUT_TABLET_AXIS_X:
@@ -1012,8 +1018,10 @@ libinput_event_tablet_get_x_transformed(struct 
libinput_event_tablet *event,
struct evdev_device *device =
(struct evdev_device *) event->base.device;
 
-   if (event->base.type != LIBINPUT_EVENT_TABLET_AXIS)
-   return 0;
+   require_event_type(libinput_event_get_context(>base),
+  event->base.type,
+  0,
+  LIBINPUT_EVENT_TABLET_AXIS);
 
return evdev_device_transform_x(device,
event->axes[LIBINPUT_TABLET_AXIS_X],
@@ -1027,8 +1035,10 @@ libinput_event_tablet_get_y_transformed(struct 
libinput_event_tablet *event,
struct evdev_device *device =
(struct evdev_device *) event->base.device;
 
-   if (event->base.type != LIBINPUT_EVENT_TABLET_AXIS)
-   return 0;
+   require_event_type(libinput_event_get_context(>base),
+  event->base.type,
+  0,
+  LIBINPUT_EVENT_TABLET_AXIS);
 
return evdev_device_transform_y(device,
event->axes[LIBINPUT_TABLET_AXIS_Y],
-- 
2.4.3

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

[PATCH libinput 6/6] tablet: rename all tool types to LIBINPUT_TOOL_TYPE_*

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev-tablet.c  | 54 ++---
 src/evdev-tablet.h  | 18 +-
 src/libinput.h  | 27 ++-
 test/tablet.c   |  8 
 tools/event-debug.c | 16 
 5 files changed, 62 insertions(+), 61 deletions(-)

diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 851d49d..04cd082 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -341,8 +341,8 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
/* ROTATION_Z is higher than TILT_X/Y so we know that the
   tilt axes are already normalized and set */
if (a == LIBINPUT_TABLET_AXIS_ROTATION_Z &&
-  (tablet->current_tool_type == LIBINPUT_TOOL_MOUSE ||
-   tablet->current_tool_type == LIBINPUT_TOOL_LENS)) {
+  (tablet->current_tool_type == LIBINPUT_TOOL_TYPE_MOUSE ||
+   tablet->current_tool_type == LIBINPUT_TOOL_TYPE_LENS)) {
convert_tilt_to_rotation(tablet);
axes[LIBINPUT_TABLET_AXIS_TILT_X] = 0;
axes[LIBINPUT_TABLET_AXIS_TILT_Y] = 0;
@@ -459,14 +459,14 @@ tablet_evcode_to_tool(int code)
enum libinput_tool_type type;
 
switch (code) {
-   case BTN_TOOL_PEN:  type = LIBINPUT_TOOL_PEN;   break;
-   case BTN_TOOL_RUBBER:   type = LIBINPUT_TOOL_ERASER;break;
-   case BTN_TOOL_BRUSH:type = LIBINPUT_TOOL_BRUSH; break;
-   case BTN_TOOL_PENCIL:   type = LIBINPUT_TOOL_PENCIL;break;
-   case BTN_TOOL_AIRBRUSH: type = LIBINPUT_TOOL_AIRBRUSH;  break;
-   case BTN_TOOL_FINGER:   type = LIBINPUT_TOOL_FINGER;break;
-   case BTN_TOOL_MOUSE:type = LIBINPUT_TOOL_MOUSE; break;
-   case BTN_TOOL_LENS: type = LIBINPUT_TOOL_LENS;  break;
+   case BTN_TOOL_PEN:  type = LIBINPUT_TOOL_TYPE_PEN;  break;
+   case BTN_TOOL_RUBBER:   type = LIBINPUT_TOOL_TYPE_ERASER;   break;
+   case BTN_TOOL_BRUSH:type = LIBINPUT_TOOL_TYPE_BRUSH;break;
+   case BTN_TOOL_PENCIL:   type = LIBINPUT_TOOL_TYPE_PENCIL;   break;
+   case BTN_TOOL_AIRBRUSH: type = LIBINPUT_TOOL_TYPE_AIRBRUSH; break;
+   case BTN_TOOL_FINGER:   type = LIBINPUT_TOOL_TYPE_FINGER;   break;
+   case BTN_TOOL_MOUSE:type = LIBINPUT_TOOL_TYPE_MOUSE;break;
+   case BTN_TOOL_LENS: type = LIBINPUT_TOOL_TYPE_LENS; break;
default:
abort();
}
@@ -676,11 +676,11 @@ tool_set_bits(const struct tablet_dispatch *tablet,
   anyway.
 */
switch (type) {
-   case LIBINPUT_TOOL_PEN:
-   case LIBINPUT_TOOL_ERASER:
-   case LIBINPUT_TOOL_PENCIL:
-   case LIBINPUT_TOOL_BRUSH:
-   case LIBINPUT_TOOL_AIRBRUSH:
+   case LIBINPUT_TOOL_TYPE_PEN:
+   case LIBINPUT_TOOL_TYPE_ERASER:
+   case LIBINPUT_TOOL_TYPE_PENCIL:
+   case LIBINPUT_TOOL_TYPE_BRUSH:
+   case LIBINPUT_TOOL_TYPE_AIRBRUSH:
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_PRESSURE);
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_DISTANCE);
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_TILT_X);
@@ -688,8 +688,8 @@ tool_set_bits(const struct tablet_dispatch *tablet,
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_SLIDER);
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_ROTATION_Z);
break;
-   case LIBINPUT_TOOL_MOUSE:
-   case LIBINPUT_TOOL_LENS:
+   case LIBINPUT_TOOL_TYPE_MOUSE:
+   case LIBINPUT_TOOL_TYPE_LENS:
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_ROTATION_Z);
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_REL_WHEEL);
break;
@@ -700,17 +700,17 @@ tool_set_bits(const struct tablet_dispatch *tablet,
/* If we don't have libwacom, copy all pen-related ones from the
   tablet vs all mouse-related ones */
switch (type) {
-   case LIBINPUT_TOOL_PEN:
-   case LIBINPUT_TOOL_BRUSH:
-   case LIBINPUT_TOOL_AIRBRUSH:
-   case LIBINPUT_TOOL_PENCIL:
-   case LIBINPUT_TOOL_ERASER:
+   case LIBINPUT_TOOL_TYPE_PEN:
+   case LIBINPUT_TOOL_TYPE_BRUSH:
+   case LIBINPUT_TOOL_TYPE_AIRBRUSH:
+   case LIBINPUT_TOOL_TYPE_PENCIL:
+   case LIBINPUT_TOOL_TYPE_ERASER:
copy_button_cap(tablet, tool, BTN_STYLUS);
copy_button_cap(tablet, tool, BTN_STYLUS2);
copy_button_cap(tablet, tool, BTN_TOUCH);
break;
-   case LIBINPUT_TOOL_MOUSE:
-   case LIBINPUT_TOOL_LENS:
+   case LIBINPUT_TOOL_TYPE_MOUSE:
+   case LIBINPUT_TOOL_TYPE_LENS:
copy_button_cap(tablet, tool, BTN_LEFT);
copy_button_cap(tablet, tool, BTN_MIDDLE);

[PATCH libinput 1/6] tablet: widen the serial type to uint64_t

[Peter Hutterer]

Internally we still use uint32_t because that's all we get from evdev. But
eventually we'll have 64 bit serials.

Signed-off-by: Peter Hutterer 
---
 src/libinput.c  | 2 +-
 src/libinput.h  | 2 +-
 tools/event-debug.c | 3 ++-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/libinput.c b/src/libinput.c
index a51e76a..65dd0d9 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1089,7 +1089,7 @@ libinput_tool_get_tool_id(struct libinput_tool *tool)
return tool->tool_id;
 }
 
-LIBINPUT_EXPORT uint32_t
+LIBINPUT_EXPORT uint64_t
 libinput_tool_get_serial(struct libinput_tool *tool)
 {
return tool->serial;
diff --git a/src/libinput.h b/src/libinput.h
index 45a6437..3b797a4 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -1648,7 +1648,7 @@ libinput_tool_unref(struct libinput_tool *tool);
  * @param tool The libinput tool
  * @return The new tool serial triggering this event
  */
-uint32_t
+uint64_t
 libinput_tool_get_serial(struct libinput_tool *tool);
 
 /**
diff --git a/tools/event-debug.c b/tools/event-debug.c
index 3e315be..29c0e56 100644
--- a/tools/event-debug.c
+++ b/tools/event-debug.c
@@ -23,6 +23,7 @@
 
 #define _GNU_SOURCE
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -489,7 +490,7 @@ print_proximity_event(struct libinput_event *ev)
abort();
}
 
-   printf("\t%s (%#x) %s",
+   printf("\t%s (%#" PRIx64 ") %s",
   tool_str, libinput_tool_get_serial(tool), state_str);
 
printf("\taxes:");
-- 
2.4.3

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

Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 12:21:29PM -0600, Derek Foreman wrote:
> On 04/11/15 07:24 PM, Jonas Ådahl wrote:
> > On Thu, Nov 05, 2015 at 08:44:57AM +1000, Peter Hutterer wrote:
> >> On Wed, Nov 04, 2015 at 09:57:35AM +0800, Jonas Ådahl wrote:
> >>> On Wed, Oct 28, 2015 at 03:34:31PM +1000, Peter Hutterer wrote:
> >> [...]
>  +
>  +  
>  +Indicates the end of a set of events that logically belong 
>  together.
>  +A client is expected to accumulate the data in all events events
>  +within the frame before proceeding.
>  +
>  +All wl_pointer events before a wl_pointer.frame event belong
>  +logically together. For example, in a diagonal scroll motion the
>  +compositor will send an optional wl_pointer.axis_source event, 
>  two
>  +wl_pointer.axis events (horizontal and vertical) and finally a
>  +wl_pointer.frame event. The client may use this information to
>  +calculate a diagonal vector for scrolling.
>  +
>  +When multiple wl_pointer.axis events occur within the same 
>  frame,
>  +the motion vector is the combined motion of all events.
>  +When a wl_pointer.axis and a wl_pointer.axis_stop event occur 
>  within
>  +the same frame, this indicates that axis movement in one axis 
>  has
>  +stopped but continues in the other axis.
>  +When multiple wl_pointer.axis_stop events occur within in the 
>  same
>  +frame, this indicates that these axes stopped in the same 
>  instance.
>  +
>  +A wl_pointer.frame event is sent for every logical event group,
>  +even if the group only contains a single wl_pointer event.
>  +Specifically, a client may get a sequence: motion, frame, 
>  button,
>  +frame, axis, frame, axis_stop, frame.
>  +
>  +The wl_pointer.enter and wl_pointer.leave events are logical 
>  events
>  +generated by the compositor and not the hardware. These events 
>  are
>  +also grouped by a wl_pointer.frame.
> >>>
> >>> I like the idea of wl_pointer.frame in general, but I don't like this
> >>> part, because enter/leave really shouldn't be seen as pointer events at
> >>> all. For example a window closing because of whatever reason will result
> >>> in a wl_pointer.enter on the window that happened to be below. This has
> >>> nothing to do with the pointer device, it is just about the pointer
> >>> focus.
> >>>
> >>> The reason you have made the enter/leave events be dispatched state
> >>> events to the frame event is, as you wrote above, to make it possible
> >>> for extensions to extend the enter/leave events, but they can already do
> >>> so by making those extensions latched events appending state to the
> >>> enter or leave events. If we need to make some extension that adds
> >>> something to receiving or loosing focus, I think they'd be worth their
> >>> own events with their own semantics.
> >>
> >> I understand it's not pretty for the enter/leave semantics, but I'd argue
> >> that it's potentially more confusing to have it to apply to all wl_pointer
> >> events except enter/leave than just apply to all.
> > 
> > I disagree. I see wl_pointer.frame to be the grouping of pointer events.
> > The enter/leave are pointer *focus* events, and have nothing in
> > particular to do with actual events from the pointer, making them
> > different enough to make me feel they have very little in common with
> > the rest of the events, thus are not suitable to be framed by
> > wl_pointer.frame.
> 
> They're quite similar in that they're coming from the same protocol
> object.  What's the benefit in having a separate frame mechanism for
> enter/leave should they need extension later?
> 
> To me the focus events feel more like "seat" events than pointer events,
> but they're still coming from the pointer object...

The benefit is a clearer semantical difference, i.e. that enter/leave
are *not* regular pointer events, they are strictly focus events, and
that wl_pointer.frame frames events from the actual pointer.

> 
> FWIW I agree with Peter on this one.  I think it'll just be more
> complicated (and potentially confusing to compositor/toolkit authors?)
> to have some wl_pointer events framed by one frame event, and others
> possibly by another should we choose to extend them later.
> 
> AIUI, pointer frame was born out of wanting to be more general than axis
> frame.  If we're going to draw the line at "just some wl_pointer events
> are managed by this frame" I think I'd rather see it go back to axis_frame.

I don't think so. I think it can be useful for the relative pointer
interface for example.


Jonas

> 
> >>
> >> This way it's also a catchall event that we don't have to worry about later
> >> down the road. Latching events is possible but again there is the
> 

Re: [PATCH weston 01/10] Use fullscreen-shell.xml from wayland-protocols

[Bill Spitzak]

On Thu, Nov 5, 2015 at 11:46 AM, Bryce Harrington 
wrote:

>
> Hmm.  With l's and 1's looking so similar in certain fonts, "shell1" is
> going to look like a typo to some users.  IMO it would be better to
> distinguish this version number with at least an underscore.
> "_shell_v1_" would feel more consistent with the scheme being used in
> the header file name, protocol file name, macro definitions, etc.
>

I'm not very clear on why the '1' is necessary at all, but it seems to me
like it should be next to the 'z', rather than adding the odd stuff at both
ends. Also I notice the header filename is following a completely different
pattern of using "x-unstable-v1" rather than the "zx1" being used for the
symbols.

Can the plan be changed to make the protocols have names more like the
header file, ie  wl_fullscreen_shell_unstable_v1 in this case? I think that
might be more readable and it would be nice if names matched. Using _
instead of - in the header filenames might be nice, too.

Pardon me for kind of glazing over all that discussion about protocol
versions, but I am not really seeing the reason for unstable protocols to
use different names than the final stable one. If it is unstable then the
meaning of a given symbol may change. This includes changing to the stable
one. Seems like the proposed final name could be used.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 00/10] weston wayland-protocols migration

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 12:21:21PM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:49 +0800
> Jonas Ådahl  wrote:
> 
> > Hi,
> > 
> > This series changes weston to depend on wayland-protocols for the
> > majority of the protocols previously in the protocols/ directory. The
> > protocols moved are also renamed to comply with the unstable naming
> > conventions of wayland-protocols, with the exception of xdg_shell which
> > will use the current name until the next version.
> > 
> > I'd appreciate if maintainers of given protocols could at least Ack the
> > patch changing their protocol implementation, as a semi formal stamp of
> > approval of the name change.
> 
> Hi Jonas,
> 
> I'll give any detailed feedback as replies to the patches, here are some
> overall comments.
> 
> > Other than that, the workspaces protocol is removed, mostly because it
> > wasn't a significant enough proof of concept needed for any particular
> > feature. text-cursor-position.xml however I have left intact, because
> > without it the zoom accessibility feature proof of concept becomes
> > a bit too useless. I'd prefer to prefix it with something like toy_ or
> > weston_, but would like to hear input on this one. Given that it is
> > completely undocumented it is quite far from a real attempt, but it
> > seems like something that will be needed sooner or later for
> > accessibility reasons, so not sure what to do with it right now.
> > 
> > Things that seemed more weston specific was weston_ prefixed. The
> > screenshooter protocol and the desktop shell protocol fell into this
> > category.
> 
> Speaking of prefixes, do we have an idea what protocols should use the
> wl_ prefix and what shouldn't?
> 
> I have had the feeling that wl_ is only Wayland core. But what does
> Wayland core mean? And wl_shell is an exception already.
> 
> Should we restrict wl_ to only for things in wayland.xml? Probably not,
> as I think wl_ in e.g. wl_scaler is justified since it's a "low-level"
> generic feature, and yet wl_scaler will not be added into wayland.xml.
> 
> Perhaps wl_ prefix should be reserved for extensions that are usable
> regardless of a shell or environment. I'm not sure if the input method
> extensions would be eligible for wl_ or not, or what to do with
> fullscreen shell.
> 
> xdg_shell is setting a precedent for using xdg_ prefix for all
> desktoppy but still DE-agnostic extensions, and I think that is fine.

We discussed this last night on IRC and you expressed that you thought
that the wl_ prefix should be limited to only libwayland-client and
libwayland-server and nothing else.

The resulting idea after that discussion was to use the wp_ prefix
instead of wl_ prefix for future protocols with the exception of the
rare cases where new interfaces actually have to be added to
wayland.xml. I don't know of any examples or plans where this is needed
yet.

This means wl_scaler would become wp_scaler, wl_fullscreen would become
wp_fullscreen, wl_presentation wp_presentation, etc.

We also somewhat concluded that generic sounding name (linux_) should
also be prefixed, meaning linux_dmabuf will become wp_linux_dmabuf, but
maybe we should really use some other prefix for non-generic protocols?
I'm not sure.

Regarding the xdg_ prefix, nothing in particular was concluded. I'm not
sure wp_xdg_ is desirable, but maybe its not that bad. We'll have to
bite this bullet the next time xdg_shell changes, or if some other
protocol depending on xdg_shell is introduced. Opinions? Stay with xdg_?
wp_xdg_? wpxdg? wxdg? wp_desktop_shell? Something else?

Anyhow, I will add the concluded parts to the README.

> 
> > Another protocol left to migrate is scalar.xml. I didn't do this yet
> > because Pekka had plans on renaming it, and I'll simply wait until he
> > has a name for it before migrating anything.
> 
> Yeah, inventing a new name for it is hard, but I'll try to come up with
> something. Something that implies both scaling and clipping...
> something used to create viewport objects...
> 
> > Other than that, the wayland-protocols have shaped up some, with the
> > pointer gestures protocol as well as the protocols of this series
> > migrated there. I wouldn't mind if people went and had a look to see if
> > there are any opinions of how things should work before we make an
> > initial release. The procedures and some details are explained in the
> > README file in the toplevel directory.
> 
> The README looks fine to me on the whole, I sent you some trivial typo
> fixes for your consideration.
> 
> This puzzles me a bit:
> 
>   "Each release of wayland-protocols finalizes the version of the
>   protocols to their state they had at that time. Between each
>   release, backward incompatible changes can be made to both
>   stable and major unstable protocol versions as long as the
>   requirements are held upon release."
> 
> It says backward-incompatible changes could be made to also stable
> protocols 

Re: [PATCH weston 01/10] Use fullscreen-shell.xml from wayland-protocols

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 11:46:46AM -0800, Bryce Harrington wrote:
> On Wed, Nov 04, 2015 at 04:49:50PM +0800, Jonas Ådahl wrote:
> > Use the fullscreen-shell protocol XML from the wayland-protocols
> > installation, and remove the one we provide ourself.
> > 
> > Signed-off-by: Jonas Ådahl 
> >
> > diff --git a/clients/fullscreen.c b/clients/fullscreen.c
> > index 4fcca3d..be316d0 100644
> > --- a/clients/fullscreen.c
> > +++ b/clients/fullscreen.c
> > @@ -35,7 +35,7 @@
> >  #include 
> >  #include 
> >  #include "window.h"
> > -#include "fullscreen-shell-client-protocol.h"
> > +#include "fullscreen-shell-unstable-v1-client-protocol.h"
> 
> Angle brackets should be used here and elsewhere, since with this change
> the header file now is located externally from the system rather than
> being locally present in the codebase.
> 
>   #include 

Good point.

>   
> >  struct fs_output {
> > struct wl_list link;
> > @@ -46,8 +46,8 @@ struct fullscreen {
> > struct display *display;
> > struct window *window;
> > struct widget *widget;
> > -   struct _wl_fullscreen_shell *fshell;
> > -   enum _wl_fullscreen_shell_present_method present_method;
> > +   struct zwl_fullscreen_shell1 *fshell;
> > +   enum zwl_fullscreen_shell1_present_method present_method;
> > int width, height;
> > int fullscreen;
> > float pointer_x, pointer_y;
> > @@ -293,10 +293,10 @@ key_handler(struct window *window, struct input 
> > *input, uint32_t time,
> > if (fullscreen->current_output)
> > wl_output = 
> > output_get_wl_output(fullscreen->current_output->output);
> > fullscreen->present_method = (fullscreen->present_method + 1) % 
> > 5;
> > -   _wl_fullscreen_shell_present_surface(fullscreen->fshell,
> > -
> > window_get_wl_surface(fullscreen->window),
> > -fullscreen->present_method,
> > -wl_output);
> > +   zwl_fullscreen_shell1_present_surface(fullscreen->fshell,
> > + 
> > window_get_wl_surface(fullscreen->window),
> > + 
> > fullscreen->present_method,
> > + wl_output);
> > window_schedule_redraw(window);
> > break;
> >  
> > @@ -308,8 +308,8 @@ key_handler(struct window *window, struct input *input, 
> > uint32_t time,
> > wl_output = fsout ? output_get_wl_output(fsout->output) : NULL;
> >  
> > /* Clear the current presentation */
> > -   _wl_fullscreen_shell_present_surface(fullscreen->fshell, NULL,
> > -0, wl_output);
> > +   zwl_fullscreen_shell1_present_surface(fullscreen->fshell, NULL,
> > + 0, wl_output);
> 
> Hmm.  With l's and 1's looking so similar in certain fonts, "shell1" is
> going to look like a typo to some users.  IMO it would be better to
> distinguish this version number with at least an underscore.
> "_shell_v1_" would feel more consistent with the scheme being used in
> the header file name, protocol file name, macro definitions, etc.

A slight implicit point of it is to make it a bit awkward, so that it's
ever so slightly more obvious that this is intended to be temporary.

The other more important reason is I think we already have very long
names, and I tried to minimize the extra name length needed.

I guess I can be convinced otherwise, but personally I prefer the way it
is.

> 
> > diff --git a/configure.ac b/configure.ac
> > index e5afbc0..cfac579 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -181,6 +181,13 @@ fi
> >  PKG_CHECK_MODULES(LIBINPUT_BACKEND, [libinput >= 0.8.0])
> >  PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])
> >  
> > +PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, [wayland-protocols >= 0.1.0],
> 
> Please also update RELEASING with a sentence or two about needing to
> check and update this protocol package version number.

Will do.


Jonas

> 
> Bryce
> ___
> 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

[PATCH weston 08/13] client: Add support for tablet cursor motion to window frames in libtoytoolkit

[Peter Hutterer]

From: Stephen Chandler Paul 

When it comes to a window frame, a tablet tool and cursor act almost
identical; they click things, drag things, etc. The tool type and extra
axes don't serve any use in the context of a window frame, so tablet
pointers share the frame_pointer structures used for the mouse pointer.

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 clients/window.c| 20 
 shared/cairo-util.h |  4 
 shared/frame.c  | 38 ++
 3 files changed, 62 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index 8ef831f..abfc223 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2580,6 +2580,24 @@ frame_touch_up_handler(struct widget *widget,
frame_handle_status(frame, input, time, THEME_LOCATION_CLIENT_AREA);
 }
 
+static int
+frame_tablet_tool_motion_handler(struct widget *widget,
+struct tablet_tool *tool,
+float x, float y,
+void *data)
+{
+   struct window_frame *frame = data;
+   enum theme_location location;
+
+   location = frame_tablet_tool_motion(frame->frame, tool, x, y);
+   if (frame_status(frame->frame) & FRAME_STATUS_REPAINT)
+   widget_schedule_redraw(frame->widget);
+
+   frame_get_pointer_image_for_location(data, location);
+
+   return CURSOR_DEFAULT;
+}
+
 struct widget *
 window_frame_create(struct window *window, void *data)
 {
@@ -2607,6 +2625,8 @@ window_frame_create(struct window *window, void *data)
widget_set_button_handler(frame->widget, frame_button_handler);
widget_set_touch_down_handler(frame->widget, frame_touch_down_handler);
widget_set_touch_up_handler(frame->widget, frame_touch_up_handler);
+   widget_set_tablet_tool_motion_handler(frame->widget,
+ frame_tablet_tool_motion_handler);
 
window->frame = frame;
 
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 019424e..0150927 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -227,6 +227,10 @@ frame_double_touch_down(struct frame *frame, void *data, 
int32_t id,
 void
 frame_double_touch_up(struct frame *frame, void *data, int32_t id);
 
+/* May set FRAME_STATUS_REPAINT */
+enum theme_location
+frame_tablet_tool_motion(struct frame *frame, void *pointer, int x, int y);
+
 void
 frame_repaint(struct frame *frame, cairo_t *cr);
 
diff --git a/shared/frame.c b/shared/frame.c
index 4179b0a..28f53e8 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -920,6 +920,44 @@ frame_double_touch_up(struct frame *frame, void *data, 
int32_t id)
}
 }
 
+enum theme_location
+frame_tablet_tool_motion(struct frame *frame, void *data, int x, int y)
+{
+   struct frame_pointer *tool_pointer = frame_pointer_get(frame, data);
+   struct frame_button *button,
+   *prev_button = tool_pointer->hover_button;
+   enum theme_location location;
+
+   location = theme_get_location(frame->theme, tool_pointer->x,
+ tool_pointer->y, frame->width,
+ frame->height,
+ frame->flags & FRAME_FLAG_MAXIMIZED ?
+ THEME_FRAME_MAXIMIZED : 0);
+
+   if (!tool_pointer)
+   return location;
+
+   tool_pointer->x = x;
+   tool_pointer->y = y;
+
+   button = frame_find_button(frame, x, y);
+
+   if (prev_button) {
+   if (prev_button == button)
+   /* The button hasn't changed so we're done here */
+   return location;
+   else
+   frame_button_leave(prev_button, tool_pointer);
+   }
+
+   if (button)
+   frame_button_enter(button);
+
+   tool_pointer->hover_button = button;
+
+   return location;
+}
+
 void
 frame_repaint(struct frame *frame, cairo_t *cr)
 {
-- 
2.4.3

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

[PATCH weston 03/13] tablet: add weston grab interfaces for tablet tools

[Peter Hutterer]

From: Stephen Chandler Paul 

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 src/compositor.h |  53 
 src/input.c  | 253 +++
 2 files changed, 306 insertions(+)

diff --git a/src/compositor.h b/src/compositor.h
index 7725c27..ce084c8 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -297,6 +297,47 @@ struct weston_touch_grab {
struct weston_touch *touch;
 };
 
+struct weston_tablet;
+struct weston_tablet_tool;
+struct weston_tablet_tool_grab;
+struct weston_tablet_tool_grab_interface {
+   void (*proximity_in)(struct weston_tablet_tool_grab *grab,
+uint32_t time,
+struct weston_tablet *tablet);
+   void (*proximity_out)(struct weston_tablet_tool_grab *grab,
+uint32_t time);
+   void (*motion)(struct weston_tablet_tool_grab *grab,
+  uint32_t time,
+  wl_fixed_t x,
+  wl_fixed_t y);
+   void (*down)(struct weston_tablet_tool_grab *grab,
+uint32_t time);
+   void (*up)(struct weston_tablet_tool_grab *grab,
+  uint32_t time);
+   void (*pressure)(struct weston_tablet_tool_grab *grab,
+uint32_t time,
+uint32_t pressure);
+   void (*distance)(struct weston_tablet_tool_grab *grab,
+uint32_t time,
+uint32_t distance);
+   void (*tilt)(struct weston_tablet_tool_grab *grab,
+uint32_t time,
+int32_t tilt_x,
+int32_t tilt_y);
+   void (*button)(struct weston_tablet_tool_grab *grab,
+  uint32_t time,
+  uint32_t button,
+  enum zwp_tablet_tool1_button_state state);
+   void (*frame)(struct weston_tablet_tool_grab *grab,
+ uint32_t time);
+   void (*cancel)(struct weston_tablet_tool_grab *grab);
+};
+
+struct weston_tablet_tool_grab {
+   const struct weston_tablet_tool_grab_interface *interface;
+   struct weston_tablet_tool *tool;
+};
+
 struct weston_data_offer {
struct wl_resource *resource;
struct weston_data_source *source;
@@ -378,12 +419,19 @@ struct weston_tablet_tool {
struct wl_listener focus_view_listener;
struct wl_listener focus_resource_listener;
uint32_t focus_serial;
+   uint32_t grab_serial;
 
struct wl_list link;
 
uint64_t serial;
uint64_t hwid;
uint32_t capabilities;
+
+   struct weston_tablet_tool_grab *grab;
+   struct weston_tablet_tool_grab default_grab;
+
+   int button_count;
+   bool tip_is_down;
 };
 
 struct weston_tablet {
@@ -476,6 +524,11 @@ void
 weston_tablet_tool_set_focus(struct weston_tablet_tool *tool,
 struct weston_view *view,
 uint32_t time);
+void
+weston_tablet_tool_start_grab(struct weston_tablet_tool *tool,
+ struct weston_tablet_tool_grab *grab);
+void
+weston_tablet_tool_end_grab(struct weston_tablet_tool *tool);
 
 void
 wl_data_device_set_keyboard_focus(struct weston_seat *seat);
diff --git a/src/input.c b/src/input.c
index e9688c5..6139b31 100644
--- a/src/input.c
+++ b/src/input.c
@@ -702,6 +702,9 @@ weston_tablet_tool_set_focus(struct weston_tablet_tool 
*tool,
focus_resource_list = >focus_resource_list;
if (tool->focus && !wl_list_empty(focus_resource_list)) {
wl_resource_for_each(resource, focus_resource_list) {
+   if (tool->tip_is_down)
+   zwp_tablet_tool1_send_up(resource);
+
zwp_tablet_tool1_send_proximity_out(resource);
zwp_tablet_tool1_send_frame(resource, time);
}
@@ -726,6 +729,11 @@ weston_tablet_tool_set_focus(struct weston_tablet_tool 
*tool,
 
zwp_tablet_tool1_send_proximity_in(resource, 
tool->focus_serial,
   tr, 
view->surface->resource);
+
+   if (tool->tip_is_down)
+   zwp_tablet_tool1_send_down(resource,
+  tool->focus_serial);
+
zwp_tablet_tool1_send_frame(resource, time);
}
}
@@ -745,6 +753,186 @@ weston_tablet_tool_set_focus(struct weston_tablet_tool 
*tool,
tool->focus_view_listener.notify = tablet_tool_focus_view_destroyed;
 }
 
+WL_EXPORT void
+weston_tablet_tool_start_grab(struct weston_tablet_tool *tool,
+ struct weston_tablet_tool_grab *grab)
+{
+   tool->grab = 

[PATCH weston 11/13] tablet: Add binding to activate surfaces using the tablet tool

[Peter Hutterer]

From: Stephen Chandler Paul 

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 desktop-shell/shell.c | 14 ++
 src/bindings.c| 39 ++-
 src/compositor.c  |  1 +
 src/compositor.h  | 16 
 src/input.c   |  6 ++
 5 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 5b604a5..d70f48f 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -5406,6 +5406,18 @@ touch_to_activate_binding(struct weston_touch *touch, 
uint32_t time,
 }
 
 static void
+tablet_tool_activate_binding(struct weston_tablet_tool *tool,
+uint32_t button, void *data)
+{
+   if (tool->grab != >default_grab)
+   return;
+   if (tool->focus == NULL)
+   return;
+
+   activate_binding(tool->seat, data, tool->focus);
+}
+
+static void
 unfocus_all_seats(struct desktop_shell *shell)
 {
struct weston_seat *seat, *next;
@@ -6688,6 +6700,8 @@ shell_add_bindings(struct weston_compositor *ec, struct 
desktop_shell *shell)
weston_compositor_add_touch_binding(ec, 0,
touch_to_activate_binding,
shell);
+   weston_compositor_add_tablet_tool_binding(ec, BTN_TOUCH, 0,
+ tablet_tool_activate_binding, 
shell);
weston_compositor_add_axis_binding(ec, WL_POINTER_AXIS_VERTICAL_SCROLL,
   MODIFIER_SUPER | MODIFIER_ALT,
   surface_opacity_binding, NULL);
diff --git a/src/bindings.c b/src/bindings.c
index 234c034..a3c142d 100644
--- a/src/bindings.c
+++ b/src/bindings.c
@@ -135,6 +135,24 @@ weston_compositor_add_touch_binding(struct 
weston_compositor *compositor,
 }
 
 WL_EXPORT struct weston_binding *
+weston_compositor_add_tablet_tool_binding(struct weston_compositor *compositor,
+ uint32_t button, uint32_t modifier,
+ weston_tablet_tool_binding_handler_t 
handler,
+ void *data)
+{
+   struct weston_binding *binding;
+
+   binding = weston_compositor_add_binding(compositor, 0, button, 0,
+   modifier, handler, data);
+   if (binding == NULL)
+   return NULL;
+
+   wl_list_insert(compositor->tablet_tool_binding_list.prev, 
>link);
+
+   return binding;
+}
+
+WL_EXPORT struct weston_binding *
 weston_compositor_add_axis_binding(struct weston_compositor *compositor,
   uint32_t axis, uint32_t modifier,
   weston_axis_binding_handler_t handler,
@@ -387,7 +405,26 @@ weston_compositor_run_touch_binding(struct 
weston_compositor *compositor,
}
 }
 
-int
+WL_EXPORT void
+weston_compositor_run_tablet_tool_binding(struct weston_compositor *compositor,
+ struct weston_tablet_tool *tool,
+ uint32_t button,
+ enum zwp_tablet_tool1_button_state 
state)
+{
+   struct weston_binding *b;
+
+   if (state != ZWP_TABLET_TOOL1_BUTTON_STATE_PRESSED)
+   return;
+
+   wl_list_for_each(b, >tablet_tool_binding_list, link) {
+   if (b->modifier == tool->seat->modifier_state) {
+   weston_tablet_tool_binding_handler_t handler = 
b->handler;
+   handler(tool, button, b->data);
+   }
+   }
+}
+
+WL_EXPORT int
 weston_compositor_run_axis_binding(struct weston_compositor *compositor,
   struct weston_pointer *pointer,
   uint32_t time, uint32_t axis,
diff --git a/src/compositor.c b/src/compositor.c
index 291..652872b 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4522,6 +4522,7 @@ weston_compositor_create(struct wl_display *display, void 
*user_data)
wl_list_init(>modifier_binding_list);
wl_list_init(>button_binding_list);
wl_list_init(>touch_binding_list);
+   wl_list_init(>tablet_tool_binding_list);
wl_list_init(>axis_binding_list);
wl_list_init(>debug_binding_list);
wl_list_init(>tablet_manager_resource_list);
diff --git a/src/compositor.h b/src/compositor.h
index 4da6bc5..8cc3cee 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -821,6 +821,7 @@ struct weston_compositor {
struct wl_list modifier_binding_list;
struct wl_list button_binding_list;
struct wl_list touch_binding_list;
+   struct wl_list tablet_tool_binding_list;
struct wl_list 

[PATCH weston 01/13] tablet: Add initial tablet support to weston

[Peter Hutterer]

From: Stephen Chandler Paul 

Introduces two new structs, weston_tablet and weston_tablet_tool with the
respective information as it's used on the protocol.

Note that tools are independent of tablets, many tools can be used across
multiple tablets.

The nesting on the protocol level requires a global tablet manager, a tablet
seat nested into weston_seat. The list of tablets and tools are also part of
the weston_seat.

Most functions are stubs except for the actual tablet and tablet tool
creation and removal.

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 Makefile.am   |  13 +-
 src/compositor.c  |   1 +
 src/compositor.h  |  99 +
 src/input.c   | 390 ++
 src/libinput-device.c | 205 ++
 src/libinput-device.h |   4 +-
 6 files changed, 708 insertions(+), 4 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e7feebd..4f2110d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -126,7 +126,9 @@ nodist_weston_SOURCES = 
\
protocol/scaler-protocol.c  \
protocol/scaler-server-protocol.h   \
protocol/linux-dmabuf-unstable-v1-protocol.c\
-   protocol/linux-dmabuf-unstable-v1-server-protocol.h
+   protocol/linux-dmabuf-unstable-v1-server-protocol.h \
+   protocol/tablet-unstable-v1-protocol.c  \
+   protocol/tablet-unstable-v1-server-protocol.h
 
 BUILT_SOURCES += $(nodist_weston_SOURCES)
 
@@ -555,7 +557,9 @@ nodist_libtoytoolkit_la_SOURCES =   \
protocol/xdg-shell-unstable-v5-protocol.c   \
protocol/xdg-shell-unstable-v5-client-protocol.h\
protocol/ivi-application-protocol.c \
-   protocol/ivi-application-client-protocol.h
+   protocol/ivi-application-client-protocol.h  \
+   protocol/tablet-unstable-v1-protocol.c  \
+   protocol/tablet-unstable-v1-client-protocol.h
 
 BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES)
 
@@ -764,7 +768,10 @@ BUILT_SOURCES +=   \
protocol/ivi-hmi-controller-protocol.c  \
protocol/ivi-hmi-controller-client-protocol.h   \
protocol/ivi-application-protocol.c \
-   protocol/ivi-application-client-protocol.h
+   protocol/ivi-application-client-protocol.h  \
+   protocol/tablet-unstable-v1-protocol.c  \
+   protocol/tablet-unstable-v1-client-protocol.h
+
 
 westondatadir = $(datadir)/weston
 dist_westondata_DATA = \
diff --git a/src/compositor.c b/src/compositor.c
index 80cd983..8eadf8c 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4518,6 +4518,7 @@ weston_compositor_create(struct wl_display *display, void 
*user_data)
wl_list_init(>touch_binding_list);
wl_list_init(>axis_binding_list);
wl_list_init(>debug_binding_list);
+   wl_list_init(>tablet_manager_resource_list);
 
weston_plane_init(>primary_plane, ec, 0, 0);
weston_compositor_stack_plane(ec, >primary_plane, NULL);
diff --git a/src/compositor.h b/src/compositor.h
index f3e0075..50c7034 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -38,6 +38,7 @@ extern "C" {
 
 #define WL_HIDE_DEPRECATED
 #include 
+#include 
 
 #include "version.h"
 #include "matrix.h"
@@ -366,6 +367,35 @@ struct weston_touch {
uint32_t grab_time;
 };
 
+struct weston_tablet_tool {
+   struct weston_seat *seat;
+   enum zwp_tablet_tool1_type type;
+
+   struct wl_list resource_list;
+
+   struct wl_list link;
+
+   uint64_t serial;
+   uint64_t hwid;
+   uint32_t capabilities;
+};
+
+struct weston_tablet {
+   struct weston_seat *seat;
+   struct evdev_device *device;
+
+   struct wl_list resource_list;
+
+   struct wl_list link;
+
+   char *name;
+   enum zwp_tablet1_type type;
+   uint32_t vid;
+   uint32_t pid;
+   const char *path;
+   struct weston_output *output;
+};
+
 struct weston_pointer *
 weston_pointer_create(struct weston_seat *seat);
 void
@@ -427,6 +457,16 @@ weston_touch_start_grab(struct weston_touch *device,
 void
 weston_touch_end_grab(struct weston_touch *touch);
 
+struct weston_tablet *
+weston_tablet_create(void);
+void
+weston_tablet_destroy(struct weston_tablet *tablet);
+
+struct weston_tablet_tool *
+weston_tablet_tool_create(void);
+void
+weston_tablet_tool_destroy(struct weston_tablet_tool *tool);
+
 void
 wl_data_device_set_keyboard_focus(struct weston_seat *seat);
 
@@ -513,6 +553,8 @@ struct weston_seat {
struct weston_pointer *pointer_state;
struct weston_keyboard *keyboard_state;
struct weston_touch *touch_state;
+   

[PATCH weston 05/13] tablet: handle tablet cursors in the compositor

[Peter Hutterer]

From: Stephen Chandler Paul 

The tablet is given a separate cursor. Most tablet interaction is an absolute
interaction and shouldn't need a cursor at all, but usually the cursor is used
to indicate the type of virtual tool currently assigned.

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 src/compositor.c |   6 +++
 src/compositor.h |  13 +
 src/input.c  | 157 ++-
 3 files changed, 175 insertions(+), 1 deletion(-)

diff --git a/src/compositor.c b/src/compositor.c
index 8eadf8c..291 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1759,6 +1759,7 @@ weston_view_unmap(struct weston_view *view)
struct weston_pointer *pointer = weston_seat_get_pointer(seat);
struct weston_keyboard *keyboard =
weston_seat_get_keyboard(seat);
+   struct weston_tablet_tool *tool;
 
if (keyboard && keyboard->focus == view->surface)
weston_keyboard_set_focus(keyboard, NULL);
@@ -1766,6 +1767,11 @@ weston_view_unmap(struct weston_view *view)
weston_pointer_clear_focus(pointer);
if (touch && touch->focus == view)
weston_touch_set_focus(touch, NULL);
+
+   wl_list_for_each(tool, >tablet_tool_list, link) {
+   if (tool->focus == view)
+   weston_tablet_tool_set_focus(tool, NULL, 0);
+   }
}
 }
 
diff --git a/src/compositor.h b/src/compositor.h
index ce084c8..2eaadf4 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -432,6 +432,12 @@ struct weston_tablet_tool {
 
int button_count;
bool tip_is_down;
+
+   int32_t hotspot_x, hotspot_y;
+   struct weston_view *sprite;
+   struct wl_listener sprite_destroy_listener;
+
+   wl_fixed_t x, y;
 };
 
 struct weston_tablet {
@@ -531,6 +537,13 @@ void
 weston_tablet_tool_end_grab(struct weston_tablet_tool *tool);
 
 void
+weston_tablet_tool_clamp(struct weston_tablet_tool *tool,
+wl_fixed_t *fx, wl_fixed_t *fy);
+void
+weston_tablet_tool_cursor_move(struct weston_tablet_tool *tool,
+  wl_fixed_t x, wl_fixed_t y);
+
+void
 wl_data_device_set_keyboard_focus(struct weston_seat *seat);
 
 int
diff --git a/src/input.c b/src/input.c
index 6139b31..69806e2 100644
--- a/src/input.c
+++ b/src/input.c
@@ -781,7 +781,13 @@ static void
 default_grab_tablet_tool_proximity_out(struct weston_tablet_tool_grab *grab,
   uint32_t time)
 {
-   weston_tablet_tool_set_focus(grab->tool, NULL, time);
+   struct weston_tablet_tool *tool = grab->tool;
+
+   weston_tablet_tool_set_focus(tool, NULL, time);
+
+   /* Hide the cursor */
+   if (weston_surface_is_mapped(tool->sprite->surface))
+   weston_surface_unmap(tool->sprite->surface);
 }
 
 static void
@@ -796,6 +802,8 @@ default_grab_tablet_tool_motion(struct 
weston_tablet_tool_grab *grab,
struct wl_resource *resource;
struct wl_list *resource_list = >focus_resource_list;
 
+   weston_tablet_tool_cursor_move(tool, x, y);
+
current_view = weston_compositor_pick_view(tool->seat->compositor,
   x, y, , );
if (current_view != tool->focus)
@@ -933,6 +941,29 @@ static struct weston_tablet_tool_grab_interface 
default_tablet_tool_grab_interfa
default_grab_tablet_tool_cancel,
 };
 
+static void
+tablet_tool_unmap_sprite(struct weston_tablet_tool *tool)
+{
+   if (weston_surface_is_mapped(tool->sprite->surface))
+   weston_surface_unmap(tool->sprite->surface);
+
+   wl_list_remove(>sprite_destroy_listener.link);
+   tool->sprite->surface->configure = NULL;
+   tool->sprite->surface->configure_private = NULL;
+   weston_view_destroy(tool->sprite);
+   tool->sprite = NULL;
+}
+
+static void
+tablet_tool_handle_sprite_destroy(struct wl_listener *listener, void *data)
+{
+   struct weston_tablet_tool *tool =
+   container_of(listener, struct weston_tablet_tool,
+sprite_destroy_listener);
+
+   tool->sprite = NULL;
+}
+
 WL_EXPORT struct weston_tablet_tool *
 weston_tablet_tool_create(void)
 {
@@ -945,6 +976,9 @@ weston_tablet_tool_create(void)
wl_list_init(>resource_list);
wl_list_init(>focus_resource_list);
 
+   wl_list_init(>sprite_destroy_listener.link);
+   tool->sprite_destroy_listener.notify = 
tablet_tool_handle_sprite_destroy;
+
wl_list_init(>focus_view_listener.link);
tool->focus_view_listener.notify = tablet_tool_focus_view_destroyed;
 
@@ -963,6 +997,9 @@ weston_tablet_tool_destroy(struct weston_tablet_tool *tool)
 {
struct 

[PATCH weston 07/13] client: Add tablet cursor support into libtoytoolkit

[Peter Hutterer]

From: Stephen Chandler Paul 

Again, a lot of this is code that has been reused from the cursor code
for pointers.

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 clients/window.c | 138 ++-
 clients/window.h |  13 --
 2 files changed, 145 insertions(+), 6 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index 25be12f..8ef831f 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -160,6 +160,12 @@ struct tablet_tool {
struct tablet *current_tablet;
struct window *focus;
struct widget *focus_widget;
+   uint32_t enter_serial;
+   uint32_t cursor_serial;
+   int current_cursor;
+   struct wl_surface *cursor_surface;
+   uint32_t cursor_anim_start;
+   struct wl_callback *cursor_frame_cb;
 
enum zwp_tablet_tool1_type type;
uint64_t serial;
@@ -326,6 +332,7 @@ struct widget {
int opaque;
int tooltip_count;
int default_cursor;
+   int default_tablet_cursor;
/* If this is set to false then no cairo surface will be
 * created before redrawing the surface. This is useful if the
 * redraw handler is going to do completely custom rendering
@@ -1654,6 +1661,7 @@ widget_create(struct window *window, struct surface 
*surface, void *data)
widget->tooltip = NULL;
widget->tooltip_count = 0;
widget->default_cursor = CURSOR_LEFT_PTR;
+   widget->default_tablet_cursor = CURSOR_LEFT_PTR;
widget->use_cairo = 1;
 
return widget;
@@ -1712,6 +1720,12 @@ widget_set_default_cursor(struct widget *widget, int 
cursor)
 }
 
 void
+widget_set_default_tablet_cursor(struct widget *widget, int cursor)
+{
+   widget->default_tablet_cursor = cursor;
+}
+
+void
 widget_get_allocation(struct widget *widget, struct rectangle *allocation)
 {
*allocation = widget->allocation;
@@ -5547,6 +5561,117 @@ tablet_tool_handle_removed(void *data, struct 
zwp_tablet_tool1 *zwp_tablet_tool1
zwp_tablet_tool1_destroy(zwp_tablet_tool1);
 }
 
+static const struct wl_callback_listener tablet_tool_cursor_surface_listener;
+
+static void
+tablet_tool_set_cursor_image_index(struct tablet_tool *tool, int index)
+{
+   struct wl_buffer *buffer;
+   struct wl_cursor *cursor;
+   struct wl_cursor_image *image;
+
+   cursor = tool->input->display->cursors[tool->current_cursor];
+   if (index >= (int)cursor->image_count) {
+   fprintf(stderr, "cursor index out of range\n");
+   return;
+   }
+
+   image = cursor->images[index];
+   buffer = wl_cursor_image_get_buffer(image);
+   if (!buffer)
+   return;
+
+   wl_surface_attach(tool->cursor_surface, buffer, 0, 0);
+   wl_surface_damage(tool->cursor_surface, 0, 0,
+ image->width, image->height);
+   wl_surface_commit(tool->cursor_surface);
+   zwp_tablet_tool1_set_cursor(tool->tool, tool->enter_serial,
+   tool->cursor_surface,
+   image->hotspot_x, image->hotspot_y);
+}
+
+static void
+tablet_tool_surface_frame_callback(void *data, struct wl_callback *callback,
+  uint32_t time)
+{
+   struct tablet_tool *tool = data;
+   struct wl_cursor *cursor;
+   int i;
+
+   if (callback) {
+   assert(callback == tool->cursor_frame_cb);
+   wl_callback_destroy(callback);
+   tool->cursor_frame_cb = NULL;
+   }
+
+   if (tool->current_cursor == CURSOR_BLANK) {
+   zwp_tablet_tool1_set_cursor(tool->tool, tool->enter_serial,
+   NULL, 0, 0);
+   return;
+   }
+
+   if (tool->current_cursor == CURSOR_UNSET)
+   return;
+
+   cursor = tool->input->display->cursors[tool->current_cursor];
+   if (!cursor)
+   return;
+
+   /* FIXME We don't have the current time on the first call so we set
+* the animation start to the time of the first frame callback. */
+   if (time == 0)
+   tool->cursor_anim_start = 0;
+   else if (tool->cursor_anim_start == 0)
+   tool->cursor_anim_start = time;
+
+   if (time == 0 || tool->cursor_anim_start == 0)
+   i = 0;
+   else
+   i = wl_cursor_frame(cursor, time - tool->cursor_anim_start);
+
+   if (cursor->image_count > 1) {
+   tool->cursor_frame_cb =
+   wl_surface_frame(tool->cursor_surface);
+   wl_callback_add_listener(tool->cursor_frame_cb,
+_tool_cursor_surface_listener,
+tool);
+   }
+
+   

[PATCH weston 02/13] tablet: add handling of tablet focus

[Peter Hutterer]

From: Stephen Chandler Paul 

Closely modelled after the pointer focus handling

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 src/compositor.h | 10 +++
 src/input.c  | 82 
 2 files changed, 92 insertions(+)

diff --git a/src/compositor.h b/src/compositor.h
index 50c7034..7725c27 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -370,8 +370,14 @@ struct weston_touch {
 struct weston_tablet_tool {
struct weston_seat *seat;
enum zwp_tablet_tool1_type type;
+   struct weston_tablet *current_tablet;
 
struct wl_list resource_list;
+   struct wl_list focus_resource_list;
+   struct weston_view *focus;
+   struct wl_listener focus_view_listener;
+   struct wl_listener focus_resource_listener;
+   uint32_t focus_serial;
 
struct wl_list link;
 
@@ -466,6 +472,10 @@ struct weston_tablet_tool *
 weston_tablet_tool_create(void);
 void
 weston_tablet_tool_destroy(struct weston_tablet_tool *tool);
+void
+weston_tablet_tool_set_focus(struct weston_tablet_tool *tool,
+struct weston_view *view,
+uint32_t time);
 
 void
 wl_data_device_set_keyboard_focus(struct weston_seat *seat);
diff --git a/src/input.c b/src/input.c
index 8814d34..e9688c5 100644
--- a/src/input.c
+++ b/src/input.c
@@ -126,6 +126,26 @@ touch_focus_resource_destroyed(struct wl_listener 
*listener, void *data)
 }
 
 static void
+tablet_tool_focus_view_destroyed(struct wl_listener *listener, void *data)
+{
+   struct weston_tablet_tool *tool =
+   container_of(listener, struct weston_tablet_tool,
+focus_view_listener);
+
+   weston_tablet_tool_set_focus(tool, NULL, 0);
+}
+
+static void
+tablet_tool_focus_resource_destroyed(struct wl_listener *listener, void *data)
+{
+   struct weston_tablet_tool *tool =
+   container_of(listener, struct weston_tablet_tool,
+focus_resource_listener);
+
+   weston_tablet_tool_set_focus(tool, NULL, 0);
+}
+
+static void
 move_resources(struct wl_list *destination, struct wl_list *source)
 {
wl_list_insert_list(destination, source);
@@ -670,6 +690,61 @@ weston_tablet_destroy(struct weston_tablet *tablet)
free(tablet);
 }
 
+WL_EXPORT void
+weston_tablet_tool_set_focus(struct weston_tablet_tool *tool,
+struct weston_view *view,
+uint32_t time)
+{
+   struct wl_list *focus_resource_list;
+   struct wl_resource *resource;
+   struct weston_seat *seat = tool->seat;
+
+   focus_resource_list = >focus_resource_list;
+   if (tool->focus && !wl_list_empty(focus_resource_list)) {
+   wl_resource_for_each(resource, focus_resource_list) {
+   zwp_tablet_tool1_send_proximity_out(resource);
+   zwp_tablet_tool1_send_frame(resource, time);
+   }
+
+   move_resources(>resource_list, focus_resource_list);
+   }
+
+   if (find_resource_for_view(>resource_list, view)) {
+   struct wl_client *surface_client =
+   wl_resource_get_client(view->surface->resource);
+
+   move_resources_for_client(focus_resource_list,
+ >resource_list,
+ surface_client);
+
+   tool->focus_serial = 
wl_display_next_serial(seat->compositor->wl_display);
+   wl_resource_for_each(resource, focus_resource_list) {
+   struct wl_resource *tr;
+
+   tr = 
wl_resource_find_for_client(>current_tablet->resource_list,
+surface_client);
+
+   zwp_tablet_tool1_send_proximity_in(resource, 
tool->focus_serial,
+  tr, 
view->surface->resource);
+   zwp_tablet_tool1_send_frame(resource, time);
+   }
+   }
+
+   wl_list_remove(>focus_view_listener.link);
+   wl_list_init(>focus_view_listener.link);
+   wl_list_remove(>focus_resource_listener.link);
+   wl_list_init(>focus_resource_listener.link);
+
+   if (view)
+   wl_signal_add(>destroy_signal,
+ >focus_view_listener);
+   if (view && view->surface->resource)
+   wl_resource_add_destroy_listener(view->surface->resource,
+
>focus_resource_listener);
+   tool->focus = view;
+   tool->focus_view_listener.notify = tablet_tool_focus_view_destroyed;
+}
+
 WL_EXPORT struct weston_tablet_tool *
 weston_tablet_tool_create(void)
 {
@@ -680,6 +755,13 @@ 

[PATCH weston 10/13] tablet: Add tablet support to the top panel of the desktop shell

[Peter Hutterer]

From: Stephen Chandler Paul 

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 clients/desktop-shell.c | 56 +
 1 file changed, 56 insertions(+)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 6ab76dc..898b060 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -331,6 +331,55 @@ panel_launcher_touch_up_handler(struct widget *widget, 
struct input *input,
 }
 
 static void
+panel_launcher_tablet_tool_proximity_in_handler(struct widget *widget,
+   struct tablet_tool *tool,
+   struct tablet *tablet, void 
*data)
+{
+   struct panel_launcher *launcher;
+
+   launcher = widget_get_user_data(widget);
+   launcher->focused = 1;
+   widget_schedule_redraw(widget);
+}
+
+static void
+panel_launcher_tablet_tool_proximity_out_handler(struct widget *widget,
+struct tablet_tool *tool, void 
*data)
+{
+   struct panel_launcher *launcher;
+
+   launcher = widget_get_user_data(widget);
+   launcher->focused = 0;
+   widget_schedule_redraw(widget);
+}
+
+static void
+panel_launcher_tablet_tool_up_handler(struct widget *widget,
+ struct tablet_tool *tool,
+ void *data)
+{
+   struct panel_launcher *launcher;
+
+   launcher = widget_get_user_data(widget);
+   panel_launcher_activate(launcher);
+}
+
+static void
+panel_launcher_tablet_tool_button_handler(struct widget *widget,
+ struct tablet_tool *tool,
+ uint32_t button,
+ enum zwp_tablet_tool1_button_state 
state,
+ void *data)
+{
+   struct panel_launcher *launcher;
+
+   launcher = widget_get_user_data(widget);
+
+   if (state == ZWP_TABLET_TOOL1_BUTTON_STATE_RELEASED)
+   panel_launcher_activate(launcher);
+}
+
+static void
 clock_func(struct task *task, uint32_t events)
 {
struct panel_clock *clock =
@@ -638,6 +687,13 @@ panel_add_launcher(struct panel *panel, const char *icon, 
const char *path)
  panel_launcher_touch_down_handler);
widget_set_touch_up_handler(launcher->widget,
panel_launcher_touch_up_handler);
+   widget_set_tablet_tool_up_handler(launcher->widget,
+   panel_launcher_tablet_tool_up_handler);
+   widget_set_tablet_tool_proximity_handlers(launcher->widget,
+   panel_launcher_tablet_tool_proximity_in_handler,
+   
panel_launcher_tablet_tool_proximity_out_handler);
+   widget_set_tablet_tool_button_handler(launcher->widget,
+   panel_launcher_tablet_tool_button_handler);
widget_set_redraw_handler(launcher->widget,
  panel_launcher_redraw_handler);
widget_set_motion_handler(launcher->widget,
-- 
2.4.3

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

[PATCH weston 06/13] clients: add support for handling tablets

[Peter Hutterer]

From: Stephen Chandler Paul 

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 clients/window.c | 472 +++
 clients/window.h |  78 +
 2 files changed, 550 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index f9797a2..25be12f 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -70,6 +70,7 @@ typedef void *EGLContext;
 #include "shared/helpers.h"
 #include "xdg-shell-unstable-v5-client-protocol.h"
 #include "text-cursor-position-client-protocol.h"
+#include "tablet-unstable-v1-client-protocol.h"
 #include "shared/os-compatibility.h"
 
 #include "window.h"
@@ -96,6 +97,7 @@ struct display {
struct wl_data_device_manager *data_device_manager;
struct text_cursor_position *text_cursor_position;
struct xdg_shell *xdg_shell;
+   struct zwp_tablet_manager1 *tablet_manager;
struct ivi_application *ivi_application; /* ivi style shell */
EGLDisplay dpy;
EGLConfig argb_config;
@@ -138,6 +140,34 @@ struct display {
int data_device_manager_version;
 };
 
+struct tablet {
+   struct zwp_tablet1 *tablet;
+   char *name;
+   int32_t vid;
+   int32_t pid;
+   enum zwp_tablet1_type type;
+
+   void *user_data;
+
+   struct wl_list link;
+};
+
+struct tablet_tool {
+   struct zwp_tablet_tool1 *tool;
+   struct input *input;
+   void *user_data;
+   struct wl_list link;
+   struct tablet *current_tablet;
+   struct window *focus;
+   struct widget *focus_widget;
+
+   enum zwp_tablet_tool1_type type;
+   uint64_t serial;
+   uint64_t hwid;
+
+   double sx, sy;
+};
+
 struct window_output {
struct output *output;
struct wl_list link;
@@ -282,6 +312,16 @@ struct widget {
widget_touch_frame_handler_t touch_frame_handler;
widget_touch_cancel_handler_t touch_cancel_handler;
widget_axis_handler_t axis_handler;
+   widget_tablet_tool_motion_handler_t tablet_tool_motion_handler;
+   widget_tablet_tool_up_handler_t tablet_tool_up_handler;
+   widget_tablet_tool_down_handler_t tablet_tool_down_handler;
+   widget_tablet_tool_pressure_handler_t tablet_tool_pressure_handler;
+   widget_tablet_tool_distance_handler_t tablet_tool_distance_handler;
+   widget_tablet_tool_tilt_handler_t tablet_tool_tilt_handler;
+   widget_tablet_tool_proximity_in_handler_t tablet_tool_prox_in_handler;
+   widget_tablet_tool_proximity_out_handler_t tablet_tool_prox_out_handler;
+   widget_tablet_tool_button_handler_t tablet_tool_button_handler;
+   widget_tablet_tool_frame_handler_t tablet_tool_frame_handler;
void *user_data;
int opaque;
int tooltip_count;
@@ -357,6 +397,10 @@ struct input {
uint32_t repeat_key;
uint32_t repeat_time;
int seat_version;
+
+   struct zwp_tablet_seat1 *tablet_seat;
+   struct wl_list tablet_list;
+   struct wl_list tablet_tool_list;
 };
 
 struct output {
@@ -1930,6 +1974,72 @@ widget_set_axis_handler(struct widget *widget,
widget->axis_handler = handler;
 }
 
+void
+widget_set_tablet_tool_motion_handler(struct widget *widget,
+ widget_tablet_tool_motion_handler_t 
handler)
+{
+   widget->tablet_tool_motion_handler = handler;
+}
+
+void
+widget_set_tablet_tool_up_handler(struct widget *widget,
+ widget_tablet_tool_up_handler_t handler)
+{
+   widget->tablet_tool_up_handler = handler;
+
+}
+
+void
+widget_set_tablet_tool_down_handler(struct widget *widget,
+   widget_tablet_tool_down_handler_t handler)
+{
+   widget->tablet_tool_down_handler = handler;
+}
+
+void
+widget_set_tablet_tool_pressure_handler(struct widget *widget,
+   widget_tablet_tool_pressure_handler_t 
handler)
+{
+   widget->tablet_tool_pressure_handler = handler;
+}
+
+void
+widget_set_tablet_tool_distance_handler(struct widget *widget,
+   widget_tablet_tool_distance_handler_t 
handler)
+{
+   widget->tablet_tool_distance_handler = handler;
+}
+
+void
+widget_set_tablet_tool_tilt_handler(struct widget *widget,
+   widget_tablet_tool_tilt_handler_t handler)
+{
+   widget->tablet_tool_tilt_handler = handler;
+}
+
+void
+widget_set_tablet_tool_proximity_handlers(struct widget *widget,
+ 
widget_tablet_tool_proximity_in_handler_t in_handler,
+ 
widget_tablet_tool_proximity_out_handler_t out_handler)
+{
+   widget->tablet_tool_prox_in_handler = in_handler;
+   widget->tablet_tool_prox_out_handler = out_handler;
+}
+
+void

[PATCH weston 04/13] tablet: hook up libinput tablet events

[Peter Hutterer]

From: Stephen Chandler Paul 

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 src/libinput-device.c | 112 ++
 1 file changed, 112 insertions(+)

diff --git a/src/libinput-device.c b/src/libinput-device.c
index 262c485..ba89410 100644
--- a/src/libinput-device.c
+++ b/src/libinput-device.c
@@ -371,6 +371,110 @@ handle_tablet_proximity(struct libinput_device 
*libinput_device,
notify_tablet_tool_frame(tool, time);
 }
 
+static void
+handle_tablet_axis(struct libinput_device *libinput_device,
+  struct libinput_event_tablet *axis_event)
+{
+   struct evdev_device *device =
+   libinput_device_get_user_data(libinput_device);
+   struct weston_tablet_tool *tool;
+   struct weston_tablet *tablet = device->tablet;
+   struct libinput_tool *libinput_tool;
+   uint32_t time;
+   const int NORMALIZED_AXIS_MAX = 65535;
+
+   libinput_tool = libinput_event_tablet_get_tool(axis_event);
+   tool = libinput_tool_get_user_data(libinput_tool);
+   time = libinput_event_tablet_get_time(axis_event);
+
+   if (libinput_event_tablet_axis_has_changed(axis_event,
+  LIBINPUT_TABLET_AXIS_X) ||
+   libinput_event_tablet_axis_has_changed(axis_event,
+  LIBINPUT_TABLET_AXIS_Y)) {
+   double x, y;
+   uint32_t width, height;
+
+   width = tablet->output->current_mode->width;
+   height = tablet->output->current_mode->height;
+   x = libinput_event_tablet_get_x_transformed(axis_event, width);
+   y = libinput_event_tablet_get_y_transformed(axis_event, height);
+
+   notify_tablet_tool_motion(tool, time,
+ wl_fixed_from_double(x),
+ wl_fixed_from_double(y));
+   }
+
+   if (libinput_event_tablet_axis_has_changed(axis_event,
+  
LIBINPUT_TABLET_AXIS_PRESSURE)) {
+   double pressure;
+
+   pressure = libinput_event_tablet_get_axis_value(axis_event,
+   LIBINPUT_TABLET_AXIS_PRESSURE);
+   /* convert axis range [0.0, 1.0] to [0, 65535] */
+   pressure *= NORMALIZED_AXIS_MAX;
+   notify_tablet_tool_pressure(tool, time, pressure);
+   }
+
+   if (libinput_event_tablet_axis_has_changed(axis_event,
+  
LIBINPUT_TABLET_AXIS_DISTANCE)) {
+   double distance;
+
+   distance = libinput_event_tablet_get_axis_value(axis_event,
+   LIBINPUT_TABLET_AXIS_PRESSURE);
+   /* convert axis range [0.0, 1.0] to [0, 65535] */
+   distance *= NORMALIZED_AXIS_MAX;
+   notify_tablet_tool_distance(tool, time, distance);
+   }
+
+   if (libinput_event_tablet_axis_has_changed(axis_event,
+  LIBINPUT_TABLET_AXIS_TILT_X) 
||
+   libinput_event_tablet_axis_has_changed(axis_event,
+  
LIBINPUT_TABLET_AXIS_TILT_Y)) {
+   double tx, ty;
+
+   tx = libinput_event_tablet_get_axis_value(axis_event,
+   LIBINPUT_TABLET_AXIS_TILT_X);
+   ty = libinput_event_tablet_get_axis_value(axis_event,
+   LIBINPUT_TABLET_AXIS_TILT_Y);
+   /* convert axis range [-1.0, 1.0] to [-65535, 65535] */
+   tx *= NORMALIZED_AXIS_MAX;
+   ty *= NORMALIZED_AXIS_MAX;
+   notify_tablet_tool_tilt(tool, time, tx, ty);
+   }
+
+   notify_tablet_tool_frame(tool, time);
+}
+
+static void
+handle_tablet_button(struct libinput_device *libinput_device,
+struct libinput_event_tablet *button_event)
+{
+   struct weston_tablet_tool *tool;
+   struct libinput_tool *libinput_tool;
+   uint32_t time, button;
+   enum zwp_tablet_tool1_button_state state;
+
+   libinput_tool = libinput_event_tablet_get_tool(button_event);
+   tool = libinput_tool_get_user_data(libinput_tool);
+   time = libinput_event_tablet_get_time(button_event);
+   button = libinput_event_tablet_get_button(button_event);
+   if (libinput_event_tablet_get_button_state(button_event) ==
+   LIBINPUT_BUTTON_STATE_PRESSED)
+   state = ZWP_TABLET_TOOL1_BUTTON_STATE_PRESSED;
+   else
+   state = ZWP_TABLET_TOOL1_BUTTON_STATE_RELEASED;
+
+   if (button == BTN_TOUCH) {
+   if (state == 

[PATCH weston 00/13] Add tablet support

[Peter Hutterer]

This set adds support for graphics tablets to weston. It's not fully
complete, there are a couple of fixmes in it but the patchset is getting a
bit unwieldly. And there are some discussions on how to do things anyway.

Note: This needs the tablet-support branch from libinput to work. And it is
on top of Jonas's wip/wayland-protocols github branch (ff0452cea150c).

Tablet events are sent serially, terminated by a frame event. A toolkit
should accumulate them and then pass them on as one struct to the client. We
don't do that atm, it may be beyond libtoytoolkit's scope to really
integrate this properly.

The tablet has a separate cursor. That's a conscious decision since the
focus handling on tablets closer to an absolute touch screen than a mouse,
but unlike touch you usually want a cursor shape to indicate the precise
position.

The rest is fairly straightforward, though as said above, some details are
missing. Implementing this also showed that libinput needs a few extra
things added to it.

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

[PATCH weston 09/13] tablet: Add support for moving windows around using the stylus

[Peter Hutterer]

From: Stephen Chandler Paul 

Changing the pointer to the appropriate image while moving the stylus
around isn't supported yet.

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 clients/window.c  |  32 ++
 desktop-shell/shell.c | 267 ++
 src/compositor.h  |   6 ++
 src/input.c   |  11 +++
 4 files changed, 316 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index abfc223..d5454b5 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2598,6 +2598,36 @@ frame_tablet_tool_motion_handler(struct widget *widget,
return CURSOR_DEFAULT;
 }
 
+static void
+frame_tablet_tool_down_handler(struct widget *widget,
+  struct tablet_tool *tool,
+  void *data)
+{
+   struct window_frame *frame = data;
+   enum theme_location location;
+   uint32_t time = 0; /* FIXME: we should be doing this in the frame
+ handler where we have the timestamp  */
+
+   /* Map a stylus touch to the left mouse button */
+   location = frame_pointer_button(frame->frame, tool, BTN_LEFT, 1);
+   frame_handle_status(frame, tool->input, time, location);
+}
+
+static void
+frame_tablet_tool_up_handler(struct widget *widget, struct tablet_tool *tool,
+void *data)
+{
+   struct window_frame *frame = data;
+   enum theme_location location;
+   uint32_t time = 0; /* FIXME: we should be doing this in the frame
+ handler where we have the timestamp  */
+
+   /* Map the stylus leaving contact with the tablet as releasing the left
+* mouse button */
+   location = frame_pointer_button(frame->frame, tool, BTN_LEFT, 0);
+   frame_handle_status(frame, tool->input, time, location);
+}
+
 struct widget *
 window_frame_create(struct window *window, void *data)
 {
@@ -2627,6 +2657,8 @@ window_frame_create(struct window *window, void *data)
widget_set_touch_up_handler(frame->widget, frame_touch_up_handler);
widget_set_tablet_tool_motion_handler(frame->widget,
  frame_tablet_tool_motion_handler);
+   widget_set_tablet_tool_down_handler(frame->widget, 
frame_tablet_tool_down_handler);
+   widget_set_tablet_tool_up_handler(frame->widget, 
frame_tablet_tool_up_handler);
 
window->frame = frame;
 
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 352ab23..5b604a5 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -195,6 +195,13 @@ struct shell_touch_grab {
struct weston_touch *touch;
 };
 
+struct shell_tablet_tool_grab {
+   struct weston_tablet_tool_grab grab;
+   struct shell_surface *shsurf;
+   struct wl_listener shsurf_destroy_listener;
+   struct weston_tablet_tool *tool;
+};
+
 struct weston_move_grab {
struct shell_grab base;
wl_fixed_t dx, dy;
@@ -207,6 +214,11 @@ struct weston_touch_move_grab {
wl_fixed_t dx, dy;
 };
 
+struct weston_tablet_tool_move_grab {
+   struct shell_tablet_tool_grab base;
+   wl_fixed_t dx, dy;
+};
+
 struct rotate_grab {
struct shell_grab base;
struct weston_matrix rotation;
@@ -224,6 +236,7 @@ struct shell_seat {
struct wl_listener caps_changed_listener;
struct wl_listener pointer_focus_listener;
struct wl_listener keyboard_focus_listener;
+   struct wl_listener tablet_tool_added_listener;
 
struct {
struct weston_pointer_grab grab;
@@ -235,6 +248,11 @@ struct shell_seat {
} popup_grab;
 };
 
+struct tablet_tool_listener {
+   struct wl_listener base;
+   struct wl_listener removed_listener;
+};
+
 struct shell_client {
struct wl_resource *resource;
struct wl_client *client;
@@ -595,6 +613,43 @@ shell_touch_grab_end(struct shell_touch_grab *grab)
 }
 
 static void
+shell_tablet_tool_grab_start(struct shell_tablet_tool_grab *grab,
+const struct weston_tablet_tool_grab_interface 
*interface,
+struct shell_surface *shsurf,
+struct weston_tablet_tool *tool)
+{
+   struct desktop_shell *shell = shsurf->shell;
+
+   if (tool->seat->pointer_state)
+   popup_grab_end(tool->seat->pointer_state);
+
+   grab->grab.interface = interface;
+   grab->shsurf = shsurf;
+   grab->shsurf_destroy_listener.notify = destroy_shell_grab_shsurf;
+   wl_signal_add(>destroy_signal, >shsurf_destroy_listener);
+
+   grab->tool = tool;
+   shsurf->grabbed = 1;
+
+   weston_tablet_tool_start_grab(tool, >grab);
+   if (shell->child.desktop_shell)
+   weston_tablet_tool_set_focus(tool,
+ 

[PATCH weston 12/13] tablet: Add demo application for tablets

[Peter Hutterer]

From: Stephen Chandler Paul 

Note that this application does not follow best practices for handling tablet
events. The events are grouped by frame, all processing should be done in the
frame instead of the respective handler.

A good toolkit would accumulate the data in the events and provide them as one
event to the actual client once the frame is received. toytoolkit just hooks
up the handler one-by-one, so we're doing this here as well.

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 .gitignore   |   1 +
 Makefile.am  |   7 +-
 clients/tablet.c | 250 +++
 3 files changed, 257 insertions(+), 1 deletion(-)
 create mode 100644 clients/tablet.c

diff --git a/.gitignore b/.gitignore
index 11d23da..2045fb8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@ weston-simple-damage
 weston-smoke
 weston-stacking
 weston-subsurfaces
+weston-tablet
 weston-transformed
 weston-view
 
diff --git a/Makefile.am b/Makefile.am
index 4f2110d..2f06538 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -469,7 +469,8 @@ demo_clients += \
weston-simple-damage\
weston-simple-touch \
weston-presentation-shm \
-   weston-multi-resource
+   weston-multi-resource   \
+   weston-tablet
 
 weston_simple_shm_SOURCES = clients/simple-shm.c
 nodist_weston_simple_shm_SOURCES = \
@@ -617,6 +618,10 @@ weston_scaler_SOURCES = clients/scaler.c
 weston_scaler_LDADD = libtoytoolkit.la
 weston_scaler_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
 
+weston_tablet_SOURCES = clients/tablet.c
+weston_tablet_LDADD = libtoytoolkit.la
+weston_tablet_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
+
 if HAVE_CAIRO_GLESV2
 demo_clients += weston-nested weston-nested-client
 
diff --git a/clients/tablet.c b/clients/tablet.c
new file mode 100644
index 000..9b79891
--- /dev/null
+++ b/clients/tablet.c
@@ -0,0 +1,250 @@
+/*
+ * Copyright © 2014 Lyude
+ *
+ * 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
+ */
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "window.h"
+#include "tablet-unstable-v1-client-protocol.h"
+
+struct display *display;
+struct window *window;
+struct widget *widget;
+
+cairo_surface_t *draw_buffer;
+
+int old_x, old_y;
+int current_x, current_y;
+enum zwp_tablet_tool1_type tool_type;
+
+bool tablet_is_down;
+
+double current_pressure;
+
+#define WL_TABLET_AXIS_MAX 65535
+
+static void
+redraw_handler(struct widget *widget, void *data)
+{
+   cairo_surface_t *surface;
+   cairo_t *window_cr, *drawing_cr;
+   struct rectangle allocation;
+
+   widget_get_allocation(widget, );
+
+   surface = window_get_surface(window);
+
+   /* Setup the background */
+   window_cr = cairo_create(surface);
+   cairo_set_operator(window_cr, CAIRO_OPERATOR_SOURCE);
+   cairo_rectangle(window_cr,
+   allocation.x,
+   allocation.y,
+   allocation.width,
+   allocation.height);
+   cairo_set_source_rgba(window_cr, 0, 0, 0, 0.8);
+   cairo_fill(window_cr);
+
+   /* Update the drawing buffer */
+   if (tablet_is_down) {
+   if (old_x != -1 && old_y != -1) {
+   drawing_cr = cairo_create(draw_buffer);
+   if (tool_type == ZWP_TABLET_TOOL1_TYPE_PEN) {
+   cairo_set_source_rgb(drawing_cr, 1, 1, 1);
+   cairo_set_line_width(drawing_cr,
+ 

Re: [PATCH weston 01/10] Use fullscreen-shell.xml from wayland-protocols

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 09:00:21PM -0800, Bryce Harrington wrote:
> On Fri, Nov 06, 2015 at 10:51:09AM +0800, Jonas Ådahl wrote:
> > On Thu, Nov 05, 2015 at 11:46:46AM -0800, Bryce Harrington wrote:
> > > On Wed, Nov 04, 2015 at 04:49:50PM +0800, Jonas Ådahl wrote:
> > > > Use the fullscreen-shell protocol XML from the wayland-protocols
> > > > installation, and remove the one we provide ourself.
> > > > 
> > > > Signed-off-by: Jonas Ådahl 
> > > >
> > > > diff --git a/clients/fullscreen.c b/clients/fullscreen.c
> > > > index 4fcca3d..be316d0 100644
> > > > --- a/clients/fullscreen.c
> > > > +++ b/clients/fullscreen.c
> > > > @@ -35,7 +35,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include "window.h"
> > > > -#include "fullscreen-shell-client-protocol.h"
> > > > +#include "fullscreen-shell-unstable-v1-client-protocol.h"
> > > 
> > > Angle brackets should be used here and elsewhere, since with this change
> > > the header file now is located externally from the system rather than
> > > being locally present in the codebase.
> > > 
> > >   #include 
> > 
> > Good point.
> > 
> > >   
> > > >  struct fs_output {
> > > > struct wl_list link;
> > > > @@ -46,8 +46,8 @@ struct fullscreen {
> > > > struct display *display;
> > > > struct window *window;
> > > > struct widget *widget;
> > > > -   struct _wl_fullscreen_shell *fshell;
> > > > -   enum _wl_fullscreen_shell_present_method present_method;
> > > > +   struct zwl_fullscreen_shell1 *fshell;
> > > > +   enum zwl_fullscreen_shell1_present_method present_method;
> > > > int width, height;
> > > > int fullscreen;
> > > > float pointer_x, pointer_y;
> > > > @@ -293,10 +293,10 @@ key_handler(struct window *window, struct input 
> > > > *input, uint32_t time,
> > > > if (fullscreen->current_output)
> > > > wl_output = 
> > > > output_get_wl_output(fullscreen->current_output->output);
> > > > fullscreen->present_method = 
> > > > (fullscreen->present_method + 1) % 5;
> > > > -   _wl_fullscreen_shell_present_surface(fullscreen->fshell,
> > > > -
> > > > window_get_wl_surface(fullscreen->window),
> > > > -
> > > > fullscreen->present_method,
> > > > -wl_output);
> > > > +   
> > > > zwl_fullscreen_shell1_present_surface(fullscreen->fshell,
> > > > + 
> > > > window_get_wl_surface(fullscreen->window),
> > > > + 
> > > > fullscreen->present_method,
> > > > + wl_output);
> > > > window_schedule_redraw(window);
> > > > break;
> > > >  
> > > > @@ -308,8 +308,8 @@ key_handler(struct window *window, struct input 
> > > > *input, uint32_t time,
> > > > wl_output = fsout ? output_get_wl_output(fsout->output) 
> > > > : NULL;
> > > >  
> > > > /* Clear the current presentation */
> > > > -   
> > > > _wl_fullscreen_shell_present_surface(fullscreen->fshell, NULL,
> > > > -0, wl_output);
> > > > +   
> > > > zwl_fullscreen_shell1_present_surface(fullscreen->fshell, NULL,
> > > > + 0, wl_output);
> > > 
> > > Hmm.  With l's and 1's looking so similar in certain fonts, "shell1" is
> > > going to look like a typo to some users.  IMO it would be better to
> > > distinguish this version number with at least an underscore.
> > > "_shell_v1_" would feel more consistent with the scheme being used in
> > > the header file name, protocol file name, macro definitions, etc.
> > 
> > A slight implicit point of it is to make it a bit awkward, so that it's
> > ever so slightly more obvious that this is intended to be temporary.
> > 
> > The other more important reason is I think we already have very long
> > names, and I tried to minimize the extra name length needed.
> 
> Being intentionally awkward seems like an anti-pattern to me.  But I
> would point out that if it is a goal, then making the names overly long
> certainly would achieve that.
> 
> Increasing the length of the names does seem like a valid problem,
> though.  I almost mentioned it but in thinking it out, I figure: a) the
> symbols are intentionally temporary, and making them intentionally
> longer might even encourage making the base names slightly shorter,
> which is in everyone's interest; b) the scheme is already adding 2
> characters, we'd be adding 4 instead, which doesn't seem *that*
> excessive; c) clarity is more important to me than brevity; d) making
> the names more consistent with header, macro names, etc. seems way more
> important than 

Re: [PATCH weston 00/10] weston wayland-protocols migration

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 09:36:18PM -0800, Bryce Harrington wrote:
> On Fri, Nov 06, 2015 at 10:39:12AM +0800, Jonas Ådahl wrote:
> > On Thu, Nov 05, 2015 at 12:21:21PM +0200, Pekka Paalanen wrote:
> > > On Wed,  4 Nov 2015 16:49:49 +0800
> > > Jonas Ådahl  wrote:
> > > > Things that seemed more weston specific was weston_ prefixed. The
> > > > screenshooter protocol and the desktop shell protocol fell into this
> > > > category.
> > > 
> > > Speaking of prefixes, do we have an idea what protocols should use the
> > > wl_ prefix and what shouldn't?
> > > 
> > > I have had the feeling that wl_ is only Wayland core. But what does
> > > Wayland core mean? And wl_shell is an exception already.
> > > 
> > > Should we restrict wl_ to only for things in wayland.xml? Probably not,
> > > as I think wl_ in e.g. wl_scaler is justified since it's a "low-level"
> > > generic feature, and yet wl_scaler will not be added into wayland.xml.
> > > 
> > > Perhaps wl_ prefix should be reserved for extensions that are usable
> > > regardless of a shell or environment. I'm not sure if the input method
> > > extensions would be eligible for wl_ or not, or what to do with
> > > fullscreen shell.
> > > 
> > > xdg_shell is setting a precedent for using xdg_ prefix for all
> > > desktoppy but still DE-agnostic extensions, and I think that is fine.
> > 
> > We discussed this last night on IRC and you expressed that you thought
> > that the wl_ prefix should be limited to only libwayland-client and
> > libwayland-server and nothing else.
> > 
> > The resulting idea after that discussion was to use the wp_ prefix
> > instead of wl_ prefix for future protocols with the exception of the
> > rare cases where new interfaces actually have to be added to
> > wayland.xml. I don't know of any examples or plans where this is needed
> > yet.
> > 
> > This means wl_scaler would become wp_scaler, wl_fullscreen would become
> > wp_fullscreen, wl_presentation wp_presentation, etc.
> 
> I can live with that, although I suspect I'll always read it as Word
> Perfect rather than Wayland Protocol...

Or WordPress...

>  
> > We also somewhat concluded that generic sounding name (linux_) should
> > also be prefixed, meaning linux_dmabuf will become wp_linux_dmabuf, but
> > maybe we should really use some other prefix for non-generic protocols?
> > I'm not sure.
> 
> Agreed on prefixing these.
> 
> > Regarding the xdg_ prefix, nothing in particular was concluded. I'm not
> > sure wp_xdg_ is desirable, but maybe its not that bad. We'll have to
> > bite this bullet the next time xdg_shell changes, or if some other
> > protocol depending on xdg_shell is introduced. Opinions? Stay with xdg_?
> > wp_xdg_? wpxdg? wxdg? wp_desktop_shell? Something else?
> 
> This is probably going to require some debate... which is why I
> suggested leaving it as a special case so as not to derail the rest of
> the effort.  But, I do think it too should be renamed, and I feel fairly
> strongly that in doing so we should just discard "xdg" from the name.

Yea, lets leave any decision to when we need to make it, which is not
before the first release of wayland-protocols.

> Here's my thinking:
> 
> 1.  "xdg" is a prefix used by an actual real open source project which
> isn't us.  We're not using it inappropriately or anything, but still.
> We wouldn't name a protocol kde_foo_thingee to make it more acceptable
> to kde folks.

I *think* one of the reasons why the prefix is xdg_ was that it was
intended to be developed and maintained as part of the xdg project, and
in that case it makes sense to use that prefix. However, that is not
really how it has worked so far, nor how I assume it will work in the
future, making the prefix a bit unfortunate.

> 
> 2.  As a corollary to #1, using it might suggest the protocol is
> something *external* to wayland and not sanctioned by us.  Just as if we
> prefixed it kde_ people would reasonably assume it was a KDE thing, not
> wayland.
> 
> 3.  While there is I guess you could say "marketing" value in including
> "XDG" in the name as a way to promote cross-desktop adoption, if it did
> have any such value in the past, we're beyond that point now.
> 
> 4.  Many people probably won't know what "XDG" stands for anyway.  We
> would do as well to just call it wp_common_desktop_shell and it'd be
> more comprehensible to the average person and no less cross-desktoppy.
> 
> 5.  I don't think it's really that important that we especially label a
> protocol as cross-desktop.  After all, the implication is that all
> Wayland protocols are intended to be widely usable.  I don't think we'd
> push a protocol that is usable by only one desktop environment, so in
> that sense xdg_ is kind of redundant with wl_ (or wp_).
> 
> 6.  As this is a protocol we want to be standardized, that we want to
> actively maintain, and that we want used broadly by Wayland-based
> projects, it seems right to give it a simple, prominent name like
> 

[PATCH wayland-protocols] Add the tablet protocol

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
This is the revamped version of the tablet protocol for graphics tablets
(e.g. Wacom tablets). Too many changes from the last version (a year ago or
so), so I won't detail them, best to look at it with fresh eyes.

 Makefile.am|   1 +
 unstable/tablet/README |   4 +
 unstable/tablet/tablet-unstable-v1.xml | 588 +
 3 files changed, 593 insertions(+)
 create mode 100644 unstable/tablet/README
 create mode 100644 unstable/tablet/tablet-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 4bcab32..588cb2c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6,6 +6,7 @@ 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/tablet/tablet-unstable-v1.xml  
\
$(NULL)
 
 nobase_dist_pkgdata_DATA = $(protocols)
diff --git a/unstable/tablet/README b/unstable/tablet/README
new file mode 100644
index 000..7ba8e77
--- /dev/null
+++ b/unstable/tablet/README
@@ -0,0 +1,4 @@
+Tablet protocol
+
+Maintainers:
+Peter Hutterer 
diff --git a/unstable/tablet/tablet-unstable-v1.xml 
b/unstable/tablet/tablet-unstable-v1.xml
new file mode 100644
index 000..b07eccb
--- /dev/null
+++ b/unstable/tablet/tablet-unstable-v1.xml
@@ -0,0 +1,588 @@
+
+
+  
+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" for each tablet connected.
+That event is followed by descriptive events about the hardware;
+currently that includes events for name, vid/pid and
+internal/external/display type, 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" 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, serial id,
+hardware serial 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 by
+wp_tablet_tool.frame events.
+
+Two special events (that don't exist in X) are down and up. They signal
+"tip touching the surface". For tablets without real proximity
+detection, the sequence is: proximity_in, motion, down, frame.
+
+When the tool leaves proximity, a proximity_out event is sent, followed
+by button release events for any button still down. This signals to
+the client that the buttons were held when the tool left proximity.
+Those events are all sent within the same frame.
+
+If the tool moves out of the surface but stays in proximity (i.e.
+between windows), compositor-specific grab policies apply. This usually
+means that the proximity-out is delayed until all buttons are released.
+
+Moving a tool physically from one tablet to the other has no real effect
+on the protocol, since we already have the tool object from the "tool
+added" event. All the information is already there and the proximity_in
+is all a client needs to reconstruct what happened.
+
+Any extra axis is normalized, i.e. the client knows the range as
+specified in the 

Re: [PATCH weston 03/10] Use presentation timing protocol from wayland-protocols

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 01:57:45PM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:52 +0800
> Jonas Ådahl  wrote:
> 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  Makefile.am  |  21 ++-
> >  clients/presentation-shm.c   |  65 +-
> >  clients/weston-info.c|  19 +--
> >  protocol/presentation_timing.xml | 274 
> > ---
> >  src/compositor-drm.c |  14 +-
> >  src/compositor-fbdev.c   |   2 +-
> >  src/compositor-headless.c|   2 +-
> >  src/compositor-rpi.c |   6 +-
> >  src/compositor-wayland.c |   2 +-
> >  src/compositor-x11.c |   2 +-
> >  src/compositor.c |  29 +++--
> >  tests/presentation-test.c|  34 ++---
> >  12 files changed, 101 insertions(+), 369 deletions(-)
> >  delete mode 100644 protocol/presentation_timing.xml
> 
> > diff --git a/clients/presentation-shm.c b/clients/presentation-shm.c
> > index 120c40c..9083d8e 100644
> > --- a/clients/presentation-shm.c
> > +++ b/clients/presentation-shm.c
> > @@ -38,7 +38,7 @@
> >  #include 
> >  #include "shared/helpers.h"
> >  #include "shared/os-compatibility.h"
> > -#include "presentation_timing-client-protocol.h"
> > +#include "presentation-timing-unstable-v1-client-protocol.h"
> >  
> >  enum run_mode {
> > RUN_MODE_FEEDBACK,
> > @@ -67,7 +67,7 @@ struct display {
> > struct wl_shm *shm;
> > uint32_t formats;
> >  
> > -   struct presentation *presentation;
> > +   struct zwl_presentation1 *presentation;
> 
> Hi Jonas,
> 
> I see you added the prefix wl_ here. I think this is good, it is aiming
> to be a standard, generic extension usable everywhere where Wayland is.
> 
> What I am not so sure about is whether keeping it unstable is still necessary.
> https://phabricator.freedesktop.org/T43
> 
> Maybe we should just promote it stable while we are moving it, and
> avoid one round of renames. I don't know of anything that would need
> fixing or reconsidering in it, apart maybe from names (presentation?).
> 
> Hmm, maybe if someone makes the case that one really *really* does
> not need 64 bits for seconds value, it could use a break. However,
> 64-bit nanoseconds value does not necessarily fit in a 32-bit seconds +
> 32-bit nsecs value when nsec is limited to [0, 9], so I think
> it's good as is. (And the code is already written and been out there
> for a long time.)
> 
> What if we skipped this one with the unstable move?

If that what you think makes sense, and noone objects to it, I see no
reason not to. I haven't followed the details regarding the protocol
itself, so I have no opinion whether it is suitable or not.


Jonas

> 
> 
> Thanks,
> pq


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

Re: [PATCH weston 01/10] Use fullscreen-shell.xml from wayland-protocols

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 01:19:27PM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:50 +0800
> Jonas Ådahl  wrote:
> 
> > Use the fullscreen-shell protocol XML from the wayland-protocols
> > installation, and remove the one we provide ourself.
> > 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  Makefile.am |  44 +---
> >  clients/fullscreen.c|  60 +--
> >  clients/simple-damage.c |  18 ++--
> >  clients/simple-dmabuf.c |  18 ++--
> >  clients/simple-shm.c|  18 ++--
> >  configure.ac|   7 ++
> >  fullscreen-shell/fullscreen-shell.c |  54 +-
> >  protocol/fullscreen-shell.xml   | 206 
> > 
> >  src/compositor-wayland.c|  48 -
> >  src/screen-share.c  |  34 +++---
> >  10 files changed, 159 insertions(+), 348 deletions(-)
> >  delete mode 100644 protocol/fullscreen-shell.xml
> 
> Hi Jonas,
> 
> I'm looking at this just to see how you hooked up the build. Nothing
> too important here. The general idea of the patch is good.
> 
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 55e3bcb..2524591 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -309,8 +309,8 @@ wayland_backend_la_SOURCES =\
> > src/compositor-wayland.c\
> > shared/helpers.h
> >  nodist_wayland_backend_la_SOURCES =\
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h
> >  endif
> >  
> >  if ENABLE_RPI_COMPOSITOR
> > @@ -475,8 +475,8 @@ weston_simple_shm_SOURCES = clients/simple-shm.c
> >  nodist_weston_simple_shm_SOURCES = \
> > protocol/xdg-shell-protocol.c   \
> > protocol/xdg-shell-client-protocol.h\
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h \
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h \
> > protocol/ivi-application-protocol.c \
> > protocol/ivi-application-client-protocol.h
> >  weston_simple_shm_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS)
> > @@ -488,8 +488,8 @@ nodist_weston_simple_damage_SOURCES =   \
> > protocol/scaler-client-protocol.h   \
> > protocol/xdg-shell-protocol.c   \
> > protocol/xdg-shell-client-protocol.h\
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h
> >  weston_simple_damage_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS)
> >  weston_simple_damage_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la
> >  
> > @@ -531,8 +531,8 @@ weston_simple_dmabuf_SOURCES = clients/simple-dmabuf.c
> >  nodist_weston_simple_dmabuf_SOURCES =  \
> > protocol/xdg-shell-protocol.c   \
> > protocol/xdg-shell-client-protocol.h\
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h \
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h \
> > protocol/linux-dmabuf-protocol.c \
> > protocol/linux-dmabuf-client-protocol.h
> >  weston_simple_dmabuf_CFLAGS = $(AM_CFLAGS) $(SIMPLE_DMABUF_CLIENT_CFLAGS)
> > @@ -649,8 +649,8 @@ weston_transformed_CFLAGS = $(AM_CFLAGS) 
> > $(CLIENT_CFLAGS)
> >  
> >  weston_fullscreen_SOURCES = clients/fullscreen.c
> >  nodist_weston_fullscreen_SOURCES = \
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h
> >  weston_fullscreen_LDADD = libtoytoolkit.la
> >  weston_fullscreen_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
> >  
> > @@ -763,8 +763,8 @@ BUILT_SOURCES +=
> > \
> > protocol/scaler-protocol.c  \
> > protocol/workspaces-client-protocol.h   \
> > protocol/workspaces-protocol.c  \
> > -   protocol/fullscreen-shell-protocol.c\
> > -   protocol/fullscreen-shell-client-protocol.h \
> > +   protocol/fullscreen-shell-unstable-v1-protocol.c\
> > +   protocol/fullscreen-shell-unstable-v1-client-protocol.h \
> > protocol/xdg-shell-protocol.c   \
> > protocol/xdg-shell-client-protocol.h\
> > protocol/ivi-hmi-controller-protocol.c  \
> > @@ -865,8 +865,8 @@ 

Re: [PATCH weston 09/10] Rename screenshooter protocol to weston_screenshooter

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 04:35:15PM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:58 +0800
> Jonas Ådahl  wrote:
> 
> > Due to the effort of moving a way from non-prefixed protocols, rename
> > the weston specific screenshooter protocol to weston_screenshooter.
> > 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  Makefile.am   | 14 +++---
> >  clients/screenshot.c  | 21 +
> >  protocol/screenshooter.xml| 12 
> >  protocol/weston-screenshooter.xml | 12 
> >  src/screenshooter.c   | 12 ++--
> >  5 files changed, 38 insertions(+), 33 deletions(-)
> >  delete mode 100644 protocol/screenshooter.xml
> >  create mode 100644 protocol/weston-screenshooter.xml
> 
> > diff --git a/src/screenshooter.c b/src/screenshooter.c
> > index 6e1af65..d0ec00e 100644
> > --- a/src/screenshooter.c
> > +++ b/src/screenshooter.c
> 
> > @@ -622,9 +622,9 @@ screenshooter_create(struct weston_compositor *ec)
> > shooter->client = NULL;
> >  
> > shooter->global = wl_global_create(ec->wl_display,
> > -  _interface, 1,
> > +  _screenshooter_interface, 1,
> >shooter, bind_shooter);
> > -   weston_compositor_add_key_binding(ec, KEY_S, MODIFIER_SUPER,
> > +   weston_compositor_add_key_binding(ec, KEY_S, MODIFIER_CTRL,
> 
> Oops? :-)

Oops indeed (MODIFIER_SUPER tends to never work on a nested weston in
gnome shell). Sorry about that.


Jonas

> 
> Otherwise
> Acked-by: Pekka Paalanen 
> 
> 
> Thanks,
> pq


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

Re: [PATCH weston 08/10] desktop-shell: Rename protocol weston_desktop_shell

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 04:31:37PM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:57 +0800
> Jonas Ådahl  wrote:
> 
> > In the effort of going away from generic names of protocols only
> > relevant for weston, rename the weston desktop shell
> > weston_desktop_shell.
> > 
> > This also resets the version to 1, as there will be no prior versions
> > to weston_desktop_shell.
> > 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  Makefile.am   |  20 +++---
> >  clients/desktop-shell.c   |  79 +++---
> >  desktop-shell/input-panel.c   |   2 +-
> >  desktop-shell/shell.c |  70 ++-
> >  desktop-shell/shell.h |   4 +-
> >  protocol/desktop-shell.xml| 138 
> > --
> >  protocol/weston-desktop-shell.xml | 134 
> > 
> >  7 files changed, 224 insertions(+), 223 deletions(-)
> >  delete mode 100644 protocol/desktop-shell.xml
> >  create mode 100644 protocol/weston-desktop-shell.xml
> 
> This renaming will break Maynard:
> https://github.com/raspberrypi/maynard.git
> 
> This is not a blocker for this patch, just something we should be aware
> of. The fix should be pretty easy if anyone cares.

Yea, and practically it is not an important name change. I do however
think weston should 'set an example' and do the right thing here though.

> 
> > diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
> > index f5342aa..6619e4c 100644
> > --- a/desktop-shell/input-panel.c
> > +++ b/desktop-shell/input-panel.c
> > @@ -30,7 +30,7 @@
> >  #include 
> >  
> >  #include "shell.h"
> > -#include "desktop-shell-server-protocol.h"
> > +#include "weston-desktop-shell-server-protocol.h"
> >  #include "input-method-unstable-v1-server-protocol.h"
> >  #include "shared/helpers.h"
> 
> And no other changes in this file, that's odd. Maybe the header is not
> needed at all?

Indeed. It could be removed.


Jonas

> 
> Acked-by: Pekka Paalanen 
> 
> 
> Thanks,
> pq


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

[PATCH weston 13/13] tablet: Remove tablet-specific tools on disconnect

[Peter Hutterer]

From: Stephen Chandler Paul 

Store all tablets that a tool was used on in a list. When the tablet
is removed, remove all tools only seen on this tablet.

Tools without a serial number are only ever bound to one tablet.

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 src/compositor.h  |  2 ++
 src/input.c   | 26 ++
 src/libinput-device.c | 27 +++
 3 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index 8cc3cee..3f563f4 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -421,6 +421,7 @@ struct weston_tablet_tool {
uint32_t focus_serial;
uint32_t grab_serial;
 
+   struct wl_list tablet_list;
struct wl_list link;
 
uint64_t serial;
@@ -452,6 +453,7 @@ struct weston_tablet {
struct wl_list resource_list;
 
struct wl_list link;
+   struct wl_list tool_link;
 
char *name;
enum zwp_tablet1_type type;
diff --git a/src/input.c b/src/input.c
index b4e6c14..3761239 100644
--- a/src/input.c
+++ b/src/input.c
@@ -682,10 +682,30 @@ WL_EXPORT void
 weston_tablet_destroy(struct weston_tablet *tablet)
 {
struct wl_resource *resource;
+   struct weston_tablet_tool *tool, *tmp;
 
wl_resource_for_each(resource, >resource_list)
zwp_tablet1_send_removed(resource);
 
+   /* Check all tools whether they're linked with this tablet and break
+* that link. If the tool is left with no linked tablets after
+* this, we can destroy it. */
+   wl_list_for_each_safe(tool, tmp, >seat->tablet_tool_list, link) 
{
+   struct weston_tablet *t, *tmpt;
+   bool remove_tool = false;
+
+   wl_list_for_each_safe(t, tmpt, >tablet_list, tool_link) {
+   if (t == tablet) {
+   wl_list_remove(>tool_link);
+   remove_tool = true;
+   break;
+   }
+   }
+
+   if (remove_tool && wl_list_empty(>tablet_list))
+   weston_tablet_tool_destroy(tool);
+   }
+
wl_list_remove(>link);
free(tablet->name);
free(tablet);
@@ -978,6 +998,7 @@ weston_tablet_tool_create(void)
 
wl_list_init(>resource_list);
wl_list_init(>focus_resource_list);
+   wl_list_init(>tablet_list);
 
wl_list_init(>sprite_destroy_listener.link);
tool->sprite_destroy_listener.notify = 
tablet_tool_handle_sprite_destroy;
@@ -1003,6 +1024,11 @@ weston_tablet_tool_destroy(struct weston_tablet_tool 
*tool)
 {
struct wl_resource *resource, *tmp;
 
+   if (!wl_list_empty(>tablet_list)) {
+   weston_log("error: tool still linked to a tablet\n");
+   return;
+   }
+
if (tool->sprite)
tablet_tool_unmap_sprite(tool);
 
diff --git a/src/libinput-device.c b/src/libinput-device.c
index ba89410..d8643c8 100644
--- a/src/libinput-device.c
+++ b/src/libinput-device.c
@@ -334,10 +334,12 @@ handle_tablet_proximity(struct libinput_device 
*libinput_device,
return;
}
 
-   wl_list_for_each(tool, >seat->tablet_tool_list, link) {
-   if (tool->serial == serial && tool->type == type) {
-   create = false;
-   break;
+   if (serial) {
+   wl_list_for_each(tool, >seat->tablet_tool_list, link) {
+   if (tool->serial == serial && tool->type == type) {
+   create = false;
+   break;
+   }
}
}
 
@@ -361,11 +363,28 @@ handle_tablet_proximity(struct libinput_device 
*libinput_device,
tool->capabilities |= 1 << ZWP_TABLET_TOOL1_CAPABILITY_TILT;
 
wl_list_insert(>seat->tablet_tool_list, >link);
+   wl_list_insert(>tablet_list, >tool_link);
+
notify_tablet_tool_added(tool);
 
libinput_tool_set_user_data(libinput_tool, tool);
}
 
+   if (serial && !create) {
+   struct weston_tablet *t;
+   bool add = true;
+
+   wl_list_for_each(t, >tablet_list, tool_link) {
+   if (t == tablet) {
+   add = false;
+   break;
+   }
+   }
+
+   if (add)
+   wl_list_insert(>tablet_list, >tool_link);
+   }
+
notify_tablet_tool_proximity_in(tool, time, tablet);
/* FIXME: we should send axis updates  here */
notify_tablet_tool_frame(tool, time);
-- 
2.4.3

___
wayland-devel mailing list

Re: Input: Hard-keys input support using libinput and weston 1.8.0

[Peter Hutterer]

On Mon, Nov 02, 2015 at 11:51:03AM +0530, Vikas Patil wrote:
> On Mon, Nov 2, 2015 at 7:56 AM, Peter Hutterer  
> wrote:
> >
> > On Fri, Oct 30, 2015 at 11:43:34AM +0530, Vikas Patil wrote:
> > > I have a requirement where Hard-Keys input events (e.g. Home button, Back
> > > button, Volume buttons or Volume Rotary Knobs) needs to be injected into
> > > weston compositor and passed to application or application can listen on
> > > those events using wayland/weston some way.
> >hardkey button
> > probably best to explain the use-case you have in a bit more detail, there
> > may be more than one solution (or zero, come to think of it :)
> >
> 
> I like to provide a wayland/weston APIs to application developer to
> handle hardkey button events (something similar wl_touch, wl_keyboard
> usage, in my case it can be wl_hardkey may be). I have five hard-keys
> on IVI device connected via GPIO (button 1, button 2, power button,
> rotatry knob (connected to two gpio)). These keys usage it not clear
> to me at the moment but any application can use I think. Will give
> more information once I get.
> 
> Is there any other method available without providing standard wayland
> API to application developer to detect hard key evevnt and act on it?

not that I'm aware of. Injection of arbitrary events is not easy, though you
could look up what virtual keyboards do, I forgot how they work in detail
under layout.

But long term we probably need to figure out a wayland protocol to let us do
this. This isn't the only use-case where it's required, braille keyboards
come to mind for example.

> One possible way to implement this is to inject hardkey event as
> keyboard event to "evdev but not sure what all changes are required in
> complete input stack? I think need to start with evdev modification to
> throw the events with require data.
> 
> 
> > > Does weston 1.8.0 and libinput supports such kind of inputs? Or Do I need
> > > to extend the full path of input (evdev -> libinput -> weston) to support
> > > this? How much effort require for this?Thanks
> > >
> > > Could you give some suggestions/ideas to start this as I am very new to
> > > input handling? It would be also helpful if you could refer me some
> > > docs/links to understand this?
> >
> > libinput forwards key events from evdev devices pretty much as-is, weston
> > handles it depending on the keyboard layout. so one solution is to create a
> > uinput device that generates those events and let the rest of the stack do
> > the thing it does anyway. That requires root privs to create the uinput
> > device though.
> >
> 
> Thanks for the suggestion. Will look into uinput. Does this means
> application then would be able to handle the hardkey as mapped key
> (e.g. button 1 mapped tp A) events inside app?

if you're going the uinput route, your device will look like a physical
keyboard and all mappings are done in userspace. e.g. KEY_Q may end up
being mapped to 'a' if a French layout is applied.
you won't have control over this mapping on the uinput level.

Cheers,
   Peter

> 
> > http://wayland.freedesktop.org/libinput/doc/latest/ has a simple
> > architecture diagram.
> > you can't inject events into libinput directly, and afaik there is no
> > waylan protocol extension to allow you to this there either.
> >
> 
> 
> Best Regards,
> Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v2] Remove protocol/wayland.dtd

[Auke Booij]

On 5 November 2015 at 14:58, Pekka Paalanen  wrote:
> On Mon, 19 Oct 2015 11:30:47 +1000
> Peter Hutterer  wrote:
>
>> On Fri, Oct 16, 2015 at 11:42:21AM +0300, Pekka Paalanen wrote:
>> > On Fri, 16 Oct 2015 12:29:11 +1000
>> > Peter Hutterer  wrote:
>> >
>> > > On Fri, Oct 09, 2015 at 01:16:49PM +0200, Nils Chr. Brause wrote:
>> > > > Hi,
>> > > >
>> > > > Reviewed-by: Nils Christopher Brause 
>> > > >
>> > > > I ran distcheck and it worked. :)
>> > >
>> > > a bit late, but I would like to register my disagreement with this patch 
>> > > :)
>> > >
>> > > Having the DTD is a much simpler and less bug-prone description of what 
>> > > the
>> > > protocol should look like. Having the scanner define the protocol means 
>> > > the
>> > > protocol is whatever the current version of the scanner supports, which 
>> > > is
>> > > not a good contract.
>> >
>> > Hi Peter,
>> >
>> > can't argue with that. It's just that the DTD was unused since
>> > 6292fe2af6a45decb7fd39090e74dd87bc4e22b2, Feb 2014.
>> >
>> > > I'd argue for reverting this and fixing any mismatch if there is one. And
>> > > using the DTD to validate before the scanner even runs.
>> >
>> > We talked in IRC about this, and came to the conclusion that maybe we
>> > could have wayland-scanner invoke a validity checker against a DTD or
>> > an XSD.
>>
>> I played around with that. As a quick basic solution we can hook validation
>> with libxml2 into the scanner and print a warning if the xml doesn't
>> validate. That's less than 50 LOC and won't break things since it doesn't
>> touch the actual parsing. and it won't break existing protocols that use
>> "creative" tags, all it will do is warn, not fail. See the diff below (after
>> reverting 06fb8bd37.
>>
>> it's an ugly solution though, but without scanner tests probably the best
>> thing we can do.
>
> Yeah, I agree. I think I'd be ok going forward with this. The patch
> looks like a good start if we can solve the DTD file loading.
>
> Libxml2 dependency should probably be build-time optional so far.
>
>> > If the original objection to a DTD was because it required manually
>> > writing a lint phase in every project build system using the XML files,
>> > then having wayland-scanner invoke the check automatically solves that.
>>
>> the question that remains though is: the dtd must be an external file for
>> extensions to be validated. Which means we need to either pass the dtd as
>> argument to the scanner (requires makefile changes everywhere), or we
>> hardcode the path into wayland-scanner (issues with running the scanner from
>> within the source tree) or we add it as variable to pkgconfig (requires
>> makefile changes again). any other solutions to fix this are welcome.
>> even if all we do is call out to xmllint we still run into that issue.
>
> Or, hopefully we can embed the DTD file into the scanner binary - is
> there no way to let libxml2 read it as a plain string?
>
> I used the following trick to embed some files in Wesgr:
> https://github.com/ppaalanen/wesgr/commit/02a840cb7db7eeb80071a353f66865d729738ae5
>
>
> Thanks,
> pq


If I understand correctly, you want to require the scanner to read the
DTD. Hence, since the scanner defines the protocol, the DTD is now
officially part of the protocol. So you might as well require that
wayland.dtd can be found in the same directory as the protocol XML
file itself.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v2] Remove protocol/wayland.dtd

[Pekka Paalanen]

On Mon, 19 Oct 2015 11:30:47 +1000
Peter Hutterer  wrote:

> On Fri, Oct 16, 2015 at 11:42:21AM +0300, Pekka Paalanen wrote:
> > On Fri, 16 Oct 2015 12:29:11 +1000
> > Peter Hutterer  wrote:
> > 
> > > On Fri, Oct 09, 2015 at 01:16:49PM +0200, Nils Chr. Brause wrote:
> > > > Hi,
> > > > 
> > > > Reviewed-by: Nils Christopher Brause 
> > > > 
> > > > I ran distcheck and it worked. :)
> > > 
> > > a bit late, but I would like to register my disagreement with this patch 
> > > :)
> > > 
> > > Having the DTD is a much simpler and less bug-prone description of what 
> > > the
> > > protocol should look like. Having the scanner define the protocol means 
> > > the
> > > protocol is whatever the current version of the scanner supports, which is
> > > not a good contract.
> > 
> > Hi Peter,
> > 
> > can't argue with that. It's just that the DTD was unused since
> > 6292fe2af6a45decb7fd39090e74dd87bc4e22b2, Feb 2014.
> > 
> > > I'd argue for reverting this and fixing any mismatch if there is one. And
> > > using the DTD to validate before the scanner even runs.
> > 
> > We talked in IRC about this, and came to the conclusion that maybe we
> > could have wayland-scanner invoke a validity checker against a DTD or
> > an XSD.
> 
> I played around with that. As a quick basic solution we can hook validation
> with libxml2 into the scanner and print a warning if the xml doesn't
> validate. That's less than 50 LOC and won't break things since it doesn't
> touch the actual parsing. and it won't break existing protocols that use
> "creative" tags, all it will do is warn, not fail. See the diff below (after
> reverting 06fb8bd37.
> 
> it's an ugly solution though, but without scanner tests probably the best
> thing we can do.

Yeah, I agree. I think I'd be ok going forward with this. The patch
looks like a good start if we can solve the DTD file loading.

Libxml2 dependency should probably be build-time optional so far.

> > If the original objection to a DTD was because it required manually
> > writing a lint phase in every project build system using the XML files,
> > then having wayland-scanner invoke the check automatically solves that.
> 
> the question that remains though is: the dtd must be an external file for
> extensions to be validated. Which means we need to either pass the dtd as
> argument to the scanner (requires makefile changes everywhere), or we
> hardcode the path into wayland-scanner (issues with running the scanner from
> within the source tree) or we add it as variable to pkgconfig (requires
> makefile changes again). any other solutions to fix this are welcome.
> even if all we do is call out to xmllint we still run into that issue.

Or, hopefully we can embed the DTD file into the scanner binary - is
there no way to let libxml2 read it as a plain string?

I used the following trick to embed some files in Wesgr:
https://github.com/ppaalanen/wesgr/commit/02a840cb7db7eeb80071a353f66865d729738ae5


Thanks,
pq


pgprqSc69Citx.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Pekka Paalanen]

On Fri, 16 Oct 2015 12:23:47 -0700
"Jon A. Cruz"  wrote:

> On 10/15/2015 01:51 AM, Pekka Paalanen wrote:
> > I think it's better to land this stuff in pieces than massage a
> > humongous replace-the-world patch series, if we can tell the pieces are
> > going in the right direction. The bits here are mostly just following
> > the existing weston-test-client-helper.c (which the commit message
> > forgot to mention).
> >
> > But yeah, probably makes sense to see how hooking even this stuff up to
> > 'make check' would happen before landing this. That will be one of the
> > most interesting things here. This patch as is does not add anything to
> > 'make check' which is a little awkward for a series adding new test
> > code.
> >
> > As for writing tests in the mean time, people should just ignore the
> > new framework for now, and write tests as if it didn't exist as long as
> > it doesn't support what the old framework does.
> >
> > This way we can incrementally advance on both fronts at the same time.
> 
> So, the immediate question would now be as to how I should stage things.
> Should the changes that will go into 'make check' be a separate patch
> set or should it be an additional patch in this set?
> 
> I'd say that running it as a separate set might make juggling git a
> little easier on me. But not to a degree to outweigh what would make
> reviewing things easier.

Hi Jon,

as I'm not sure how you are going to hook things up to Weston and it
will be interesting to see how you do it, I would like to have it as a
part of this series adding waycheck. In my view, you can't even
demonstrate one without the other: waycheck needs a compositor, and
seeing how 'make check' starts a compositor for a test needs the test
client.

I would very much like to see both pieces at the same time, in case one
requires changes in the other. It would be nice to keep in mind all the
various test styles (client, module, ...) we listed in the past, so
that adding a new case later shouldn't cause a huge refactoring.

By test styles I mean basically the different cases in
tests/weston-tests-env script.


Thanks,
pq

PS. Sorry for disappearing, I cought a flu.


pgpt0I9_HVxMh.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 07/10] Use xdg_shell protocol from wayland-protocols

[Pekka Paalanen]

On Wed,  4 Nov 2015 16:49:56 +0800
Jonas Ådahl  wrote:

> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am|  29 ++-
>  protocol/xdg-shell.xml | 616 
> -
>  2 files changed, 14 insertions(+), 631 deletions(-)
>  delete mode 100644 protocol/xdg-shell.xml
> 

Acked-by: Pekka Paalanen 

The xdg-shell version in wayland-protocols has no interface renamed,
like Daniel S. suggested. We talked about renaming this in irc, and that
will probably wait until there is something to actually break in the
protocol.


Thanks,
pq


pgpR9fsWi1tnH.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel