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

[Carlos Garnacho]

Hey,

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

Re: [PATCH libinput] tablet: add libinput_tablet_tool_is_unique()

[Hans de Goede]

Hi,

On 12/20/2015 11:34 PM, Peter Hutterer wrote:

For checking if a tablet tool can be uniquely identified by libinput. In
practice this means checking for a nonzero serial number, but let's not
restrict ourselves to allowing just that.

Signed-off-by: Peter Hutterer 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
  doc/tablet-support.dox |  4 +++-
  src/libinput.c |  6 ++
  src/libinput.h | 24 ++--
  src/libinput.sym   |  1 +
  test/tablet.c  | 25 +
  5 files changed, 53 insertions(+), 7 deletions(-)

diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
index ac56e47..fbe778d 100644
--- a/doc/tablet-support.dox
+++ b/doc/tablet-support.dox
@@ -126,7 +126,9 @@ and @ref LIBINPUT_TABLET_TOOL_TYPE_LENS tools.
  Some tools provide hardware information that enables libinput to uniquely
  identify the physical device. For example, tools compatible with the Wacom
  Intuos 4, Intuos 5, Intuos Pro and Cintiq series are uniquely identifiable
-through a serial number.
+through a serial number. libinput does not specify how a tool can be
+identified uniquely, a caller should use libinput_tablet_tool_is_unique() to
+check if the tool is unique.

  libinput creates a struct libinput_tablet_tool on the first proximity in of
  this tool. By default, this struct is destroyed on proximity out and
diff --git a/src/libinput.c b/src/libinput.c
index 093f318..082c1b0 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1318,6 +1318,12 @@ libinput_tablet_tool_get_tool_id(struct 
libinput_tablet_tool *tool)
return tool->tool_id;
  }

+LIBINPUT_EXPORT int
+libinput_tablet_tool_is_unique(struct libinput_tablet_tool *tool)
+{
+   return tool->serial != 0;
+}
+
  LIBINPUT_EXPORT uint64_t
  libinput_tablet_tool_get_serial(struct libinput_tablet_tool *tool)
  {
diff --git a/src/libinput.h b/src/libinput.h
index 8726dc5..cc1a083 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -144,7 +144,7 @@ enum libinput_pointer_axis_source {
   * Tablet events generated by such a device are bound to a specific tool
   * rather than coming from the device directly. Depending on the hardware it
   * is possible to track the same physical tool across multiple
- * struct libinput_device devices.
+ * struct libinput_device devices, see @ref tablet-serial-numbers.
   */
  struct libinput_tablet_tool;

@@ -1955,14 +1955,26 @@ libinput_tablet_tool_has_button(struct 
libinput_tablet_tool *tool,
  /**
   * @ingroup event_tablet
   *
- * Return the serial number of a tool
+ * Return nonzero if the physical tool can be uniquely identified by
+ * libinput, or nonzero otherwise. If a tool can be uniquely identified,
+ * keeping a reference to the tool allows tracking the tool across
+ * proximity out sequences and across compatible tablets.
+ * See @ref tablet-serial-numbers for more details.
   *
- * @note Not all tablets report a serial number along with the type of tool
- * being used. If the hardware does not provide a unique serial number, the
- * serial number is always 0.
+ * @param tool A tablet tool
+ * @return 1 if the tool can be uniquely identified, 0 otherwise.
+ */
+int
+libinput_tablet_tool_is_unique(struct libinput_tablet_tool *tool);
+
+/**
+ * @ingroup event_tablet
+ *
+ * Return the serial number of a tool. If the tool does not report a serial
+ * number, this function returns zero.
   *
   * @param tool The libinput tool
- * @return The new tool serial triggering this event
+ * @return The tool serial number
   */
  uint64_t
  libinput_tablet_tool_get_serial(struct libinput_tablet_tool *tool);
diff --git a/src/libinput.sym b/src/libinput.sym
index ddfe81d..22a8dd8 100644
--- a/src/libinput.sym
+++ b/src/libinput.sym
@@ -226,6 +226,7 @@ LIBINPUT_TABLET_SUPPORT {
libinput_tablet_tool_has_wheel;
libinput_tablet_tool_has_slider;
libinput_tablet_tool_has_button;
+   libinput_tablet_tool_is_unique;
libinput_tablet_tool_ref;
libinput_tablet_tool_set_user_data;
libinput_tablet_tool_unref;
diff --git a/test/tablet.c b/test/tablet.c
index 1afbb51..ff979a8 100644
--- a/test/tablet.c
+++ b/test/tablet.c
@@ -1257,6 +1257,30 @@ START_TEST(normalization)
  }
  END_TEST

+START_TEST(tool_unique)
+{
+   struct litest_device *dev = litest_current_device();
+   struct libinput *li = dev->libinput;
+   struct libinput_event_tablet_tool *tablet_event;
+   struct libinput_event *event;
+   struct libinput_tablet_tool *tool;
+
+   litest_drain_events(li);
+
+   litest_event(dev, EV_KEY, BTN_TOOL_PEN, 1);
+   litest_event(dev, EV_MSC, MSC_SERIAL, 1000);
+   litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+   libinput_dispatch(li);
+   event = libinput_get_event(li);
+   tablet_event = litest_is_tablet_event(event,
+   LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY);
+   tool = 

Re: [IDEA] Support several fullscreen behaviors - potentially rename 'fullscreen'

[Jasper St. Pierre]

The first thing I thought about with full-window is how, in fullscreen
mode, Firefox puts up a status bar when you put your mouse to the top
of the window, assuming there's a screen edge there.

You are totally allowed to lie -- and that doesn't really need to be
"proposed" at all -- you just have to write a compositor to let you do
that. But you have to be prepared to deal with the consequences --
applications may rely on assumed behavior or placement.

On Tue, Dec 22, 2015 at 4:43 AM, Coroutines  wrote:
> # Summary
>
> Wayland compositors like weston have the freedom to display
> 'fullscreen'-selected content in 3 ways (that I can think of):
>
> - full-window
> - fullscreen
> - multi-display fullscreen
>
> # The Problem
>
> Something that I've always wanted to have control over is how an
> application is shown in in its fullscreen state.  Typically when I'm
> watching a video on youtube in a web browser I want the player to
> instead fill the existing window dimensions and not the screen.  In
> this example I am looking for full-window behavior.  I can of course
> propose this to Google's devs, but I'd have to do this for every app
> where I want full-window.  I'd much rather have a wayland compositor
> that gives me this ability to 'abuse' the fullscreen state.
>
> # What I propose:
>
> The compositor has the freedom with xdg-shell to "lie" to the client
> about the geometry of the screen in the configure event, when a
> surface sets itself as fullscreen.
>
> In this way, the compositor can show the surface in 3 modes that give
> the user more choice/convenience:
>
> - fullscreen (traditional)
> - full-window (same size, placed at the same x, y)
> - multi-display "fullscreen" (think Far Cry playing across 3 displays)
>
> I also imagined the compositor would have options for dimming the
> areas between fullscreen clients (think theater-mode).  Or immediately
> turn off all other displays ~
>
> # Why abuse fullscreen?
>
> 1) It seems perfectly legal per xdg-shell with no bad side-effects.
>
> 2) I was thinking about something said over and over in #wayland, that
> xdg-shell is not about providing mechanisms/primitive operations like
> X.  It's about providing requests for clients to convey intent.  In my
> opinion, the intent of fullscreen behavior is to enlarge and focus
> content.  To display specific content from a window in a way that the
> user will not be distracted by other apps and activities they're
> doing.
>
> If I want to convey "intent" I'm bringing *select* content to the
> forefront of what the user has open on screen.
>
> In my opinion, the user should be the one choosing how large this
> selected content appears and where - and if other clients are still
> visible.
>
> I avoided calling this 'focused' content, if not 'fullscreen'.  I was
> thinking maybe it could be called a 'forefront' or 'foreground' state
> - or even just 'closer'.  From a protocol perspective, if wayland
> compositors were to support this greater level of control over the
> fullscreen state, I think it should be renamed in the future.
>
> Anyway, I just wanted to write about this and put the idea in the
> heads of people shaping our future desktop experience on Linux.  If
> you work on mutter or kde plasma, or shape xdg-shell's mechanics...
> This is something we can't do on Mac/Windows (across all clients), and
> imo it'd be pretty cool. :>  I personally wish I were prompted by the
> compositor to confirm which fullscreen mode I want a client to conform
> to, but others might want a default of the 3 modes ~
>
> Thanks for reading ~
>
> Disclaimer?: I don't expect anyone to do anything for me.  I think I
> come up with original ideas so I'm simply trying to share it.
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: inserting a "wl_display" object

[Jasper St. Pierre]

Yeah. wl_display is the "bootstrap" phase on which everything else
rests. In the protocol, it's implicit knowledge that there is always
an wl_display object with ID 1. It never gets created or destroyed,
you just start using ID 1.

On Tue, Dec 22, 2015 at 4:55 AM, Pekka Paalanen  wrote:
> On Tue, 22 Dec 2015 14:34:08 +0200
> m...@beroal.in.ua wrote:
>
>> Hello, I'm new to Wayland. I need a "wl_display" object in order to
>> insert "wl_registry" and start working. I see no means of inserting it.
>> (I want to know how to do that in the Wayland protocol, not in the C
>> binding to it.)
>
> Hi,
>
> wl_display is implicitly constructed with ID 1 on both sides when a
> connection is created. It "just exists", there is no protocol to create
> it.
>
>
> Thanks,
> pq
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



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

[PATCH wayland-protocols] test: add make check

[Derek Foreman]

We can now test all the protocol files by running make check (or distcheck)
which will pass them through the scanner.

Signed-off-by: Derek Foreman 
---
Changes from v1:
Use #~/bin/sh -e and drop the && from each line in the script
Discover the scanner's location and use it

 .gitignore| 3 +++
 Makefile.am   | 7 +++
 configure.ac  | 6 ++
 tests/scan.sh | 5 +
 4 files changed, 21 insertions(+)
 create mode 100755 tests/scan.sh

diff --git a/.gitignore b/.gitignore
index e6f85d0..ca19ecf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,6 @@ missing
 *.pc
 autom4te.cache
 aclocal.m4
+*.trs
+*.log
+test-driver
diff --git a/Makefile.am b/Makefile.am
index 5926a41..dc44c28 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -16,3 +16,10 @@ dist_noinst_DATA =   
\
$(NULL)
 
 noarch_pkgconfig_DATA = wayland-protocols.pc
+
+EXTRA_DIST = tests/scan.sh
+
+TESTS = $(unstable_protocols)
+TEST_EXTENSIONS = .xml
+AM_TESTS_ENVIRONMENT = SCANNER='$(wayland_scanner)'; export SCANNER;
+XML_LOG_COMPILER = $(srcdir)/tests/scan.sh
diff --git a/configure.ac b/configure.ac
index c51b7fc..dc5d899 100644
--- a/configure.ac
+++ b/configure.ac
@@ -15,6 +15,12 @@ AC_CONFIG_MACRO_DIR([m4])
 
 AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])
 
