[PATCH wayland] scanner: Fix oddities in copyright printing

[Derek Foreman]

Some copyright strings could result in broken generated header files with
unmatched */

This change:
Runs the loop long enough so the copyright[i] == 0 test can actually
happen. (if there was no \n no copyright text was printed, */ still was)

Prints the opening /* even if there was whitespace at the start of
the very first line.

Only emits a */ if a /* was printed.

Signed-off-by: Derek Foreman 
---
 src/scanner.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/scanner.c b/src/scanner.c
index dda5473..d3e2328 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1284,25 +1284,29 @@ emit_structs(struct wl_list *message_list, struct 
interface *interface, enum sid
 static void
 format_copyright(const char *copyright)
 {
-   int bol = 1, start = 0, i;
+   int bol = 1, start = 0, i, length;
+   bool comment_started = false;
 
-   for (i = 0; copyright[i]; i++) {
+   length = strlen(copyright);
+   for (i = 0; i <= length; i++) {
if (bol && (copyright[i] == ' ' || copyright[i] == '\t')) {
continue;
} else if (bol) {
bol = 0;
start = i;
}
-
-   if (copyright[i] == '\n' || copyright[i] == '\0') {
+   if (copyright[i] == '\n' ||
+   (copyright[i] == '\0' && !(start == i))) {
printf("%s%s%.*s\n",
-  i == 0 ? "/*" : " *",
+  comment_started ? " *" : "/*",
   i > start ? " " : "",
   i - start, copyright + start);
bol = 1;
+   comment_started = true;
}
}
-   printf(" */\n\n");
+   if (comment_started)
+   printf(" */\n\n");
 }
 
 static void
-- 
2.7.0

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

Re: [PATCH wayland] scanner: Fix oddities in copyright printing

[Jon A. Cruz]

On 02/02/2016 12:56 PM, Derek Foreman wrote:

Some copyright strings could result in broken generated header files with
unmatched */

This change:
Runs the loop long enough so the copyright[i] == 0 test can actually
happen. (if there was no \n no copyright text was printed, */ still was)

Prints the opening /* even if there was whitespace at the start of
the very first line.

Only emits a */ if a /* was printed.

Signed-off-by: Derek Foreman 


Looks good to me:
Reviewed-by: Jon A. Cruz 



---
  src/scanner.c | 16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/scanner.c b/src/scanner.c
index dda5473..d3e2328 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1284,25 +1284,29 @@ emit_structs(struct wl_list *message_list, struct 
interface *interface, enum sid
  static void
  format_copyright(const char *copyright)
  {
-   int bol = 1, start = 0, i;
+   int bol = 1, start = 0, i, length;
+   bool comment_started = false;
  
-	for (i = 0; copyright[i]; i++) {

+   length = strlen(copyright);
+   for (i = 0; i <= length; i++) {
if (bol && (copyright[i] == ' ' || copyright[i] == '\t')) {
continue;
} else if (bol) {
bol = 0;
start = i;
}
-
-   if (copyright[i] == '\n' || copyright[i] == '\0') {
+   if (copyright[i] == '\n' ||
+   (copyright[i] == '\0' && !(start == i))) {
printf("%s%s%.*s\n",
-  i == 0 ? "/*" : " *",
+  comment_started ? " *" : "/*",
   i > start ? " " : "",
   i - start, copyright + start);
bol = 1;
+   comment_started = true;
}
}
-   printf(" */\n\n");
+   if (comment_started)
+   printf(" */\n\n");
  }
  
  static void


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

Re: Recursive dispatch (Re: [PATCH v2] server: Calculate remaining data size after a closure is processed)

[Derek Foreman]

On 02/02/16 06:57 AM, Pekka Paalanen wrote:
> On Tue, 12 Jan 2016 13:03:19 +0900 "Jaeyoon Jung"
>  wrote:
> 
>>> -Original Message- From: wayland-devel
>>> [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf
>>> Of Jonas Adahl Sent: Tuesday, January 12, 2016 12:27 PM To:
>>> Jaeyoon Jung Cc: wayland-devel@lists.freedesktop.org Subject:
>>> Re: [PATCH v2] server: Calculate remaining data size after a
>>> closure is processed
>>> 
>>> On Tue, Jan 12, 2016 at 08:22:56AM +0900, Jaeyoon Jung wrote:
>>> 
 When processing a closure, data in the connection can be
 consumed again if the closure itself invokes extra event
 dispatch. In that case the remaining data size is also
 altered, so the variable len should be updated after the
 closure is processed.
 
 Signed-off-by: Jaeyoon Jung 
>>> 
>>> I don't like the name wl_connection_size
>>> (wl_connection_pending_input() or something would be more
>>> descriptive).
>> 
>> I just wanted to have a shorter name.
>> wl_connection_pending_input() looks better to me as well, and
>> I'll update the patch accordingly. Thanks.
>> 
>> 
>>> A good follow up would be a test case where this would
>>> otherwise cause issues. I assume it would be triggered by a 
>>> wl_event_loop_dispatch() in a interface request handler?
>> 
>> Yes, exactly.
> 
> Hi,
> 
> could you humor me and explain in what sort of situations
> dispatching from within a request handler is useful?
> 
> I thought recursive dispatch is a programming pattern that can
> only lead to painful and erratic problems later. Don't we consider
> this to be bad practice also in the client API?

Is that actually documented somewhere?

> If you do it in the server, that is like: this message causes more 
> messages to be dispatched - how does that make sense? A server must
> not block waiting for any client message.

I agree that a server blocking on a client message is a great way to
create a terrible user experience - but I'm not certain it's
libwayland's mandate to prevent it?

> Also, inspecting future messages before finishing the processing of
> the current message is racy: the following messages may or may not
> be in the receive buffer and nothing guarantees either way, you
> just get lucky a lot of times. Wayland IPC does not guarantee more
> than one message to be delivered at a time, this is why we have
> things like wl_surface.commit request.

This is a really good point. :)

> If someone starts hardening libwayland against programmer errors,
> I'd expect one thing to be to abort() on recursive dispatch. Can
> you tell me why we should support recursive dispatch?

IMHO we should either do that immediately (before the 1.10 release) or
revert this patch now.  Not that anything is wrong with the patch - it
doesn't introduce bugs in libwayland...

Previously recursive dispatch was impossible, with this patch it's
possible.  The patch was landed to allow recursive dispatch to work,
and it's obvious someone's about to start using it.

If we later intentionally break that code, we're jerks.
-- From the jerk that posted a bunch of patches to do more stringent
checks on resource versions a few days ago...  arguably those have
always been bugs, though. ;)

So, with the release coming so quickly, I think we should either
decide whether recursive dispatch is legal or illegal before the
release, or revert the patch (thus re-breaking recursive dispatch) and
worry about it for 1.11.

> I have nothing against this patch per se, mind. Just the whole
> premise that is behind this patch smells fishy to me and makes me
> think your software architecture that uses recursive dispatch is
> fundamentally broken.
> 
> Thanks, pq
> 

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

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

[Bill Spitzak]

On Mon, Feb 1, 2016 at 6:38 PM, Jason Gerecke  wrote:

>
> Ultimately, the tilt information is almost universally used by
> applications to set brush orientation. To do that, you have to use
> some trig to transform the X and Y tilt values into something like
> Alt-Az form. Tilt on a scale of 0-1 is fine for calculating the
> azimuth, but you can't calculate the altitude angle without knowing
> what 100% physically corresponds to. You can guess (e.g. assume it
> corresponds to the reasonable physical limit of +-90 degrees), get a
> horribly wrong answer (since the hardware limit is actually +-64
> degrees), and then either ignore the discrepancy or fudge other bits
> of the brush engine to not do nonsensical things. Actually, to be
> fair, that's exactly how GIMP does things right now :P
>

I think a lot of software treats the tilt information as actually the
position of a point some distance up the pen relative to the tip. I would
guess the hardware produces this directly (by reusing the proximity
hardware for a different point higher up in the pen). To get a projection
of the pen onto the tablet surface, these values can be fed to atan2.

If they were actual angles, they must be the angle of the projection of the
pen onto the two vertical planes of the x and y axis. This is really noisy
when the pen is near one of the axis, and I would think the hardware/driver
could not produce this except by calculating atan2 of a more linear value.

Therefore I would be very suspicious of any claim that the values being
produced are angles. The current api reporting them as normalized values
seems better.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Moving bugs to Phabricator

[Bill Spitzak]

Can you make a clone of the current Bugzilla state in Phabricator so that
we can see what it looks like?


On Tue, Feb 2, 2016 at 7:43 AM, Daniel Stone  wrote:

> Hi,
> As previously discussed with a few people (when it was much more in
> its infancy than now), I'd like to move our bug tracking from Bugzilla
> to Phabricator.
>
> There's a few reasons behind this. Phabricator is actually a pretty
> decent suite of utilities, including repository browsing and code
> review (Gerrit-style, including iterative revisions of patches,
> line-by-line comments, etc), and having our bugs in that would allow
> us better integration between the two. For instance, putting
> 'Maniphest Tasks: T1234' in a commit message when uploading a diff
> automatically links the commit and the bug, and similarly it also gets
> closed when pushing commits.
>
> We can push this out further as well, including automatically
> triggering CI from commits sent for review. I actually had this
> working last year (running distcheck for every commit), but am in the
> middle of rejigging my setup for a few things and haven't yet fixed
> that to happen again yet.
>
> Personally, just the improved UI (BZ is a nightmare) is enough for me,
> but in terms of what we can do with it in future, I think it's got a
> much better model than Bugzilla. The data store in Phabricator is very
> important to their upstream, and is sensible and extensible. Whilst
>
> We've had an instance at fd.o for a while, which has been used to
> varying degrees by projects such as PiTiVi, GStreamer, et al. Also, we
> use it internally for everything at Collabora, so the tree we maintain
> for use there also gets pushed to fd.o.
>
> In terms of what this would mean mechanically, we already have a
> fairly mature suite of scripts which have been used to do imports for
> quite a few projects. Using this would mirror all the Bugzilla bugs to
> Phabricator, add a link from the existing Bugzilla bugs to their
> replacements on Phabricator, and then redirect all new bug-filers to
> Phabricator. The import process also creates accounts for everyone, so
> once they'd recovered their passwords, so no data will be lost. It
> also ports attachments over.
>
> Beyond that, we can start using code review for it as and when people
> feel comfortable, particularly using git-phab, which submits patchsets
> to Phabricator for review. I'm probably most excited about getting
> review on there, though also fairly cautious; while Bugzilla is just
> trading one antiquated web tool which no-one uses for a nice modern
> one which equally few people will probably look at, review is a bigger
> part. Nonetheless, having things like concrete review approval status,
> line-by-line review separated from wider/conceptual review,
> at-a-glance review status, etc, I think is valuable enough that I
> think it's worth shifting things over at some point.
>
> Anyone have any thoughts/opinions/fears/encouragement?
>
> Cheers,
> Daniel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jason Gerecke]

On Tue, Feb 2, 2016 at 1:12 PM, Bill Spitzak  wrote:
>
>
> On Mon, Feb 1, 2016 at 6:38 PM, Jason Gerecke  wrote:
>>
>>
>> Ultimately, the tilt information is almost universally used by
>> applications to set brush orientation. To do that, you have to use
>> some trig to transform the X and Y tilt values into something like
>> Alt-Az form. Tilt on a scale of 0-1 is fine for calculating the
>> azimuth, but you can't calculate the altitude angle without knowing
>> what 100% physically corresponds to. You can guess (e.g. assume it
>> corresponds to the reasonable physical limit of +-90 degrees), get a
>> horribly wrong answer (since the hardware limit is actually +-64
>> degrees), and then either ignore the discrepancy or fudge other bits
>> of the brush engine to not do nonsensical things. Actually, to be
>> fair, that's exactly how GIMP does things right now :P
>
>
> I think a lot of software treats the tilt information as actually the
> position of a point some distance up the pen relative to the tip. I would

That's certainly true for GIMP and Krita at least (see [1] and [2]).
Its incorrect, but its "close enough" that nobody seems to complain
(though I've been tempted to in the past ;))

> guess the hardware produces this directly (by reusing the proximity hardware
> for a different point higher up in the pen). To get a projection of the pen
> onto the tablet surface, these values can be fed to atan2.
>
> If they were actual angles, they must be the angle of the projection of the
> pen onto the two vertical planes of the x and y axis. This is really noisy
> when the pen is near one of the axis, and I would think the hardware/driver
> could not produce this except by calculating atan2 of a more linear value.
>
> Therefore I would be very suspicious of any claim that the values being
> produced are angles. The current api reporting them as normalized values
> seems better.
>

I've been down this road before a few years back. Does the hardware
measure and report true angles or does it measure a projection? If its
a projection, does it report them directly, or does it calculate
sin^-1 to transform it into an angle?

In the end, the specs from the firmware guys say to interpret the data
as measured in degrees, so that's what we do.

[1]: https://git.gnome.org/browse/gimp/tree/app/core/gimpdynamicsoutput.c#n548
[2]: 
https://github.com/KDE/krita/blob/master/libs/image/brushengine/kis_paint_information.cc#L507

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput] tablet: change tilt axes to use degrees

[Peter Hutterer]

The Wacom tilt range is 64 degrees so we map everything into that until we
know otherwise.

This commit also switches the tilt axes around to align the angles with the
x/y orientation, i.e. tilting the top of the stylus towards the positive x
axis now generates a positive x tilt.

Signed-off-by: Peter Hutterer 
---
 doc/tablet-support.dox | 12 
 src/evdev-tablet.c | 28 +++
 src/libinput-private.h |  7 ++-
 src/libinput.h | 16 
 test/tablet.c  | 52 +-
 5 files changed, 72 insertions(+), 43 deletions(-)

diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
index cc5d409..ff4e460 100644
--- a/doc/tablet-support.dox
+++ b/doc/tablet-support.dox
@@ -83,15 +83,19 @@ additionally provide tilt information along the x and y 
axis.
 
 @image html tablet-axes.svg "Illustration of the distance, pressure and tilt 
axes"
 
-The granularity and precision of these axes varies between tablet devices
-and cannot usually be mapped into a physical unit.
-libinput normalizes distance and pressure into the [0, 1] range and the tilt
-axes into the [-1, 1] range with 0 as the neutral point.
+The granularity and precision of the distance and pressure axes varies
+between tablet devices and cannot usually be mapped into a physical unit.
+libinput normalizes distance and pressure into the [0, 1] range.
 
 While the normalization range is identical for these axes, a caller should
 not interpret identical values as identical across axes, i.e. a value v1 on
 the distance axis has no relation to the same value v1 on the pressure axis.
 
+The tilt axes provide the angle in degrees between a vertical line out of
+the tablet and the top of the stylus. The angle is measured along the x and
+y axis, respectively, a positive tilt angle thus means that the stylus' top
+is tilted towards the logical right and/or bottom of the tablet.
+
 @section tablet-fake-proximity Handling of proximity events
 
 libinput's @ref LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY events notify a caller
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index e684055..2157dfc 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -225,13 +225,25 @@ normalize_pressure(const struct input_absinfo *absinfo,
 }
 
 static inline double
-normalize_tilt(const struct input_absinfo *absinfo)
+adjust_tilt(const struct input_absinfo *absinfo)
 {
double range = absinfo->maximum - absinfo->minimum;
double value = (absinfo->value - absinfo->minimum) / range;
+   const int WACOM_MAX_DEGREES = 64;
 
/* Map to the (-1, 1) range */
-   return (value * 2) - 1;
+   value = (value * 2) - 1;
+
+   /* Wacom supports physical [-64, 64] degrees, so map to that by
+* default. If other tablets have a different physical range or
+* nonzero physical offsets, they need extra treatment
+* here.
+*
+* And invert because we flip the axes to align with the x/y
+* positive direction.
+*/
+
+   return value * WACOM_MAX_DEGREES  * -1;
 }
 
 static inline int32_t
