Re: [PATCH v6] protocol: Extend wl_touch with touchpoint shape and orientation
On Nov 4, 2016, at 9:31 AM, Dennis Kempin wrote: > > This CL updates the wl_touch interface with a shape and > orientation event. > The shape/orientation of a touch point is not relevant for most UI > applications, but allows a better experience in some cases > such as drawing apps. > > The events are used by the compositor to inform the client > about changes in the shape and orientation of a touchpoint, which is > approximated by an ellipse and it's angle to the y-axis. > > The event is optional and only sent when compositor and the > touch device support this type of information. The client is > responsible for making a reasonable assumption about the > touch shape if no shape is reported. > > Signed-off-by: Dennis Kempin Reviewed-by: Yong Bakos Cheers, yong > --- > protocol/wayland.xml | 80 +--- > 1 file changed, 76 insertions(+), 4 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 6c6d078..04c3784 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1669,7 +1669,7 @@ > > > > - > + > > A seat is a group of keyboards, pointer and touch devices. This > object is published as a global during start up, or when such a > @@ -1778,7 +1778,7 @@ > > > > - > + > > The wl_pointer interface represents one or more input devices, > such as mice, which control the pointer location and pointer_focus > @@ -2092,7 +2092,7 @@ > > > > - > + > > The wl_keyboard interface represents one or more keyboards > associated with a seat. > @@ -2256,7 +2256,14 @@ > > > > - Indicates the end of a contact point list. > + Indicates the end of a set of events that logically belong together. > + A client is expected to accumulate the data in all events within the > + frame before proceeding. > + > + A wl_touch.frame terminates at least one event but otherwise no > + guarantee is provided about the set of events within a frame. A client > + must assume that any state not updated in a frame is unchanged from the > + previously known state. > > > > @@ -2276,6 +2283,71 @@ > > > > + > + > + > + > + > + Sent when a touchpoint has changed its shape. > + > + This event does not occur on its own. It is sent before a > + wl_touch.frame event and carries the new shape information for > + any previously reported, or new touch points of that frame. > + > + Other events describing the touch point such as wl_touch.down, > + wl_touch.motion or wl_touch.orientation may be sent within the > + same wl_touch.frame. A client should treat these events as a single > + logical touch point update. The order of wl_touch.shape, > + wl_touch.orientation and wl_touch.motion is not guaranteed. > + A wl_touch.down event is guaranteed to occur before the first > + wl_touch.shape event for this touch ID but both events may occur within > + the same wl_touch.frame. > + > + A touchpoint shape is approximated by an ellipse through the major and > + minor axis length. The major axis length describes the longer diameter > + of the ellipse, while the minor axis length describes the shorter > + diameter. Major and minor are orthogonal and both are specified in > + surface-local coordinates. The center of the ellipse is always at the > + touchpoint location as reported by wl_touch.down or wl_touch.move. > + > + This event is only sent by the compositor if the touch device supports > + shape reports. The client has to make reasonable assumptions about the > + shape if it did not receive this event. > + > + > + > + > + > + > + > + > + Sent when a touchpoint has changed its orientation. > + > + This event does not occur on its own. It is sent before a > + wl_touch.frame event and carries the new shape information for > + any previously reported, or new touch points of that frame. > + > + Other events describing the touch point such as wl_touch.down, > + wl_touch.motion or wl_touch.shape may be sent within the > + same wl_touch.frame. A client should treat these events as a single > + logical touch point update. The order of wl_touch.shape, > + wl_touch.orientation and wl_touch.motion is not guaranteed. > + A wl_touch.down event is guaranteed to occur before the first > + wl_touch.orientation event for this touch ID but both events may occur > + within the same wl_touch.frame. > + > + The orientation describes the clockwise angle of a touchpoint's major > + axis to the positive surface y-axis and is normalized to the -180 to > + +180 degree range. The granularity of orientation depends on the touch > + device, some devices only support binary rotation values between 0 and > + 90 degrees. > + > + This event is o
Re: [PATCH wayland-protocols] tablet: specify the tool button numbers are simply sequentially numbered
On 11/03/2016 06:46 PM, Peter Hutterer wrote: > We're using sequentially numbered buttons for the pad because actual tablets > are quite varied in how the present buttons (BTN_A, BTN_0, etc.). For this > reason, libinput numbers pad buttons sequentially. > > Let's do the same for tablet tools. Unfortunately libinput doesn't do this, so > the mapping is up to the compositor but at least we can get the wayland > protocol right. The ony event codes a tool currently sends are BTN_STYLUS and > BTN_STYLUS2 anyway, so it's already sequentially numbered with a make-pretend > fancy name. > This sounds fine from the viewpoint of making things consistent, but I'm a still a little hesitant about making such a change. I don't want to throw away semantic information which could be valuable to clients. If there's one thing I've learned from X11 and xf86-input-wacom its that sequentially numbered buttons only work if the buttons are effectively interchangeable (example: ExpressKeys, whose functions are arbitrarily defined by the client; anti-example: mouse buttons, whose functions are defined by tradition[1]). Are the two buttons on a stylus arbitrarily interchangeable? My immediate gut feeling is "yes"[2], but I don't want to be too hasty in changing protocol. If a stylus is introduced with a third button that has some specific intended functionality, is it added to the sequential button list or do we define a new event that gets sent when that button is pressed? Does it depend on how the kernel defines it? I'm willing to give this an acked-by but I'd like to hear your thoughts back first :) > Signed-off-by: Peter Hutterer > --- > This is something Carlos and I discussed at XDC, TLDR: it doesn't make much > sense sending BTN_STYLUS for a tool but button index 0 for the pad. > > I didn't bump the version number here because it either > a) doesn't matter to clients > b) needs a interface version bump, but then probably a) applies > c) needs a full tablet-unstable-v3.xml but that seems excessive. > > Not 100% which one of those applies, Carlos will know more since he's doing > the mutter/GTK bits. Weston doesn't care, we don't have a tablet > implementation yet. > Shouldn't changing the starting point for button numbers from 0x14B (BTN_STYLUS) to 0 necessitate a version change? I haven't looked at Mutter/GTK, but my in-development Xwayland patches[3] would break from the change. [1]: Oh, you have a four-button mouse with left/right/forward/back buttons? Well, I hope the last two are reported as the 6th and 7th mouse button or else they aren't going to work right. [2]: A couple of reasons: "BTN_STYLUS" and "BTN_STYLUS2" sound pretty interchangeable, the buttons have no "obvious" or "traditional" semantics, and the default right/middle mapping on Linux is opposite to Windows but I haven't heard any complaints. [3]: Hopefully my queue of higher-priority tasks will clear up soon(TM) and I can get back to finishing them... 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 > unstable/tablet/tablet-unstable-v2.xml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/unstable/tablet/tablet-unstable-v2.xml > b/unstable/tablet/tablet-unstable-v2.xml > index 728a3df..e7a15bd 100644 > --- a/unstable/tablet/tablet-unstable-v2.xml > +++ b/unstable/tablet/tablet-unstable-v2.xml > @@ -555,6 +555,8 @@ > button events are generated by the compositor. See > wp_tablet_tool.proximity_in and wp_tablet_tool.proximity_out for > details. > + > + Buttons are indexed sequentially, starting at button 0. > > > > @@ -1141,6 +1143,8 @@ > > > Sent whenever the physical state of a button changes. > + > + Buttons are indexed sequentially, starting at button 0. > > > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v6] protocol: Extend wl_touch with touchpoint shape and orientation
This CL updates the wl_touch interface with a shape and orientation event. The shape/orientation of a touch point is not relevant for most UI applications, but allows a better experience in some cases such as drawing apps. The events are used by the compositor to inform the client about changes in the shape and orientation of a touchpoint, which is approximated by an ellipse and it's angle to the y-axis. The event is optional and only sent when compositor and the touch device support this type of information. The client is responsible for making a reasonable assumption about the touch shape if no shape is reported. Signed-off-by: Dennis Kempin --- protocol/wayland.xml | 80 +--- 1 file changed, 76 insertions(+), 4 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 6c6d078..04c3784 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1669,7 +1669,7 @@ - + A seat is a group of keyboards, pointer and touch devices. This object is published as a global during start up, or when such a @@ -1778,7 +1778,7 @@ - + The wl_pointer interface represents one or more input devices, such as mice, which control the pointer location and pointer_focus @@ -2092,7 +2092,7 @@ - + The wl_keyboard interface represents one or more keyboards associated with a seat. @@ -2256,7 +2256,14 @@ - Indicates the end of a contact point list. + Indicates the end of a set of events that logically belong together. + A client is expected to accumulate the data in all events within the + frame before proceeding. + + A wl_touch.frame terminates at least one event but otherwise no + guarantee is provided about the set of events within a frame. A client + must assume that any state not updated in a frame is unchanged from the + previously known state. @@ -2276,6 +2283,71 @@ + + + + + + Sent when a touchpoint has changed its shape. + + This event does not occur on its own. It is sent before a + wl_touch.frame event and carries the new shape information for + any previously reported, or new touch points of that frame. + + Other events describing the touch point such as wl_touch.down, + wl_touch.motion or wl_touch.orientation may be sent within the + same wl_touch.frame. A client should treat these events as a single + logical touch point update. The order of wl_touch.shape, + wl_touch.orientation and wl_touch.motion is not guaranteed. + A wl_touch.down event is guaranteed to occur before the first + wl_touch.shape event for this touch ID but both events may occur within + the same wl_touch.frame. + + A touchpoint shape is approximated by an ellipse through the major and + minor axis length. The major axis length describes the longer diameter + of the ellipse, while the minor axis length describes the shorter + diameter. Major and minor are orthogonal and both are specified in + surface-local coordinates. The center of the ellipse is always at the + touchpoint location as reported by wl_touch.down or wl_touch.move. + + This event is only sent by the compositor if the touch device supports + shape reports. The client has to make reasonable assumptions about the + shape if it did not receive this event. + + + + + + + + + Sent when a touchpoint has changed its orientation. + + This event does not occur on its own. It is sent before a + wl_touch.frame event and carries the new shape information for + any previously reported, or new touch points of that frame. + + Other events describing the touch point such as wl_touch.down, + wl_touch.motion or wl_touch.shape may be sent within the + same wl_touch.frame. A client should treat these events as a single + logical touch point update. The order of wl_touch.shape, + wl_touch.orientation and wl_touch.motion is not guaranteed. + A wl_touch.down event is guaranteed to occur before the first + wl_touch.orientation event for this touch ID but both events may occur + within the same wl_touch.frame. + + The orientation describes the clockwise angle of a touchpoint's major + axis to the positive surface y-axis and is normalized to the -180 to + +180 degree range. The granularity of orientation depends on the touch + device, some devices only support binary rotation values between 0 and + 90 degrees. + + This event is only sent by the compositor if the touch device supports + orientation reports. + + + + -- 2.8.0.rc3.226.g39d4020 ___ wayland-devel mailing list waylan
Re: [PATCH v6] protocol: Extend wl_touch with touchpoint shape and orientation
Thanks for catching my ESL mistakes, Yong! :) I am uploading an updated version! On Thu, Nov 3, 2016 at 7:39 PM Yong Bakos wrote: > Hi Dennis, > > > On Nov 3, 2016, at 3:52 PM, Dennis Kempin > wrote: > > > > This CL updates the wl_touch interface with a shape and > > orientation event. > > The shape/orientation of a touch point is not relevant for most UI > > applications, but allows a better experience in some cases > > such as drawing apps. > > > > The events are used by the compositor to inform the client > > about changes in the shape and orientation of a touchpoint, which is > > approximated by an ellipse and it's angle to the y-axis. > > > > The event is optional and only sent when compositor and the > > touch device support this type of information. The client is > > responsible for making a reasonable assumption about the > > touch shape if no shape is reported. > > > > Signed-off-by: Dennis Kempin > > My apologies for not noticing the following sooner, but some issues are > noted > inline below. Also, the line lengths of those descriptions should max out > at > 80 characters (please). I've noted them inline for convenience. > > > > --- > > protocol/wayland.xml | 79 > +--- > > 1 file changed, 75 insertions(+), 4 deletions(-) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 6c6d078..31902e6 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -1669,7 +1669,7 @@ > > > > > > > > - > > + > > > > A seat is a group of keyboards, pointer and touch devices. This > > object is published as a global during start up, or when such a > > @@ -1778,7 +1778,7 @@ > > > > > > > > - > > + > > > > The wl_pointer interface represents one or more input devices, > > such as mice, which control the pointer location and pointer_focus > > @@ -2092,7 +2092,7 @@ > > > > > > > > - > > + > > > > The wl_keyboard interface represents one or more keyboards > > associated with a seat. > > @@ -2256,7 +2256,14 @@ > > > > > > > > - Indicates the end of a contact point list. > > + Indicates the end of a set of events that logically belong > together. > > + A client is expected to accumulate the data in all events within > the > > + frame before proceeding. > > + > > + A wl_touch.frame terminates at least one event but otherwise no > > + guarantee is provided about the set of events within a frame. A > client > > + must assume that any state not updated in a frame is unchanged > from the > > + previously known state. > > > > > > > > @@ -2276,6 +2283,70 @@ > > > > > > > > + > > + > > + > > + > > + > > + Sent when a touchpoint has changed its shape. > > + > > + This event event does not occur on its own. It is sent before a > > This event does not... > > > > + wl_touch.frame event and carries the new shape information for > > + any previously reported, or new touch points of that frame. > > + > > + Other events describing the touch point such as wl_touch.down, > > + wl_touch.motion or wl_touch.orientation may be sent within the > > + same wl_touch.frame. A client should treat these events as a single > > + logical touch point update. The order of wl_touch.shape, > > + wl_touch.orientation and wl_touch.motion is not guaranteed. > > + A wl_touch.down event is guaranteed to occur before the first > > + wl_touch.shape event for this touch ID but both events may occur > within the > > Above line exceeds 80 characters followed by other protocol descriptions. > > > > + same wl_touch.frame. > > + > > + A touchpoint shape is approximated by an ellipse through the major > and > > + minor axis length. The major axis length describes the longer > diameter > > + of the ellipse, while the minor axis length describes the shorter > > + diameter. Major and minor are orthogonal and both are specified in > > + surface-local coordinates. The center of the ellipse is always at > the > > + touchpoint location as reported by wl_touch.down or wl_touch.move. > > + > > + This event is only sent by the compositor if the touch device > supports shape > > + reports. The client has to make reasonable assumptions about the > shape if > > The two lines above exceed 80 characters followed by other protocol > descriptions. > > > > + it did not receive this event. > > + > > + > > + > > + > > + > > + > > + > > + > > + Sent when a touchpoint has changed its orientation. > > + > > + This event event does not occur on its own. It is sent before a > > + wl_touch.frame event and carries the new shape information for > > + any previously reported, or new touch points of that frame. > > + > > + Other events describing the touch point such as wl_touch.down, > > + wl_touc
Re: [PATCH weston 1/2] gl-renderer: add support for EGL_KHR_swap_buffers_with_damage
On Thursday, 2016-11-03 22:38:19 +, Emil Velikov wrote:
> Extension is identical to the EXT one, yet we need to check for the KHR
> abbreviated extension name + entry-point.
>
> Signed-off-by: Emil Velikov
> ---
> libweston/gl-renderer.c | 29 +++--
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
> index 3e8e5ab..a585001 100644
> --- a/libweston/gl-renderer.c
> +++ b/libweston/gl-renderer.c
> @@ -2781,6 +2781,18 @@ renderer_setup_egl_client_extensions(struct
> gl_renderer *gr)
> static int
> gl_renderer_setup_egl_extensions(struct weston_compositor *ec)
> {
> + static const struct {
> + char *extension, *entrypoint;
> + } foo[] = {
Since the goal of this table is to get the entrypoint when you found an
extension, how about `swap_buffers_with_damage_ext_to_entrypoint`?
Rather long I'll concede, but explicit.
You can also drop the middle bit: `swap_damage_ext_to_entrypoint`
With an appropriate name here (and the other patch), the series is:
Reviewed-by: Eric Engestrom
> + {
> + .extension = "EGL_EXT_swap_buffers_with_damage",
> + .entrypoint = "eglSwapBuffersWithDamageEXT",
> + },
> + {
> + .extension = "EGL_KHR_swap_buffers_with_damage",
> + .entrypoint = "eglSwapBuffersWithDamageKHR",
> + },
> + };
> struct gl_renderer *gr = get_renderer(ec);
> const char *extensions;
> EGLBoolean ret;
> @@ -2815,12 +2827,17 @@ gl_renderer_setup_egl_extensions(struct
> weston_compositor *ec)
> weston_log("warning: EGL_EXT_buffer_age not supported. "
> "Performance could be affected.\n");
>
> - if (weston_check_egl_extension(extensions,
> "EGL_EXT_swap_buffers_with_damage"))
> - gr->swap_buffers_with_damage =
> - (void *)
> eglGetProcAddress("eglSwapBuffersWithDamageEXT");
> - else
> - weston_log("warning: EGL_EXT_swap_buffers_with_damage not "
> -"supported. Performance could be affected.\n");
> + for (unsigned i = 0; i < ARRAY_LENGTH(foo); i++) {
Yay for not forgetting `i<` :P
> + if (weston_check_egl_extension(extensions, foo[i].extension)) {
> + gr->swap_buffers_with_damage =
> + (void *) eglGetProcAddress(foo[i].entrypoint);
> + break;
> + }
> + }
> + if (!gr->swap_buffers_with_damage)
> + weston_log("warning: neither %s or %s is supported. "
> +"Performance could be affected.\n",
> +foo[0].extension, foo[1].extension);
>
> if (weston_check_egl_extension(extensions,
> "EGL_MESA_configless_context"))
> gr->has_configless_context = 1;
> --
> 2.9.3
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