+AC_PATH_PROG([wayland_scanner], [wayland-scanner])
+if test x$wayland_scanner = x; then
+PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
+wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner 
wayland-scanner`
+fi
+
 AM_INIT_AUTOMAKE([1.11 foreign no-dist-gzip dist-xz])
 
 AM_SILENT_RULES([yes])
diff --git a/tests/scan.sh b/tests/scan.sh
new file mode 100755
index 000..fd92bec
--- /dev/null
+++ b/tests/scan.sh
@@ -0,0 +1,5 @@
+#!/bin/sh -e
+
+$SCANNER client-header $1 /dev/null
+$SCANNER server-header $1 /dev/null
+$SCANNER code $1 /dev/null
-- 
2.6.4

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

Re: [PATCH libinput 1/9] tablet: dump deltas_discrete, replace with a single wheel_discrete variable

[Hans de Goede]

Hi,

On 12/21/2015 06:56 AM, Peter Hutterer wrote:

Only the wheel has a discrete value, no need to keep arrays for a single
value.

Signed-off-by: Peter Hutterer 


Entire series looks good to me and is:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
  src/evdev-tablet.c |  6 +++---
  src/libinput-private.h |  2 +-
  src/libinput.c | 10 --
  3 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index ffb141c..83cf433 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -337,7 +337,7 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
int a;
double axes[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1] = {0};
double deltas[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1] = {0};
-   double deltas_discrete[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1] = {0};
+   int wheel_discrete = 0;
double oldval;
struct device_coords point, old_point;
const struct input_absinfo *absinfo;
@@ -400,7 +400,7 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
deltas[a] = get_delta(a, tablet->axes[a], oldval);
continue;
} else if (a == LIBINPUT_TABLET_TOOL_AXIS_REL_WHEEL) {
-   deltas_discrete[a] = tablet->deltas[a];
+   wheel_discrete = tablet->deltas[a];
deltas[a] = normalize_wheel(tablet,
tablet->deltas[a]);
axes[a] = 0;
@@ -468,7 +468,7 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
   tablet->changed_axes,
   axes,
   deltas,
-  deltas_discrete);
+  wheel_discrete);
}
}

diff --git a/src/libinput-private.h b/src/libinput-private.h
index 1c8d97c..b404b0a 100644
--- a/src/libinput-private.h
+++ b/src/libinput-private.h
@@ -482,7 +482,7 @@ tablet_notify_axis(struct libinput_device *device,
   unsigned char *changed_axes,
   double *axes,
   double *deltas,
-  double *deltas_discrete);
+  int wheel_discrete);

  void
  tablet_notify_proximity(struct libinput_device *device,
diff --git a/src/libinput.c b/src/libinput.c
index b1bced0..e5b2180 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -133,7 +133,7 @@ struct libinput_event_tablet_tool {
uint64_t time;
double axes[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1];
double deltas[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1];
-   double deltas_discrete[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1];
+   int wheel_discrete;
unsigned char changed_axes[NCHARS(LIBINPUT_TABLET_TOOL_AXIS_MAX + 1)];
struct libinput_tablet_tool *tool;
enum libinput_tablet_tool_proximity_state proximity_state;
@@ -1161,7 +1161,7 @@ libinput_event_tablet_tool_get_wheel_delta_discrete(
   LIBINPUT_EVENT_TABLET_TOOL_TIP,
   LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY);

-   return event->deltas_discrete[LIBINPUT_TABLET_TOOL_AXIS_REL_WHEEL];
+   return event->wheel_discrete;
  }

  LIBINPUT_EXPORT double
@@ -2153,7 +2153,7 @@ tablet_notify_axis(struct libinput_device *device,
   unsigned char *changed_axes,
   double *axes,
   double *deltas,
-  double *deltas_discrete)
+  int wheel_discrete)
  {
struct libinput_event_tablet_tool *axis_event;

@@ -2166,6 +2166,7 @@ tablet_notify_axis(struct libinput_device *device,
.tool = tool,
.proximity_state = LIBINPUT_TABLET_TOOL_PROXIMITY_IN,
.tip_state = tip_state,
+   .wheel_discrete = wheel_discrete,
};

memcpy(axis_event->changed_axes,
@@ -2173,9 +2174,6 @@ tablet_notify_axis(struct libinput_device *device,
   sizeof(axis_event->changed_axes));
memcpy(axis_event->axes, axes, sizeof(axis_event->axes));
memcpy(axis_event->deltas, deltas, sizeof(axis_event->deltas));
-   memcpy(axis_event->deltas_discrete,
-  deltas_discrete,
-  sizeof(axis_event->deltas_discrete));

post_device_event(device,
  time,


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

Re: [PATCH wayland-protocols] test: add make check

[Quentin Glidic]

On 22/12/2015 19:19, Derek Foreman wrote:

We can now test all the protocol files by running make check (or distcheck)
which will pass them through the scanner.

Signed-off-by: Derek Foreman 
---
Changes from v1:
Use #~/bin/sh -e and drop the && from each line in the script
Discover the scanner's location and use it

  .gitignore| 3 +++
  Makefile.am   | 7 +++
  configure.ac  | 6 ++
  tests/scan.sh | 5 +
  4 files changed, 21 insertions(+)
  create mode 100755 tests/scan.sh

diff --git a/.gitignore b/.gitignore
index e6f85d0..ca19ecf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,6 @@ missing
  *.pc
  autom4te.cache
  aclocal.m4
+*.trs
+*.log
+test-driver
diff --git a/Makefile.am b/Makefile.am
index 5926a41..dc44c28 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -16,3 +16,10 @@ dist_noinst_DATA =   
\
$(NULL)

  noarch_pkgconfig_DATA = wayland-protocols.pc
+
+EXTRA_DIST = tests/scan.sh


dist_check_SCRIPTS maybe? :-)



+
+TESTS = $(unstable_protocols)


Why not all the variables already?



+TEST_EXTENSIONS = .xml
+AM_TESTS_ENVIRONMENT = SCANNER='$(wayland_scanner)'; export SCANNER;
+XML_LOG_COMPILER = $(srcdir)/tests/scan.sh
diff --git a/configure.ac b/configure.ac
index c51b7fc..dc5d899 100644
--- a/configure.ac
+++ b/configure.ac
@@ -15,6 +15,12 @@ AC_CONFIG_MACRO_DIR([m4])

  AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])

+AC_PATH_PROG([wayland_scanner], [wayland-scanner])


It makes me wonder… Do we expect wayland-scanner to generate 
arch-independent code? If so, it’s ok. If not, it should be AC_PATH_TOOL.




+if test x$wayland_scanner = x; then
+PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
+wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner 
wayland-scanner`