@@ -251,8 +263,8 @@ convert_tilt_to_rotation(struct tablet_dispatch *tablet)
   values. The device has a 175 degree CCW hardware offset but since we 
use
   atan2 the effective offset is just 5 degrees.
   */
-   x = tablet->axes.tilt.x;
-   y = tablet->axes.tilt.y;
+   x = -tablet->axes.tilt.x;
+   y = -tablet->axes.tilt.y;
clear_bit(tablet->changed_axes, LIBINPUT_TABLET_TOOL_AXIS_TILT_X);
clear_bit(tablet->changed_axes, LIBINPUT_TABLET_TOOL_AXIS_TILT_Y);
 
@@ -398,17 +410,17 @@ tablet_handle_slider(struct tablet_dispatch *tablet,
return tablet->axes.slider;
 }
 
-static inline struct normalized_range_coords
+static inline struct tilt_degrees
 tablet_handle_tilt(struct tablet_dispatch *tablet,
   struct evdev_device *device)
 {
-   struct normalized_range_coords tilt;
+   struct tilt_degrees tilt;
const struct input_absinfo *absinfo;
 
if (bit_is_set(tablet->changed_axes,
   LIBINPUT_TABLET_TOOL_AXIS_TILT_X)) {
absinfo = libevdev_get_abs_info(device->evdev, ABS_TILT_X);
-   tablet->axes.tilt.x = normalize_tilt(absinfo);
+   tablet->axes.tilt.x = adjust_tilt(absinfo);
if (device->left_handed.enabled)
tablet->axes.tilt.x *= -1;
}
@@ -417,7 +429,7 @@ tablet_handle_tilt(struct tablet_dispatch *tablet,
if (bit_is_set(tablet->changed_axes,
   LIBINPUT_TABLET_TOOL_AXIS_TILT_Y)) {
absinfo = libevdev_get_abs_info(device->evdev, ABS_TILT_Y);
-   tablet->axes.tilt.y = normalize_tilt(absinfo);
+   tablet->axes.tilt.y = adjust_tilt(absinfo);
if (device->left_handed.enabled)

[PATCH] egl: move Null check to eglGetSyncAttribKHR to prevent Segfault

[Dongwon Kim]

Null-check on "*value" is currently done in
_eglGetSyncAttrib, which is after eglGetSyncAttribKHR
attempts to copy data at 'value' to 'attrib'. Segfault
is enevitable if value==NULL in this case. Therefore,
null-check should be moved to beginning of
eglGetSyncAttribKHR to avoid any possible segfaults.

Signed-off-by: Dongwon Kim 
---
 src/egl/main/eglapi.c  | 10 --
 src/egl/main/eglsync.c |  3 ---
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 323634e..32f6823 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -1555,8 +1555,14 @@ eglGetSyncAttrib(EGLDisplay dpy, EGLSync sync, EGLint 
attribute, EGLAttrib *valu
 static EGLBoolean EGLAPIENTRY
 eglGetSyncAttribKHR(EGLDisplay dpy, EGLSync sync, EGLint attribute, EGLint 
*value)
 {
-   EGLAttrib attrib = *value;
-   EGLBoolean result = eglGetSyncAttrib(dpy, sync, attribute, );
+   EGLAttrib attrib;
+   EGLBoolean result;
+
+   if (!value)
+  RETURN_EGL_ERROR(NULL, EGL_BAD_PARAMETER, EGL_FALSE);
+
+   attrib = *value;
+   result = eglGetSyncAttrib(dpy, sync, attribute, );
 
/* The EGL_KHR_fence_sync spec says this about eglGetSyncAttribKHR:
 *
diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c
index 3019e6e..999cb48 100644
--- a/src/egl/main/eglsync.c
+++ b/src/egl/main/eglsync.c
@@ -144,9 +144,6 @@ EGLBoolean
 _eglGetSyncAttrib(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSync *sync,
   EGLint attribute, EGLAttrib *value)
 {
-   if (!value)
-  return _eglError(EGL_BAD_PARAMETER, "eglGetSyncAttribKHR");
-
switch (attribute) {
case EGL_SYNC_TYPE_KHR:
   *value = sync->Type;
-- 
1.9.1

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

[ANNOUNCE] weston 1.9.92

[Bryce Harrington]

This is the beta for the 1.10 release.  This includes a handful of bug
fixes beyond the 1.9.91 alpha: Structures used for Xwayland clipboard
sources are initialized properly.  Touchscreens that send coordinates
outside the nominal maximum X/Y coordinates no longer cause a crash.
Clients that don't grab mouse focus no longer cause a crash when mousing
into them.


As mentioned in the release notes announcing the alpha, the 1.10 release
adds support into Weston for a number of recently added Wayland
protocols.  This includes the new drag and drop actions, new frame and
axis events, and buffer co-ordinates for surface damage.

A V4L2 (Video for Linux 2) client is now included for demonstrating a
way to retrieve video frames from V4L2 devices as dmabuf.  YUV dmabuf
formats are also supported now.

The IVI shell improves its multi screen functionality, and now supports
a variety of modes including side-by-side, fullscreen, tiled, and
random.

Touch input support is added.

Various configuration options in weston.ini have been added to make it
easier to use and do testing with Weston.  "vt-switching"
enables/disables Ctrl-Alt-fn key combos.  "allow-zap" enables/disables
Ctrl-Alt-Backspace from killing the server.

systemd notification support can be enabled by the
--enable-systemd-notify configuration flag.  This permits for instance
establishing a watchdog that can restart weston if it crashes.

Weston now requires the recently created wayland-protocols package to be
installed.  wayland-protocols provides a collection of proposed,
experimental, and/or unstable protocols for use with Wayland.  These
used to be included in Weston, but were split out to make it easier for
other compositor implementations to contribute to and track them,
without needing a dependency on Weston or needing to provide a Weston
reference implementation before they can be shared.

There's probably many more features included which I've overlooked.  Of
course, this release also brings the usual heap of bug fixes, leak
plugging, code refactoring, documentation, and test improvements.


Changes since 1.9.91:
-

Bryce Harrington (3):
  releasing: register_release now inserts the email announcement urls
  input: Fix crash when touchscreen generates out of screen coordinate
  configure.ac: bump to version 1.9.92 for the beta release

Carlos Garnacho (3):
  clipboard: zalloc the clipboard_source
  xwayland: zalloc the x11_data_sources
  data-device: Check harder for selection/non-wayland sources

Derek Foreman (1):
  input: Don't try to send pointer frames if no focus_client

For the full set of changes since 1.9.0 was released, please see the
1.9.91 release note.


git tag: 1.9.92
http://wayland.freedesktop.org/releases/weston-1.9.92.tar.xz
MD5:  baa5d7dd5a919bac9b08224490c21798  weston-1.9.92.tar.xz
SHA1: 17d94a667b08f1754ac28e8ce0952c7336a2ac7a  weston-1.9.92.tar.xz
SHA256: 0b2322a0b9cf9fdb9c1ba3bfaf513f57d7dae92b4cf6a510ce1584d63119fa6a  
weston-1.9.92.tar.xz
PGP:  http://wayland.freedesktop.org/releases/weston-1.9.92.tar.xz.sig



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

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

diff --git a/src/libinput-device.c b/src/libinput-device.c
index be41091..31ce786 100644
--- a/src/libinput-device.c
+++ b/src/libinput-device.c
@@ -429,6 +429,114 @@ handle_tablet_proximity(struct libinput_device 
*libinput_device,
notify_tablet_tool_frame(tool, time);
 }
 
+static void
+handle_tablet_axis(struct libinput_device *libinput_device,
+  struct libinput_event_tablet_tool *axis_event)
+{
+   struct evdev_device *device =
+   libinput_device_get_user_data(libinput_device);
+   struct weston_tablet_tool *tool;
+   struct weston_tablet *tablet = device->tablet;
+   struct libinput_tablet_tool *libinput_tool;
+   uint32_t time;
+   const int NORMALIZED_AXIS_MAX = 65535;
+
+   libinput_tool = libinput_event_tablet_tool_get_tool(axis_event);
+   tool = libinput_tablet_tool_get_user_data(libinput_tool);
+   time = libinput_event_tablet_tool_get_time(axis_event);
+
+   if (libinput_event_tablet_tool_x_has_changed(axis_event) ||
+   libinput_event_tablet_tool_y_has_changed(axis_event)) {
+   double x, y;
+   uint32_t width, height;
+
+   width = tablet->output->current_mode->width;
+   height = tablet->output->current_mode->height;
+   x = libinput_event_tablet_tool_get_x_transformed(axis_event,
+width);
+   y = libinput_event_tablet_tool_get_y_transformed(axis_event,
+height);
+
+   notify_tablet_tool_motion(tool, time,
+ wl_fixed_from_double(x),
+ wl_fixed_from_double(y));
+   }
+
+   if (libinput_event_tablet_tool_pressure_has_changed(axis_event)) {
+   double pressure;
+
+   pressure = libinput_event_tablet_tool_get_pressure(axis_event);
+   /* convert axis range [0.0, 1.0] to [0, 65535] */
+   pressure *= NORMALIZED_AXIS_MAX;
+   notify_tablet_tool_pressure(tool, time, pressure);
+   }
+
+   if (libinput_event_tablet_tool_distance_has_changed(axis_event)) {
+   double distance;
+
+   distance = libinput_event_tablet_tool_get_distance(axis_event);
+   /* convert axis range [0.0, 1.0] to [0, 65535] */
+   distance *= NORMALIZED_AXIS_MAX;
+   notify_tablet_tool_distance(tool, time, distance);
+   }
+
+   if (libinput_event_tablet_tool_tilt_x_has_changed(axis_event) ||
+   libinput_event_tablet_tool_tilt_y_has_changed(axis_event)) {
+   double tx, ty;
+
+   tx = libinput_event_tablet_tool_get_tilt_x(axis_event);
+   ty = libinput_event_tablet_tool_get_tilt_y(axis_event);
+   /* convert axis range [-1.0, 1.0] to [-65535, 65535] */
+   tx *= NORMALIZED_AXIS_MAX;
+   ty *= NORMALIZED_AXIS_MAX;
+   notify_tablet_tool_tilt(tool, time, tx, ty);
+   }
+
+   notify_tablet_tool_frame(tool, time);
+}
+
+static void
+handle_tablet_tip(struct libinput_device *libinput_device,
+ struct libinput_event_tablet_tool *tip_event)
+{
+   struct weston_tablet_tool *tool;
+   struct libinput_tablet_tool *libinput_tool;
+   uint32_t time;
+
+   libinput_tool = libinput_event_tablet_tool_get_tool(tip_event);
+   tool = libinput_tablet_tool_get_user_data(libinput_tool);
+   time = libinput_event_tablet_tool_get_time(tip_event);
+
+   if (libinput_event_tablet_tool_get_tip_state(tip_event) ==
+   LIBINPUT_TABLET_TOOL_TIP_DOWN)
+   notify_tablet_tool_down(tool, time);
+   else
+   notify_tablet_tool_up(tool, time);
+}
+
+
+static void
+handle_tablet_button(struct libinput_device *libinput_device,
+struct libinput_event_tablet_tool *button_event)
+{
+   struct weston_tablet_tool *tool;
+   struct libinput_tablet_tool *libinput_tool;
+   uint32_t time, button;
+   enum zwp_tablet_tool_v1_button_state state;
+
+   libinput_tool = libinput_event_tablet_tool_get_tool(button_event);
+   tool = libinput_tablet_tool_get_user_data(libinput_tool);
+   time = libinput_event_tablet_tool_get_time(button_event);
+   button = libinput_event_tablet_tool_get_button(button_event);
+   if (libinput_event_tablet_tool_get_button_state(button_event) ==
+   LIBINPUT_BUTTON_STATE_PRESSED)
+   state = ZWP_TABLET_TOOL_V1_BUTTON_STATE_PRESSED;
+ 

[PATCH v2 weston 00/13] Add tablet support

[Peter Hutterer]

Next version of the tablet support patches for weston. This set has been
updated for the libinput API that had a few changes since November and for
the protocol changes.

The segfaults on unplug are now fixed, caused by a erroneous cleanup code
that ended up trying to clean up twice.

It has the new axes for slider, z-rotation, etc. in the client bindings but
they're not hooked up in the compositor. The overlap between people running
weston and using custom wacom styluses is quite small.

Branch available here:
http://github.com/whot/weston/tree/tablet-support-v4

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

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

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

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

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

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
Changes since v1:
- fixed freeing of tablets and tools, previous version caused the occasional
  segfault when a client released the resource. Split now into unlinking the
  tablet (during destroy) and actual freeing (during resource cleanup)
- shared code for initialization of tablets/tools, was duplicated before

 Makefile.am   |  13 +-
 configure.ac  |   2 +-
 src/compositor.c  |   1 +
 src/compositor.h  |  98 
 src/input.c   | 416 ++
 src/libinput-device.c | 187 +++
 src/libinput-device.h |   4 +-
 7 files changed, 716 insertions(+), 5 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 623621d..d5b4aae 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -126,7 +126,9 @@ nodist_weston_SOURCES = 
\
protocol/scaler-protocol.c  \
protocol/scaler-server-protocol.h   \
protocol/linux-dmabuf-unstable-v1-protocol.c\
-   protocol/linux-dmabuf-unstable-v1-server-protocol.h
+   protocol/linux-dmabuf-unstable-v1-server-protocol.h \
+   protocol/tablet-unstable-v1-protocol.c  \
+   protocol/tablet-unstable-v1-server-protocol.h
 
 BUILT_SOURCES += $(nodist_weston_SOURCES)
 
@@ -570,7 +572,9 @@ nodist_libtoytoolkit_la_SOURCES =   \
protocol/xdg-shell-unstable-v5-protocol.c   \
protocol/xdg-shell-unstable-v5-client-protocol.h\
protocol/ivi-application-protocol.c \
-   protocol/ivi-application-client-protocol.h
+   protocol/ivi-application-client-protocol.h  \
+   protocol/tablet-unstable-v1-protocol.c  \
+   protocol/tablet-unstable-v1-client-protocol.h
 
 BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES)
 
@@ -779,7 +783,10 @@ BUILT_SOURCES +=   \
protocol/ivi-hmi-controller-protocol.c  \
protocol/ivi-hmi-controller-client-protocol.h   \
protocol/ivi-application-protocol.c \
-   protocol/ivi-application-client-protocol.h
+   protocol/ivi-application-client-protocol.h  \
+   protocol/tablet-unstable-v1-protocol.c  \
+   protocol/tablet-unstable-v1-client-protocol.h
+
 
 westondatadir = $(datadir)/weston
 dist_westondata_DATA = \
diff --git a/configure.ac b/configure.ac
index 107c155..e45d74c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -178,7 +178,7 @@ if test x$enable_drm_compositor = xyes; then
 fi
 
 
-PKG_CHECK_MODULES(LIBINPUT_BACKEND, [libinput >= 0.8.0])
+PKG_CHECK_MODULES(LIBINPUT_BACKEND, [libinput >= 1.1.901])
 PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])
 
 PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, [wayland-protocols >= 1.0],
diff --git a/src/compositor.c b/src/compositor.c
index 98efb4c..cbdb14c 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4769,6 +4769,7 @@ weston_compositor_create(struct wl_display *display, void 
*user_data)
wl_list_init(>touch_binding_list);
wl_list_init(>axis_binding_list);
wl_list_init(>debug_binding_list);
+   wl_list_init(>tablet_manager_resource_list);
 
weston_plane_init(>primary_plane, ec, 0, 0);
weston_compositor_stack_plane(ec, >primary_plane, NULL);
diff --git a/src/compositor.h b/src/compositor.h
index 58ae94b..3c67ffe 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -38,6 +38,7 @@ extern "C" {
 
 #define WL_HIDE_DEPRECATED
 #include 
+#include 
 
 #include "version.h"
 #include "matrix.h"
@@ -404,6 +405,34 @@ struct weston_touch {
uint32_t grab_time;
 };
 
+struct weston_tablet_tool {
+   struct weston_seat *seat;
+   enum zwp_tablet_tool_v1_type type;
+
+   struct wl_list resource_list;
+
+   struct wl_list link;
+
+   uint64_t serial;
+   uint64_t hwid;
+   uint32_t capabilities;
+};
+
+struct weston_tablet {
+   struct weston_seat *seat;
+   struct evdev_device *device;
+
+   struct wl_list resource_list;
+
+   struct wl_list link;
+
+   char *name;
+   uint32_t vid;
+   uint32_t pid;
+   const char *path;
+   struct weston_output 

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

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

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

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

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

Co-authored-by: Peter Hutterer 
Signed-off-by: Stephen Chandler Paul 
Signed-off-by: Peter Hutterer 
---
 src/compositor.h  |  8 
 src/input.c   | 33 +++--
 src/libinput-device.c | 41 +
 3 files changed, 76 insertions(+), 6 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index bd6af4d..c6f5f07 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -483,6 +483,13 @@ struct weston_tablet_tool {
wl_fixed_t grab_x, grab_y;
 };
 
+struct weston_tablet_tool_id {
+   struct wl_list link;
+
+   enum zwp_tablet_tool_v1_type type;
+   uint64_t serial;
+};
+
 struct weston_tablet {
struct weston_seat *seat;
struct evdev_device *device;
@@ -490,6 +497,7 @@ struct weston_tablet {
struct wl_list resource_list;
 
struct wl_list link;
+   struct wl_list tool_id_list;
 
char *name;
uint32_t vid;
diff --git a/src/input.c b/src/input.c
index 11ed0c4..03b5a9f 100644
--- a/src/input.c
+++ b/src/input.c
@@ -869,6 +869,7 @@ weston_tablet_create(void)
return NULL;
 
wl_list_init(>resource_list);
+   wl_list_init(>tool_id_list);
 
return tablet;
 }
@@ -877,11 +878,41 @@ WL_EXPORT void
 weston_tablet_destroy(struct weston_tablet *tablet)
 {
struct wl_resource *resource;
+   struct weston_tablet *t;
+   struct weston_tablet_tool *tool, *tmptool;
+   struct weston_tablet_tool_id *id, *tmpid;
 
wl_resource_for_each(resource, >resource_list)
zwp_tablet_v1_send_removed(resource);
 
+   /* First drop all tool ids from this tablet */
+   wl_list_for_each_safe(id, tmpid, >tool_id_list, link) {
+   wl_list_remove(>link);
+   free(id);
+   }
+
+   /* Remove the tablet from the list */
wl_list_remove(>link);
+
+   /* For each tool, check remaining tablets for the stored ID list. If we
+* can't find this tool anywhere, we can drop it */
+   wl_list_for_each_safe(tool, tmptool,
+ >seat->tablet_tool_list, link) {
+   bool remove_tool = true;
+
+   wl_list_for_each(t, >seat->tablet_list, link) {
+   wl_list_for_each(id, >tool_id_list, link) {
+   if (tool->type == id->type &&
+   tool->serial == id->serial) {
+   remove_tool = false;
+   break;
+   }
+   }
+   }
+
+   if (remove_tool)
+   weston_seat_release_tablet_tool(tool);
+   }
 }
 
 WL_EXPORT void
@@ -3394,8 +3425,6 @@ weston_seat_release_pointer(struct weston_seat *seat)
 WL_EXPORT void
 weston_seat_release_tablet_tool(struct weston_tablet_tool *tool)
 {
-   /* FIXME: nothing is calling this function yet, tools are only
-  released on shutdown when the seat goes away */
wl_signal_emit(>removed_signal, tool);
 
weston_tablet_tool_destroy(tool);
diff --git a/src/libinput-device.c b/src/libinput-device.c
index 31ce786..729825b 100644
--- a/src/libinput-device.c
+++ b/src/libinput-device.c
@@ -363,6 +363,7 @@ handle_tablet_proximity(struct libinput_device 
*libinput_device,
struct evdev_device *device;
struct weston_tablet *tablet;
struct weston_tablet_tool *tool;
+   struct weston_tablet_tool_id *id;
struct libinput_tablet_tool *libinput_tool;
enum libinput_tablet_tool_type libinput_tool_type;
uint32_t serial, type;
@@ -397,10 +398,12 @@ handle_tablet_proximity(struct libinput_device 
*libinput_device,
return;
}
 
-   wl_list_for_each(tool, >seat->tablet_tool_list, link) {
-   if (tool->serial == serial && tool->type == type) {
-   create = false;
-   break;
+   if (serial) {
+   wl_list_for_each(tool, >seat->tablet_tool_list, link) {
+   if (tool->serial == serial && tool->type == type) {
+   create = false;
+   break;
+   }
}
}
 
@@ -419,11 +422,41 @@ handle_tablet_proximity(struct libinput_device 
*libinput_device,
tool->capabilities |= 1 << 
ZWP_TABLET_TOOL_V1_CAPABILITY_TILT;
 
wl_list_insert(>seat->tablet_tool_list, >link);
+
+   id = zalloc(sizeof *id);
+   if (id) {
+   id->type = tool->type;
+   

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

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

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

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

diff --git a/clients/window.c b/clients/window.c
index 35261b6..37c703b 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -70,6 +70,7 @@ typedef void *EGLContext;
 #include "shared/helpers.h"
 #include "xdg-shell-unstable-v5-client-protocol.h"
 #include "text-cursor-position-client-protocol.h"
+#include "tablet-unstable-v1-client-protocol.h"
 #include "shared/os-compatibility.h"
 
 #include "window.h"
@@ -96,6 +97,7 @@ struct display {
struct wl_data_device_manager *data_device_manager;
struct text_cursor_position *text_cursor_position;
struct xdg_shell *xdg_shell;
+   struct zwp_tablet_manager_v1 *tablet_manager;
struct ivi_application *ivi_application; /* ivi style shell */
EGLDisplay dpy;
EGLConfig argb_config;
@@ -138,6 +140,33 @@ struct display {
int data_device_manager_version;
 };
 
+struct tablet {
+   struct zwp_tablet_v1 *tablet;
+   char *name;
+   int32_t vid;
+   int32_t pid;
+
+   void *user_data;
+
+   struct wl_list link;
+};
+
+struct tablet_tool {
+   struct zwp_tablet_tool_v1 *tool;
+   struct input *input;
+   void *user_data;
+   struct wl_list link;
+   struct tablet *current_tablet;
+   struct window *focus;
+   struct widget *focus_widget;
+
+   enum zwp_tablet_tool_v1_type type;
+   uint64_t serial;
+   uint64_t hwid;
+
+   double sx, sy;
+};
+
 struct window_output {
struct output *output;
struct wl_list link;
@@ -286,6 +315,19 @@ struct widget {
widget_axis_source_handler_t axis_source_handler;
widget_axis_stop_handler_t axis_stop_handler;
widget_axis_discrete_handler_t axis_discrete_handler;
+   widget_tablet_tool_motion_handler_t tablet_tool_motion_handler;
+   widget_tablet_tool_up_handler_t tablet_tool_up_handler;
+   widget_tablet_tool_down_handler_t tablet_tool_down_handler;
+   widget_tablet_tool_pressure_handler_t tablet_tool_pressure_handler;
+   widget_tablet_tool_distance_handler_t tablet_tool_distance_handler;
+   widget_tablet_tool_tilt_handler_t tablet_tool_tilt_handler;
+   widget_tablet_tool_rotation_handler_t tablet_tool_rotation_handler;
+   widget_tablet_tool_slider_handler_t tablet_tool_slider_handler;
+   widget_tablet_tool_wheel_handler_t tablet_tool_wheel_handler;
+   widget_tablet_tool_proximity_in_handler_t tablet_tool_prox_in_handler;
+   widget_tablet_tool_proximity_out_handler_t tablet_tool_prox_out_handler;
+   widget_tablet_tool_button_handler_t tablet_tool_button_handler;
+   widget_tablet_tool_frame_handler_t tablet_tool_frame_handler;
void *user_data;
int opaque;
int tooltip_count;
@@ -361,6 +403,10 @@ struct input {
uint32_t repeat_key;
uint32_t repeat_time;
int seat_version;
+
+   struct zwp_tablet_seat_v1 *tablet_seat;
+   struct wl_list tablet_list;
+   struct wl_list tablet_tool_list;
 };
 
 struct output {
@@ -1970,6 +2016,62 @@ widget_set_axis_handlers(struct widget *widget,
widget->axis_discrete_handler = axis_discrete_handler;
 }
 
+void
+widget_set_tablet_tool_axis_handlers(struct widget *widget,
+widget_tablet_tool_motion_handler_t motion,
+widget_tablet_tool_pressure_handler_t 
pressure,
+widget_tablet_tool_distance_handler_t 
distance,
+widget_tablet_tool_tilt_handler_t tilt,
+widget_tablet_tool_rotation_handler_t 
rotation,
+widget_tablet_tool_slider_handler_t slider,
+widget_tablet_tool_wheel_handler_t wheel)
+{
+   widget->tablet_tool_motion_handler = motion;
+   widget->tablet_tool_pressure_handler = pressure;
+   widget->tablet_tool_distance_handler = distance;
+   widget->tablet_tool_tilt_handler = tilt;
+   widget->tablet_tool_rotation_handler = rotation;
+   widget->tablet_tool_slider_handler = slider;
+   widget->tablet_tool_wheel_handler = wheel;
+}
+
+void
+widget_set_tablet_tool_up_handler(struct widget *widget,
+ widget_tablet_tool_up_handler_t handler)
+{
+   widget->tablet_tool_up_handler = handler;
+}
+
+void
+widget_set_tablet_tool_down_handler(struct widget *widget,
+   widget_tablet_tool_down_handler_t handler)
+{
+   widget->tablet_tool_down_handler = handler;
+}
+
+void

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

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

diff --git a/src/compositor.c b/src/compositor.c
index cbdb14c..f419818 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1866,6 +1866,7 @@ weston_view_unmap(struct weston_view *view)
struct weston_pointer *pointer = weston_seat_get_pointer(seat);
struct weston_keyboard *keyboard =
weston_seat_get_keyboard(seat);
+   struct weston_tablet_tool *tool;
 
if (keyboard && keyboard->focus == view->surface)
weston_keyboard_set_focus(keyboard, NULL);
@@ -1873,6 +1874,11 @@ weston_view_unmap(struct weston_view *view)
weston_pointer_clear_focus(pointer);
if (touch && touch->focus == view)
weston_touch_set_focus(touch, NULL);
+
+   wl_list_for_each(tool, >tablet_tool_list, link) {
+   if (tool->focus == view)
+   weston_tablet_tool_set_focus(tool, NULL, 0);
+   }
}
 }
 
diff --git a/src/compositor.h b/src/compositor.h
index 784a70d..7960325 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -470,6 +470,12 @@ struct weston_tablet_tool {
 
int button_count;
bool tip_is_down;
+
+   int32_t hotspot_x, hotspot_y;
+   struct weston_view *sprite;
+   struct wl_listener sprite_destroy_listener;
+
+   wl_fixed_t x, y;
 };
 
 struct weston_tablet {
@@ -580,6 +586,13 @@ void
 weston_tablet_tool_end_grab(struct weston_tablet_tool *tool);
 
 void
+weston_tablet_tool_clamp(struct weston_tablet_tool *tool,
+wl_fixed_t *fx, wl_fixed_t *fy);
+void
+weston_tablet_tool_cursor_move(struct weston_tablet_tool *tool,
+  wl_fixed_t x, wl_fixed_t y);
+
+void
 wl_data_device_set_keyboard_focus(struct weston_seat *seat);
 
 int
diff --git a/src/input.c b/src/input.c
index 006ab5a..fc74856 100644
--- a/src/input.c
+++ b/src/input.c
@@ -974,7 +974,13 @@ static void
 default_grab_tablet_tool_proximity_out(struct weston_tablet_tool_grab *grab,
   uint32_t time)
 {
-   weston_tablet_tool_set_focus(grab->tool, NULL, time);
+   struct weston_tablet_tool *tool = grab->tool;
+
+   weston_tablet_tool_set_focus(tool, NULL, time);
+
+   /* Hide the cursor */
+   if (weston_surface_is_mapped(tool->sprite->surface))
+   weston_surface_unmap(tool->sprite->surface);
 }
 
 static void
@@ -989,6 +995,8 @@ default_grab_tablet_tool_motion(struct 
weston_tablet_tool_grab *grab,
struct wl_resource *resource;
struct wl_list *resource_list = >focus_resource_list;
 
+   weston_tablet_tool_cursor_move(tool, x, y);
+
current_view = weston_compositor_pick_view(tool->seat->compositor,
   x, y, , );
if (current_view != tool->focus)
@@ -1126,6 +1134,29 @@ static struct weston_tablet_tool_grab_interface 
default_tablet_tool_grab_interfa
default_grab_tablet_tool_cancel,
 };
 
+static void
+tablet_tool_unmap_sprite(struct weston_tablet_tool *tool)
+{
+   if (weston_surface_is_mapped(tool->sprite->surface))
+   weston_surface_unmap(tool->sprite->surface);
+
+   wl_list_remove(>sprite_destroy_listener.link);
+   tool->sprite->surface->configure = NULL;
+   tool->sprite->surface->configure_private = NULL;
+   weston_view_destroy(tool->sprite);
+   tool->sprite = NULL;
+}
+
+static void
+tablet_tool_handle_sprite_destroy(struct wl_listener *listener, void *data)
+{
+   struct weston_tablet_tool *tool =
+   container_of(listener, struct weston_tablet_tool,
+sprite_destroy_listener);
+
+   tool->sprite = NULL;
+}
+
 WL_EXPORT struct weston_tablet_tool *
 weston_tablet_tool_create(void)
 {
@@ -1138,6 +1169,9 @@ weston_tablet_tool_create(void)
wl_list_init(>resource_list);
wl_list_init(>focus_resource_list);
 
+   wl_list_init(>sprite_destroy_listener.link);
+   tool->sprite_destroy_listener.notify = 
tablet_tool_handle_sprite_destroy;
+
wl_list_init(>focus_view_listener.link);
tool->focus_view_listener.notify = tablet_tool_focus_view_destroyed;
 
@@ -1156,12 +1190,57 @@ weston_tablet_tool_destroy(struct weston_tablet_tool 
*tool)
 {
   

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

diff --git a/src/compositor.h b/src/compositor.h
index c1f3cc4..784a70d 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -318,6 +318,47 @@ struct weston_touch_grab {
struct weston_touch *touch;
 };
 
+struct weston_tablet;
+struct weston_tablet_tool;
+struct weston_tablet_tool_grab;
+struct weston_tablet_tool_grab_interface {
+   void (*proximity_in)(struct weston_tablet_tool_grab *grab,
+uint32_t time,
+struct weston_tablet *tablet);
+   void (*proximity_out)(struct weston_tablet_tool_grab *grab,
+uint32_t time);
+   void (*motion)(struct weston_tablet_tool_grab *grab,
+  uint32_t time,
+  wl_fixed_t x,
+  wl_fixed_t y);
+   void (*down)(struct weston_tablet_tool_grab *grab,
+uint32_t time);
+   void (*up)(struct weston_tablet_tool_grab *grab,
+  uint32_t time);
+   void (*pressure)(struct weston_tablet_tool_grab *grab,
+uint32_t time,
+uint32_t pressure);
+   void (*distance)(struct weston_tablet_tool_grab *grab,
+uint32_t time,
+uint32_t distance);
+   void (*tilt)(struct weston_tablet_tool_grab *grab,
+uint32_t time,
+int32_t tilt_x,
+int32_t tilt_y);
+   void (*button)(struct weston_tablet_tool_grab *grab,
+  uint32_t time,
+  uint32_t button,
+  enum zwp_tablet_tool_v1_button_state state);
+   void (*frame)(struct weston_tablet_tool_grab *grab,
+ uint32_t time);
+   void (*cancel)(struct weston_tablet_tool_grab *grab);
+};
+
+struct weston_tablet_tool_grab {
+   const struct weston_tablet_tool_grab_interface *interface;
+   struct weston_tablet_tool *tool;
+};
+
 struct weston_data_offer {
struct wl_resource *resource;
struct weston_data_source *source;
@@ -416,12 +457,19 @@ struct weston_tablet_tool {
struct wl_listener focus_view_listener;
struct wl_listener focus_resource_listener;
uint32_t focus_serial;
+   uint32_t grab_serial;
 
struct wl_list link;
 
uint64_t serial;
uint64_t hwid;
uint32_t capabilities;
+
+   struct weston_tablet_tool_grab *grab;
+   struct weston_tablet_tool_grab default_grab;
+
+   int button_count;
+   bool tip_is_down;
 };
 
 struct weston_tablet {
@@ -525,6 +573,11 @@ void
 weston_tablet_tool_set_focus(struct weston_tablet_tool *tool,
 struct weston_view *view,
 uint32_t time);
+void
+weston_tablet_tool_start_grab(struct weston_tablet_tool *tool,
+ struct weston_tablet_tool_grab *grab);
+void
+weston_tablet_tool_end_grab(struct weston_tablet_tool *tool);
 
 void
 wl_data_device_set_keyboard_focus(struct weston_seat *seat);
diff --git a/src/input.c b/src/input.c
index f835cf4..006ab5a 100644
--- a/src/input.c
+++ b/src/input.c
@@ -895,6 +895,9 @@ weston_tablet_tool_set_focus(struct weston_tablet_tool 
*tool,
focus_resource_list = >focus_resource_list;
if (tool->focus && !wl_list_empty(focus_resource_list)) {
wl_resource_for_each(resource, focus_resource_list) {
+   if (tool->tip_is_down)
+   zwp_tablet_tool_v1_send_up(resource);
+
zwp_tablet_tool_v1_send_proximity_out(resource);
zwp_tablet_tool_v1_send_frame(resource, time);
}
@@ -919,6 +922,11 @@ weston_tablet_tool_set_focus(struct weston_tablet_tool 
*tool,
 
zwp_tablet_tool_v1_send_proximity_in(resource, 
tool->focus_serial,
   tr, 
view->surface->resource);
+
+   if (tool->tip_is_down)
+   zwp_tablet_tool_v1_send_down(resource,
+  tool->focus_serial);
+
zwp_tablet_tool_v1_send_frame(resource, time);
}
}
@@ -938,6 +946,186 @@ weston_tablet_tool_set_focus(struct weston_tablet_tool 
*tool,
tool->focus_view_listener.notify = tablet_tool_focus_view_destroyed;
 }
 
+WL_EXPORT void
+weston_tablet_tool_start_grab(struct weston_tablet_tool *tool,
+ struct weston_tablet_tool_grab *grab)
+{
+   

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

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

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

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

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

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

diff --git a/.gitignore b/.gitignore
index dfbb4d3..ebbc96c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -75,6 +75,7 @@ weston-simple-damage
 weston-smoke
 weston-stacking
 weston-subsurfaces
+weston-tablet
 weston-transformed
 weston-view
 
diff --git a/Makefile.am b/Makefile.am
index d5b4aae..d26ebd0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -469,7 +469,8 @@ demo_clients += \
weston-simple-damage\
weston-simple-touch \
weston-presentation-shm \
-   weston-multi-resource
+   weston-multi-resource   \
+   weston-tablet
 
 weston_simple_shm_SOURCES = clients/simple-shm.c
 nodist_weston_simple_shm_SOURCES = \
@@ -632,6 +633,10 @@ weston_scaler_SOURCES = clients/scaler.c
 weston_scaler_LDADD = libtoytoolkit.la
 weston_scaler_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
 
+weston_tablet_SOURCES = clients/tablet.c
+weston_tablet_LDADD = libtoytoolkit.la
+weston_tablet_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
+
 if HAVE_CAIRO_GLESV2
 demo_clients += weston-nested weston-nested-client
 
diff --git a/clients/tablet.c b/clients/tablet.c
new file mode 100644
index 000..e6d314d
--- /dev/null
+++ b/clients/tablet.c
@@ -0,0 +1,254 @@
+/*
+ * Copyright © 2014 Lyude
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission.  The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose.  It is provided "as is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE
+ */
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "window.h"
+#include "tablet-unstable-v1-client-protocol.h"
+
+struct display *display;
+struct window *window;
+struct widget *widget;
+
+cairo_surface_t *draw_buffer;
+
+int old_x, old_y;
+int current_x, current_y;
+enum zwp_tablet_tool_v1_type tool_type;
+
+bool tablet_is_down;
+
+double current_pressure;
+
+#define WL_TABLET_AXIS_MAX 65535
+
+static void
+redraw_handler(struct widget *widget, void *data)
+{
+   cairo_surface_t *surface;
+   cairo_t *window_cr, *drawing_cr;
+   struct rectangle allocation;
+
+   widget_get_allocation(widget, );
+
+   surface = window_get_surface(window);
+
+   /* Setup the background */
+   window_cr = cairo_create(surface);
+   cairo_set_operator(window_cr, CAIRO_OPERATOR_SOURCE);
+   cairo_rectangle(window_cr,
+   allocation.x,
+   allocation.y,
+   allocation.width,
+   allocation.height);
+   cairo_set_source_rgba(window_cr, 0, 0, 0, 0.8);
+   cairo_fill(window_cr);
+
+   /* Update the drawing buffer */
+   if (tablet_is_down) {
+   if (old_x != -1 && old_y != -1) {
+   drawing_cr = cairo_create(draw_buffer);
+   if (tool_type == ZWP_TABLET_TOOL_V1_TYPE_PEN) {
+   cairo_set_source_rgb(drawing_cr, 1, 1, 1);
+   cairo_set_line_width(drawing_cr,
+ 

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

[Peter Hutterer]

From: Stephen Chandler Paul 

Closely modelled after the pointer focus handling

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

diff --git a/src/compositor.h b/src/compositor.h
index 3c67ffe..c1f3cc4 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -408,8 +408,14 @@ struct weston_touch {
 struct weston_tablet_tool {
struct weston_seat *seat;
enum zwp_tablet_tool_v1_type type;
+   struct weston_tablet *current_tablet;
 
struct wl_list resource_list;
+   struct wl_list focus_resource_list;
+   struct weston_view *focus;
+   struct wl_listener focus_view_listener;
+   struct wl_listener focus_resource_listener;
+   uint32_t focus_serial;
 
struct wl_list link;
 
@@ -515,6 +521,10 @@ struct weston_tablet_tool *
 weston_tablet_tool_create(void);
 void
 weston_tablet_tool_destroy(struct weston_tablet_tool *tool);
+void
+weston_tablet_tool_set_focus(struct weston_tablet_tool *tool,
+struct weston_view *view,
+uint32_t time);
 
 void
 wl_data_device_set_keyboard_focus(struct weston_seat *seat);
diff --git a/src/input.c b/src/input.c
index 0b43fd8..f835cf4 100644
--- a/src/input.c
+++ b/src/input.c
@@ -215,6 +215,26 @@ touch_focus_resource_destroyed(struct wl_listener 
*listener, void *data)
 }
 
 static void
+tablet_tool_focus_view_destroyed(struct wl_listener *listener, void *data)
+{
+   struct weston_tablet_tool *tool =
+   container_of(listener, struct weston_tablet_tool,
+focus_view_listener);
+
+   weston_tablet_tool_set_focus(tool, NULL, 0);
+}
+
+static void
+tablet_tool_focus_resource_destroyed(struct wl_listener *listener, void *data)
+{
+   struct weston_tablet_tool *tool =
+   container_of(listener, struct weston_tablet_tool,
+focus_resource_listener);
+
+   weston_tablet_tool_set_focus(tool, NULL, 0);
+}
+
+static void
 move_resources(struct wl_list *destination, struct wl_list *source)
 {
wl_list_insert_list(destination, source);
@@ -607,6 +627,16 @@ find_resource_for_surface(struct wl_list *list, struct 
weston_surface *surface)
return wl_resource_find_for_client(list, 
wl_resource_get_client(surface->resource));
 }
 
+static struct wl_resource *
+find_resource_for_view(struct wl_list *list, struct weston_view *view)
+{
+   if (!view)
+   return NULL;
+
+   return find_resource_for_surface(list,
+view->surface);
+}
+
 static void
 default_grab_keyboard_modifiers(struct weston_keyboard_grab *grab,
uint32_t serial, uint32_t mods_depressed,
@@ -853,6 +883,61 @@ weston_tablet_destroy(struct weston_tablet *tablet)
wl_list_remove(>link);
 }
 
+WL_EXPORT void
+weston_tablet_tool_set_focus(struct weston_tablet_tool *tool,
+struct weston_view *view,
+uint32_t time)
+{
+   struct wl_list *focus_resource_list;
+   struct wl_resource *resource;
+   struct weston_seat *seat = tool->seat;
+
+   focus_resource_list = >focus_resource_list;
+   if (tool->focus && !wl_list_empty(focus_resource_list)) {
+   wl_resource_for_each(resource, focus_resource_list) {
+   zwp_tablet_tool_v1_send_proximity_out(resource);
+   zwp_tablet_tool_v1_send_frame(resource, time);
+   }
+
+   move_resources(>resource_list, focus_resource_list);
+   }
+
+   if (find_resource_for_view(>resource_list, view)) {
+   struct wl_client *surface_client =
+   wl_resource_get_client(view->surface->resource);
+
+   move_resources_for_client(focus_resource_list,
+ >resource_list,
+ surface_client);
+
+   tool->focus_serial = 
wl_display_next_serial(seat->compositor->wl_display);
+   wl_resource_for_each(resource, focus_resource_list) {
+   struct wl_resource *tr;
+
+   tr = 
wl_resource_find_for_client(>current_tablet->resource_list,
+surface_client);
+
+   zwp_tablet_tool_v1_send_proximity_in(resource, 
tool->focus_serial,
+  tr, 
view->surface->resource);
+   zwp_tablet_tool_v1_send_frame(resource, time);
+   }
+   }
+
+   wl_list_remove(>focus_view_listener.link);
+   wl_list_init(>focus_view_listener.link);
+   

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 958c7ea..c1425e3 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -5446,6 +5446,18 @@ touch_to_activate_binding(struct weston_touch *touch, 
uint32_t time,
 }
 
 static void
+tablet_tool_activate_binding(struct weston_tablet_tool *tool,
+uint32_t button, void *data)
+{
+   if (tool->grab != >default_grab)
+   return;
+   if (tool->focus == NULL)
+   return;
+
+   activate_binding(tool->seat, data, tool->focus);
+}
+
+static void
 unfocus_all_seats(struct desktop_shell *shell)
 {
struct weston_seat *seat, *next;
@@ -6748,6 +6760,8 @@ shell_add_bindings(struct weston_compositor *ec, struct 
desktop_shell *shell)
weston_compositor_add_touch_binding(ec, 0,
touch_to_activate_binding,
shell);
+   weston_compositor_add_tablet_tool_binding(ec, BTN_TOUCH, 0,
+ tablet_tool_activate_binding, 
shell);
weston_compositor_add_axis_binding(ec, WL_POINTER_AXIS_VERTICAL_SCROLL,
   MODIFIER_SUPER | MODIFIER_ALT,
   surface_opacity_binding, NULL);
diff --git a/src/bindings.c b/src/bindings.c
index cc68cfe..64e151b 100644
--- a/src/bindings.c
+++ b/src/bindings.c
@@ -135,6 +135,24 @@ weston_compositor_add_touch_binding(struct 
weston_compositor *compositor,
 }
 
 WL_EXPORT struct weston_binding *
+weston_compositor_add_tablet_tool_binding(struct weston_compositor *compositor,
+ uint32_t button, uint32_t modifier,
+ weston_tablet_tool_binding_handler_t 
handler,
+ void *data)
+{
+   struct weston_binding *binding;
+
+   binding = weston_compositor_add_binding(compositor, 0, button, 0,
+   modifier, handler, data);
+   if (binding == NULL)
+   return NULL;
+
+   wl_list_insert(compositor->tablet_tool_binding_list.prev, 
>link);
+
+   return binding;
+}
+
+WL_EXPORT struct weston_binding *
 weston_compositor_add_axis_binding(struct weston_compositor *compositor,
   uint32_t axis, uint32_t modifier,
   weston_axis_binding_handler_t handler,
@@ -387,7 +405,26 @@ weston_compositor_run_touch_binding(struct 
weston_compositor *compositor,
}
 }
 
-int
+WL_EXPORT void
+weston_compositor_run_tablet_tool_binding(struct weston_compositor *compositor,
+ struct weston_tablet_tool *tool,
+ uint32_t button,
+ enum zwp_tablet_tool_v1_button_state 
state)
+{
+   struct weston_binding *b;
+
+   if (state != ZWP_TABLET_TOOL_V1_BUTTON_STATE_PRESSED)
+   return;
+
+   wl_list_for_each(b, >tablet_tool_binding_list, link) {
+   if (b->modifier == tool->seat->modifier_state) {
+   weston_tablet_tool_binding_handler_t handler = 
b->handler;
+   handler(tool, button, b->data);
+   }
+   }
+}
+
+WL_EXPORT int
 weston_compositor_run_axis_binding(struct weston_compositor *compositor,
   struct weston_pointer *pointer,
   uint32_t time,
diff --git a/src/compositor.c b/src/compositor.c
index f419818..d93917b 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4773,6 +4773,7 @@ weston_compositor_create(struct wl_display *display, void 
*user_data)
wl_list_init(>modifier_binding_list);
wl_list_init(>button_binding_list);
wl_list_init(>touch_binding_list);
+   wl_list_init(>tablet_tool_binding_list);
wl_list_init(>axis_binding_list);
wl_list_init(>debug_binding_list);
wl_list_init(>tablet_manager_resource_list);
diff --git a/src/compositor.h b/src/compositor.h
index 6806d06..bd6af4d 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -869,6 +869,7 @@ struct weston_compositor {
struct wl_list modifier_binding_list;
struct wl_list button_binding_list;
struct wl_list touch_binding_list;
+   struct wl_list tablet_tool_binding_list;
struct wl_list 

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

[Peter Hutterer]

From: Stephen Chandler Paul 

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

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

diff --git a/clients/window.c b/clients/window.c
index 26c2593..2b57962 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2612,6 +2612,24 @@ frame_touch_up_handler(struct widget *widget,
frame_handle_status(frame, input, time, THEME_LOCATION_CLIENT_AREA);
 }
 
+static int
+frame_tablet_tool_motion_handler(struct widget *widget,
+struct tablet_tool *tool,
+float x, float y,
+void *data)
+{
+   struct window_frame *frame = data;
+   enum theme_location location;
+
+   location = frame_tablet_tool_motion(frame->frame, tool, x, y);
+   if (frame_status(frame->frame) & FRAME_STATUS_REPAINT)
+   widget_schedule_redraw(frame->widget);
+
+   frame_get_pointer_image_for_location(data, location);
+
+   return CURSOR_LEFT_PTR;
+}
+
 struct widget *
 window_frame_create(struct window *window, void *data)
 {
@@ -2639,7 +2657,10 @@ window_frame_create(struct window *window, void *data)
widget_set_button_handler(frame->widget, frame_button_handler);
widget_set_touch_down_handler(frame->widget, frame_touch_down_handler);
widget_set_touch_up_handler(frame->widget, frame_touch_up_handler);
-
+   widget_set_tablet_tool_axis_handlers(frame->widget,
+frame_tablet_tool_motion_handler,
+NULL, NULL, NULL,
+NULL, NULL, NULL);
window->frame = frame;
 
return frame->child;
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 4fee087..af4c537 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -227,6 +227,10 @@ frame_double_touch_down(struct frame *frame, void *data, 
int32_t id,
 void
 frame_double_touch_up(struct frame *frame, void *data, int32_t id);
 
+/* May set FRAME_STATUS_REPAINT */
+enum theme_location
+frame_tablet_tool_motion(struct frame *frame, void *pointer, int x, int y);
+
 void
 frame_repaint(struct frame *frame, cairo_t *cr);
 
diff --git a/shared/frame.c b/shared/frame.c
index 1b67eb1..4645679 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -921,6 +921,44 @@ frame_double_touch_up(struct frame *frame, void *data, 
int32_t id)
}
 }
 
+enum theme_location
+frame_tablet_tool_motion(struct frame *frame, void *data, int x, int y)
+{
+   struct frame_pointer *tool_pointer = frame_pointer_get(frame, data);
+   struct frame_button *button,
+   *prev_button = tool_pointer->hover_button;
+   enum theme_location location;
+
+   location = theme_get_location(frame->theme, tool_pointer->x,
+ tool_pointer->y, frame->width,
+ frame->height,
+ frame->flags & FRAME_FLAG_MAXIMIZED ?
+ THEME_FRAME_MAXIMIZED : 0);
+
+   if (!tool_pointer)
+   return location;
+
+   tool_pointer->x = x;
+   tool_pointer->y = y;
+
+   button = frame_find_button(frame, x, y);
+
+   if (prev_button) {
+   if (prev_button == button)
+   /* The button hasn't changed so we're done here */
+   return location;
+   else
+   frame_button_leave(prev_button, tool_pointer);
+   }
+
+   if (button)
+   frame_button_enter(button);
+
+   tool_pointer->hover_button = button;
+
+   return location;
+}
+
 void
 frame_repaint(struct frame *frame, cairo_t *cr)
 {
-- 
2.5.0

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

Re: [PATCH weston 00/13] Add tablet support

[Peter Hutterer]

On Fri, Nov 06, 2015 at 03:13:46PM -0800, Jason Gerecke wrote:
> On Thu, Nov 5, 2015 at 8:31 PM, Peter Hutterer  
> wrote:
> >
> > This set adds support for graphics tablets to weston. It's not fully
> > complete, there are a couple of fixmes in it but the patchset is getting a
> > bit unwieldly. And there are some discussions on how to do things anyway.
> >
> > Note: This needs the tablet-support branch from libinput to work. And it is
> > on top of Jonas's wip/wayland-protocols github branch (ff0452cea150c).
> >
> > Tablet events are sent serially, terminated by a frame event. A toolkit
> > should accumulate them and then pass them on as one struct to the client. We
> > don't do that atm, it may be beyond libtoytoolkit's scope to really
> > integrate this properly.
> >
> > The tablet has a separate cursor. That's a conscious decision since the
> > focus handling on tablets closer to an absolute touch screen than a mouse,
> > but unlike touch you usually want a cursor shape to indicate the precise
> > position.
> >
> > The rest is fairly straightforward, though as said above, some details are
> > missing. Implementing this also showed that libinput needs a few extra
> > things added to it.
> >
> > Cheers,
> >   Peter
> 
> Having trouble getting this patchset to work properly for me. Of the
> many times I've launched 'weston-tablet', only once did it work as
> expected. The rest of the time I get no response and more often than
> not a segfault when the pen leaves proximity (first backtrace). I've
> also seen a segfault when simply trying to exit Weston with
> CTRL+ALT+BACKSPACE (second backgrace).
> 
> Haven't had time to track down the cause; all I know at the moment is
> that it seems the demo client's proximity_in_handler isn't actually
> being called for some reason...

fwiw, the reason for this bug was:
http://lists.freedesktop.org/archives/wayland-devel/2016-February/026765.html

Cheers,
   Peter

> 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0041596f in default_grab_tablet_tool_proximity_out
> (grab=0x20e8388, time=23980253) at src/input.c:812
> 812 if (weston_surface_is_mapped(tool->sprite->surface))
> (gdb) bt
> #0  0x0041596f in default_grab_tablet_tool_proximity_out
> (grab=0x20e8388, time=23980253) at src/input.c:812
> #1  0x00418ffb in notify_tablet_tool_proximity_out
> (tool=0x20e82d0, time=23980253) at src/input.c:2307
> #2  0x7fe3699a6ce1 in handle_tablet_proximity
> (libinput_device=0x1c1d7c0, proximity_event=0x20e0580) at
> src/libinput-device.c:320
> #3  0x7fe3699a7587 in evdev_device_process_event (event=0x20e0580)
> at src/libinput-device.c:543
> #4  0x7fe3699a5cf3 in process_event (event=0x20e0580) at
> src/libinput-seat.c:169
> #5  0x7fe3699a5d14 in process_events (input=0x1b07c88) at
> src/libinput-seat.c:179
> #6  0x7fe3699a5d79 in udev_input_dispatch (input=0x1b07c88) at
> src/libinput-seat.c:190
> #7  0x7fe3699a5da6 in libinput_source_dispatch (fd=16, mask=1,
> data=0x1b07c88) at src/libinput-seat.c:200
> #8  0x7fe36b3bcc72 in wl_event_loop_dispatch (loop=0x1aef220,
> timeout=timeout@entry=-1) at src/event-loop.c:422
> #9  0x7fe36b3bb5e5 in wl_display_run (display=0x1aef190) at
> src/wayland-server.c:1004
> #10 0x004275c6 in main (argc=1, argv=0x7ffe86bcca88) at src/main.c:871
> 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x7f3f3e63a0e7 in wl_list_remove (elm=0x195a910) at src/wayland-util.c:57
> 57 elm->prev->next = elm->next;
> (gdb) bt
> #0  0x7f3f3e63a0e7 in wl_list_remove (elm=0x195a910) at
> src/wayland-util.c:57
> #1  0x0041550f in weston_tablet_destroy (tablet=0x195a8e0) at
> src/input.c:699
> #2  0x0041a9df in weston_seat_release_tablet
> (tablet=0x195a8e0) at src/input.c:3116
> #3  0x7f3f3cc22ff3 in evdev_device_destroy (device=0x19acc80) at
> src/libinput-device.c:867
> #4  0x7f3f3cc20bc6 in udev_seat_remove_devices (seat=0x19a8fa0) at
> src/libinput-seat.c:126
> #5  0x7f3f3cc21427 in udev_seat_destroy (seat=0x19a8fa0) at
> src/libinput-seat.c:397
> #6  0x7f3f3cc211b0 in udev_input_destroy (input=0x1852c88) at
> src/libinput-seat.c:333
> #7  0x7f3f3cc1f5f7 in drm_destroy (ec=0x183bfc0) at
> src/compositor-drm.c:2712
> #8  0x0041379f in weston_compositor_destroy
> (compositor=0x183bfc0) at src/compositor.c:4780
> #9  0x004275f1 in main (argc=1, argv=0x7ffdd6f32308) at src/main.c:882
> 
> Jason
> ---
> Now instead of four in the eights place /
> you’ve got three, ‘Cause you added one  /
> (That is to say, eight) to the two, /
> But you can’t take seven from three,/
> So you look at the sixty-fours
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Moving bugs to Phabricator

[Daniel Stone]

Hi,
As previously discussed with a few people (when it was much more in
its infancy than now), I'd like to move our bug tracking from Bugzilla
to Phabricator.

There's a few reasons behind this. Phabricator is actually a pretty
decent suite of utilities, including repository browsing and code
review (Gerrit-style, including iterative revisions of patches,
line-by-line comments, etc), and having our bugs in that would allow
us better integration between the two. For instance, putting
'Maniphest Tasks: T1234' in a commit message when uploading a diff
automatically links the commit and the bug, and similarly it also gets
closed when pushing commits.

We can push this out further as well, including automatically
triggering CI from commits sent for review. I actually had this
working last year (running distcheck for every commit), but am in the
middle of rejigging my setup for a few things and haven't yet fixed
that to happen again yet.

Personally, just the improved UI (BZ is a nightmare) is enough for me,
but in terms of what we can do with it in future, I think it's got a
much better model than Bugzilla. The data store in Phabricator is very
important to their upstream, and is sensible and extensible. Whilst

We've had an instance at fd.o for a while, which has been used to
varying degrees by projects such as PiTiVi, GStreamer, et al. Also, we
use it internally for everything at Collabora, so the tree we maintain
for use there also gets pushed to fd.o.

In terms of what this would mean mechanically, we already have a
fairly mature suite of scripts which have been used to do imports for
quite a few projects. Using this would mirror all the Bugzilla bugs to
Phabricator, add a link from the existing Bugzilla bugs to their
replacements on Phabricator, and then redirect all new bug-filers to
Phabricator. The import process also creates accounts for everyone, so
once they'd recovered their passwords, so no data will be lost. It
also ports attachments over.

Beyond that, we can start using code review for it as and when people
feel comfortable, particularly using git-phab, which submits patchsets
to Phabricator for review. I'm probably most excited about getting
review on there, though also fairly cautious; while Bugzilla is just
trading one antiquated web tool which no-one uses for a nice modern
one which equally few people will probably look at, review is a bigger
part. Nonetheless, having things like concrete review approval status,
line-by-line review separated from wider/conceptual review,
at-a-glance review status, etc, I think is valuable enough that I
think it's worth shifting things over at some point.

Anyone have any thoughts/opinions/fears/encouragement?

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

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

[Jan Arne Petersen]

There were some shortcomings in the first version of the protocol which
makes it not really useful in real world applications. It is not really
possible to fix them in a compatible way so introduce a new v2 of the
protocol.

Fixes some shortcomings of the first version:

* Use only one wp_text_input per wl_seat (client side should be
  handled by client toolkit)
* Allow focus tracking without wl_keyboard present
* Improve update state handling
* Allow state requests
---
 unstable/text-input/text-input-unstable-v2.xml | 481 +
 1 file changed, 481 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v2.xml

diff --git a/unstable/text-input/text-input-unstable-v2.xml 
b/unstable/text-input/text-input-unstable-v2.xml
new file mode 100644
index 000..e7d2d50
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v2.xml
@@ -0,0 +1,481 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v2 interface repesents text input and input methods
+  associated with a seat. It provides enter/leave event to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about entered text is sent to the text-input object via
+  the pre-edit and commit events. Using this interface removes the need
+  for applications to directly process hardware key events and compose text
+  out of them.
+
+  Text is UTF-8 encoded, indices and lengths are in bytes.
+
+  Serials are used to synchronize the state between the text input and
+  an input method. New serials are sent by the text input in the
+  update_state request and are used by the input method to indicate
+  the known text input state in evsents like preedit_string, commit_string,
+  and keysym. The text input can then ignore events from the input method
+  which are based on an outdated state (for example after a reset).
+
+
+
+  
+   Destroy the wp_text_input object. Also disables all surfaces enabled
+   through this wp_text_input object
+  
+
+
+
+  
+   Enable text input in a surface (usually when a text entry inside of it
+   has focus).
+
+   This can be called before or after a surface gets text (or keyboard)
+   focus via the enter event. Text input to a surface is only active
+   when it has the current text (or keyboard) focus and is enabled.
+  
+  
+
+
+
+  
+   Disable text input in a surface (typically when there is no focus on any
+   text entry inside the surface).
+  
+  
+
+
+
+  
+   Requests input panels (virtual keyboard) to show.
+
+   This should be used for example to show a virtual keyboard again
+   (with a tap) after it was closed by pressing on a close button on the
+   keyboard.
+  
+
+
+
+  
+   Requests input panels (virtual keyboard) to hide.
+  
+
+
+
+  
+   Sets the plain surrounding text around the input position. Text is
+   UTF-8 encoded. Cursor is the byte offset within the
+   surrounding text. Anchor is the byte offset of the
+   selection anchor within the surrounding text. If there is no selected
+   text anchor is the same as cursor.
+
+   Make sure to always send some text before and after the cursor
+   except when the cursor is at the beginning or end of text.
+
+   When there was a configure_surrounding_text event take the
+   before_cursor and after_cursor arguments into account for picking how
+   much surrounding 

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

[Jan Arne Petersen]

On 28/01/16 11:05, Jonas Ådahl wrote:
> On Thu, Jan 28, 2016 at 08:52:40AM +0100, Jan Arne Petersen wrote:
>> There were some shortcomings in the first version of the protocol which
>> makes it not really useful in real world applications. It is not really
>> possible to fix them in a compatible way so introduce a new v2 of the
>> protocol.
>>
>> Fixes some shortcomings of the first version:
>>
>> * Use only one wp_text_input per wl_seat (client side should be
>>   handled by client toolkit)
>> * Allow focus tracking without wl_keyboard present
>> * Improve update state handling
>> * Allow state requests
> 
> I haven't looked much at the actual protocol yet, but I have some
> comments anyway to begin with.
>> ---
>>  unstable/text-input/text-input-unstable-v2.xml | 369 
>> +
>>  1 file changed, 369 insertions(+)
>>  create mode 100644 unstable/text-input/text-input-unstable-v2.xml
>>
>> diff --git a/unstable/text-input/text-input-unstable-v2.xml 
>> b/unstable/text-input/text-input-unstable-v2.xml
>> new file mode 100644
>> index 000..f757e92
>> --- /dev/null
>> +++ b/unstable/text-input/text-input-unstable-v2.xml
>> @@ -0,0 +1,369 @@
>> +
>> +
>> +
>> +  
>> +Copyright © 2012, 2013 Intel Corporation
>> +Copyright © 2015, 2016 Jan Arne Petersen
>> +
>> +Permission to use, copy, modify, distribute, and sell this
>> +software and its documentation for any purpose is hereby granted
>> +without fee, provided that the above copyright notice appear in
>> +all copies and that both that copyright notice and this permission
>> +notice appear in supporting documentation, and that the name of
>> +the copyright holders not be used in advertising or publicity
>> +pertaining to distribution of the software without specific,
>> +written prior permission.  The copyright holders make no
>> +representations about the suitability of this software for any
>> +purpose.  It is provided "as is" without express or implied
>> +warranty.
>> +
>> +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
>> +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
>> +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
>> +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>> +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
>> +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
>> +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
>> +THIS SOFTWARE.
>> +  
>> +
>> +  
>> +
>> +  The zwp_text_input_v2 interface repesents text input and input methods
>> +  associated with a seat. It provides enter/leave event to follow the
>> +  text input focus for a seat.
>> +
>> +  Requests are used to activate/deactivate the text-input object and set
>> +  state information like surrounding and selected text or the content 
>> type.
>> +  The information about entered text is sent to the text-input object 
>> via
>> +  the pre-edit and commit events. Using this interface removes the need
>> +  for applications to directly process hardware key events and compose 
>> text
>> +  out of them.
>> +
>> +  Text is generally UTF-8 encoded, indices and lengths are in bytes.
>> +
>> +  Serials are used to synchronize the state between the text input and
>> +  an input method. New serials are sent by the text input in the
>> +  commit_state request and are used by the input method to indicate
>> +  the known text input state in evsents like preedit_string, 
>> commit_string,
>> +  and keysym. The text input can then ignore events from the input 
>> method
>> +  which are based on an outdated state (for example after a reset).
>> +
> 
> Please add an empty line between the events, requests and enums in the
> interfaces. It makes it much easer to read.
> 
> Seems to miss a 

Both done

>> +
>> +  
>> +Requests to activate a surface for text input (typically when a
>> +text entry in it gets focus).
>> +
>> +There can only be one active surface per client and seat. When surface 
>> is
>> +null all surfaces of the client get deactivated.
> 
> Why not make this a separate request and drop the allow-null? It makes
> it clearer that "activate" sometimes deactivates.

There are enable and disable now.

>> +  
>> +  > allow-null="true"/>
>> +
>> +
>> +  
>> +Requests input panels (virtual keyboard) to show.
>> +  
>> +
>> +
>> +  
>> +Requests input panels (virtual keyboard) to hide.
>> +  
>> +
>> +
>> +  
>> +Should be called by an editor widget when the input state should be
>> +reset, for example after the text was changed outside of the normal
>> +input method flow.
>> +  
>> +
>> +
>> +  
>> +Sets the plain surrounding text around the input position. Text is
>> +UTF-8 encoded. 

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

[Jan Arne Petersen]

Hi,

On 28/01/16 13:05, Daiki Ueno wrote:
> Hello,
> 
> Jan Arne Petersen  writes:
> 
>> Fixes some shortcomings of the first version:
>>
>> * Use only one wp_text_input per wl_seat (client side should be
>>   handled by client toolkit)
>> * Allow focus tracking without wl_keyboard present
> 
> These sound nice.
> 
>> * Improve update state handling
>> * Allow state requests
> 
> I have a few comments regarding them, inlined below.
> 
>> +  Serials are used to synchronize the state between the text input and
>> +  an input method. New serials are sent by the text input in the
>> +  commit_state request and are used by the input method to indicate
> 
> There is no commit_state request anymore.

Ok fixed to update_state.

>> +
>> +  
>> +Request to get the surrounding text and cursor position sent from the 
>> client.
>> +  
>> +  
>> +  
>> +  
>> +  
>> +
>> +
>> +  
>> +Request to get the surrounding text and cursor position sent from the 
>> client.
>> +  
>> +  
>> +  
>> +
> 
> These events have the same description.  Would you mind explaining how
> they are supposed to be used, maybe in combination with the
> set_surrounding_text request?

They are called configure_surrounding_text and demand_full_state and are
better documented in PATCH v3.

Thanks
Jan Arne

-- 
Jan Arne Petersen | jan.peter...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jan Arne Petersen]

There were some shortcomings in the first version of the protocol which
makes it not really useful in real world applications. It is not really
possible to fix them in a compatible way so introduce a new v2 of the
protocol.

Fixes some shortcomings of the first version:

* Use only one wp_text_input per wl_seat (client side should be
  handled by client toolkit)
* Allow focus tracking without wl_keyboard present
* Improve update state handling
* Allow state requests
---
 unstable/text-input/text-input-unstable-v2.xml | 481 +
 1 file changed, 481 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v2.xml

diff --git a/unstable/text-input/text-input-unstable-v2.xml 
b/unstable/text-input/text-input-unstable-v2.xml
new file mode 100644
index 000..2fc5e7d
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v2.xml
@@ -0,0 +1,481 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v2 interface repesents text input and input methods
+  associated with a seat. It provides enter/leave event to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about entered text is sent to the text-input object via
+  the pre-edit and commit events. Using this interface removes the need
+  for applications to directly process hardware key events and compose text
+  out of them.
+
+  Text is UTF-8 encoded, indices and lengths are in bytes.
+
+  Serials are used to synchronize the state between the text input and
+  an input method. New serials are sent by the text input in the
+  update_state request and are used by the input method to indicate
+  the known text input state in evsents like preedit_string, commit_string,
+  and keysym. The text input can then ignore events from the input method
+  which are based on an outdated state (for example after a reset).
+
+
+
+  
+   Destroy the wp_text_input object. Also disables all surfaces enabled
+   through this wp_text_input object
+  
+
+
+
+  
+   Enable text input in a surface (usually when a text entry inside of it
+   has focus).
+
+   This can be called before or after a surface gets text (or keyboard)
+   focus via the enter event. Text input to a surface is only active
+   when it has the current text (or keyboard) focus and is enabled.
+  
+  
+
+
+
+  
+   Disable text input in a surface (typically when there is no focus on any
+   text entry inside the surface).
+  
+  
+
+
+
+  
+   Requests input panels (virtual keyboard) to show.
+
+   This should be used for example to show a virtual keyboard again
+   (with a tap) after it was closed by pressing on a close button on the
+   keyboard.
+  
+
+
+
+  
+   Requests input panels (virtual keyboard) to hide.
+  
+
+
+
+  
+  
+
+
+
+  
+   Sets the plain surrounding text around the input position. Text is
+   UTF-8 encoded. Cursor is the byte offset within the
+   surrounding text. Anchor is the byte offset of the
+   selection anchor within the surrounding text. If there is no selected
+   text anchor is the same as cursor.
+
+   Make sure to always send some text before and after the cursor
+   except when the cursor is at the beginning or end of text.
+
+   When there was a
+  
+  
+  
+  
+
+
+
+  
+   Content hint is a bitmask to allow to modify the 

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

[Jan Arne Petersen]

There were some shortcomings in the first version of the protocol which
makes it not really useful in real world applications. It is not really
possible to fix them in a compatible way so introduce a new v2 of the
protocol.

Fixes some shortcomings of the first version:

* Use only one wp_text_input per wl_seat (client side should be
  handled by client toolkit)
* Allow focus tracking without wl_keyboard present
* Improve update state handling
* Allow state requests
---
 unstable/text-input/text-input-unstable-v2.xml | 484 +
 1 file changed, 484 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v2.xml

diff --git a/unstable/text-input/text-input-unstable-v2.xml 
b/unstable/text-input/text-input-unstable-v2.xml
new file mode 100644
index 000..0cfa837
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v2.xml
@@ -0,0 +1,484 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v2 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the pre-edit and commit events. Using this interface removes the need
+  for applications to directly process hardware key events and compose text
+  out of them.
+
+  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+  have to always point to the first byte of an UTF-8 encoded code point.
+  Lengths are not allowed to contain just a part of an UTF-8 encoded code
+  point.
+
+  Serials are used to synchronize the state between the text input and
+  an input method. New serials are sent by the text input in the
+  update_state request and are used by the input method to indicate
+  the known text input state in events like preedit_string, commit_string,
+  and keysym. The text input can then ignore events from the input method
+  which are based on an outdated state (for example after a reset).
+
+
+
+  
+   Destroy the wp_text_input object. Also disables all surfaces enabled
+   through this wp_text_input object
+  
+
+
+
+  
+   Enable text input in a surface (usually when a text entry inside of it
+   has focus).
+
+   This can be called before or after a surface gets text (or keyboard)
+   focus via the enter event. Text input to a surface is only active
+   when it has the current text (or keyboard) focus and is enabled.
+  
+  
+
+
+
+  
+   Disable text input in a surface (typically when there is no focus on any
+   text entry inside the surface).
+  
+  
+
+
+
+  
+   Requests input panels (virtual keyboard) to show.
+
+   This should be used for example to show a virtual keyboard again
+   (with a tap) after it was closed by pressing on a close button on the
+   keyboard.
+  
+
+
+
+  
+   Requests input panels (virtual keyboard) to hide.
+  
+
+
+
+  
+   Sets the plain surrounding text around the input position. Text is
+   UTF-8 encoded. Cursor is the byte offset within the surrounding text.
+   Anchor is the byte offset of the selection anchor within the
+   surrounding text. If there is no selected text, anchor is the same as
+   cursor.
+
+   Make sure to always send some text before and after the cursor
+   except when the cursor is at the 

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

[Jan Arne Petersen]

Hi Silvan,

On 02/02/16 13:23, Silvan Jegen wrote:
> Hi
> 
> Please find some comments and spelling corrections below.
> 
> 
>> There were some shortcomings in the first version of the protocol which
>> makes it not really useful in real world applications. It is not really
>> possible to fix them in a compatible way so introduce a new v2 of the
>> protocol.
>>
>> Fixes some shortcomings of the first version:
>>
>> * Use only one wp_text_input per wl_seat (client side should be
>>   handled by client toolkit)
>> * Allow focus tracking without wl_keyboard present
>> * Improve update state handling
>> * Allow state requests
>> ---
>>  unstable/text-input/text-input-unstable-v2.xml | 481 
>> +
>>  1 file changed, 481 insertions(+)
>>  create mode 100644 unstable/text-input/text-input-unstable-v2.xml
>>
>> diff --git a/unstable/text-input/text-input-unstable-v2.xml 
>> b/unstable/text-input/text-input-unstable-v2.xml
>> new file mode 100644
>> index 000..2fc5e7d
>> --- /dev/null
>> +++ b/unstable/text-input/text-input-unstable-v2.xml
>> @@ -0,0 +1,481 @@
>> +
>> +
>> +
>> +  
>> +Copyright © 2012, 2013 Intel Corporation
>> +Copyright © 2015, 2016 Jan Arne Petersen
>> +
>> +Permission to use, copy, modify, distribute, and sell this
>> +software and its documentation for any purpose is hereby granted
>> +without fee, provided that the above copyright notice appear in
>> +all copies and that both that copyright notice and this permission
>> +notice appear in supporting documentation, and that the name of
>> +the copyright holders not be used in advertising or publicity
>> +pertaining to distribution of the software without specific,
>> +written prior permission.  The copyright holders make no
>> +representations about the suitability of this software for any
>> +purpose.  It is provided "as is" without express or implied
>> +warranty.
>> +
>> +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
>> +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
>> +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
>> +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>> +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
>> +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
>> +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
>> +THIS SOFTWARE.
>> +  
>> +
>> +  
>> +
>> +  The zwp_text_input_v2 interface represents text input and input 
>> methods
> 
> s/repesents/represents/

fixed

>> +  associated with a seat. It provides enter/leave event to follow the
> 
> s/event/events/


fixed

>> +  text input focus for a seat.
>> +
>> +  Requests are used to enable/disable the text-input object and set
>> +  state information like surrounding and selected text or the content 
>> type.
>> +  The information about entered text is sent to the text-input object 
>> via
> 
> "about the entered text" may sound more natural.

fixed

>> +  the pre-edit and commit events. Using this interface removes the need
>> +  for applications to directly process hardware key events and compose 
>> text
>> +  out of them.
>> +
>> +  Text is UTF-8 encoded, indices and lengths are in bytes.
> 
> This seems problematic to me when dealing with multi-byte encoded
> Unicode points. The behavior should be better defined in that case.
> Please see comments further below.

From v4:

"Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
have to always point to the first byte of an UTF-8 encoded code point.
Lengths are not allowed to contain just a part of an UTF-8 encoded code
point."

The protocol is usually not used by application developers directly but
by a toolkit which has to convert from toolkit strings/indices/lengths
to the protocol string/index/length format and back. Which seems to be
quite easy with above protocol definition. We could also use Unicode
characters for index/length should not make much a difference.

>> +  Serials are used to synchronize the state between the text input and
>> +  an input method. New serials are sent by the text input in the
>> +  update_state request and are used by the input method to indicate
>> +  the known text input state in evsents like preedit_string, 
>> commit_string,
> 
> s/evsents/events/

fixed

>> +  and keysym. The text input can then ignore events from the input 
>> method
>> +  which are based on an outdated state (for example after a reset).
>> +
>> +
>> +
>> +  
>> +   Destroy the wp_text_input object. Also disables all surfaces enabled
>> +   through this wp_text_input object
>> +  
>> +
>> +
>> +
>> +  
>> +   Enable text input in a surface (usually when a text entry inside of 
>> it
>> +   has focus).
>> +
>> +   This can be called before or after a surface gets 

Re: [PATCH weston] hmi-controller: remove duplicate commit_changes in random mode

[Pekka Paalanen]

Hi,

I don't think this patch is ready to be merged, more below.

TL;DR: It would probably be best to just ignore which ivilayer an
ivisurface is currently on, and always just remove and add. That would be
the simplest solution, if the ivilayout API just allows it.

Specifically, do not clear the layer's surface list in advance. Just go
over each surface and reassign the layer for it. Then doing a single
commit_changes() in the end will ensure that ivisurfaces get atomically
moved from layer to layer as appropriate, and there won't be any
multiple assignments.


On Fri, 25 Dec 2015 13:47:15 +0900
Nobuhiko Tanibata  wrote:

> From: Nobuhiko Tanibata 
> 
> Previous code cleaned up surfaces in layer once and then added surfaces
> to a layer in random. In this flow, two commitchanges are required.
> 
> This patch proposes that it avoids calling add_surface if a surface is
> already added to a layer in random. In this flow, cleaning up
> surfaces is not required.
> 
> Signed-off-by: Nobuhiko Tanibata 
> ---
>  ivi-shell/hmi-controller.c | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
> index 77426bc..8a81f5c 100644
> --- a/ivi-shell/hmi-controller.c
> +++ b/ivi-shell/hmi-controller.c
> @@ -418,24 +418,18 @@ mode_random_replace(struct hmi_controller *hmi_ctrl,
>   struct ivi_layout_surface *ivisurf  = NULL;
>   const uint32_t duration = hmi_ctrl->hmi_setting->transition_duration;
>   int32_t i = 0;
> + int32_t j = 0;
>   int32_t layer_idx = 0;
> + int32_t surface_len_on_layer = 0;
> + struct ivi_layout_surface **ivisurfs = NULL;
>  
>   layers = MEM_ALLOC(sizeof(*layers) * hmi_ctrl->screen_num);
>  
>   wl_list_for_each(application_layer, layer_list, link) {
>   layers[layer_idx] = application_layer;
> - 
> ivi_layout_interface->layer_set_render_order(layers[layer_idx]->ivilayer,
> - NULL, 0);
>   layer_idx++;
>   }
>  
> - /*
> -  * This commit change is needed because ivisurface can not belongs to 
> several layers
> -  * at the same time. So ivisurfaces shall be removed from layers once 
> and then set them
> -  * to layers randomly.
> -  */
> - ivi_layout_interface->commit_changes();

This is a lengthy side-comment that came to my mind while looking at
the code:

An ivisurface indeed cannot belong to several layers at the same time,
but I don't think that would happen (break anything) even if you
literally removed only this commit_changes() call.

That is because the staging list (ivi_layout_surface::pending) and the
current list (ivi_layout_surface::order) are separate. I believe it is
fine to have an ivi_layout_surface on one layer in the current list and
on a different layer in the staging list. You have to make that work
anyway, because it is the only way to move an ivisurface from one layer
to another without potentially causing it to disappear from the screen
in between.

When the connecting structures, that were meant to allow an ivisurface
to be on several layers, were removed, the code automatically became
such that it naturally avoids attempting to have an ivisurface on
multiple layers, even if you tried to do that from the ivilayout
external API. The list manipulations just work, and the last assignment
will prevail.

There are also leftovers in the code, that go through a list of all
ivisurfaces just to find an ivisurface with the right ivi-id when you
already have a pointer to the ivisurface with the ivi-id you are
looking for. Since there cannot be multiple ivisurfaces with the same
ivi-id, the search will only check if the given ivisurface is on the
given list. If the list by definition contains all ivisurfaces, the
check is moot. I think this happens in functions like
ivi_layout_layer_add_surface() and ivi_layout_layer_set_render_order().

But, as said, that is an aside. I think there is a lot that could be
simplified and cleaned up in the surface/layer/screen management, but
that's off-topic here.

> -
>   for (i = 0; i < surface_length; i++) {
>   ivisurf = pp_surface[i];
>  
> @@ -463,6 +457,19 @@ mode_random_replace(struct hmi_controller *hmi_ctrl,
>surface_width,
>surface_height);
>  
> + ivi_layout_interface
> + ->get_surfaces_on_layer(layers[layer_idx]->ivilayer,
> + _len_on_layer,
> + );

Please, try not to split around -> as it looks odd.

This call allocates memory and stores the pointer to 'ivisurfs', which
is then never freed, leaking.

> +
> + for (j = 

Re: Moving bugs to Phabricator

[Jasper St. Pierre]

The current major issue with Phabricator for me currently is that it
doesn't support patch-based code review, unless this has changed in
the meantime: 
http://stackoverflow.com/questions/20756320/how-to-prevent-phabricator-from-eating-my-commit-history

( The linked article has since moved to
https://secure.phabricator.com/book/phabflavor/article/recommendations_on_revision_control/
, but it still contains mostly the same text. )

On Tue, Feb 2, 2016 at 7:43 AM, Daniel Stone  wrote:
> Hi,
> As previously discussed with a few people (when it was much more in
> its infancy than now), I'd like to move our bug tracking from Bugzilla
> to Phabricator.
>
> There's a few reasons behind this. Phabricator is actually a pretty
> decent suite of utilities, including repository browsing and code
> review (Gerrit-style, including iterative revisions of patches,
> line-by-line comments, etc), and having our bugs in that would allow
> us better integration between the two. For instance, putting
> 'Maniphest Tasks: T1234' in a commit message when uploading a diff
> automatically links the commit and the bug, and similarly it also gets
> closed when pushing commits.
>
> We can push this out further as well, including automatically
> triggering CI from commits sent for review. I actually had this
> working last year (running distcheck for every commit), but am in the
> middle of rejigging my setup for a few things and haven't yet fixed
> that to happen again yet.
>
> Personally, just the improved UI (BZ is a nightmare) is enough for me,
> but in terms of what we can do with it in future, I think it's got a
> much better model than Bugzilla. The data store in Phabricator is very
> important to their upstream, and is sensible and extensible. Whilst
>
> We've had an instance at fd.o for a while, which has been used to
> varying degrees by projects such as PiTiVi, GStreamer, et al. Also, we
> use it internally for everything at Collabora, so the tree we maintain
> for use there also gets pushed to fd.o.
>
> In terms of what this would mean mechanically, we already have a
> fairly mature suite of scripts which have been used to do imports for
> quite a few projects. Using this would mirror all the Bugzilla bugs to
> Phabricator, add a link from the existing Bugzilla bugs to their
> replacements on Phabricator, and then redirect all new bug-filers to
> Phabricator. The import process also creates accounts for everyone, so
> once they'd recovered their passwords, so no data will be lost. It
> also ports attachments over.
>
> Beyond that, we can start using code review for it as and when people
> feel comfortable, particularly using git-phab, which submits patchsets
> to Phabricator for review. I'm probably most excited about getting
> review on there, though also fairly cautious; while Bugzilla is just
> trading one antiquated web tool which no-one uses for a nice modern
> one which equally few people will probably look at, review is a bigger
> part. Nonetheless, having things like concrete review approval status,
> line-by-line review separated from wider/conceptual review,
> at-a-glance review status, etc, I think is valuable enough that I
> think it's worth shifting things over at some point.
>
> Anyone have any thoughts/opinions/fears/encouragement?
>
> Cheers,
> Daniel
> ___
> 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: [PATCH v3 wayland-protocols] Add the tablet protocol

[Peter Hutterer]

On Fri, Jan 29, 2016 at 11:40:44AM -0800, Jason Gerecke wrote:
> On Thu, Jan 28, 2016 at 8:32 PM, Peter Hutterer
>  wrote:
> > Signed-off-by: Peter Hutterer 
> > ---
> > Changes to v2:
> > - renamed hwserial to hardware_serial
> > - renamed to hwid event to a hardware_id_wacom. no-one else uses this ID
> >   type, so having a generic event with a wacom-specific type + enum is
> >   optimistic. The next company may use a string instead, so it'll be
> >   non-generic anyway. Might as well rename it to something specific now.
> > - added slider, rotation and wheel axes
> > - couple of documentation fixes
> >
> >  Makefile.am|   1 +
> >  unstable/tablet/README |   4 +
> >  unstable/tablet/tablet-unstable-v1.xml | 622 
> > +
> >  3 files changed, 627 insertions(+)
> >  create mode 100644 unstable/tablet/README
> >  create mode 100644 unstable/tablet/tablet-unstable-v1.xml

[...]

> > +
> > +
> > +  
> > +   If the physical tool can be identified by a unique 64-bit serial
> > +   number, this event notifies the client of this serial number.
> > +
> > +   If multiple tablets are available in the same seat and the tool is
> > +   uniquely identifiable by the serial number, that tool may move
> > +   between tablets.
> > +
> > +   Otherwise, if the tool has no serial number and this event is
> > +   missing, the tool is tied to the tablet it first comes into
> > +   proximity with. Even if the physical tool is used on multiple
> > +   tablets, separate wp_tablet_tool objects will be created, one per
> > +   tablet.
> > +
> > +   This event is sent in the initial burst of events before the
> > +   wp_tablet_tool.done event.
> > +  
> > +  
> > +  
> 
> Any idea how resistant the core Wayland protocol developers would be
> to adding native 64-bit datatypes? Its a bit of a hassle to split and
> recombine the data on both sides of the wire, though its admittedly
> not often that you need to deal with such large types...

did some digging, found:
http://lists.freedesktop.org/archives/wayland-devel/2014-April/014305.html
probably still accurate, so I guess the answer remains at "no can do" :)

> 
> > +
> > +
> > +
> > +  
> > +   This event notifies the client of a hardware id available on this 
> > tool.
> > +
> > +   The hardware id is a device-specific 64-bit id that provides extra
> > +   information about the tool in use, beyond the wl_tool.type
> > +   enumeration. The format of the id is specific to tablets made by
> > +   Wacom Inc. For example, the hardware id of a Wacom Grip
> > +   Pen (a stylus) is 0x802.
> > +
> > +   This event is sent in the initial burst of events before the
> > +   wp_tablet_tool.done event.
> > +  
> > +  
> > +  
> > +
> 
> If this event is specific to Wacom hardware, it would probably be okay
> to limit it to a single uint since that's all that is reported by
> current tools. Though since it'd be painful to expand retroactively
> I'm also fine leaving it at 64 bits if you want.

I think having 64 bits now will just save us the trouble later and it's
fairly minimal code on the client side.

Cheers,
   Peter

> > +
> > +
> > +  
> > +   Sent whenever one or both of the tilt axes on a tool change. Each 
> > tilt
> > +   value is normalized between -65535 and 65535.
> > +  
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +   Sent whenever the z-rotation axis on the tool changes. The
> > +   rotation value is in 0.01 of a degree clockwise from the tool's
> > +   logical neutral position.
> > +  
> 
> From the protocol description: "Any extra axis is normalized, i.e. the
> client knows the range as specified in the protocol (e.g. [0, 65535]),
> the granularity however is unknown." This was chosen because we don't
> always have the necessary information to translate a kernel value for
> a given device's axis into a physical measurement, but we can always
> report a normalized value that that gives clients a sense of its
> relative magnitude.
> 
> We do need to provide a way for clients to translate the normalized
> values into physical measurements if possible though. I would suggest
> adding the following event to the tool definition. Several could be
> sent as part of the initial pre-"done" burst.
> 
>  
>
>  This event provides information about the physical range of one
>  of the axes of the tool. This information can be used to translate
>  the normalized values (0 to 65535, or -65535 to +65535) axis values
>  sent by events into physical quantities.
> 
>  Minimum and maximum values have units of gram-force for pressure,
>  millimeters for distance, and degrees of arc for tilt and rotation.
>  This event will not be sent for axes whose physical 

[PATCH v4 wayland-protocols] Add the tablet protocol

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
Changes to v3:
- various comment typos fixed as pointed out by Jason
- reword initial section talking about extra axes
- change tilt to use degrees instead of normalized values

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

diff --git a/Makefile.am b/Makefile.am
index 582b3f2..f3a6dd5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@ unstable_protocols =
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
+   unstable/tablet/tablet-unstable-v1.xml  
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/tablet/README b/unstable/tablet/README
new file mode 100644
index 000..7ba8e77
--- /dev/null
+++ b/unstable/tablet/README
@@ -0,0 +1,4 @@
+Tablet protocol
+
+Maintainers:
+Peter Hutterer 
diff --git a/unstable/tablet/tablet-unstable-v1.xml 
b/unstable/tablet/tablet-unstable-v1.xml
new file mode 100644
index 000..494d6e2
--- /dev/null
+++ b/unstable/tablet/tablet-unstable-v1.xml
@@ -0,0 +1,627 @@
+
+
+  
+Copyright 2014 © Stephen "Lyude" Chandler Paul
+Copyright 2015 © Red Hat, Inc.
+
+Permission is hereby granted, free of charge, to any person
+obtaining a copy of this software and associated documentation files
+(the "Software"), to deal in the Software without restriction,
+including without limitation the rights to use, copy, modify, merge,
+publish, distribute, sublicense, and/or sell copies of the Software,
+and to permit persons to whom the Software is furnished to do so,
+subject to the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+  
+  
+This description provides a high-level overview of the interplay between
+the interfaces defined this protocol. For details, see the protocol
+specification.
+
+More than one tablet may exist, and device-specifics matter. Tablets are
+not represented by a single virtual device like wl_pointer. A client
+binds to the tablet manager object which is just a proxy object. From
+that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
+and that returns the actual interface that has all the tablets. With
+this indirection, we can avoid merging wp_tablet into the actual wayland
+protocol, a long-term benefit.
+
+The wp_tablet_seat sends a "tablet added" for each tablet connected.
+That event is followed by descriptive events about the hardware;
+currently that includes events for name, vid/pid and
+a wp_tablet.path event that describes a local path. This path can be
+used to uniquely identify a tablet, or get more information through
+libwacom.  Emulated or nested tablets can skip any of those, e.g. a
+virtual tablet may not have a vid/pid. The sequence of descriptive
+events is terminated by a wp_tablet.done event to signal that a client
+may now finalize any initialization for that tablet.
+
+Events from tablets require a tool in proximity. Tools are also managed
+by the tablet seat, a "tool added" is sent whenever a tool is new to
+the compositor. That event is followed by a number of descriptive events
+about the hardware; currently that includes capabilities, serial id,
+hardware serial and tool type. Similar to the tablet interface, a
+wp_tablet_tool.done event is sent to terminate that initial sequence.
+
+Any event from a tool happens on the wp_tablet_tool interface. When the
+tool gets into proximity of the tablet, a proximity_in event is sent on
+the wp_tablet_tool interface, listing the tablet and the surface. That
+event is followed by a motion event with the coordinates. After that,
+it's the usual motion, axis, button, etc. 

RE: Recursive dispatch (Re: [PATCH v2] server: Calculate remaining data size after a closure is processed)

[Jaeyoon Jung]

> -Original Message-
> From: Derek Foreman [mailto:der...@osg.samsung.com]
> Sent: Wednesday, February 03, 2016 6:56 AM
> To: Pekka Paalanen; Jaeyoon Jung
> Cc: 'Jonas Ådahl'; wayland-devel@lists.freedesktop.org
> Subject: Re: Recursive dispatch (Re: [PATCH v2] server: Calculate remaining
> data size after a closure is processed)
> 
> On 02/02/16 06:57 AM, Pekka Paalanen wrote:
> > On Tue, 12 Jan 2016 13:03:19 +0900 "Jaeyoon Jung"
> >  wrote:
> >
> >>> -Original Message- From: wayland-devel
> >>> [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf
> >>> Of Jonas Adahl Sent: Tuesday, January 12, 2016 12:27 PM To:
> >>> Jaeyoon Jung Cc: wayland-devel@lists.freedesktop.org Subject:
> >>> Re: [PATCH v2] server: Calculate remaining data size after a
> >>> closure is processed
> >>>
> >>> On Tue, Jan 12, 2016 at 08:22:56AM +0900, Jaeyoon Jung wrote:
> >>>
>  When processing a closure, data in the connection can be
>  consumed again if the closure itself invokes extra event
>  dispatch. In that case the remaining data size is also
>  altered, so the variable len should be updated after the
>  closure is processed.
> 
>  Signed-off-by: Jaeyoon Jung 
> >>>
> >>> I don't like the name wl_connection_size
> >>> (wl_connection_pending_input() or something would be more
> >>> descriptive).
> >>
> >> I just wanted to have a shorter name.
> >> wl_connection_pending_input() looks better to me as well, and
> >> I'll update the patch accordingly. Thanks.
> >>
> >>
> >>> A good follow up would be a test case where this would
> >>> otherwise cause issues. I assume it would be triggered by a
> >>> wl_event_loop_dispatch() in a interface request handler?
> >>
> >> Yes, exactly.
> >
> > Hi,
> >
> > could you humor me and explain in what sort of situations
> > dispatching from within a request handler is useful?

Suppose a server has a single event queue for all kind of events
including wayland events. If the server wants to process more events
from the queue in the middle of the request handler, and there is
another wayland request arrived in the queue, it induces a recursive
dispatch. I'm not saying that this is a good practice though.


> > I thought recursive dispatch is a programming pattern that can
> > only lead to painful and erratic problems later. Don't we consider
> > this to be bad practice also in the client API?
> 
> Is that actually documented somewhere?
> 
> > If you do it in the server, that is like: this message causes more
> > messages to be dispatched - how does that make sense? A server must
> > not block waiting for any client message.
> 
> I agree that a server blocking on a client message is a great way to
> create a terrible user experience - but I'm not certain it's
> libwayland's mandate to prevent it?
> 
> > Also, inspecting future messages before finishing the processing of
> > the current message is racy: the following messages may or may not
> > be in the receive buffer and nothing guarantees either way, you
> > just get lucky a lot of times. Wayland IPC does not guarantee more
> > than one message to be delivered at a time, this is why we have
> > things like wl_surface.commit request.
> 
> This is a really good point. :)
> 
> > If someone starts hardening libwayland against programmer errors,
> > I'd expect one thing to be to abort() on recursive dispatch. Can
> > you tell me why we should support recursive dispatch?
> 
> IMHO we should either do that immediately (before the 1.10 release) or
> revert this patch now.  Not that anything is wrong with the patch - it
> doesn't introduce bugs in libwayland...
> 
> Previously recursive dispatch was impossible, with this patch it's
> possible.  The patch was landed to allow recursive dispatch to work,
> and it's obvious someone's about to start using it.

To be more exact, previously recursive dispatch allowed a message copy
from empty buffer and resulted in an irrelevant error post to the client.
If we want to disallow recursive dispatch, it would be nice to raise an
error like abort() when it is detected. Reverting this patch is just
going back to the past without resolving the issue.
I agree that recursive dispatch might be harmful and should be avoided.
However, I'm not sure if it is something must be done in libwayland.
Isn't it sufficient to be documented somewhere and let the implementor
make a decision?


> If we later intentionally break that code, we're jerks.
> -- From the jerk that posted a bunch of patches to do more stringent
> checks on resource versions a few days ago...  arguably those have
> always been bugs, though. ;)
> 
> So, with the release coming so quickly, I think we should either
> decide whether recursive dispatch is legal or illegal before the
> release, or revert the patch (thus re-breaking recursive dispatch) and
> worry about it for 1.11.
> 
> > I have nothing against this patch per se, mind. Just the whole
> > premise that 

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

[Jan Arne Petersen]

Hi Rui,

On 28/01/16 21:16, Rui Tiago Cação Matos wrote:
> Hi,
> 
> thanks for sending this. I was actually going to start a discussion
> about the existing protocol but let's go from here instead. Comments
> inline:
> 
> First a question of scope: a client would only ever need to instance
> one text_input object per wl_seat and then "associate" it with a
> particular wl_surface through the activate request. Am I right?

Yes. There is one text_input object per wl_seat, which can be used to
track the text focus via enter/leave and to enable text input per
wl_suface via enable/disable (renamed in v3).

So there is only text input happening when the surface which has text
focus is also enabled.

> Not having a destroy request isn't so bad if that's the intended scope
> but I think we should still have one.

Added them.

> On Thu, Jan 28, 2016 at 8:52 AM, Jan Arne Petersen  wrote:
>> +  Text is generally UTF-8 encoded, indices and lengths are in bytes.
> 
> Why bytes instead of characters? It seems to me that using characters
> is less error prone since an offset in bytes might end up in the
> middle of an UTF-8 encoded character.

Yes text needs also to be valid UTF-8. Bytes seemed easier to use for
different toolkits with UTF-16 strings. But yes one could also use
characters if there is a big demand for it.

>> +  Serials are used to synchronize the state between the text input and
>> +  an input method. New serials are sent by the text input in the
>> +  commit_state request and are used by the input method to indicate
>> +  the known text input state in evsents like preedit_string, 
>> commit_string,
>> +  and keysym. The text input can then ignore events from the input 
>> method
>> +  which are based on an outdated state (for example after a reset).
> 
> Any particular reason for serials to be generated and controlled by
> clients? For the intended use case it seems ok but it's odd when
> compared with other serials in wayland.

Yes usually serials are used in Wayland on compositor side to make sure
that requests from clients are valid (setting a cursor in response to an
enter event for example).

Here we need to make sure that events from the compositor still make
sense for the client. In this case serials need to be generated on
client side.

>> +
>> +  
>> +   Requests input panels (virtual keyboard) to show.
>> +  
>> +
>> +
>> +  
>> +   Requests input panels (virtual keyboard) to hide.
>> +  
>> +
> 
> Do we really need these requests? Isn't the fact that a text input is
> currently active enough for the compositor/IM to decide on its own if
> it should show an input panel?

Added some more description. Basically when the virtual keyboard is
hidden by pressing some hide button (or sliding it away or whatever)
there needs to be a way for the client to request it again.

>> +
>> +  
>> +   Should be called by an editor widget when the input state should be
>> +   reset, for example after the text was changed outside of the normal
>> +   input method flow.
>> +  
>> +
> 
> Shouldn't this have a serial argument if we go with client controlled serials?
> 
> Otherwise reset could remain like this but adding specification to
> what happens with serials sent in events from this point onwards.

Removed reset. It is part of update_state now.

> 
>> +
>> +  
>> +   Sets the content purpose and content hint. While the purpose is the
>> +   basic purpose of an input field, the hint flags allow to modify some
>> +   of the behavior.
>> +
>> +   When no content type is explicitly set, a normal content purpose with
>> +   default hints (auto completion, auto correction, auto capitalization)
>> +   should be assumed.
> 
> No strong opinion, particularly since these are just hints and thus
> compositors/IMs are free to ignore them (right?), but I think the
> default should be "none".

Yes, they might be not relevant for all input methods. Removed the
defaults, which should be handled by toolkits (what to set when nothing
special is specified on an input widget).

>> +
>> +  
>> +  
>> +  
>> +  
>> +
> 
> This needs specification. Why is it a rectangle and what does it
> represent exactly? Are the coordinates relative to the activated
> wl_surface? What are compositors expected to do with it?

"Sets the cursor outline as a rectangle relative to the surface.

Allows the compositor to put a window with word suggestions near the
cursor." from patch v3

>> +
>> +  
>> +   Defines the reason for sending an updated state.
>> +  
>> +  
>> +  
>> +  
>> +  
>> +
>> +
>> +  
>> +  
>> +
> 
> This seems very underspecified. Care to elaborate how it's supposed to be 
> used?

See better description in v3:
"Allows to atomically send state updates from client.

 This request should follow after a batch of 

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

[Jan Arne Petersen]

On 29/01/16 00:33, Bill Spitzak wrote:
> 
> 
> On Wed, Jan 27, 2016 at 11:52 PM, Jan Arne Petersen  > wrote:
> 
> 
> +  Text is generally UTF-8 encoded, indices and lengths are in
> bytes.
> 
> 
> Remove the word "generally". *All* text in your api's are UTF-8.

Done

> +
> +  
> +   Requests to activate a surface for text input (typically when a
> +   text entry in it gets focus).
> +
> +   There can only be one active surface per client and seat.
> When surface is
> +   null all surfaces of the client get deactivated.
> +  
> 
> 
> I think clients should be allowed to send activate more than once per
> surface, it is to indicate the input focus switching between widgets.
> This removes the need for another api to indicate the widget is
> switching. Sending null for the surface, or a different event, would
> indicate that the keyboard focus is no longer on a text input widget.

We use enable/disable request now. That should be a bit easier to handle
from client side.

> +
> +  
> +   Should be called by an editor widget when the input state
> should be
> +   reset, for example after the text was changed outside of the
> normal
> +   input method flow.
> +  
> +
> 
> 
> I believe this request can be replaced by redundant activate requests.

It got integrated into update_state.

> +
> +  
> +   Sets the plain surrounding text around the input position.
> Text is
> +   UTF-8 encoded. Cursor is the byte offset within the
> +   surrounding text. Anchor is the byte offset of the
> +   selection anchor within the surrounding text. If there is no
> selected
> +   text anchor is the same as cursor.
> +  
> +  
> +  
> +  
> +
> 
> 
> The anchor could be very far away from the cursor, much farther than any
> small limit on the request size. I think this means the anchor position
> could be negative or larger than the text length. Sending this without
> clamping would be a good idea, the input method would then have a hint
> where the anchor is, and it can clamp the value itself.
> 
> If the client wants new text to replace the selected text, the text
> between anchor+cursor will be deleted, and any input method decisions
> would depend on the text outside the anchor..cursor range. This may be
> larger than the allowed buffer size, so I think clients have to send the
> text as though the selection was deleted.
> 
> A client that does not want to replace the selected text could still
> send an anchor, but then I am not clear if the input method can take
> advantage of knowing what characters are selected to modify the results.
> So it is possible the anchor is not needed at all.

Ok I use an int for anchor now. It still make sense for an input method
to know what is in the selection even when it gets replaced by new
entered text.

> +  
> +  
> 
> 
> I think you might want non-zero bits to *disable* features. This allows
> zero to be the default, and means that if some new correction is
> invented in the future then they can default to on without you having to
> modify the numerical value of default.

Toolkits need to handle default on client side now.

> +  
> 
> 
> Can you explain this? The client still has to do something to display
> dots instead of characters, right? My guess is that this is an indicator
> that the input method should not show any of the surrounding text in
> popup controls. For instance maybe it can suggest word completion for
> your password, but the display must show stars for the already-typed
> characters. Is this correct?
> 
> Hopefully how clients and the input methods show hidden characters can
> be agreed by convention, rather than adding more api to communicate that.

Yes you do not want to show already typed text on a virtual keyboard in
a password field. Usually the keyboard would show nothing then, no
reason to show dots/stars on the virtual keyboard.

> +  
> 
> 
> Do you mean ASCII? It seems unlikely you mean "the subset of Unicode
> that they have declared are Latin characters" since that excludes
> numbers and space and includes vast numbers of characters that some
> software will not handle.

I guess we can remove it. Instead clients should just use
set_preferred_language("en").

> +  
> +  
> +  
> +  
> +  
> +  
> +  
> 
> 
> I think it will work a lot better if the client can indicate in
> set_surrounding_text that only a certain class of character is
> acceptable right now. So if it is a date of for nn/nn/nn, then it will
> indicate that slash or digit is required, depending on what is to the
> left of the cursor. And the meaning of "phone number" and "date" and
> "time" and "url" (and "zip code" 

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

[Jan Arne Petersen]

On 29/01/16 21:43, Bill Spitzak wrote:
> 
> 
> On Wed, Jan 27, 2016 at 11:52 PM, Jan Arne Petersen  > wrote:
> 
> 
> +
> +  
> +   Notify when a new composing text (pre-edit) should be set
> around the
> +   current cursor position. Any previously set composing text
> should
> +   be removed.
> +
> +   The commit text can be used to replace the preedit text on reset
> +   (for example on unfocus).
> +
> +   The text input should also handle all preedit_style and
> preedit_cursor
> +   events occurring directly before preedit_string.
> +  
> +  
> +  
> +  
> +
> +
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +
> +
> +  
> +   Sets styling information on composing text. The style is
> applied for
> +   length bytes from index relative to the beginning of the
> composing
> +   text (as byte offset). Multiple styles can
> +   be applied to a composing text by sending multiple
> preedit_styling
> +   events.
> +
> +   This event is handled as part of a following preedit_string
> event.
> +  
> +  
> +  
> +  
> +
> +
> +  
> +   Sets the cursor position inside the composing text (as byte
> +   offset) relative to the start of the composing text. When
> index is a
> +   negative number no cursor is shown.
> +
> +   This event is handled as part of a following preedit_string
> event.
> +  
> +  
> +
> +
> +  
> +   Notify when text should be inserted into the editor widget.
> The text to
> +   commit could be either just a single character after a key
> press or the
> +   result of some composing (pre-edit). It could be also an
> empty text
> +   when some text should be removed (see
> delete_surrounding_text) or when
> +   the input cursor should be moved (see cursor_position).
> +
> +   Any previously set composing text should be removed.
> +  
> +  
> +  
> +
> +
> +  
> +   Notify when the cursor or anchor position should be modified.
> +
> +   This event should be handled as part of a following
> commit_string
> +   event.
> +  
> +  
> +  
> +
> +
> +  
> +   Notify when the text around the current cursor position
> should be
> +   deleted.
> +
> +   Index is relative to the current cursor (in bytes).
> +   Length is the length of deleted text (in bytes).
> +
> +   This event should be handled as part of a following
> commit_string
> +   event.
> +  
> +  
> +  
> +
> 
> 
> I feel there are a lot of reasons to combine the preview and commit
> strings. An actual commit would be done by setting the preview and then
> sending a commit event.
> 
> - The preview has to be able to delete surrounding text, so that it can
> preview a merge between typed text and surrounding characters.
> 
> - Conversely, to match how most text input works in software now, you
> need to preserve the "incorrect" indicator in the committed text. This
> is so the word remains marked as incorrect. There also has to be a way
> for the client to return to that text and tell the input method to
> continue, so the spelling correction code in the input method can be
> reused (not just to make the client's work easier, but for the far more
> important reason of making the ui consistent!).
> 
> These remove the differences between commit and preview, so it makes
> sense to merge them.
> 
> Besides allowing the user to return to a misspelled word, it may make
> sense to return to a preedit. I'm not sure as I have no experience with
> Asian input methods. But it does seem possible.

Sorry no toolkit supports that. While the current proposed protocol can
be implemented with current Qt, Gtk+ and EFL. Androids input method API
is also quite similar to what is proposed here.

> So some possible modifications:
> 
> - Make delete surrounding text part of preview. Client has to remember
> the deleted text so it can restore it for the next preview (which may
> delete less).

Delete surrounding text also works for pre-edit, i fixed the documentation.

> - Change commit_string to just a commit event that says the previous
> preview string is the final result. This allows the commit to include
> highlighting.
> 
> - Possibly allow the highlight regions to be larger than the preview
> text. This could allow a spelling corrector to mark existing text as
> part of the incorrect word. The 

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

[Silvan Jegen]

Hi

Please find some comments and spelling corrections below.


> There were some shortcomings in the first version of the protocol which
> makes it not really useful in real world applications. It is not really
> possible to fix them in a compatible way so introduce a new v2 of the
> protocol.
>
> Fixes some shortcomings of the first version:
>
> * Use only one wp_text_input per wl_seat (client side should be
>   handled by client toolkit)
> * Allow focus tracking without wl_keyboard present
> * Improve update state handling
> * Allow state requests
> ---
>  unstable/text-input/text-input-unstable-v2.xml | 481 
> +
>  1 file changed, 481 insertions(+)
>  create mode 100644 unstable/text-input/text-input-unstable-v2.xml
>
> diff --git a/unstable/text-input/text-input-unstable-v2.xml 
> b/unstable/text-input/text-input-unstable-v2.xml
> new file mode 100644
> index 000..2fc5e7d
> --- /dev/null
> +++ b/unstable/text-input/text-input-unstable-v2.xml
> @@ -0,0 +1,481 @@
> +
> +
> +
> +  
> +Copyright © 2012, 2013 Intel Corporation
> +Copyright © 2015, 2016 Jan Arne Petersen
> +
> +Permission to use, copy, modify, distribute, and sell this
> +software and its documentation for any purpose is hereby granted
> +without fee, provided that the above copyright notice appear in
> +all copies and that both that copyright notice and this permission
> +notice appear in supporting documentation, and that the name of
> +the copyright holders not be used in advertising or publicity
> +pertaining to distribution of the software without specific,
> +written prior permission.  The copyright holders make no
> +representations about the suitability of this software for any
> +purpose.  It is provided "as is" without express or implied
> +warranty.
> +
> +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
> +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> +THIS SOFTWARE.
> +  
> +
> +  
> +
> +  The zwp_text_input_v2 interface represents text input and input methods

s/repesents/represents/


> +  associated with a seat. It provides enter/leave event to follow the

s/event/events/


> +  text input focus for a seat.
> +
> +  Requests are used to enable/disable the text-input object and set
> +  state information like surrounding and selected text or the content 
> type.
> +  The information about entered text is sent to the text-input object via

"about the entered text" may sound more natural.

> +  the pre-edit and commit events. Using this interface removes the need
> +  for applications to directly process hardware key events and compose 
> text
> +  out of them.
> +
> +  Text is UTF-8 encoded, indices and lengths are in bytes.

This seems problematic to me when dealing with multi-byte encoded
Unicode points. The behavior should be better defined in that case.
Please see comments further below.


> +  Serials are used to synchronize the state between the text input and
> +  an input method. New serials are sent by the text input in the
> +  update_state request and are used by the input method to indicate
> +  the known text input state in evsents like preedit_string, 
> commit_string,

s/evsents/events/

> +  and keysym. The text input can then ignore events from the input method
> +  which are based on an outdated state (for example after a reset).
> +
> +
> +
> +  
> +   Destroy the wp_text_input object. Also disables all surfaces enabled
> +   through this wp_text_input object
> +  
> +
> +
> +
> +  
> +   Enable text input in a surface (usually when a text entry inside of it
> +   has focus).
> +
> +   This can be called before or after a surface gets text (or keyboard)
> +   focus via the enter event. Text input to a surface is only active
> +   when it has the current text (or keyboard) focus and is enabled.
> +  
> +  
> +
> +
> +
> +  
> +   Disable text input in a surface (typically when there is no focus on 
> any
> +   text entry inside the surface).
> +  
> +  
> +
> +
> +
> +  
> +   Requests input panels (virtual keyboard) to show.
> +
> +   This should be used for example to show a virtual keyboard again
> +   (with a tap) after it was closed by pressing on a close button on the
> +   keyboard.
> +  
> +
> +
> +
> +  
> +   Requests input panels (virtual keyboard) to hide.
> +  
> +
> +
> +
> +  

There is a description 

Recursive dispatch (Re: [PATCH v2] server: Calculate remaining data size after a closure is processed)

[Pekka Paalanen]

On Tue, 12 Jan 2016 13:03:19 +0900
"Jaeyoon Jung"  wrote:

> > -Original Message-
> > From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On
> > Behalf Of Jonas Adahl
> > Sent: Tuesday, January 12, 2016 12:27 PM
> > To: Jaeyoon Jung
> > Cc: wayland-devel@lists.freedesktop.org
> > Subject: Re: [PATCH v2] server: Calculate remaining data size after a 
> > closure
> > is processed
> > 
> > On Tue, Jan 12, 2016 at 08:22:56AM +0900, Jaeyoon Jung wrote:  
> > > When processing a closure, data in the connection can be consumed again
> > > if the closure itself invokes extra event dispatch. In that case the
> > > remaining data size is also altered, so the variable len should be
> > > updated after the closure is processed.
> > >
> > > Signed-off-by: Jaeyoon Jung   
> > 
> > I don't like the name wl_connection_size (wl_connection_pending_input()
> > or something would be more descriptive).  
> 
> I just wanted to have a shorter name. wl_connection_pending_input()
> looks better to me as well, and I'll update the patch accordingly.
> Thanks.
> 
>  
> > A good follow up would be a test case where this would otherwise
> > cause issues. I assume it would be triggered by a
> > wl_event_loop_dispatch() in a interface request handler?  
> 
> Yes, exactly.

Hi,

could you humor me and explain in what sort of situations dispatching
from within a request handler is useful?

I thought recursive dispatch is a programming pattern that can only
lead to painful and erratic problems later. Don't we consider this to
be bad practice also in the client API?

If you do it in the server, that is like: this message causes more
messages to be dispatched - how does that make sense? A server must not
block waiting for any client message.

Also, inspecting future messages before finishing the processing of the
current message is racy: the following messages may or may not be in
the receive buffer and nothing guarantees either way, you just get
lucky a lot of times. Wayland IPC does not guarantee more than one
message to be delivered at a time, this is why we have things like
wl_surface.commit request.

If someone starts hardening libwayland against programmer errors, I'd
expect one thing to be to abort() on recursive dispatch. Can you tell
me why we should support recursive dispatch?

I have nothing against this patch per se, mind. Just the whole premise
that is behind this patch smells fishy to me and makes me think your
software architecture that uses recursive dispatch is fundamentally
broken.


Thanks,
pq


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