Ok, this is a good idea (and maybe am I the one originally writing it 
like that, or reviewing something similar) but it can lead to strange 
situations while cross-compiling.


If you cross-compile from x86 to arm64, with no scanner installed for 
x86, it will try to run the arm64 scanner, which is not possible.


I see the need for it in the “$HOME testing environment” but then we 
should at least check that $host == $build.




+fi
+
  AM_INIT_AUTOMAKE([1.11 foreign no-dist-gzip dist-xz])

  AM_SILENT_RULES([yes])
diff --git a/tests/scan.sh b/tests/scan.sh
new file mode 100755
index 000..fd92bec
--- /dev/null
+++ b/tests/scan.sh
@@ -0,0 +1,5 @@
+#!/bin/sh -e
+
+$SCANNER client-header $1 /dev/null
+$SCANNER server-header $1 /dev/null
+$SCANNER code $1 /dev/null




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] tablet: invert tilt axes when left-handed is enabled

[Hans de Goede]

Hi,

On 12/21/2015 02:46 AM, Peter Hutterer wrote:

Signed-off-by: Peter Hutterer 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
  src/evdev-tablet.c |  4 
  test/tablet.c  | 38 ++
  2 files changed, 42 insertions(+)

diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index bf61411..50891e3 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -365,6 +365,8 @@ tablet_handle_tilt(struct tablet_dispatch *tablet,
if (bit_is_set(tablet->changed_axes, a)) {
absinfo = libevdev_get_abs_info(device->evdev, ABS_TILT_X);
tablet->axes[a] = normalize_tilt(absinfo);
+   if (device->left_handed.enabled)
+   tablet->axes[a] *= -1;
}
tilt.x = tablet->axes[a];

@@ -372,6 +374,8 @@ tablet_handle_tilt(struct tablet_dispatch *tablet,
if (bit_is_set(tablet->changed_axes, a)) {
absinfo = libevdev_get_abs_info(device->evdev, ABS_TILT_Y);
tablet->axes[a] = normalize_tilt(absinfo);
+   if (device->left_handed.enabled)
+   tablet->axes[a] *= -1;
}
tilt.y = tablet->axes[a];

diff --git a/test/tablet.c b/test/tablet.c
index a55b60a..87af814 100644
--- a/test/tablet.c
+++ b/test/tablet.c
@@ -1018,6 +1018,43 @@ START_TEST(no_left_handed)
  }
  END_TEST

+START_TEST(left_handed_tilt)
+{
+#if HAVE_LIBWACOM
+   struct litest_device *dev = litest_current_device();
+   struct libinput *li = dev->libinput;
+   struct libinput_event *event;
+   struct libinput_event_tablet_tool *tev;
+   enum libinput_config_status status;
+   struct axis_replacement axes[] = {
+   { ABS_DISTANCE, 10 },
+   { ABS_TILT_X, 90 },
+   { ABS_TILT_Y, 10 },
+   { -1, -1 }
+   };
+   double tx, ty;
+
+   status = libinput_device_config_left_handed_set(dev->libinput_device, 
1);
+   ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+
+   litest_drain_events(li);
+
+   litest_tablet_proximity_in(dev, 10, 10, axes);
+   libinput_dispatch(li);
+   event = libinput_get_event(li);
+   tev = litest_is_tablet_event(event,
+LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY);
+   tx = libinput_event_tablet_tool_get_tilt_x(tev);
+   ty = libinput_event_tablet_tool_get_tilt_y(tev);
+
+   ck_assert_double_lt(tx, 0);
+   ck_assert_double_gt(ty, 0);
+
+   libinput_event_destroy(event);
+#endif
+}
+END_TEST
+
  START_TEST(motion_event_state)
  {
struct litest_device *dev = litest_current_device();
@@ -2852,6 +2889,7 @@ litest_setup_tests(void)
litest_add("tablet:tilt", tilt_x, LITEST_TABLET|LITEST_TILT, 
LITEST_ANY);
litest_add("tablet:tilt", tilt_y, LITEST_TABLET|LITEST_TILT, 
LITEST_ANY);
litest_add_for_device("tablet:left_handed", left_handed, 
LITEST_WACOM_INTUOS);
+   litest_add_for_device("tablet:left_handed", left_handed_tilt, 
LITEST_WACOM_INTUOS);
litest_add_for_device("tablet:left_handed", no_left_handed, 
LITEST_WACOM_CINTIQ);
litest_add("tablet:normalization", normalization, LITEST_TABLET, 
LITEST_ANY);
litest_add("tablet:pad", pad_buttons_ignored, LITEST_TABLET, 
LITEST_ANY);


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

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

[Jonas Ådahl]

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

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

[Jonas Ådahl]

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

Re: [PATCH wayland-protocols] test: add make check

[Derek Foreman]

On 22/12/15 01:15 PM, Quentin Glidic wrote:
> On 22/12/2015 19:19, Derek Foreman wrote:
>> We can now test all the protocol files by running make check (or
>> distcheck)
>> which will pass them through the scanner.
>>
>> Signed-off-by: Derek Foreman 
>> ---
>> Changes from v1:
>> Use #~/bin/sh -e and drop the && from each line in the script
>> Discover the scanner's location and use it
>>
>>   .gitignore| 3 +++
>>   Makefile.am   | 7 +++
>>   configure.ac  | 6 ++
>>   tests/scan.sh | 5 +
>>   4 files changed, 21 insertions(+)
>>   create mode 100755 tests/scan.sh
>>
>> diff --git a/.gitignore b/.gitignore
>> index e6f85d0..ca19ecf 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -9,3 +9,6 @@ missing
>>   *.pc
>>   autom4te.cache
>>   aclocal.m4
>> +*.trs
>> +*.log
>> +test-driver
>> diff --git a/Makefile.am b/Makefile.am
>> index 5926a41..dc44c28 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -16,3 +16,10 @@ dist_noinst_DATA =\
>>   $(NULL)
>>
>>   noarch_pkgconfig_DATA = wayland-protocols.pc
>> +
>> +EXTRA_DIST = tests/scan.sh
> 
> dist_check_SCRIPTS maybe? :-)

Sure! :)

> 
>> +
>> +TESTS = $(unstable_protocols)
> 
> Why not all the variables already?

Sorry to be dense - what other variables should I be using?

>> +TEST_EXTENSIONS = .xml
>> +AM_TESTS_ENVIRONMENT = SCANNER='$(wayland_scanner)'; export SCANNER;
>> +XML_LOG_COMPILER = $(srcdir)/tests/scan.sh
>> diff --git a/configure.ac b/configure.ac
>> index c51b7fc..dc5d899 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -15,6 +15,12 @@ AC_CONFIG_MACRO_DIR([m4])
>>
>>   AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])
>>
>> +AC_PATH_PROG([wayland_scanner], [wayland-scanner])
> 
> It makes me wonder… Do we expect wayland-scanner to generate
> arch-independent code? If so, it’s ok. If not, it should be AC_PATH_TOOL.

Hmm, I think it's supposed to generate the same thing no matter what
architecture it's run on...

> 
>> +if test x$wayland_scanner = x; then
>> +PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
>> +wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner
>> wayland-scanner`
> 
> Ok, this is a good idea (and maybe am I the one originally writing it
> like that, or reviewing something similar) but it can lead to strange
> situations while cross-compiling.

Stolen from weston, it's half yours and half Emil Velikov with your
review. :)

> If you cross-compile from x86 to arm64, with no scanner installed for
> x86, it will try to run the arm64 scanner, which is not possible.
> 
> I see the need for it in the “$HOME testing environment” but then we
> should at least check that $host == $build.

So is this a problem that needs to be fixed in weston too?

> 
>> +fi
>> +
>>   AM_INIT_AUTOMAKE([1.11 foreign no-dist-gzip dist-xz])
>>
>>   AM_SILENT_RULES([yes])
>> diff --git a/tests/scan.sh b/tests/scan.sh
>> new file mode 100755
>> index 000..fd92bec
>> --- /dev/null
>> +++ b/tests/scan.sh
>> @@ -0,0 +1,5 @@
>> +#!/bin/sh -e
>> +
>> +$SCANNER client-header $1 /dev/null
>> +$SCANNER server-header $1 /dev/null
>> +$SCANNER code $1 /dev/null
>>
> 
> 

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

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

[Carlos Garnacho]

Hey,

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

Re: [PATCH 2/2] compositor: Document routines relating to idle behavior

[Bryce Harrington]

On Tue, Dec 22, 2015 at 04:24:18PM +0200, Pekka Paalanen wrote:
> Hi Bryce
> 
> On Fri, 11 Dec 2015 13:11:38 -0800
> Bryce Harrington  wrote:
> 
> > Signed-off-by: Bryce Harrington 
> > ---
> >  src/compositor.c | 46 ++
> >  1 file changed, 46 insertions(+)
> > 
> > diff --git a/src/compositor.c b/src/compositor.c
> > index 254e9e4..3e1f588 100644
> > --- a/src/compositor.c
> > +++ b/src/compositor.c
> > @@ -3817,6 +3817,11 @@ bind_subcompositor(struct wl_client *client,
> >compositor, NULL);
> >  }
> >  
> > +/** Set a DPMS mode on all of the compositor's outputs
> > + *
> > + * \param compositor The compositor instance
> > + * \param state The DPMS state the outputs will be set to
> > + */
> 
> Ok.
> 
> >  static void
> >  weston_compositor_dpms(struct weston_compositor *compositor,
> >enum dpms_enum state)
> > @@ -3828,6 +3833,17 @@ weston_compositor_dpms(struct weston_compositor 
> > *compositor,
> > output->set_dpms(output, state);
> >  }
> >  
> > +/** Restores the compositor to active status
> > + *
> > + * \param compositor The compositor instance
> > + *
> > + * If the compositor was in a sleeping mode, all outputs are powered
> > + * back on via DPMS.  Otherwise if the compositor was inactive
> > + * (idle/locked, offscreen, or sleeping) then the compositor's wake
> > + * signal will fire.
> > + *
> > + * Resets the idle timer by one second.
> 
> Should be: Restarts the idle timer.
> 
> > + */
> >  WL_EXPORT void
> >  weston_compositor_wake(struct weston_compositor *compositor)
> >  {
> > @@ -3852,6 +3868,17 @@ weston_compositor_wake(struct weston_compositor 
> > *compositor)
> > }
> >  }
> >  
> > +/** Turns off rendering and frame events for the compositor.
> > + *
> > + * \param compositor The compositor instance
> > + *
> > + * This is used for example to prevent further rendering while the
> > + * compositor is shutting down.
> > + *
> 
> Add: Stops the idle timer.
> 
> Checking the call sites of this function, this seems to be mostly used
> when VT-switching away. The shutdown-path is good to mention because
> it's not calling this function but still uses offscreen mode.
> 
> > + * \note When offscreen state is entered, outputs will be powered
> > + * back on if they were sleeping (in DPMS off mode), even though
> > + * no rendering will be performed.
> > + */
> >  WL_EXPORT void
> >  weston_compositor_offscreen(struct weston_compositor *compositor)
> >  {
> > @@ -3867,6 +3894,14 @@ weston_compositor_offscreen(struct weston_compositor 
> > *compositor)
> > }
> >  }
> >  
> > +/** Powers down all attached output devices
> > + *
> > + * \param compositor The compositor instance
> > + *
> 
> Add: Stops the idle timer.
> 
> > + * Causes rendering to the outputs to cease, and no frame events to be
> > + * sent.  Only powers down the outputs if the compositor is not already
> > + * in sleep mode.
> > + */
> >  WL_EXPORT void
> >  weston_compositor_sleep(struct weston_compositor *compositor)
> >  {
> > @@ -3878,6 +3913,17 @@ weston_compositor_sleep(struct weston_compositor 
> > *compositor)
> > weston_compositor_dpms(compositor, WESTON_DPMS_OFF);
> >  }
> >  
> > +/** Sets compositor to idle mode
> > + *
> > + * \param data The compositor instance
> > + *
> 
> Add: This is called by the idle timer firing.
> 
> > + * Once the compositor is in idle mode it requires a wake action
> > + * (e.g. via weston_compositor_wake()) to restore it.  The compositor's
> > + * idle_signal will be triggered when the idle event occurs.
> > + *
> > + * Idleness can be inhibited by setting the compositor's idle_inhibit
> > + * property.
> > + */
> >  static int
> >  idle_handler(void *data)
> >  {
> 
> Looks good, no factual errors except that "one second". The other
> comments are just adding detail.
> 
> With these or equivalent changes:
> Reviewed-by: Pekka Paalanen 

Pushed with the recommended changes.

To ssh://git.freedesktop.org/git/wayland/weston
   c2be857..c9626a3  master -> master


> Thanks,
> pq

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIVAwUBVnldEiNf5bQRqqqnAQg9Iw//V8et1ojljHk3RBVsZ7yJvykEbTHaR3O5
> dDITz+RZrIX6KAgsx8YXfPKeYFQKrhPRZauBOdq75E45PAqF85hdscGtdWLsU6MW
> SwRgiVBcTijTqLCY4aY30TWH7JfUxVm8emeDZOTBjeZENOavcyEGzwLjL46YzY70
> pCNCyNhykjZ59iVirIbFM6wuL7KEFXwILtcSZsH4Z+1+2SxT1W5WpE/6Fqlv3M/V
> wMZVaZphoQSo0nC/avZ3wURPIpcwVR18bTHgkJq3ouDhQzIzCdjSKJ2eB8bpmFk+
> OPJhjTuLsZF2xTW77uBB3E8pyqX3NtQGeYNqQ0M9oFgdamTuiejP6YjbZz0ueZj/
> hCkJx8srhb+x9Qig4N5J6A/SYmf3o3G9WWXlnoGlPKc4KuyNUTOisaoh6fQzpCeG
> X2b19LgWjGZ5ZKqeMiEELNMdGjtVnDXk1lU21cUXhE8+niBWOHeNycV9lz/ibIrO
> 5VOrb/i54x14dUhJT3dPVJMuL6pDr3K/yt47Yy1mZlq85fUF8Hlr25csQBSCth7u
> quNgapGdnRJnbyD10OCZ5KNCn/1saEAlhZVbs2i0XhxuLJaXiD9NUe386rDDQKVv
> ILW5LuXz97xBWy6/fj9ZOXLdT7GfSleN8GNsGa43TW2TcD6V91xV1UFotLe+hIzi
> xBhF54neecs=
> =tBUB
> 

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

[Jonas Ådahl]

Hi again,

I was reading an E-mail in another thread that brought up different
types of backward compatibility promises, and it made me think of a
potential issue. I'm commenting inline close to the relevant change this
patch introduces.

On Tue, Dec 22, 2015 at 02:33:32AM +0100, Carlos Garnacho wrote:
> Currently, there's no means for the DnD origin to know whether the
> destination is actually finished with the DnD transaction, short of
> finalizing it after the first transfer finishes, or leaking it forever.
> 
> But this poses other interoperation problems, drag destinations might
> be requesting several mimetypes at once, might be just poking to find
> out the most suitable format, might want to defer the action to a popup,
> might be poking contents early before the selection was dropped...
> 
> In addition, data_source.cancelled is suitable for the situations where
> the DnD operation fails (not on a drop target, no matching mimetypes,
> etc..), but seems undocumented for that use (and unused in weston's DnD).
> 
> In order to improve the situation, the drag source should be notified
> of all stages of DnD. In addition to documenting the "cancelled" event
> for DnD purposes, The following 2 events have been added:
> 
> - wl_data_source.dnd_drop_performed: Happens when the operation has been
>   physically finished (eg. the button is released), it could be the right
>   place to reset the pointer cursor back and undo any other state resulting
>   from the initial button press.
> - wl_data_source.dnd_finished: Happens when the destination side destroys
>   the wl_data_offer, at this point the source can just forget all data
>   related to the DnD selection as well, plus optionally deleting the data
>   on move operations.
> 
> Changes since v4:
>   - Applied rewording suggestions from Jonas Ådahl. Added new
> wl_data_offer.finish request to allow explicit finalization on the
> destination side.
> 
> Changes since v3:
>   - Renamed dnd_performed to a more descriptive dnd_drop_performed,
> documented backwards compatible behavior on wl_data_offer.accept and
> wl_data_source.cancelled.
> 
> Changes since v2:
>   - Minor rewording.
> 
> Changes since v1:
>   - Renamed events to have a common "dnd" namespace. Made dnd_performed to
> happen invariably, data_device.cancelled may still happen afterwards.
> 
> Signed-off-by: Carlos Garnacho 
> Reviewed-by: Michael Catanzaro 
> Reviewed-by: Jonas Ådahl 
> Reviewed-by: Mike Blumenkrantz 
> ---
>  protocol/wayland.xml | 75 
> +++-
>  1 file changed, 69 insertions(+), 6 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index df8ed19..ae5ef21 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -408,7 +408,7 @@
>
>  
>  
> -  
> +  
>  
>A wl_data_offer represents a piece of data offered for transfer
>by another client (the source client).  It is used by the
> @@ -423,7 +423,17 @@
>   Indicate that the client can accept the given mime type, or
>   NULL for not accepted.
>  
> - Used for feedback during drag-and-drop.
> + For objects of version 2 or older, this request is used by the
> + client to give feedback whether the client can receive the given
> + mime type, or NULL if none is accepted; the feedback does not
> + determine whether drag-and-drop operation succeeds or not.
> +
> + For objects of version 3 or newer, this request determines the
> + final result of the drag-and-drop operation. If the end result
> + is that no mime types was accepted, the drag-and-drop operation
> + will be cancelled and the corresponding drag source will receive
> + wl_data_source.cancelled. Clients may still use this event in
> + conjunction with wl_data_source.action for feedback.

As Pekka (CC:ed) wrote in a reply to the proxy version tracking thread
[0], the kind of change that is introduced above is not really backward
compatible. The possible issue would be, if I understand things
correctly, that if we have a client split up into two separate parts (an
application and a third party library); if the application creates a
wl_data_device of version 3 and then passes it (or a wl_data_offer) to
the library that only support version 1 or 2, the client will break
because according to version < 3 there is no requirement to reason to
reply with "accept" other than wishing to provide optional feedback, and
the library may rely on this.

I think the "wl_data_source.cancelled" change is backward compatible
though, since it doesn't alter any expectations from client.


Jonas


[0] 
http://lists.freedesktop.org/archives/wayland-devel/2015-December/026004.html

>
>  
>
> @@ -461,9 +471,24 @@
>  
>
>  
> +
> +
> +
> +
> +  
> + Notifies the compositor that the data offer will no 

[PATCH libinput 1/4] tablet: always set the pressure offset

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev-tablet.c | 8 
 src/libinput-private.h | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 7804c91..7f6c860 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -882,6 +882,8 @@ tablet_get_tool(struct tablet_dispatch *tablet,
/* If we didn't already have the new_tool in our list of tools,
 * add it */
if (!tool) {
+   const struct input_absinfo *pressure;
+
tool = zalloc(sizeof *tool);
*tool = (struct libinput_tablet_tool) {
.type = type,
@@ -892,6 +894,12 @@ tablet_get_tool(struct tablet_dispatch *tablet,
 
tool->pressure_offset = 0;
tool->has_pressure_offset = false;
+
+   pressure = libevdev_get_abs_info(tablet->device->evdev,
+ABS_PRESSURE);
+   if (pressure)
+   tool->pressure_offset = pressure->minimum;
+
tool_set_bits(tablet, tool);
 
list_insert(tool_list, >link);
diff --git a/src/libinput-private.h b/src/libinput-private.h
index 246986e..3d714af 100644
--- a/src/libinput-private.h
+++ b/src/libinput-private.h
@@ -277,7 +277,7 @@ struct libinput_tablet_tool {
int refcount;
void *user_data;
 
-   int pressure_offset;
+   int pressure_offset; /* in device coordinates */
bool has_pressure_offset;
 };
 
-- 
2.5.0

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

[PATCH libinput 3/4] tablet: add pressure threshold handling

[Peter Hutterer]

On tablets with ABS_PRESSURE use a pressure value to determine tip state, not
BTN_TOUCH. This enables us (down the road) to have device-specific pressure
thresholds. For now we use a 5% default for all devices.

The threshold is a range, if we go past the upper range we initiate the tip
down, if we go below the lower range we release the tip again.

This affects two current tests:
* Once we have pressure offsets and pressure thresholds, we're biased towards
pressure. So we can only check that distance is zero when there is a pressure
value, not the other way round.
* When the pressure threshold is exceeded on proximity in with a nonzero
distance, we can only warn and handle the pressure as normal. Since this is a
niche case anyway anything fancier is likely unnecessary.

Signed-off-by: Peter Hutterer 
---
 doc/tablet-support.dox | 16 +
 src/evdev-tablet.c | 94 --
 src/libinput-private.h |  8 +
 test/tablet.c  | 67 ---
 4 files changed, 122 insertions(+), 63 deletions(-)

diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
index fbe778d..a3d4d7b 100644
--- a/doc/tablet-support.dox
+++ b/doc/tablet-support.dox
@@ -33,6 +33,22 @@ Tablet tools may send button events; these are exclusively 
for extra buttons
 unrelated to the tip. A button event is independent of the tip and occur
 at any time.
 
+Some tablet tools' pressure detection is too sensitive, causing phantom
+touches when the user only slightly brushes the surfaces. For example, some
+tools are capable of detecting 1 gram of pressure.
+
+libinput uses a device-specific pressure threshold to determine when the tip
+is considered logically down. As a result, libinput may send a nonzero
+pressure value while the tip is logically up. Most application can and
+should ignore pressure information until they receive the event of type @ref
+LIBINPUT_EVENT_TABLET_TOOL_TIP. Applications that require extremely
+fine-grained pressure sensitivity should use the pressure data instead of
+the tip events.
+
+Note that the pressure threshold to trigger a logical tip event may be zero
+on some devices. On tools without pressure sensitivity, determining when a
+tip is down is device-specific.
+
 @section tablet-axes Special axes on tablet tools
 
 A tablet tool usually provides additional information beyond x/y positional
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 7f6c860..2f57805 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -617,10 +617,15 @@ tablet_process_key(struct tablet_dispatch *tablet,
   e->value);
break;
case BTN_TOUCH:
-   if (e->value)
-   tablet_set_status(tablet, TABLET_TOOL_ENTERING_CONTACT);
-   else
-   tablet_set_status(tablet, TABLET_TOOL_LEAVING_CONTACT);
+   if (!bit_is_set(tablet->axis_caps,
+   LIBINPUT_TABLET_TOOL_AXIS_PRESSURE)) {
+   if (e->value)
+   tablet_set_status(tablet,
+ TABLET_TOOL_ENTERING_CONTACT);
+   else
+   tablet_set_status(tablet,
+ TABLET_TOOL_LEAVING_CONTACT);
+   }
break;
case BTN_LEFT:
case BTN_RIGHT:
@@ -844,6 +849,12 @@ tool_set_bits(const struct tablet_dispatch *tablet,
}
 }
 
+static inline int
+axis_range_percentage(const struct input_absinfo *a, double percent)
+{
+   return (a->maximum - a->minimum) * percent/100.0 + a->minimum;
+}
+
 static struct libinput_tablet_tool *
 tablet_get_tool(struct tablet_dispatch *tablet,
enum libinput_tablet_tool_type type,
@@ -894,12 +905,22 @@ tablet_get_tool(struct tablet_dispatch *tablet,
 
tool->pressure_offset = 0;
tool->has_pressure_offset = false;
+   tool->pressure_threshold.lower = 0;
+   tool->pressure_threshold.upper = 1;
 
pressure = libevdev_get_abs_info(tablet->device->evdev,
 ABS_PRESSURE);
-   if (pressure)
+   if (pressure) {
tool->pressure_offset = pressure->minimum;
 
+   /* 5% of the pressure range */
+   tool->pressure_threshold.upper =
+   pressure->minimum +
+   axis_range_percentage(pressure, 5);
+   tool->pressure_threshold.lower =
+   pressure->minimum;
+   }
+
tool_set_bits(tablet, tool);
 
list_insert(tool_list, >link);
@@ -965,7 +986,8 @@ tablet_notify_buttons(struct tablet_dispatch *tablet,
 }
 
 static void

[PATCH libinput 2/4] test: fix a bunch of tablet tests for pressure threshold introduction

[Peter Hutterer]

Preparation work for a pressure threshold where we can't just send a BTN_TOUCH
and expect it to trigger the tip event. So the event sequence now needs to
resemble the right order so the threshold will be triggered.

In some cases requires processing an axis event before the tip event. That
behavior will be changed in a follow-up commit.

It also requires that all tablets set ABS_PRESSURE on proximity in.

Signed-off-by: Peter Hutterer 
---
 test/litest-device-huion-pentablet.c|   1 +
 test/litest-device-wacom-isdv4-tablet.c |   1 +
 test/litest-device-waltop-tablet.c  |   1 +
 test/tablet.c   | 209 +++-
 4 files changed, 182 insertions(+), 30 deletions(-)

diff --git a/test/litest-device-huion-pentablet.c 
b/test/litest-device-huion-pentablet.c
index 6be659b..e030f20 100644
--- a/test/litest-device-huion-pentablet.c
+++ b/test/litest-device-huion-pentablet.c
@@ -36,6 +36,7 @@ static void litest_huion_tablet_setup(void)
 static struct input_event proximity_in[] = {
{ .type = EV_ABS, .code = ABS_X, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
+   { .type = EV_ABS, .code = ABS_PRESSURE, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_KEY, .code = BTN_TOOL_PEN, .value = 1 },
{ .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
{ .type = -1, .code = -1 },
diff --git a/test/litest-device-wacom-isdv4-tablet.c 
b/test/litest-device-wacom-isdv4-tablet.c
index bc60705..400fb57 100644
--- a/test/litest-device-wacom-isdv4-tablet.c
+++ b/test/litest-device-wacom-isdv4-tablet.c
@@ -36,6 +36,7 @@ static void litest_wacom_isdv4_tablet_setup(void)
 static struct input_event proximity_in[] = {
{ .type = EV_ABS, .code = ABS_X, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
+   { .type = EV_ABS, .code = ABS_PRESSURE, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_KEY, .code = BTN_TOOL_PEN, .value = 1 },
{ .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
{ .type = -1, .code = -1 },
diff --git a/test/litest-device-waltop-tablet.c 
b/test/litest-device-waltop-tablet.c
index 8b6de52..880ddf3 100644
--- a/test/litest-device-waltop-tablet.c
+++ b/test/litest-device-waltop-tablet.c
@@ -38,6 +38,7 @@ static struct input_event proximity_in[] = {
{ .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_TILT_X, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_TILT_Y, .value = LITEST_AUTO_ASSIGN },
+   { .type = EV_ABS, .code = ABS_PRESSURE, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_KEY, .code = BTN_TOOL_PEN, .value = 1 },
{ .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
{ .type = -1, .code = -1 },
diff --git a/test/tablet.c b/test/tablet.c
index 3c509e7..fc6d1df 100644
--- a/test/tablet.c
+++ b/test/tablet.c
@@ -42,16 +42,27 @@ START_TEST(tip_down_up)
struct libinput_event_tablet_tool *tablet_event;
struct axis_replacement axes[] = {
{ ABS_DISTANCE, 10 },
+   { ABS_PRESSURE, 0 },
{ -1, -1 }
};
 
litest_tablet_proximity_in(dev, 10, 10, axes);
litest_drain_events(li);
 
+   litest_axis_set_value(axes, ABS_DISTANCE, 0);
+   litest_axis_set_value(axes, ABS_PRESSURE, 30);
+   litest_push_event_frame(dev);
+   litest_tablet_motion(dev, 10, 10, axes);
litest_event(dev, EV_KEY, BTN_TOUCH, 1);
-   litest_event(dev, EV_SYN, SYN_REPORT, 0);
+   litest_pop_event_frame(dev);
 
libinput_dispatch(li);
+
+   event = libinput_get_event(li);
+   tablet_event = litest_is_tablet_event(event,
+ LIBINPUT_EVENT_TABLET_TOOL_AXIS);
+   libinput_event_destroy(event);
+
event = libinput_get_event(li);
tablet_event = litest_is_tablet_event(event,
  LIBINPUT_EVENT_TABLET_TOOL_TIP);
@@ -60,12 +71,21 @@ START_TEST(tip_down_up)
libinput_event_destroy(event);
litest_assert_empty_queue(li);
 
+   litest_axis_set_value(axes, ABS_DISTANCE, 10);
+   litest_axis_set_value(axes, ABS_PRESSURE, 0);
+   litest_push_event_frame(dev);
+   litest_tablet_motion(dev, 10, 10, axes);
litest_event(dev, EV_KEY, BTN_TOUCH, 0);
-   litest_event(dev, EV_SYN, SYN_REPORT, 0);
+   litest_pop_event_frame(dev);
 
libinput_dispatch(li);
event = libinput_get_event(li);
tablet_event = litest_is_tablet_event(event,
+ LIBINPUT_EVENT_TABLET_TOOL_AXIS);
+   libinput_event_destroy(event);
+
+   event = libinput_get_event(li);
+   tablet_event = litest_is_tablet_event(event,
  LIBINPUT_EVENT_TABLET_TOOL_TIP);

[PATCH libinput 4/4] tablet: a tip event can replace an axis event

[Peter Hutterer]

When we're only dealing with BTN_TOUCH we can make the tip event independent
of the axis event. Now that we handle pressure thresholds to trigger tip state
this does not work, we'd have to send an axis event with the new pressure and
then a tip event. Since the pressure triggers the tip event this seems
disconnected.

Make the tip event officially capable of carrying axes. A caller can then
decide how to forward this to the next layer.

Signed-off-by: Peter Hutterer 
---
 doc/tablet-support.dox |   2 +-
 src/evdev-tablet.c | 168 +++--
 src/libinput-private.h |   1 +
 src/libinput.c |   4 ++
 src/libinput.h |  28 -
 test/tablet.c  | 101 -
 6 files changed, 178 insertions(+), 126 deletions(-)

diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
index a3d4d7b..7113fd1 100644
--- a/doc/tablet-support.dox
+++ b/doc/tablet-support.dox
@@ -43,7 +43,7 @@ pressure value while the tip is logically up. Most 
application can and
 should ignore pressure information until they receive the event of type @ref
 LIBINPUT_EVENT_TABLET_TOOL_TIP. Applications that require extremely
 fine-grained pressure sensitivity should use the pressure data instead of
-the tip events.
+the tip events to determine a logical tip down state.
 
 Note that the pressure threshold to trigger a logical tip event may be zero
 on some devices. On tools without pressure sensitivity, determining when a
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 2f57805..0c20483 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -453,13 +453,14 @@ tablet_handle_wheel(struct tablet_dispatch *tablet,
return tablet->axes[a];
 }
 
-static void
+static bool
 tablet_check_notify_axes(struct tablet_dispatch *tablet,
 struct evdev_device *device,
-uint64_t time,
-struct libinput_tablet_tool *tool)
+struct libinput_tablet_tool *tool,
+double *axes_out,
+size_t axes_sz,
+int *wheel_discrete_out)
 {
-   struct libinput_device *base = >base;
double axes[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1] = {0};
int wheel_discrete = 0;
struct device_coords point;
@@ -467,8 +468,9 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
const char tmp[sizeof(tablet->changed_axes)] = {0};
 
if (memcmp(tmp, tablet->changed_axes, sizeof(tmp)) == 0)
-   return;
+   return false;
 
+   assert(axes_sz == sizeof(axes));
point = tablet_handle_xy(tablet, device);
axes[LIBINPUT_TABLET_TOOL_AXIS_X] = point.x;
axes[LIBINPUT_TABLET_TOOL_AXIS_Y] = point.y;
@@ -501,41 +503,10 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
axes[LIBINPUT_TABLET_TOOL_AXIS_REL_WHEEL] =
tablet_handle_wheel(tablet, device, _discrete);
 
-   /* We need to make sure that we check that the tool is not out of
-* proximity before we send any axis updates. This is because many
-* tablets will send axis events with incorrect values if the tablet
-* tool is close enough so that the tablet can partially detect that
-* it's there, but can't properly receive any data from the tool. */
-   if (!tablet_has_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY) &&
-   !tablet_has_status(tablet, TABLET_TOOL_LEAVING_PROXIMITY)) {
-   if (tablet_has_status(tablet,
- TABLET_TOOL_ENTERING_PROXIMITY)) {
-   tablet_notify_proximity(>base,
-   time,
-   tool,
-   
LIBINPUT_TABLET_TOOL_PROXIMITY_IN,
-   tablet->changed_axes,
-   axes);
-   } else {
-   enum libinput_tablet_tool_tip_state tip_state;
+   memcpy(axes_out, axes, sizeof(axes));
+   *wheel_discrete_out = wheel_discrete;
 
-   if (tablet_has_status(tablet,
- TABLET_TOOL_IN_CONTACT))
-   tip_state = LIBINPUT_TABLET_TOOL_TIP_DOWN;
-   else
-   tip_state = LIBINPUT_TABLET_TOOL_TIP_UP;
-
-   tablet_notify_axis(base,
-  time,
-  tool,
-  tip_state,
-  tablet->changed_axes,
-  axes,
-  wheel_discrete);
-   }
-   }
-
-   memset(tablet->changed_axes, 0, 

Re: [PATCH 2/3] Introduce WAYLAND_SERVER_SOCKET to change the path where the server will create the socket. It will be possible for a nested compositor to offer a socket located on WAYLAND_SERVER_SOCK

[Pekka Paalanen]

On Tue,  3 Mar 2015 13:49:54 +0100
Davide Bettio  wrote:

> Signed-off-by: Davide Bettio 
> ---
>  src/wayland-server.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index eefbe35..05e9c07 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -1216,9 +1216,9 @@ wl_display_add_socket_auto(struct wl_display *display)
>   * This adds a Unix socket to Wayland display which can be used by clients to
>   * connect to Wayland display.
>   *
> - * If NULL is passed as name, then it would look for WAYLAND_DISPLAY env
> - * variable for the socket name. If WAYLAND_DISPLAY is not set, then default
> - * wayland-0 is used.
> + * If NULL is passed as name, then it would look in order for 
> WAYLAND_SERVER_SOCKET
> + * and WAYLAND_DISPLAY env variable for the socket name. If WAYLAND_DISPLAY 
> and
> + * WAYLAND_SERVER_SOCKET are not set, then default wayland-0 is used.
>   *
>   * The Unix socket will be created in the directory pointed to by environment
>   * variable XDG_RUNTIME_DIR. If XDG_RUNTIME_DIR is not set, then this 
> function
> @@ -1241,6 +1241,8 @@ wl_display_add_socket(struct wl_display *display, const 
> char *name)
>   return -1;
>  
>   if (name == NULL)
> + name = getenv("WAYLAND_SERVER_SOCKET");
> + if (name == NULL)
>   name = getenv("WAYLAND_DISPLAY");
>   if (name == NULL)
>   name = "wayland-0";

Hi Davide,

there is no longer a need to play with these environment variables
trying to contort libwayland-server to create a socket like you want it.

http://cgit.freedesktop.org/wayland/wayland/commit/?id=225830dcb8bf1a6583d0f4ca182584024783923e
"server: Add a socket with an existing fd"

You can create the socket any way you want, and have libwayland-server
start answering connections on it.

Mind, that nested Wayland or mini-compositor setups are better off
creating the connection with socketpair(2) and using WAYLAND_SOCKET
environment variable per client process, because then you control
exactly which processes can be connected.


Thanks,
pq


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

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

[Carlos Garnacho]

Hey!,

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

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

[Jonas Ådahl]

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

[IDEA] Support several fullscreen behaviors - potentially rename 'fullscreen'

[Coroutines]

# Summary

Wayland compositors like weston have the freedom to display
'fullscreen'-selected content in 3 ways (that I can think of):

- full-window
- fullscreen
- multi-display fullscreen

# The Problem

Something that I've always wanted to have control over is how an
application is shown in in its fullscreen state.  Typically when I'm
watching a video on youtube in a web browser I want the player to
instead fill the existing window dimensions and not the screen.  In
this example I am looking for full-window behavior.  I can of course
propose this to Google's devs, but I'd have to do this for every app
where I want full-window.  I'd much rather have a wayland compositor
that gives me this ability to 'abuse' the fullscreen state.

# What I propose:

The compositor has the freedom with xdg-shell to "lie" to the client
about the geometry of the screen in the configure event, when a
surface sets itself as fullscreen.

In this way, the compositor can show the surface in 3 modes that give
the user more choice/convenience:

- fullscreen (traditional)
- full-window (same size, placed at the same x, y)
- multi-display "fullscreen" (think Far Cry playing across 3 displays)

I also imagined the compositor would have options for dimming the
areas between fullscreen clients (think theater-mode).  Or immediately
turn off all other displays ~

# Why abuse fullscreen?

1) It seems perfectly legal per xdg-shell with no bad side-effects.

2) I was thinking about something said over and over in #wayland, that
xdg-shell is not about providing mechanisms/primitive operations like
X.  It's about providing requests for clients to convey intent.  In my
opinion, the intent of fullscreen behavior is to enlarge and focus
content.  To display specific content from a window in a way that the
user will not be distracted by other apps and activities they're
doing.

If I want to convey "intent" I'm bringing *select* content to the
forefront of what the user has open on screen.

In my opinion, the user should be the one choosing how large this
selected content appears and where - and if other clients are still
visible.

I avoided calling this 'focused' content, if not 'fullscreen'.  I was
thinking maybe it could be called a 'forefront' or 'foreground' state
- or even just 'closer'.  From a protocol perspective, if wayland
compositors were to support this greater level of control over the
fullscreen state, I think it should be renamed in the future.

Anyway, I just wanted to write about this and put the idea in the
heads of people shaping our future desktop experience on Linux.  If
you work on mutter or kde plasma, or shape xdg-shell's mechanics...
This is something we can't do on Mac/Windows (across all clients), and
imo it'd be pretty cool. :>  I personally wish I were prompted by the
compositor to confirm which fullscreen mode I want a client to conform
to, but others might want a default of the 3 modes ~

Thanks for reading ~

Disclaimer?: I don't expect anyone to do anything for me.  I think I
come up with original ideas so I'm simply trying to share it.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Carlos Garnacho]

Hey!,

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

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

>
> One comment and a couple of nits below.
>
>> ---
>>  protocol/wayland.xml | 75 
>> +++-
>>  1 file changed, 69 insertions(+), 6 deletions(-)
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index df8ed19..ae5ef21 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -408,7 +408,7 @@
>>
>>
>>
>> -  
>> +  
>>  
>>A wl_data_offer represents a piece of data offered for transfer
>>by another client (the source client).  It is used by the
>> @@ -423,7 +423,17 @@
>>   Indicate that the client can accept the given mime type, or
>>   NULL for not accepted.
>>
>> - Used for feedback during drag-and-drop.
>> + For objects of version 2 or older, this request is used by the
>> + client to give feedback whether the client can receive the given
>> + mime type, or NULL if none is accepted; the feedback does not
>> + determine whether drag-and-drop operation succeeds or not.
>> +
>> + For objects of version 3 or newer, this request determines the
>> + final result of the drag-and-drop operation. If the end result
>> + is that no mime types was accepted, the drag-and-drop operation
>> + will be cancelled and the corresponding drag source will receive
>> + wl_data_source.cancelled. Clients may still use this event in
>> + conjunction with wl_data_source.action for feedback.
>>
>>
>>
>> @@ -461,9 +471,24 @@
>>
>>
>>  
>> +
>> +
>> +
>> +
>> +  
>> + Notifies the compositor that the data offer will no longer be used.
>> + Upon receiving this request, the compositor will emit
>> + wl_data_source.drag_finished or wl_data_source.cancelled on the drag
>> + source client depending on the most recent wl_data_offer.accept and
>> + wl_data_offer.set_actions requests received from this offer.
>
> Hmm. What I had in mind is that .finish is called after the transfer is
> completed, i.e. the accept and actions (nit: which btw is not introduced
> in this patch so I suppose should not really be referenced yet) have

Oops indeed.

> already been ensured to be compatible. So, I don't see how
> wl_data_source.cancelled 

Re: inserting a "wl_display" object

[Pekka Paalanen]

On Tue, 22 Dec 2015 14:34:08 +0200
m...@beroal.in.ua wrote:

> Hello, I'm new to Wayland. I need a "wl_display" object in order to 
> insert "wl_registry" and start working. I see no means of inserting it. 
> (I want to know how to do that in the Wayland protocol, not in the C 
> binding to it.)

Hi,

wl_display is implicitly constructed with ID 1 on both sides when a
connection is created. It "just exists", there is no protocol to create
it.


Thanks,
pq


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

inserting a "wl_display" object

[me]

Hello, I'm new to Wayland. I need a "wl_display" object in order to 
insert "wl_registry" and start working. I see no means of inserting it. 
(I want to know how to do that in the Wayland protocol, not in the C 
binding to it.)

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

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

[Jonas Ådahl]

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

Actually I don't know what is preferred. Personally I put the changelog
outside of the commit message and thought that was what was preferred
but I might be wrong.

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

Re: [PATCH 2/2] compositor: Document routines relating to idle behavior

[Pekka Paalanen]

Hi Bryce

On Fri, 11 Dec 2015 13:11:38 -0800
Bryce Harrington  wrote:

> Signed-off-by: Bryce Harrington 
> ---
>  src/compositor.c | 46 ++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/src/compositor.c b/src/compositor.c
> index 254e9e4..3e1f588 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -3817,6 +3817,11 @@ bind_subcompositor(struct wl_client *client,
>  compositor, NULL);
>  }
>  
> +/** Set a DPMS mode on all of the compositor's outputs
> + *
> + * \param compositor The compositor instance
> + * \param state The DPMS state the outputs will be set to
> + */

Ok.

>  static void
>  weston_compositor_dpms(struct weston_compositor *compositor,
>  enum dpms_enum state)
> @@ -3828,6 +3833,17 @@ weston_compositor_dpms(struct weston_compositor 
> *compositor,
>   output->set_dpms(output, state);
>  }
>  
> +/** Restores the compositor to active status
> + *
> + * \param compositor The compositor instance
> + *
> + * If the compositor was in a sleeping mode, all outputs are powered
> + * back on via DPMS.  Otherwise if the compositor was inactive
> + * (idle/locked, offscreen, or sleeping) then the compositor's wake
> + * signal will fire.
> + *
> + * Resets the idle timer by one second.

Should be: Restarts the idle timer.

> + */
>  WL_EXPORT void
>  weston_compositor_wake(struct weston_compositor *compositor)
>  {
> @@ -3852,6 +3868,17 @@ weston_compositor_wake(struct weston_compositor 
> *compositor)
>   }
>  }
>  
> +/** Turns off rendering and frame events for the compositor.
> + *
> + * \param compositor The compositor instance
> + *
> + * This is used for example to prevent further rendering while the
> + * compositor is shutting down.
> + *

Add: Stops the idle timer.

Checking the call sites of this function, this seems to be mostly used
when VT-switching away. The shutdown-path is good to mention because
it's not calling this function but still uses offscreen mode.

> + * \note When offscreen state is entered, outputs will be powered
> + * back on if they were sleeping (in DPMS off mode), even though
> + * no rendering will be performed.
> + */
>  WL_EXPORT void
>  weston_compositor_offscreen(struct weston_compositor *compositor)
>  {
> @@ -3867,6 +3894,14 @@ weston_compositor_offscreen(struct weston_compositor 
> *compositor)
>   }
>  }
>  
> +/** Powers down all attached output devices
> + *
> + * \param compositor The compositor instance
> + *

Add: Stops the idle timer.

> + * Causes rendering to the outputs to cease, and no frame events to be
> + * sent.  Only powers down the outputs if the compositor is not already
> + * in sleep mode.
> + */
>  WL_EXPORT void
>  weston_compositor_sleep(struct weston_compositor *compositor)
>  {
> @@ -3878,6 +3913,17 @@ weston_compositor_sleep(struct weston_compositor 
> *compositor)
>   weston_compositor_dpms(compositor, WESTON_DPMS_OFF);
>  }
>  
> +/** Sets compositor to idle mode
> + *
> + * \param data The compositor instance
> + *

Add: This is called by the idle timer firing.

> + * Once the compositor is in idle mode it requires a wake action
> + * (e.g. via weston_compositor_wake()) to restore it.  The compositor's
> + * idle_signal will be triggered when the idle event occurs.
> + *
> + * Idleness can be inhibited by setting the compositor's idle_inhibit
> + * property.
> + */
>  static int
>  idle_handler(void *data)
>  {

Looks good, no factual errors except that "one second". The other
comments are just adding detail.

With these or equivalent changes:
Reviewed-by: Pekka Paalanen 


Thanks,
pq


pgpM5_lNm_2Ho.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 2/5] data-device: Implement DnD actions

[Carlos Garnacho]

Hey!,

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

Right

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

Re: [PATCH 1/2] compositor: Fix a couple comment typos

[Pekka Paalanen]

On Fri, 11 Dec 2015 13:11:37 -0800
Bryce Harrington  wrote:

> Signed-off-by: Bryce Harrington 
> ---
>  src/compositor-fbdev.c | 2 +-
>  src/compositor.h   | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> index 57c54c2..e27df6d 100644
> --- a/src/compositor-fbdev.c
> +++ b/src/compositor-fbdev.c
> @@ -786,7 +786,7 @@ session_notify(struct wl_listener *listener, void *data)
>   /* If we have a repaint scheduled (from the idle handler), make
>* sure we cancel that so we don't try to pageflip when we're
>* vt switched away.  The OFFSCREEN state will prevent
> -  * further attemps at repainting.  When we switch
> +  * further attempts at repainting.  When we switch
>* back, we schedule a repaint, which will process
>* pending frame callbacks. */
>  
> diff --git a/src/compositor.h b/src/compositor.h
> index 43db92e..c25a103 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -566,10 +566,10 @@ struct weston_seat {
>  };
>  
>  enum {
> - WESTON_COMPOSITOR_ACTIVE,
> + WESTON_COMPOSITOR_ACTIVE,   /* normal rendering and events */
>   WESTON_COMPOSITOR_IDLE, /* shell->unlock called on activity */
>   WESTON_COMPOSITOR_OFFSCREEN,/* no rendering, no frame events */
> - WESTON_COMPOSITOR_SLEEPING  /* same as offscreen, but also set dmps
> + WESTON_COMPOSITOR_SLEEPING  /* same as offscreen, but also set dpms
>   * to off */
>  };
>  

Pushed:
   f05d18f..c2be857  master -> master


Thanks,
pq


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