[ANNOUNCE] wayland-protocols
Hi, With this E-mail I'd like to officially announce the new repository for Wayland protocols and protocol development: wayland-protocols. The repository can be cloned using git clone git://anongit.freedesktop.org/wayland/wayland-protocols and be viewed using a web browser by going to http://cgit.freedesktop.org/wayland/wayland-protocols The purpose of this repository is to decouple Wayland protocol development from the implementation in weston. wayland-protocols will have its own releases not coupled with with wayland/weston releases and will not carry any implementations. Some benefits of introducing a separate repository with separate releases are the reduced burden on always having a complete weston implementation before introducing a new protocol, and the fact that one can introduce changes or additions to non-core Wayland protocol without having to wait a new wayland/weston release. With this said, developers are still urged to implement wayland-protocols protocols in weston, as weston is still the reference compositor, and as such it is most often within weston's scope to carry such implementations. At the point of this announcement, there is yet to be a release of wayland-protocols, but I expect a release to be made in the not to distant future. In its current state, wayland-protocols contain the following unstable protocols: . fullscreen shell . input method . linux dmabuf . pointer gestures . text input . xdg shell And will probably soon contain the following stable protocols: . viewporter (currently scaler) . presentation timing In progress wayland-protocols additions are . tablet support . relative pointer . pointer constraints Other road map:y things for wayland-protocols worth noting is generated protocol documentation and C API (see Peter's wayland-scanner patches). I'd urge anyone to take a look at the README[0] file in toplevel directory in the repository for details about various aspects including how to deal with multiple versions of unstable protocols, how to contribute changes and new protocols, stabilization procedures etc. I won't duplicate all those details here in this E-mail. If there are no further major objections to naming, conventions, procedures etc, I think we are pretty close to a first release. Jonas [0] http://cgit.freedesktop.org/wayland/wayland-protocols/tree/README ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH weston] Fix runtime error caused by missing header inclusion
Hi Daniel. here it is. :-) thank you. __ Yong-iL Joh, Sr.MTS, Wind River -Original Message- From: Daniel Stone [mailto:dan...@fooishbar.org] Sent: Monday, November 16, 2015 7:20 PM To: Joh, Yong-Il (Tolkien) Cc: wayland-devel@lists.freedesktop.org Subject: Re: [PATCH weston] Fix runtime error caused by missing header inclusion Hi Yong-Il, On 14 November 2015 at 06:16, Joh, Yong-Il (Tolkien) wrote: > when I run weston on yocto for qemux86 device, there is an error with > following. > > [08:02:07.897] launching '/usr/lib/weston/weston-ivi-shell-user-interface' > [08:02:08.201] /usr/lib/weston/weston-ivi-shell-user-interface died on > signal 11 > > it is caused everytime > when I build yocto software on Ubuntu 12.04 64bit desktop for qemux86 > device. (not qemux86-64) > > to resolve this, > apply following patch. Thanks for the patch - it looks good to me. Can you please send this patch via git-send-email, instead of inline? Cheers, Daniel 0001-ivi-shell-user-interface-fix-runtime-error-caused-by.patch Description: 0001-ivi-shell-user-interface-fix-runtime-error-caused-by.patch ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete
On Mon, Nov 16, 2015 at 12:02:14PM +, Auke Booij wrote: > On 28 October 2015 at 05:34, Peter Hutterer wrote: > > The frame event groups separate pointer events together. The primary > > use-case > > for this at the moment is diagonal scrolling - a vertical/horizontal scroll > > event can be grouped together to calculate the correct motion vector. > > Frame events group all wl_pointer events. An example sequence of motion > > events > > followed by a diagonal scroll followed by a button event is: > > wl_pointer.motion > > wl_pointer.frame > > wl_pointer.motion > > wl_pointer.frame > > wl_pointer.axis > > wl_pointer.axis > > wl_pointer.frame > > wl_pointer.button > > wl_pointer.frame > > > > In the future, other extensions may insert additional information about an > > event into the frame. For example, an extension may add information about > > the > > physical device that generated an event into the frame. For this reason, > > enter/leave events are grouped by a frame event too. > > > > The axis_source event determines how an axis event was generated. That > > enables > > clients to judge when to use kinetic scrolling. Only one axis_source event > > is > > allowed per frame and applies to all events in this frame. > > > > The axis_stop event notifies a client about the termination of a scroll > > sequence, likewise needed to calculate kinetic scrolling parameters. > > Multiple axis_stop events within the same frame indicate that scrolling has > > stopped in all these axis at the same time. > > > > The axis_discrete event provides the wheel click count. Previously the axis > > value was some hardcoded number (10), with the discrete steps this enables a > > client to differ between line-based scrolling on a mouse wheel and smooth > > scrolling with a touchpad. > > > > We can't extend the existing wl_pointer.axis events so we introduce a new > > concept: latching events. These events (currently only axis_discrete) > > are prefixed before a wl_pointer.axis event. A client must build the full > > state of the event until the respective top-level event arrives. > > i.e. a single event frame for a diagonal scroll with discrete information > > may > > be: > > > > wl_pointer.axis_source > > wl_pointer.axis_discrete > > wl_pointer.axis > > wl_pointer.axis_discrete > > wl_pointer.axis > > wl_pointer.frame > > > > Signed-off-by: Peter Hutterer > > --- > > (as for your tablet protocol patch) Perhaps we can use the enum > attribute here as well: > > > ... > > ... > fwiw, the latter two are just enum="axis". I've merged this in locally now, thanks. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 wayland 3/3] doc: generate doxygen html output from the scanner
This switches the scanner to generate doxygen-compatible tags for the
generated protocol headers, and hooks up the doxygen build to generate server
and client-side API documentation.
Each protocol is a separate doxygen @page, with each interface a @subpage.
Wayland only has one protocol, wayland-protocols will have these nested.
Each protocol page has a list of interfaces and the copyright and description
where available.
All interfaces are grouped by doxygen @defgroup and @ingroups and appear in
"Modules" in the generated output. Each interface subpage has the description
and a link to the actual API doc.
Function, struct and #defines are documented in doxygen style and associated
with the matching interface.
Note that pages and groups have fixed HTML file names and are directly
linkable/bookmark-able.
The @mainpage is a separate file that's included at build time. It doesn't
contain much other than links to where the interesting bits are. It's a static
file though that supports markdown, so we can extend it easily in the future.
For doxygen we need the new options EXTRACT_ALL and OPTIMIZE_OUTPUT_FOR_C so
it scans C code properly. EXTRACT_STATIC is needed since most of the protocol
hooks are static. WARN_IF_DOC_ERROR is required to silence the warnings when
some parameters are documented but others aren't.
Signed-off-by: Peter Hutterer
---
Changes to v1:
- rebase to master (c7bada036db1b)
- add EXTRACT_STATIC doxygen command, otherwise we'll miss most of the
actual functions in the protocol API.
doc/doxygen/Makefile.am| 27 +-
doc/doxygen/mainpage.dox | 13 +++
doc/doxygen/wayland.doxygen.in | 5 +-
src/scanner.c | 207 +++--
4 files changed, 177 insertions(+), 75 deletions(-)
create mode 100644 doc/doxygen/mainpage.dox
diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am
index a8bb95f..e80c401 100644
--- a/doc/doxygen/Makefile.am
+++ b/doc/doxygen/Makefile.am
@@ -1,7 +1,11 @@
.SUFFIXES = .gv .png .map
-noinst_DATA = xml/Client/index.xml xml/Server/index.xml
+noinst_DATA = \
+ xml/Client/index.xml \
+ xml/Server/index.xml \
+ html/Client/index.html \
+ html/Server/index.html
dist_noinst_DATA = wayland.doxygen.in
scanned_src_files_shared = \
@@ -27,6 +31,17 @@ scanned_src_files_man =
\
$(top_srcdir)/src/wayland-client.h \
$(top_srcdir)/src/wayland-client-core.h
+extra_doxygen = \
+ mainpage.dox
+
+extra_doxygen_Server = \
+ $(top_builddir)/protocol/wayland-server-protocol.h \
+ $(extra_doxygen)
+
+extra_doxygen_Client = \
+ $(top_builddir)/protocol/wayland-client-protocol.h \
+ $(extra_doxygen)
+
diagramsdir := $(srcdir)/dot
diagramssrc := $(wildcard $(diagramsdir)/*.gv)
diagrams := $(patsubst $(diagramsdir)/%,xml/%,$(diagramssrc:.gv=.png))
@@ -38,7 +53,7 @@ diagram_maps := $(patsubst
$(diagramsdir)/%,xml/%,$(diagramssrc:.gv=.map))
dist_man3_MANS = $(shell test -d man && find man/man3 -name "wl_*.3" -printf
"man/man3/%P\n")
# Listing various directories that might need to be created.
-alldirs := xml xml/Client xml/Server man/man3
+alldirs := xml xml/Client xml/Server man/man3 html/Client html/Server
$(diagrams): $(diagramssrc)
@@ -51,6 +66,13 @@ xml/%/index.xml: $(top_srcdir)/src/scanner.c
$(scanned_src_files_%) wayland.doxy
echo "INPUT= $(scanned_src_files_$*)"; \
) | $(DOXYGEN) -
+html/%/index.html: $(scanned_src_files_%) wayland.doxygen $(diagrams)
$(diagram_maps) | html/%
+ $(AM_V_GEN)(cat wayland.doxygen; \
+ echo "GENERATE_HTML=YES"; \
+ echo "HTML_OUTPUT=html/$*"; \
+ echo "INPUT= $(scanned_src_files_$*) $(extra_doxygen_$*)"; \
+ ) | $(DOXYGEN) -
+
man/man3/wl_display.3: $(top_srcdir)/src/scanner.c $(scanned_src_files_man)
wayland.doxygen | man/man3
$(AM_V_GEN)(cat wayland.doxygen; \
echo "GENERATE_MAN=YES"; \
@@ -74,6 +96,7 @@ all-local: man/man3/wl_display.3
clean-local:
rm -rf xml/
+ rm -rf html/
rm -rf man/
EXTRA_DIST = $(diagramssrc)
diff --git a/doc/doxygen/mainpage.dox b/doc/doxygen/mainpage.dox
new file mode 100644
index 000..8f9bf03
--- /dev/null
+++ b/doc/doxygen/mainpage.dox
@@ -0,0 +1,13 @@
+/**
+ * @mainpage
+ * Wayland protocol API documentation.
+ *
+ * @section ifaces Interfaces
+ * For the list of available interfaces, please see the
+ * modules list.
+ *
+ * @section protocols Protocols
+ * For the list of protocols, please see the
+ * Related Pages.
+ *
+ */
diff --git a/doc/doxygen/wayland.doxygen.in b/doc/doxygen/wayland.doxygen.in
index fb76b12..bf188cb 100644
--- a/doc/doxygen/wayland.doxygen.in
+++ b/doc/doxygen/wayland.doxygen.in
@@ -13,4 +13,7 @@ MACRO_EXPANSION= YES
EXPAND_ONLY_PREDEF = YES
DOT_MULTI_TARGETS = YES
ALIASES+= comment{1
Re: [PATCH wayland-protocols] Add the tablet protocol
Hi Daniel, Thanks for the review. I'll reply to a few select pieces, anything skipped is something I'll just fold into the next diff. On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote: > Peter, Stephen, > > On 6 November 2015 at 04:24, Peter Hutterer wrote: > > This is the revamped version of the tablet protocol for graphics tablets > > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > > so), so I won't detail them, best to look at it with fresh eyes. > > Thanks a lot for doing this! Looks really good to me, and I think > getting it in wayland-protocols would be good. > > Do you have other implementations, e.g. GTK+/Mutter? If so, a pointer > (ha) to those would be great. > > Obligatory nitpicks follow: > > > + > > + > > + > > +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. > > Yes, it turns out the wl_seat.get_* model was probably a pretty bad > anti-pattern. Oh well. To avoid too much object proliferation though, > how about something like: > > > > Add a seat of interest to this tablet manager. The client will > receive events for all tablets currently on this seat, as well as > tablets added to this seat in future. > > > > [inline wp_tablet_seat here ...] > > > Then you can just bin wp_tablet_seat. > > Not a pattern we've previously employed, but I think it's a good one > that avoids one extra step of indirection, as well as making it a bit > easier for clients to do the right thing. > > > +The wp_tablet_seat sends a "tablet added" for each tablet connected. > > +That event is followed by descriptive events about the hardware; > > +currently that includes events for name, vid/pid and > > +internal/external/display type, and a wp_tablet.path event that > > +describes a local path. This path can be used to uniquely identify a > > +tablet, or get more information through libwacom. Emulated or nested > > +tablets can skip any of those, e.g. a virtual tablet may not have a > > +vid/pid. The sequence of descriptive events is terminated by a > > +wp_tablet.done event to signal that a client may now finalize any > > +initialization for that tablet. > > Is VID/PID in USB space? (Answers in diff form preferred.) > > > +Two special events (that don't exist in X) are down and up. They signal > > +"tip touching the surface". For tablets without real proximity > > +detection, the sequence is: proximity_in, motion, down, frame. > > + > > +When the tool leaves proximity, a proximity_out event is sent, followed > > +by button release events for any button still down. This signals to > > +the client that the buttons were held when the tool left proximity. > > +Those events are all sent within the same frame. > > Can we please enforce a strict bracketing of down/up occurring in > matched pairs inside of proximity_in/out? So, the total event stream > would be: > - proximity_in > - motion > - down > - motion/motion/button/... > - up > - proximity_out > > I assume the implementation does this, but it would be nice to have > encoded in the protocol. the original plan was to have the proximity out event sent before the button event iff the tool goes out of proximity with the button still pressed. the frame events (similar to SYN_REPORT) group them together, so as long as you process those correctly you still know the state. so the order would be, and I'm using button event here rather than the tip event because that is actually likely to happen: - proximity_in - motion - frame - button down - frame - proximity out - button up - frame The above signals that the button was still down during proximity. but you're right, it be easier to pair them symmetrically and any sensible client that handles frame events correctly will do exactly the right thing. So the above would turn into: - proximity_in - motion - frame - button down - frame - button up - proximity out - frame I'll reword that. > > +If the tool moves out of the surface but stays in proximity (i.e. > > +between windows), compositor-specific grab policies apply. This usually > > +means that the proximity-out is delayed until all buttons are released. > > If no buttons are down, we'd _expect_ to just get a proximity_out >
Re: [PATCH wayland-protocols] Add the tablet protocol
On Mon, Nov 16, 2015 at 12:07:12PM +, Daniel Stone wrote: > Hi Jonas, > > On 16 November 2015 at 11:59, Jonas Ådahl wrote: > > On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote: > >> On 6 November 2015 at 04:24, Peter Hutterer > >> wrote: > >> > +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. > >> > >> Yes, it turns out the wl_seat.get_* model was probably a pretty bad > >> anti-pattern. Oh well. To avoid too much object proliferation though, > >> how about something like: > >> > >> > >> > >> Add a seat of interest to this tablet manager. The client will > >> receive events for all tablets currently on this seat, as well as > >> tablets added to this seat in future. > >> > >> > >> > >> [inline wp_tablet_seat here ...] > >> > >> > >> Then you can just bin wp_tablet_seat. > >> > >> Not a pattern we've previously employed, but I think it's a good one > >> that avoids one extra step of indirection, as well as making it a bit > >> easier for clients to do the right thing. > > > > How would it be easier for clients to do the right thing? It'd just make > > it easy to mix different seats' tools and tablets as there would be no > > more separation (except if one would bind a tablet manager per seat). Or > > should tools and tablets be considered on the same "super seat", i.e. > > would it be possible to see tool A from seat X on tablet V on seat Y? > > It makes it easier, because right now we expect them to hold a > wp_tablet_manager, respond to new seats by creating a new > wp_tablet_seat, and having them respond to events on that as well. We > already make people hold absolute piles of objects, so one less seems > like it could be a good thing. I have to say it sounds a lot worse in the protocol than it is in the implementation. But this was the easiest bit of the implementation, clients already have some wrapper object for the wl_seat anyway, this just adds one pointer for the tablet seat to that object, plus one global one for the tablet manager. [1] And that too is just adding one more pointer to existing infrastructure. And the effective cost is minimal - how many wl_seats do we expect in the worst case? 10? In the 99% case we only have one and that's what IMO we should optimise for (and the code would look identical anyway since in the client it'll all hang off the struct seat_something). I think that the potential confusion of mixing tablets from different seats is a lot worse than the extra objects here. Cheers, Peter [1] https://github.com/whot/weston/commit/64dc64a4dbabd7fbe1b6b80a2a08ff2cc8c0c288#diff-87a1da5a7e6453c81e19091e66a9015dR5757 > > Seems to me that making it possible to shove all seats in one pile is > > more error prone than having them clearly separated. > > Possibly. I guess it depends on the failure mode. I can see it either way. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v6 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete
On Mon, Nov 16, 2015 at 10:57:24AM +1000, Peter Hutterer wrote: > The frame event groups separate pointer events together. The primary use-case > for this at the moment is diagonal scrolling - a vertical/horizontal scroll > event can be grouped together to calculate the correct motion vector. > Frame events group all wl_pointer events. An example sequence of motion events > followed by a diagonal scroll followed by a button event is: > wl_pointer.motion > wl_pointer.frame > wl_pointer.motion > wl_pointer.frame > wl_pointer.axis > wl_pointer.axis > wl_pointer.frame > wl_pointer.button > wl_pointer.frame > > In the future, other extensions may insert additional information about an > event into the frame. For example, an extension may add information about the > physical device that generated an event into the frame. For this reason, > enter/leave events are grouped by a frame event too. > > The axis_source event determines how an axis event was generated. That enables > clients to judge when to use kinetic scrolling. Only one axis_source event is > allowed per frame and applies to all events in this frame. > > The axis_stop event notifies a client about the termination of a scroll > sequence, likewise needed to calculate kinetic scrolling parameters. > Multiple axis_stop events within the same frame indicate that scrolling has > stopped in all these axis at the same time. > > The axis_discrete event provides the wheel click count. Previously the axis > value was some hardcoded number (10), with the discrete steps this enables a > client to differ between line-based scrolling on a mouse wheel and smooth > scrolling with a touchpad. > > We can't extend the existing wl_pointer.axis events so we introduce a new > concept: latching events. These events (currently only axis_discrete) > are prefixed before a wl_pointer.axis event. A client must build the full > state of the event until the respective top-level event arrives. > i.e. a single event frame for a diagonal scroll with discrete information may > be: > > wl_pointer.axis_source > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.frame > > Signed-off-by: Peter Hutterer > Reviewed-by: Carlos Garnacho Reviewed-by: Bryce Harrington > --- > Changes to v5: > - rewordings requested by Bryce and Jonas added (and the copyedits) > - enum field declared as enum > > protocol/wayland.xml | 148 > +-- > 1 file changed, 145 insertions(+), 3 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 9c22d45..12962a0 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1411,7 +1411,7 @@ > > > > - > + > >The wl_pointer interface represents one or more input devices, >such as mice, which control the pointer location and pointer_focus > @@ -1578,9 +1578,151 @@ > > > > + > + > + > + > + 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. > + > + All wl_pointer events before a wl_pointer.frame event belong > + logically together. For example, in a diagonal scroll motion the > + compositor will send an optional wl_pointer.axis_source event, two > + wl_pointer.axis events (horizontal and vertical) and finally a > + wl_pointer.frame event. The client may use this information to > + calculate a diagonal vector for scrolling. > + > + When multiple wl_pointer.axis events occur within the same frame, > + the motion vector is the combined motion of all events. > + When a wl_pointer.axis and a wl_pointer.axis_stop event occur within > + the same frame, this indicates that axis movement in one axis has > + stopped but continues in the other axis. > + When multiple wl_pointer.axis_stop events occur within in the same > + frame, this indicates that these axes stopped in the same instance. > + > + A wl_pointer.frame event is sent for every logical event group, > + even if the group only contains a single wl_pointer event. > + Specifically, a client may get a sequence: motion, frame, button, > + frame, axis, frame, axis_stop, frame. > + > + The wl_pointer.enter and wl_pointer.leave events are logical events > + generated by the compositor and not the hardware. These events are > + also grouped by a wl_pointer.frame. > + > + > + > + > + > + Describes the source types for axis events. This indicates to the > + client how an axis event was physically generated; a client may > + adjust the user interface accordingly. For example, scroll events > + from a "finger" source may be in a smooth coordinate space with > + kinetic scrolling whereas a "wheel" source may be in discrete steps > + of a number of lines. > + > + The "contin
Re: [PATCH weston v2 1/5] compositor-wayland: Change focus to a bool instead of an int
On Fri, Nov 06, 2015 at 03:56:06PM -0600, Derek Foreman wrote:
> Also rename focus to has_focus to be slightly less confusing.
>
> Signed-off-by: Derek Foreman
Reviewed-by: Bryce Harrington
Pushed:
remote: I: patch #64087 updated using rev
4bcc54d1a56057293d3a7a34e9592707406a6c9a
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/wayland/weston
1118952..4bcc54d master -> master
> ---
>
> Changes from v1:
> rename focus to has_focus
> src/compositor-wayland.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
> index a819867..0f3a1a7 100644
> --- a/src/compositor-wayland.c
> +++ b/src/compositor-wayland.c
> @@ -177,7 +177,8 @@ struct wayland_input {
> enum weston_key_state_update keyboard_state_update;
> uint32_t key_serial;
> uint32_t enter_serial;
> - int focus;
> + bool has_focus;
> +
> struct wayland_output *output;
> struct wayland_output *keyboard_focus;
> };
> @@ -1296,12 +1297,12 @@ input_handle_pointer_enter(void *data, struct
> wl_pointer *pointer,
> weston_output_transform_coordinate(&input->output->base, x, y, &x, &y);
>
> if (location == THEME_LOCATION_CLIENT_AREA) {
> - input->focus = 1;
> + input->has_focus = true;
> notify_pointer_focus(&input->base, &input->output->base, x, y);
> wl_pointer_set_cursor(input->parent.pointer,
> input->enter_serial, NULL, 0, 0);
> } else {
> - input->focus = 0;
> + input->has_focus = false;
> notify_pointer_focus(&input->base, NULL, 0, 0);
> input_set_cursor(input);
> }
> @@ -1325,7 +1326,7 @@ input_handle_pointer_leave(void *data, struct
> wl_pointer *pointer,
>
> notify_pointer_focus(&input->base, NULL, 0, 0);
> input->output = NULL;
> - input->focus = 0;
> + input->has_focus = false;
> }
>
> static void
> @@ -1355,15 +1356,16 @@ input_handle_motion(void *data, struct wl_pointer
> *pointer,
>
> weston_output_transform_coordinate(&input->output->base, x, y, &x, &y);
>
> - if (input->focus && location != THEME_LOCATION_CLIENT_AREA) {
> + if (input->has_focus && location != THEME_LOCATION_CLIENT_AREA) {
> input_set_cursor(input);
> notify_pointer_focus(&input->base, NULL, 0, 0);
> - input->focus = 0;
> - } else if (!input->focus && location == THEME_LOCATION_CLIENT_AREA) {
> + input->has_focus = false;
> + } else if (!input->has_focus &&
> +location == THEME_LOCATION_CLIENT_AREA) {
> wl_pointer_set_cursor(input->parent.pointer,
> input->enter_serial, NULL, 0, 0);
> notify_pointer_focus(&input->base, &input->output->base, x, y);
> - input->focus = 1;
> + input->has_focus = true;
> }
>
> if (location == THEME_LOCATION_CLIENT_AREA)
> --
> 2.6.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] add wl_abort private function
On Mon, Nov 16, 2015 at 02:01:20PM -0600, Derek Foreman wrote:
> On 16/11/15 04:49 AM, Marek Chalupa wrote:
> > On many places in the code we use wl_log + abort or wl_log + assert(0).
> > Replace these with one call to wl_abort, so that we don't mix abort(),
> > assert(0) and we'll save few lines
> >
> > Signed-off-by: Marek Chalupa
>
> Sure, I think this looks cleaner than before - and I agree with Bill
> that the assert(0); calls really should've been abort() instead.
>
> Reviewed-by: Derek Foreman
Pushed:
remote: I: patch #64884 updated using rev
c7bada036db1b630bbd4de8a31914b521d3bcdd1
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/wayland/wayland
5660ea4..c7bada0 master -> master
dorset+14.04:~/src/Wayland/wayland$
> > ---
> > src/connection.c | 22 +++---
> > src/wayland-client.c | 12
> > src/wayland-private.h | 1 +
> > src/wayland-util.c| 12
> > tests/sanity-test.c | 7 ++-
> > 5 files changed, 30 insertions(+), 24 deletions(-)
> >
> > diff --git a/src/connection.c b/src/connection.c
> > index b3d9bd4..6742f19 100644
> > --- a/src/connection.c
> > +++ b/src/connection.c
> > @@ -33,7 +33,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -569,16 +568,12 @@ wl_closure_marshal(struct wl_object *sender, uint32_t
> > opcode,
> > case 'h':
> > fd = args[i].h;
> > dup_fd = wl_os_dupfd_cloexec(fd, 0);
> > - if (dup_fd < 0) {
> > - wl_log("dup failed: %m");
> > - abort();
> > - }
> > + if (dup_fd < 0)
> > + wl_abort("dup failed: %s\n", strerror(errno));
> > closure->args[i].h = dup_fd;
> > break;
> > default:
> > - wl_log("unhandled format code: '%c'\n",
> > - arg.type);
> > - assert(0);
> > + wl_abort("unhandled format code: '%c'\n", arg.type);
> > break;
> > }
> > }
> > @@ -771,8 +766,7 @@ wl_connection_demarshal(struct wl_connection
> > *connection,
> > closure->args[i].h = fd;
> > break;
> > default:
> > - wl_log("unknown type\n");
> > - assert(0);
> > + wl_abort("unknown type\n");
> > break;
> > }
> > }
> > @@ -906,8 +900,7 @@ convert_arguments_to_ffi(const char *signature,
> > uint32_t flags,
> > ffi_args[i] = &args[i].h;
> > break;
> > default:
> > - wl_log("unknown type\n");
> > - assert(0);
> > + wl_abort("unknown type\n");
> > break;
> > }
> > }
> > @@ -938,9 +931,8 @@ wl_closure_invoke(struct wl_closure *closure, uint32_t
> > flags,
> >
> > implementation = target->implementation;
> > if (!implementation[opcode]) {
> > - wl_log("listener function for opcode %u of %s is NULL\n",
> > - opcode, target->interface->name);
> > - abort();
> > + wl_abort("listener function for opcode %u of %s is NULL\n",
> > +opcode, target->interface->name);
> > }
> > ffi_call(&cif, implementation[opcode], NULL, ffi_args);
> > }
> > diff --git a/src/wayland-client.c b/src/wayland-client.c
> > index b1c600f..509be08 100644
> > --- a/src/wayland-client.c
> > +++ b/src/wayland-client.c
> > @@ -597,18 +597,14 @@ wl_proxy_marshal_array_constructor(struct wl_proxy
> > *proxy,
> > }
> >
> > closure = wl_closure_marshal(&proxy->object, opcode, args, message);
> > - if (closure == NULL) {
> > - wl_log("Error marshalling request: %m\n");
> > - abort();
> > - }
> > + if (closure == NULL)
> > + wl_abort("Error marshalling request: %s\n", strerror(errno));
> >
> > if (debug_client)
> > wl_closure_print(closure, &proxy->object, true);
> >
> > - if (wl_closure_send(closure, proxy->display->connection)) {
> > - wl_log("Error sending request: %m\n");
> > - abort();
> > - }
> > + if (wl_closure_send(closure, proxy->display->connection))
> > + wl_abort("Error sending request: %s\n", strerror(errno));
> >
> > wl_closure_destroy(closure);
> >
> > diff --git a/src/wayland-private.h b/src/wayland-private.h
> > index da9040a..58ac952 100644
> > --- a/src/wayland-private.h
> > +++ b/src/wayland-private.h
> > @@ -209,6 +209,7 @@ wl_closure_destroy(struct wl_closure *closure);
> > extern wl_log_func_t wl_log_handler;
> >
> > void wl_log(const char *fmt, ...);
> > +void wl_abort(const char *fmt, ...);
> >
> > struct wl_display;
> >
> > diff
Re: [PATCH wayland 3/3] doc: generate doxygen html output from the scanner
On Fri, Nov 06, 2015 at 08:02:01AM +1000, Peter Hutterer wrote: > This switches the scanner to generate doxygen-compatible tags for the > generated protocol headers, and hooks up the doxygen build to generate server > and client-side API documentation. > > Each protocol is a separate doxygen @page, with each interface a @subpage. > Wayland only has one protocol, wayland-protocols will have these nested. > Each protocol page has a list of interfaces and the copyright and description > where available. > All interfaces are grouped by doxygen @defgroup and @ingroups and appear in > "Modules" in the generated output. Each interface subpage has the description > and a link to the actual API doc. > Function, struct and #defines are documented in doxygen style and associated > with the matching interface. > > Note that pages and groups have fixed HTML file names and are directly > linkable/bookmark-able. > > The @mainpage is a separate file that's included at build time. It doesn't > contain much other than links to where the interesting bits are. It's a static > file though that supports markdown, so we can extend it easily in the future. > > For doxygen we need the new options EXTRACT_ALL and OPTIMIZE_OUTPUT_FOR_C so > it scans C code properly. WARN_IF_DOC_ERROR is required to silence the > warnings when some parameters are documented but others aren't. > > Signed-off-by: Peter Hutterer Reviewed-by: Bryce Harrington This looks fine to me in general, but would you mind respinning it to apply against current HEAD? There's a couple really minor questions below. Bryce > --- > Generated output for wayland and wayland-protocols is here: > http://people.freedesktop.org/~whot/wayland-doxygen/ > > * as discussed in the other thread, this doesn't touch the current generated > xml files, the current doc doesn't actually include the protocol API > anyway. > * mainpage is separate because it's easier this way for wayland-protocols > * the generated code contains a lot of comment now but is still readable. > Only duplication is the copyright (once at file level, once as protocol > section), but that shouldn't hurt anyone. > * we should start including tags at the level. the > scanner supports it and it provides extra info (see the tablet > protocol in wayland-protocols) > > doc/doxygen/Makefile.am| 27 +- > doc/doxygen/mainpage.dox | 13 +++ > doc/doxygen/wayland.doxygen.in | 4 +- > src/scanner.c | 207 > +++-- > 4 files changed, 176 insertions(+), 75 deletions(-) > create mode 100644 doc/doxygen/mainpage.dox > > diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am > index a8bb95f..e80c401 100644 > --- a/doc/doxygen/Makefile.am > +++ b/doc/doxygen/Makefile.am > @@ -1,7 +1,11 @@ > > .SUFFIXES = .gv .png .map > > -noinst_DATA = xml/Client/index.xml xml/Server/index.xml > +noinst_DATA = \ > + xml/Client/index.xml \ > + xml/Server/index.xml \ > + html/Client/index.html \ > + html/Server/index.html > dist_noinst_DATA = wayland.doxygen.in > > scanned_src_files_shared = \ > @@ -27,6 +31,17 @@ scanned_src_files_man = > \ > $(top_srcdir)/src/wayland-client.h \ > $(top_srcdir)/src/wayland-client-core.h > > +extra_doxygen = \ > + mainpage.dox > + > +extra_doxygen_Server = \ > + $(top_builddir)/protocol/wayland-server-protocol.h \ > + $(extra_doxygen) > + > +extra_doxygen_Client = \ > + $(top_builddir)/protocol/wayland-client-protocol.h \ > + $(extra_doxygen) > + > diagramsdir := $(srcdir)/dot > diagramssrc := $(wildcard $(diagramsdir)/*.gv) > diagrams := $(patsubst $(diagramsdir)/%,xml/%,$(diagramssrc:.gv=.png)) > @@ -38,7 +53,7 @@ diagram_maps := $(patsubst > $(diagramsdir)/%,xml/%,$(diagramssrc:.gv=.map)) > dist_man3_MANS = $(shell test -d man && find man/man3 -name "wl_*.3" -printf > "man/man3/%P\n") > > # Listing various directories that might need to be created. > -alldirs := xml xml/Client xml/Server man/man3 > +alldirs := xml xml/Client xml/Server man/man3 html/Client html/Server > > $(diagrams): $(diagramssrc) > > @@ -51,6 +66,13 @@ xml/%/index.xml: $(top_srcdir)/src/scanner.c > $(scanned_src_files_%) wayland.doxy >echo "INPUT= $(scanned_src_files_$*)"; \ >) | $(DOXYGEN) - > > +html/%/index.html: $(scanned_src_files_%) wayland.doxygen $(diagrams) > $(diagram_maps) | html/% > + $(AM_V_GEN)(cat wayland.doxygen; \ > + echo "GENERATE_HTML=YES"; \ > + echo "HTML_OUTPUT=html/$*"; \ > + echo "INPUT= $(scanned_src_files_$*) $(extra_doxygen_$*)"; \ > + ) | $(DOXYGEN) - > + > man/man3/wl_display.3: $(top_srcdir)/src/scanner.c $(scanned_src_files_man) > wayland.doxygen | man/man3 > $(AM_V_GEN)(cat wayland.doxygen; \ >echo "GENERATE_MAN=YES"; \ > @@ -74,6 +96,7 @@
Re: [PATCH wayland-protocols] Add the tablet protocol
On Mon, Nov 16, 2015 at 11:55 AM, Carlos Garnacho wrote: > It's probably worth pointing out that his concerns are moot, there is > no blinking, or rather, has an easy solution in compositors. > > When a tool physically enters in proximity over a surface, the cursor > should be effectively invisible, the client below it will emit > wp_tablet_tool.set_cursor in response to proximity_in, and it will be > set accordingly from the previous invisible state. If the tool moves > across surfaces, the cursor won't be modified until the new focus > surface calls wp_tablet_tool.set_cursor, just like it happens with > wl_pointer.set_cursor and wl_pointer.enter. When the tool physically > leaves proximity, the cursor would be made invisible, destroyed, or > whatnot. > > Compositors may of course want to set a default cursor if the > proximity_in happened outside a surface, so that there's something > visible until the tool enters a surface, but this is easy enough to > detect before even showing the cursor. AFAICS the only source of > "blinking" would be compositors invariably setting a visible cursor > before the client has an opportunity to do so, that sounds somewhat > sloppy though. > I'm not sure why you think I am arguing for an old point, as Carlos describes exactly the same thing I am thinking of. His proposal removes the need for there to be a per-tool cursor in the client api. The client only sets the cursor for the most recent tool, and the user can only see one cursor. IMHO this can be done in the easiest way by reusing the wl_pointer api, rather than adding new api that clients will just be forced to select between because only one of the api's works at any time. He is proposing the "strong" version of what I said, which is that the cursor is actually frozen (not moving or changing) until a cursor-set is received from the client that has focus. If this is a good idea it probably should be done for normal pointer enter events as well. The benifit of this is that it obeys the "every frame is perfect" rule of Wayland. I was assuming a "soft" version that works like the current pointer enter events, where the cursor does not change but follows the pointer without waiting for the client to set the image. The cursor image is thus a "guess" by the compositor. IMHO the best "guess" is to leave the cursor unchanged from whatever it is now, as this will reduce the number of transitions when the guess is wrong, and it is how enter events work currently. However a compositor could try to save a "guess" that tracks the cursor per-tool, per-surface, or even per tool+surface combination. None of that should be visible in the client api however. Changing the cursor on proximity-in outside any client is an interesting problem. I think the compositor should be entirely in charge of this, though "guessing" that it is the same as the most-recent client, which seems to be the proposal here, may be reasonable. The compositor is still going to need an image to use if no client has gotten a proximity-in yet, so this does not remove the need for it to supply something without client help. I also have no idea what you mean by this being a repeat of some mistake done by X11. I am not changing in any way what events are being received by the client compared to the current proposal, therefore if my idea is wrong, so is the current proposal. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] protocol: Define further the behavior of input on the presence of grabs
On Monday, 16 November 2015, Bill Spitzak wrote: > > Exit events generated by the client's own actions are a huge pain, it > forces clients to look ahead for the enter event to distinguish between the > focus moving to another surface and losing it entirely. This should be > fixed. A few ideas: > Sigh, please not this again. Every time anything even tenuously related comes up, you bring this up. The result is going to be the exact same as every other time. Please just mentally write this off as a lost battle and refrain from bringing it up at great length for the 47th time. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] add wl_abort private function
On 16/11/15 04:49 AM, Marek Chalupa wrote:
> On many places in the code we use wl_log + abort or wl_log + assert(0).
> Replace these with one call to wl_abort, so that we don't mix abort(),
> assert(0) and we'll save few lines
>
> Signed-off-by: Marek Chalupa
Sure, I think this looks cleaner than before - and I agree with Bill
that the assert(0); calls really should've been abort() instead.
Reviewed-by: Derek Foreman
> ---
> src/connection.c | 22 +++---
> src/wayland-client.c | 12
> src/wayland-private.h | 1 +
> src/wayland-util.c| 12
> tests/sanity-test.c | 7 ++-
> 5 files changed, 30 insertions(+), 24 deletions(-)
>
> diff --git a/src/connection.c b/src/connection.c
> index b3d9bd4..6742f19 100644
> --- a/src/connection.c
> +++ b/src/connection.c
> @@ -33,7 +33,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -569,16 +568,12 @@ wl_closure_marshal(struct wl_object *sender, uint32_t
> opcode,
> case 'h':
> fd = args[i].h;
> dup_fd = wl_os_dupfd_cloexec(fd, 0);
> - if (dup_fd < 0) {
> - wl_log("dup failed: %m");
> - abort();
> - }
> + if (dup_fd < 0)
> + wl_abort("dup failed: %s\n", strerror(errno));
> closure->args[i].h = dup_fd;
> break;
> default:
> - wl_log("unhandled format code: '%c'\n",
> - arg.type);
> - assert(0);
> + wl_abort("unhandled format code: '%c'\n", arg.type);
> break;
> }
> }
> @@ -771,8 +766,7 @@ wl_connection_demarshal(struct wl_connection *connection,
> closure->args[i].h = fd;
> break;
> default:
> - wl_log("unknown type\n");
> - assert(0);
> + wl_abort("unknown type\n");
> break;
> }
> }
> @@ -906,8 +900,7 @@ convert_arguments_to_ffi(const char *signature, uint32_t
> flags,
> ffi_args[i] = &args[i].h;
> break;
> default:
> - wl_log("unknown type\n");
> - assert(0);
> + wl_abort("unknown type\n");
> break;
> }
> }
> @@ -938,9 +931,8 @@ wl_closure_invoke(struct wl_closure *closure, uint32_t
> flags,
>
> implementation = target->implementation;
> if (!implementation[opcode]) {
> - wl_log("listener function for opcode %u of %s is NULL\n",
> - opcode, target->interface->name);
> - abort();
> + wl_abort("listener function for opcode %u of %s is NULL\n",
> + opcode, target->interface->name);
> }
> ffi_call(&cif, implementation[opcode], NULL, ffi_args);
> }
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index b1c600f..509be08 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c
> @@ -597,18 +597,14 @@ wl_proxy_marshal_array_constructor(struct wl_proxy
> *proxy,
> }
>
> closure = wl_closure_marshal(&proxy->object, opcode, args, message);
> - if (closure == NULL) {
> - wl_log("Error marshalling request: %m\n");
> - abort();
> - }
> + if (closure == NULL)
> + wl_abort("Error marshalling request: %s\n", strerror(errno));
>
> if (debug_client)
> wl_closure_print(closure, &proxy->object, true);
>
> - if (wl_closure_send(closure, proxy->display->connection)) {
> - wl_log("Error sending request: %m\n");
> - abort();
> - }
> + if (wl_closure_send(closure, proxy->display->connection))
> + wl_abort("Error sending request: %s\n", strerror(errno));
>
> wl_closure_destroy(closure);
>
> diff --git a/src/wayland-private.h b/src/wayland-private.h
> index da9040a..58ac952 100644
> --- a/src/wayland-private.h
> +++ b/src/wayland-private.h
> @@ -209,6 +209,7 @@ wl_closure_destroy(struct wl_closure *closure);
> extern wl_log_func_t wl_log_handler;
>
> void wl_log(const char *fmt, ...);
> +void wl_abort(const char *fmt, ...);
>
> struct wl_display;
>
> diff --git a/src/wayland-util.c b/src/wayland-util.c
> index 00265e9..e782309 100644
> --- a/src/wayland-util.c
> +++ b/src/wayland-util.c
> @@ -385,3 +385,15 @@ wl_log(const char *fmt, ...)
> wl_log_handler(fmt, argp);
> va_end(argp);
> }
> +
> +void
> +wl_abort(const char *fmt, ...)
> +{
> + va_list argp;
> +
> + va_start(argp, fmt);
> + wl_log_handler(fmt, argp);
> + va_end(argp);
> +
> + abort();
> +}
> diff --git a/tests/sanity
Re: [PATCH wayland 2/3] doc: make the doxygen output dependent on scanner.c
On Thu, Nov 05, 2015 at 02:21:02PM -0800, Bryce Harrington wrote: > On Fri, Nov 06, 2015 at 08:02:00AM +1000, Peter Hutterer wrote: > > When the scanner changes, we need to rebuild > > > > Signed-off-by: Peter Hutterer > > Reviewed-by: Bryce Harrington Thanks, pushed: remote: I: patch #63925 updated using rev 5660ea414f9a2a81409074346bb6140342e02425 remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/wayland/wayland 10d5f97..5660ea4 master -> master > > --- > > doc/doxygen/Makefile.am | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am > > index 5520d39..a8bb95f 100644 > > --- a/doc/doxygen/Makefile.am > > +++ b/doc/doxygen/Makefile.am > > @@ -44,14 +44,14 @@ $(diagrams): $(diagramssrc) > > > > $(diagram_maps): $(diagramssrc) > > > > -xml/%/index.xml: $(scanned_src_files_%) wayland.doxygen $(diagrams) > > $(diagram_maps) | xml/% > > +xml/%/index.xml: $(top_srcdir)/src/scanner.c $(scanned_src_files_%) > > wayland.doxygen $(diagrams) $(diagram_maps) | xml/% > > $(AM_V_GEN)(cat wayland.doxygen; \ > >echo "GENERATE_XML=YES"; \ > >echo "XML_OUTPUT=xml/$*"; \ > >echo "INPUT= $(scanned_src_files_$*)"; \ > >) | $(DOXYGEN) - > > > > -man/man3/wl_display.3: $(scanned_src_files_man) wayland.doxygen | man/man3 > > +man/man3/wl_display.3: $(top_srcdir)/src/scanner.c > > $(scanned_src_files_man) wayland.doxygen | man/man3 > > $(AM_V_GEN)(cat wayland.doxygen; \ > >echo "GENERATE_MAN=YES"; \ > >echo "MAN_OUTPUT=man"; \ > > -- > > 2.4.3 > > > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 1/3] scanner: don't print trailing whitespaces
On Thu, Nov 05, 2015 at 02:20:04PM -0800, Bryce Harrington wrote:
> On Fri, Nov 06, 2015 at 08:01:59AM +1000, Peter Hutterer wrote:
> > If we're printing a zero-length string, we end up printing " * " and that
> > makes anything unhappy that doesn't handle trailing whitespaces.
> >
> > Signed-off-by: Peter Hutterer
>
> Easy enough.
>
> Reviewed-by: Bryce Harrington
A fix for this by Jon was landed already, that appears to do
functionally the same thing.
Bryce
> > ---
> > src/scanner.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/scanner.c b/src/scanner.c
> > index f456aa5..7b0f482 100644
> > --- a/src/scanner.c
> > +++ b/src/scanner.c
> > @@ -1141,8 +1141,9 @@ format_copyright(const char *copyright)
> > }
> >
> > if (copyright[i] == '\n' || copyright[i] == '\0') {
> > - printf("%s %.*s\n",
> > + printf("%s%s%.*s\n",
> >i == 0 ? "/*" : " *",
> > + (i - start) == 0 ? "" : " ",
> >i - start, copyright + start);
> > bol = 1;
> > }
> > --
> > 2.4.3
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hey, On Mon, Nov 16, 2015 at 8:04 PM, Daniel Stone wrote: > Bill, > > On Monday, 16 November 2015, Bill Spitzak wrote: >> >> There is a need to distinguish proximity-out from exit events. It is quite >> possible to move the stylus so that the focus enters another client without >> doing a proximity-out. Clients are interested in distinguishing these. > > > This is true, hence my suggestion. > >> >> I really feel the best method is to say a "seat" has a keyboard focus and >> a pointer focus, and let the stylus manipulate the pointer focus. Thus the >> client will get enter/exit events as the stylus is moved around above the >> tablet, and proximity in/out when it is moved toward/away from the tablet >> (it may also get a fake proximity-in event on enter). > > > Pointer and tablet/touch are separate. X11 integrated them, and _that_ was a > huge mistake. From our point of view, this is a closed topic. > > We've been over it time and time again, we've seen the ways the alternate > model - though it seems attractive at first, which is why we did it for X11 > - fails, and we're not going back there. > >> >> I really feel the cursor stuff is a huge mistake. It adds lots of >> complexity for almost no actual gain. Witness how much code you had to add >> to toytoolkit to support it. It adds complexity to clients as the client has >> to pass which tool to subroutines for no reason other than to allow them to >> change the correct cursor. The clients cannot assume the tool has the >> "right" cursor and therefore they are required to have code to change it, so >> this removes no complexity from clients. It is also hugely inconsistent with >> how normal pointer enter events are handled in Wayland. > > > It's not 'no actual gain', it's integral to the model. > >> >> The only argument you had was that the cursor is more likely to be >> correct, so when the proximity-in event happens, the cursor that appears has >> a higher chance of being the same as the one the client sets and there will >> be less blinking. However this can be implemented by the compositor without >> any client api. Just have the compositor remember what cursor was used and >> set that as a guess on the enter event. The client can remain completely >> unaware of whether a cursor is remembered per-tool, or per-surface, or per >> tool*surface, or whatever. > > > The reason the protocol does not do this, is because when the cursor is > different, you go from the other-surface cursor, to the old new-surface > cursor, to the new new-surface cursor, very rapidly. It's ugly, and a > bandaid for clients not responding quickly enough. It's probably worth pointing out that his concerns are moot, there is no blinking, or rather, has an easy solution in compositors. When a tool physically enters in proximity over a surface, the cursor should be effectively invisible, the client below it will emit wp_tablet_tool.set_cursor in response to proximity_in, and it will be set accordingly from the previous invisible state. If the tool moves across surfaces, the cursor won't be modified until the new focus surface calls wp_tablet_tool.set_cursor, just like it happens with wl_pointer.set_cursor and wl_pointer.enter. When the tool physically leaves proximity, the cursor would be made invisible, destroyed, or whatnot. Compositors may of course want to set a default cursor if the proximity_in happened outside a surface, so that there's something visible until the tool enters a surface, but this is easy enough to detect before even showing the cursor. AFAICS the only source of "blinking" would be compositors invariably setting a visible cursor before the client has an opportunity to do so, that sounds somewhat sloppy though. Cheers, Carlos ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] protocol: Define further the behavior of input on the presence of grabs
On Thu, Nov 12, 2015 at 4:31 AM, Carlos Garnacho wrote: > The leave events in the respective device interfaces has been further > documented so those can convey the necessary info when input is being > redirected out of their currently focused surface. > > Only wl_touch is missing something semantically similar, a wl_touch.leave > event has been added so the touch interface can cope with such input > redirection situations. > > Changes since v1: > - Reuse leave events for this purpose. This meant one had to be added > on wl_touch. > + Normally, a pointer will not leave a surface while there are > + buttons pressed, there's however circumstances where this event > + may be received in this situation, for example: > I have some doubts some of these can happen, or that the need is so rare or esoteric that it might be better to just not allow it at all: + - When a popup is shown by this or other client. > For "this" client I would prefer that no exit event be sent, only an enter event for the new surface. At the moment these fake exit events are a pain to handle and the client has to add specific code to ignore them (see below). Fixing this would remove the primary reason clients need to be able to peek ahead in the event queue. For "other" clients: are they really capable of making a popup without the pointer focus? It seems like only the compositor could do this, but is there really a need to support this? > + - When a drag-and-drop operation is initiated from this or > + any other surface. > Again for "this" client, I would greatly prefer not getting an exit event that I have to ignore. And it sure seems like the grab is still going on: the client gets all information about mouse motion, the modifiers, and the client is in control of the cursor, and everything goes away when the mouse is released. So I certainly would not expect this to be any different than a normal automatic grab. Again I doubt other clients without the pointer focus could start a drag, and whether there is any reason to support this. > + - Other compositor-specific grabs, like pointer gestures. > As the gesture may go to the same client, it does not seem like exit events are correct. Send the gesture-cancel event, and clients have to know this cancels grabs by the wl_pointer device. 2.5.0 > If this is possible it seems like a client could also get focus back while there are buttons held down. How is that handled? I guess you can send button-down events in the "frame" along with the enter. Though the keyboard is done differently, by sending a "keymap" event. Exit events generated by the client's own actions are a huge pain, it forces clients to look ahead for the enter event to distinguish between the focus moving to another surface and losing it entirely. This should be fixed. A few ideas: 1. (my preference) don't send exit events if the enter is going to the same client. Exit events are "none of your surfaces now have focus". I believe this is the simplest solution and will not break any client written by a sane programmer. 2. Sent enter events *before* exit events. Clients can then ignore exit events for the "wrong" surface. This has the least invasive change to the api, though I can imagine this breaking some clients. 3. Pair the exit + enter events into a single "frame". This is a new possible fix introduced by the new frame ideas. The advantage here is that it really is compatible with any old client. My personal opinion is that all there should be a single pointer focus per seat, and the wl_pointer enter/leave events reused for all of these. Otherwise you are going to end up adding enter/leave events to every new device api, and sending them all simultaneously. So a better fix would be to just say that anything using the wl_touch api should obey the wl_pointer enter/exit events for the same seat. I'm guessing this idea will be tough to sell here, but wanted to mention it. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] event-loop: remove extra header
On Mon, Nov 16, 2015 at 11:53:36AM +0100, Marek Chalupa wrote: > we don't use assert() anywhere in this file, so remove #include > > Signed-off-by: Marek Chalupa Reviewed-by: Bryce Harrington Thanks, pushed: remote: I: patch #64885 updated using rev 10d5f97706f6228b607daebb90166752beb8fc77 remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/wayland/wayland 8bc42fb..10d5f97 master -> master > --- > src/event-loop.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/src/event-loop.c b/src/event-loop.c > index 130c7be..ea27b69 100644 > --- a/src/event-loop.c > +++ b/src/event-loop.c > @@ -36,7 +36,6 @@ > #include > #include > #include > -#include > #include "wayland-private.h" > #include "wayland-server.h" > #include "wayland-os.h" > -- > 2.5.0 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete
Hi, On Monday, 16 November 2015, Bill Spitzak wrote: > > Since the "frame" event groups everything together, it does not seem like > there is a need to talk about "latching". _descrete events are "latching" > in that they are in the same frame. This could remove some complexity from > your description I think. > Indeed, talking about grouped rather than latched events may help a bit. We already use latched to describe, e.g. wl_surface.commit, and using different language may help clarify a bit. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] add wl_abort private function
This sure looks correct to me.
Using assert(0) seems like it was a mistake, as it would not happen if
NDEBUG was defined but it appears the code is relying on it. And since it
was already doing a call to wl_log no overhead was reduced by the removal.
On Mon, Nov 16, 2015 at 2:49 AM, Marek Chalupa wrote:
> On many places in the code we use wl_log + abort or wl_log + assert(0).
> Replace these with one call to wl_abort, so that we don't mix abort(),
> assert(0) and we'll save few lines
>
> Signed-off-by: Marek Chalupa
> ---
> src/connection.c | 22 +++---
> src/wayland-client.c | 12
> src/wayland-private.h | 1 +
> src/wayland-util.c| 12
> tests/sanity-test.c | 7 ++-
> 5 files changed, 30 insertions(+), 24 deletions(-)
>
> diff --git a/src/connection.c b/src/connection.c
> index b3d9bd4..6742f19 100644
> --- a/src/connection.c
> +++ b/src/connection.c
> @@ -33,7 +33,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -569,16 +568,12 @@ wl_closure_marshal(struct wl_object *sender,
> uint32_t opcode,
> case 'h':
> fd = args[i].h;
> dup_fd = wl_os_dupfd_cloexec(fd, 0);
> - if (dup_fd < 0) {
> - wl_log("dup failed: %m");
> - abort();
> - }
> + if (dup_fd < 0)
> + wl_abort("dup failed: %s\n",
> strerror(errno));
> closure->args[i].h = dup_fd;
> break;
> default:
> - wl_log("unhandled format code: '%c'\n",
> - arg.type);
> - assert(0);
> + wl_abort("unhandled format code: '%c'\n",
> arg.type);
> break;
> }
> }
> @@ -771,8 +766,7 @@ wl_connection_demarshal(struct wl_connection
> *connection,
> closure->args[i].h = fd;
> break;
> default:
> - wl_log("unknown type\n");
> - assert(0);
> + wl_abort("unknown type\n");
> break;
> }
> }
> @@ -906,8 +900,7 @@ convert_arguments_to_ffi(const char *signature,
> uint32_t flags,
> ffi_args[i] = &args[i].h;
> break;
> default:
> - wl_log("unknown type\n");
> - assert(0);
> + wl_abort("unknown type\n");
> break;
> }
> }
> @@ -938,9 +931,8 @@ wl_closure_invoke(struct wl_closure *closure, uint32_t
> flags,
>
> implementation = target->implementation;
> if (!implementation[opcode]) {
> - wl_log("listener function for opcode %u of %s is NULL\n",
> - opcode, target->interface->name);
> - abort();
> + wl_abort("listener function for opcode %u of %s is NULL\n",
> +opcode, target->interface->name);
> }
> ffi_call(&cif, implementation[opcode], NULL, ffi_args);
> }
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index b1c600f..509be08 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c
> @@ -597,18 +597,14 @@ wl_proxy_marshal_array_constructor(struct wl_proxy
> *proxy,
> }
>
> closure = wl_closure_marshal(&proxy->object, opcode, args,
> message);
> - if (closure == NULL) {
> - wl_log("Error marshalling request: %m\n");
> - abort();
> - }
> + if (closure == NULL)
> + wl_abort("Error marshalling request: %s\n",
> strerror(errno));
>
> if (debug_client)
> wl_closure_print(closure, &proxy->object, true);
>
> - if (wl_closure_send(closure, proxy->display->connection)) {
> - wl_log("Error sending request: %m\n");
> - abort();
> - }
> + if (wl_closure_send(closure, proxy->display->connection))
> + wl_abort("Error sending request: %s\n", strerror(errno));
>
> wl_closure_destroy(closure);
>
> diff --git a/src/wayland-private.h b/src/wayland-private.h
> index da9040a..58ac952 100644
> --- a/src/wayland-private.h
> +++ b/src/wayland-private.h
> @@ -209,6 +209,7 @@ wl_closure_destroy(struct wl_closure *closure);
> extern wl_log_func_t wl_log_handler;
>
> void wl_log(const char *fmt, ...);
> +void wl_abort(const char *fmt, ...);
>
> struct wl_display;
>
> diff --git a/src/wayland-util.c b/src/wayland-util.c
> index 00265e9..e782309 100644
> --- a/src/wayland-util.c
> +++ b/src/wayland-util.c
> @@ -385,3 +385,15 @@ wl_log(const char *fmt, ...)
> wl_log_handler(fmt, argp);
> va_end(argp);
>
Re: [PATCH wayland-protocols] Add the tablet protocol
Bill, On Monday, 16 November 2015, Bill Spitzak wrote: > There is a need to distinguish proximity-out from exit events. It is quite > possible to move the stylus so that the focus enters another client without > doing a proximity-out. Clients are interested in distinguishing these. > This is true, hence my suggestion. > I really feel the best method is to say a "seat" has a keyboard focus and > a pointer focus, and let the stylus manipulate the pointer focus. Thus the > client will get enter/exit events as the stylus is moved around above the > tablet, and proximity in/out when it is moved toward/away from the tablet > (it may also get a fake proximity-in event on enter). > Pointer and tablet/touch are separate. X11 integrated them, and _that_ was a huge mistake. From our point of view, this is a closed topic. We've been over it time and time again, we've seen the ways the alternate model - though it seems attractive at first, which is why we did it for X11 - fails, and we're not going back there. > I really feel the cursor stuff is a huge mistake. It adds lots of > complexity for almost no actual gain. Witness how much code you had to add > to toytoolkit to support it. It adds complexity to clients as the client > has to pass which tool to subroutines for no reason other than to allow > them to change the correct cursor. The clients cannot assume the tool has > the "right" cursor and therefore they are required to have code to change > it, so this removes no complexity from clients. It is also hugely > inconsistent with how normal pointer enter events are handled in Wayland. > It's not 'no actual gain', it's integral to the model. > The only argument you had was that the cursor is more likely to be > correct, so when the proximity-in event happens, the cursor that appears > has a higher chance of being the same as the one the client sets and there > will be less blinking. However this can be implemented by the compositor > without any client api. Just have the compositor remember what cursor was > used and set that as a guess on the enter event. The client can remain > completely unaware of whether a cursor is remembered per-tool, or > per-surface, or per tool*surface, or whatever. > The reason the protocol does not do this, is because when the cursor is different, you go from the other-surface cursor, to the old new-surface cursor, to the new new-surface cursor, very rapidly. It's ugly, and a bandaid for clients not responding quickly enough. This line has been discussed to death, and we won't be pursuing it any further. I've enjoyed some of your more constructive contributions over the past year or so, but am sad to see you regress back into suggesting rewriting the entire protocol - overriding considered discussion made at the time - because you prefer the superficial aspects of an alternate approach. Please don't make a habit of this. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete
On Mon, Nov 16, 2015 at 4:02 AM, Auke Booij wrote: > > > We can't extend the existing wl_pointer.axis events so we introduce a new > > concept: latching events. These events (currently only axis_discrete) > > are prefixed before a wl_pointer.axis event. A client must build the full > > state of the event until the respective top-level event arrives. > > i.e. a single event frame for a diagonal scroll with discrete > information may > > be: > > > > wl_pointer.axis_source > > wl_pointer.axis_discrete > > wl_pointer.axis > > wl_pointer.axis_discrete > > wl_pointer.axis > > wl_pointer.frame > Since the "frame" event groups everything together, it does not seem like there is a need to talk about "latching". _descrete events are "latching" in that they are in the same frame. This could remove some complexity from your description I think. Objections I see is that it makes it impossible to have both discreet and non-discreet axis events in the same frame, but I find it hard to imagine an input device where this would be physically possible. Also that this allows the order to be random rather than forcing the discrete events to be immediately before the axis, but I don't see any way a useful client could take advantage of this (a client is pretty much forced to accumulate the information in a structure until the frame event happens, so enforced ordering is of no help). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
There is a need to distinguish proximity-out from exit events. It is quite possible to move the stylus so that the focus enters another client without doing a proximity-out. Clients are interested in distinguishing these. I really feel the best method is to say a "seat" has a keyboard focus and a pointer focus, and let the stylus manipulate the pointer focus. Thus the client will get enter/exit events as the stylus is moved around above the tablet, and proximity in/out when it is moved toward/away from the tablet (it may also get a fake proximity-in event on enter). I really feel the cursor stuff is a huge mistake. It adds lots of complexity for almost no actual gain. Witness how much code you had to add to toytoolkit to support it. It adds complexity to clients as the client has to pass which tool to subroutines for no reason other than to allow them to change the correct cursor. The clients cannot assume the tool has the "right" cursor and therefore they are required to have code to change it, so this removes no complexity from clients. It is also hugely inconsistent with how normal pointer enter events are handled in Wayland. I would change this so the cursor remains the wl_pointer cursor, and exactly the same code is used by the client to change the cursor as it does for wl_pointer. The fact that you need to use the wl_pointer interface to deal with stylus events can be considered a historical artefact, they should have been on the wl_seat. The only argument you had was that the cursor is more likely to be correct, so when the proximity-in event happens, the cursor that appears has a higher chance of being the same as the one the client sets and there will be less blinking. However this can be implemented by the compositor without any client api. Just have the compositor remember what cursor was used and set that as a guess on the enter event. The client can remain completely unaware of whether a cursor is remembered per-tool, or per-surface, or per tool*surface, or whatever. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hi, On 16 November 2015 at 13:27, Carlos Garnacho wrote: > On Mon, Nov 16, 2015 at 12:21 PM, Daniel Stone wrote: >> Can we please enforce a strict bracketing of down/up occurring in >> matched pairs inside of proximity_in/out? So, the total event stream >> would be: >> - proximity_in >> - motion >> - down >> - motion/motion/button/... >> - up >> - proximity_out >> >> I assume the implementation does this, but it would be nice to have >> encoded in the protocol. > > It is worth noting that stylus button events can be obtained while in > proximity regardless of down/up state, so that'd roughly be: > > - proximity_in > - motion/button/... > - down > - motion/button/... > - up > - motion/button/... > - proximity_out Oh sure, that's fine, just as long as down/up is strictly bracketed such that you can't just get proximity_in -> down -> proximity_out -> [nothing]. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hey :), On Mon, Nov 16, 2015 at 12:21 PM, Daniel Stone wrote: > Peter, Stephen, > > On 6 November 2015 at 04:24, Peter Hutterer wrote: >> This is the revamped version of the tablet protocol for graphics tablets >> (e.g. Wacom tablets). Too many changes from the last version (a year ago or >> so), so I won't detail them, best to look at it with fresh eyes. > > Thanks a lot for doing this! Looks really good to me, and I think > getting it in wayland-protocols would be good. > > Do you have other implementations, e.g. GTK+/Mutter? If so, a pointer > (ha) to those would be great. The branch in mutter corresponding to this last version is: https://git.gnome.org/browse/mutter/log/?h=wip/tablet-protocol-v3 There's also: https://git.gnome.org/browse/gtk+/log/?h=wip/wayland-tablet For GTK+, but that one hasn't caught up yet with wayland-protocols > > Obligatory nitpicks follow: > >> + >> + >> + >> +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. > > Yes, it turns out the wl_seat.get_* model was probably a pretty bad > anti-pattern. Oh well. To avoid too much object proliferation though, > how about something like: > > > > Add a seat of interest to this tablet manager. The client will > receive events for all tablets currently on this seat, as well as > tablets added to this seat in future. > > > > [inline wp_tablet_seat here ...] > > > Then you can just bin wp_tablet_seat. > > Not a pattern we've previously employed, but I think it's a good one > that avoids one extra step of indirection, as well as making it a bit > easier for clients to do the right thing. > >> +The wp_tablet_seat sends a "tablet added" for each tablet connected. >> +That event is followed by descriptive events about the hardware; >> +currently that includes events for name, vid/pid and >> +internal/external/display type, and a wp_tablet.path event that >> +describes a local path. This path can be used to uniquely identify a >> +tablet, or get more information through libwacom. Emulated or nested >> +tablets can skip any of those, e.g. a virtual tablet may not have a >> +vid/pid. The sequence of descriptive events is terminated by a >> +wp_tablet.done event to signal that a client may now finalize any >> +initialization for that tablet. > > Is VID/PID in USB space? (Answers in diff form preferred.) > >> +Two special events (that don't exist in X) are down and up. They signal >> +"tip touching the surface". For tablets without real proximity >> +detection, the sequence is: proximity_in, motion, down, frame. >> + >> +When the tool leaves proximity, a proximity_out event is sent, followed >> +by button release events for any button still down. This signals to >> +the client that the buttons were held when the tool left proximity. >> +Those events are all sent within the same frame. > > Can we please enforce a strict bracketing of down/up occurring in > matched pairs inside of proximity_in/out? So, the total event stream > would be: > - proximity_in > - motion > - down > - motion/motion/button/... > - up > - proximity_out > > I assume the implementation does this, but it would be nice to have > encoded in the protocol. It is worth noting that stylus button events can be obtained while in proximity regardless of down/up state, so that'd roughly be: - proximity_in - motion/button/... - down - motion/button/... - up - motion/button/... - proximity_out Cheers, Carlos ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hi Jonas, On 16 November 2015 at 11:59, Jonas Ådahl wrote: > On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote: >> On 6 November 2015 at 04:24, Peter Hutterer wrote: >> > +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. >> >> Yes, it turns out the wl_seat.get_* model was probably a pretty bad >> anti-pattern. Oh well. To avoid too much object proliferation though, >> how about something like: >> >> >> >> Add a seat of interest to this tablet manager. The client will >> receive events for all tablets currently on this seat, as well as >> tablets added to this seat in future. >> >> >> >> [inline wp_tablet_seat here ...] >> >> >> Then you can just bin wp_tablet_seat. >> >> Not a pattern we've previously employed, but I think it's a good one >> that avoids one extra step of indirection, as well as making it a bit >> easier for clients to do the right thing. > > How would it be easier for clients to do the right thing? It'd just make > it easy to mix different seats' tools and tablets as there would be no > more separation (except if one would bind a tablet manager per seat). Or > should tools and tablets be considered on the same "super seat", i.e. > would it be possible to see tool A from seat X on tablet V on seat Y? It makes it easier, because right now we expect them to hold a wp_tablet_manager, respond to new seats by creating a new wp_tablet_seat, and having them respond to events on that as well. We already make people hold absolute piles of objects, so one less seems like it could be a good thing. > Seems to me that making it possible to shove all seats in one pile is > more error prone than having them clearly separated. Possibly. I guess it depends on the failure mode. I can see it either way. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete
On 28 October 2015 at 05:34, Peter Hutterer wrote: > The frame event groups separate pointer events together. The primary use-case > for this at the moment is diagonal scrolling - a vertical/horizontal scroll > event can be grouped together to calculate the correct motion vector. > Frame events group all wl_pointer events. An example sequence of motion events > followed by a diagonal scroll followed by a button event is: > wl_pointer.motion > wl_pointer.frame > wl_pointer.motion > wl_pointer.frame > wl_pointer.axis > wl_pointer.axis > wl_pointer.frame > wl_pointer.button > wl_pointer.frame > > In the future, other extensions may insert additional information about an > event into the frame. For example, an extension may add information about the > physical device that generated an event into the frame. For this reason, > enter/leave events are grouped by a frame event too. > > The axis_source event determines how an axis event was generated. That enables > clients to judge when to use kinetic scrolling. Only one axis_source event is > allowed per frame and applies to all events in this frame. > > The axis_stop event notifies a client about the termination of a scroll > sequence, likewise needed to calculate kinetic scrolling parameters. > Multiple axis_stop events within the same frame indicate that scrolling has > stopped in all these axis at the same time. > > The axis_discrete event provides the wheel click count. Previously the axis > value was some hardcoded number (10), with the discrete steps this enables a > client to differ between line-based scrolling on a mouse wheel and smooth > scrolling with a touchpad. > > We can't extend the existing wl_pointer.axis events so we introduce a new > concept: latching events. These events (currently only axis_discrete) > are prefixed before a wl_pointer.axis event. A client must build the full > state of the event until the respective top-level event arrives. > i.e. a single event frame for a diagonal scroll with discrete information may > be: > > wl_pointer.axis_source > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.frame > > Signed-off-by: Peter Hutterer > --- (as for your tablet protocol patch) Perhaps we can use the enum attribute here as well: ... ... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote: > Peter, Stephen, > > On 6 November 2015 at 04:24, Peter Hutterer wrote: > > This is the revamped version of the tablet protocol for graphics tablets > > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > > so), so I won't detail them, best to look at it with fresh eyes. > > Thanks a lot for doing this! Looks really good to me, and I think > getting it in wayland-protocols would be good. > > Do you have other implementations, e.g. GTK+/Mutter? If so, a pointer > (ha) to those would be great. > > Obligatory nitpicks follow: > > > + > > + > > + > > +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. > > Yes, it turns out the wl_seat.get_* model was probably a pretty bad > anti-pattern. Oh well. To avoid too much object proliferation though, > how about something like: > > > > Add a seat of interest to this tablet manager. The client will > receive events for all tablets currently on this seat, as well as > tablets added to this seat in future. > > > > [inline wp_tablet_seat here ...] > > > Then you can just bin wp_tablet_seat. > > Not a pattern we've previously employed, but I think it's a good one > that avoids one extra step of indirection, as well as making it a bit > easier for clients to do the right thing. How would it be easier for clients to do the right thing? It'd just make it easy to mix different seats' tools and tablets as there would be no more separation (except if one would bind a tablet manager per seat). Or should tools and tablets be considered on the same "super seat", i.e. would it be possible to see tool A from seat X on tablet V on seat Y? Seems to me that making it possible to shove all seats in one pile is more error prone than having them clearly separated. > > > +The wp_tablet_seat sends a "tablet added" for each tablet connected. > > +That event is followed by descriptive events about the hardware; > > +currently that includes events for name, vid/pid and > > +internal/external/display type, and a wp_tablet.path event that > > +describes a local path. This path can be used to uniquely identify a > > +tablet, or get more information through libwacom. Emulated or nested > > +tablets can skip any of those, e.g. a virtual tablet may not have a > > +vid/pid. The sequence of descriptive events is terminated by a > > +wp_tablet.done event to signal that a client may now finalize any > > +initialization for that tablet. > > Is VID/PID in USB space? (Answers in diff form preferred.) > > > +Two special events (that don't exist in X) are down and up. They signal > > +"tip touching the surface". For tablets without real proximity > > +detection, the sequence is: proximity_in, motion, down, frame. > > + > > +When the tool leaves proximity, a proximity_out event is sent, followed > > +by button release events for any button still down. This signals to > > +the client that the buttons were held when the tool left proximity. > > +Those events are all sent within the same frame. > > Can we please enforce a strict bracketing of down/up occurring in > matched pairs inside of proximity_in/out? So, the total event stream > would be: > - proximity_in > - motion > - down > - motion/motion/button/... > - up > - proximity_out > > I assume the implementation does this, but it would be nice to have > encoded in the protocol. > > > +If the tool moves out of the surface but stays in proximity (i.e. > > +between windows), compositor-specific grab policies apply. This usually > > +means that the proximity-out is delayed until all buttons are released. > > If no buttons are down, we'd _expect_ to just get a proximity_out > immediately, right? It almost seems like we'd want a subtype argument > here, enumerating what happened: did the user lift the tool entirely > (actually out of proximity), or is the tablet still in proximity but > just wandered off to another surface? > > The doc for proximity_out also doesn't contradict this, but reading > the two together is a bit jarring: > > + [wp_tablet_tool1::proximity_out] > > + When the tablet tool leaves proximity of the tablet, button release > > + events are sen
Re: [PATCH v6 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete
On 16 November 2015 at 00:57, Peter Hutterer wrote: > The frame event groups separate pointer events together. The primary use-case > for this at the moment is diagonal scrolling - a vertical/horizontal scroll > event can be grouped together to calculate the correct motion vector. > Frame events group all wl_pointer events. An example sequence of motion events > followed by a diagonal scroll followed by a button event is: > wl_pointer.motion > wl_pointer.frame > wl_pointer.motion > wl_pointer.frame > wl_pointer.axis > wl_pointer.axis > wl_pointer.frame > wl_pointer.button > wl_pointer.frame > > In the future, other extensions may insert additional information about an > event into the frame. For example, an extension may add information about the > physical device that generated an event into the frame. For this reason, > enter/leave events are grouped by a frame event too. > > The axis_source event determines how an axis event was generated. That enables > clients to judge when to use kinetic scrolling. Only one axis_source event is > allowed per frame and applies to all events in this frame. > > The axis_stop event notifies a client about the termination of a scroll > sequence, likewise needed to calculate kinetic scrolling parameters. > Multiple axis_stop events within the same frame indicate that scrolling has > stopped in all these axis at the same time. > > The axis_discrete event provides the wheel click count. Previously the axis > value was some hardcoded number (10), with the discrete steps this enables a > client to differ between line-based scrolling on a mouse wheel and smooth > scrolling with a touchpad. > > We can't extend the existing wl_pointer.axis events so we introduce a new > concept: latching events. These events (currently only axis_discrete) > are prefixed before a wl_pointer.axis event. A client must build the full > state of the event until the respective top-level event arrives. > i.e. a single event frame for a diagonal scroll with discrete information may > be: > > wl_pointer.axis_source > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.frame > > Signed-off-by: Peter Hutterer > Reviewed-by: Carlos Garnacho Good stuff. Reviewed-by: Daniel Stone Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Peter, Stephen, On 6 November 2015 at 04:24, Peter Hutterer wrote: > This is the revamped version of the tablet protocol for graphics tablets > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > so), so I won't detail them, best to look at it with fresh eyes. Thanks a lot for doing this! Looks really good to me, and I think getting it in wayland-protocols would be good. Do you have other implementations, e.g. GTK+/Mutter? If so, a pointer (ha) to those would be great. Obligatory nitpicks follow: > + > + > + > +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. Yes, it turns out the wl_seat.get_* model was probably a pretty bad anti-pattern. Oh well. To avoid too much object proliferation though, how about something like: Add a seat of interest to this tablet manager. The client will receive events for all tablets currently on this seat, as well as tablets added to this seat in future. [inline wp_tablet_seat here ...] Then you can just bin wp_tablet_seat. Not a pattern we've previously employed, but I think it's a good one that avoids one extra step of indirection, as well as making it a bit easier for clients to do the right thing. > +The wp_tablet_seat sends a "tablet added" for each tablet connected. > +That event is followed by descriptive events about the hardware; > +currently that includes events for name, vid/pid and > +internal/external/display type, and a wp_tablet.path event that > +describes a local path. This path can be used to uniquely identify a > +tablet, or get more information through libwacom. Emulated or nested > +tablets can skip any of those, e.g. a virtual tablet may not have a > +vid/pid. The sequence of descriptive events is terminated by a > +wp_tablet.done event to signal that a client may now finalize any > +initialization for that tablet. Is VID/PID in USB space? (Answers in diff form preferred.) > +Two special events (that don't exist in X) are down and up. They signal > +"tip touching the surface". For tablets without real proximity > +detection, the sequence is: proximity_in, motion, down, frame. > + > +When the tool leaves proximity, a proximity_out event is sent, followed > +by button release events for any button still down. This signals to > +the client that the buttons were held when the tool left proximity. > +Those events are all sent within the same frame. Can we please enforce a strict bracketing of down/up occurring in matched pairs inside of proximity_in/out? So, the total event stream would be: - proximity_in - motion - down - motion/motion/button/... - up - proximity_out I assume the implementation does this, but it would be nice to have encoded in the protocol. > +If the tool moves out of the surface but stays in proximity (i.e. > +between windows), compositor-specific grab policies apply. This usually > +means that the proximity-out is delayed until all buttons are released. If no buttons are down, we'd _expect_ to just get a proximity_out immediately, right? It almost seems like we'd want a subtype argument here, enumerating what happened: did the user lift the tool entirely (actually out of proximity), or is the tablet still in proximity but just wandered off to another surface? The doc for proximity_out also doesn't contradict this, but reading the two together is a bit jarring: > + [wp_tablet_tool1::proximity_out] > + When the tablet tool leaves proximity of the tablet, button release > + events are sent for each button that was held down at the time of > + leaving proximity. These events are sent in the same wp_tablet.frame > + of the proximity_out event. It'd be nice to have discussion of the two cases - genuinely leaving proximity vs. retaining proximity but leaving surface focus - together. > +Moving a tool physically from one tablet to the other has no real effect > +on the protocol, since we already have the tool object from the "tool > +added" event. All the information is already there and the proximity_in > +is all a client needs to reconstruct what happened. ... also (up+)proximity_out from the old tablet. > + > + > + An unique object that represents a physical tool that has been, or is > + cu
Re: Changing wl_output.transform type to unsigned?
Changing C int to C uint is ok for Java. Java only knows signed ints anyway, I therefore already map C uint to Java int, which is ok as long as no arithmetic is needed. On Mon, Nov 16, 2015 at 11:46 AM, Pekka Paalanen wrote: > On Sun, 15 Nov 2015 22:17:38 +0100 > "Nils Chr. Brause" wrote: > > > On Sun, Nov 15, 2015 at 9:48 PM, Auke Booij wrote: > > > On 9 November 2015 at 18:17, Bill Spitzak wrote: > > >> I really do not see the problem with allowing it to be an int > argument as > > >> long as the enum value 2^31 is not used. Though I am also stumped as > to why > > >> you can't change the current misused ints into uint in the protocol. > It will > > >> not change the bit layout in the messages and therefore is not a > protocol > > >> change. > > > > > > I don't really know what to do with this final claim. I like the idea, > > > and it makes sense. Finally, it will solve this issue and potentially > > > future ones as well. Is there any chance it could be implemented or is > > > it a crazy idea? > > > > Bill is absolutely right. And it also doesn't even really change the C > API, > > because nobody is passing negetive numbers or number greater than 2^31-1 > > there anyway. Therefore, I am all for a change. :) > > Hi, > > your logic seems sound at first. > > The things we would need to change in the protocol are: > - wl_surface.set_buffer_transform > - wl_output.geometry > - (possible third party extensions) > > It would break existing bindings for strongly typed languages that do > not allow implicit conversion between signed and unsigned. (Does Java > fall into that category?) > > You don't see any change on the wire, but changing the type changes the > C API, which then changes types of variables used in C programs. I > can't imagine this having an impact in this particular case, though. > > Weston seems to use mostly 'enum wl_buffer_transform' as the type, but > struct weston_buffer_viewport already uses uint32_t. > > Ok, I suppose we could try this. > > The next step would be for someone to propose a patch to change the > ints to uints in wayland.xml. Special attention should be given to the > commit message: why change this, what benefits it gives, and even > though it is breaking the protocol, why it cannot break anything in > practice. > > It is important to write a good commit message, because I expect people > to be looking at it a lot, since it is changing stable interfaces. > > We'll see how that patch is received. If anyone complains it breaks > their thing, I think we have to revert it, because it is technically > breaking the stability rules. > > > Thanks, > pq > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland] protocol: Add wl_surface.buffer_damage
On Mon, 16 Nov 2015 10:19:39 + Daniel Stone wrote: > Hi, > > On 14 November 2015 at 07:55, Jason Ekstrand wrote: > > On Nov 13, 2015 10:43 AM, "Derek Foreman" wrote: > >> Interesting problem just occurred to me... I don't think just not > >> mixing damage/buffer_damage within a commit is good enough. > >> > >> What if a client commits faster than the screen refresh rate? Then > >> we're expected to accumulate the damage inside the compositor, right? > >> > >> So a client could use damage exclusively in one commit, damage_buffer > >> exclusively in another, and the compositor still has to mix the result... > >> > >> Is it too heavy handed to allow the first damage/damage_buffer to set > >> what must be used on the surface for its lifetime? > > > > I think it's better to just let the client damage however it wants and > > highly recommend they pick one and stick with it. It's perfectly > > well-defined to damage in both and trying to come up with a precise > > condition for a protocol error is, as you pointed out, rather difficult. The > > only sane condition I can think of is "don't use both in the same commit" > > but, as you pointed out, that doesn't actually help the compositor. > > Compositors that don't want to deal with it can just stomp to full damage as > > soon as things get complicated. > > I completely agree. Trying to make the spec too rigidly defined will > ultimately end up in compositors not quite getting it right and people > getting surprised at the variance. If a particular compositor > pessimises too hard, then that compositor will be rightly noted for > its non-performance and eventually fixed. The worst case would be > changing a transform at the same time as submitting damage in both > buffer and surface co-ords, at which point you'll probably want to > stomp to full damage. Which is fine, as I can't really imagine why you > _wouldn't_ be sending full damage when sending a buffer with a totally > different transformation to previous. This was my first preference too. "damage_buffer" is fine by me. Or even "damage_in_buffer". Thanks, pq signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] event-loop: remove extra header
we don't use assert() anywhere in this file, so remove #include Signed-off-by: Marek Chalupa --- src/event-loop.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/event-loop.c b/src/event-loop.c index 130c7be..ea27b69 100644 --- a/src/event-loop.c +++ b/src/event-loop.c @@ -36,7 +36,6 @@ #include #include #include -#include #include "wayland-private.h" #include "wayland-server.h" #include "wayland-os.h" -- 2.5.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] add wl_abort private function
On many places in the code we use wl_log + abort or wl_log + assert(0).
Replace these with one call to wl_abort, so that we don't mix abort(),
assert(0) and we'll save few lines
Signed-off-by: Marek Chalupa
---
src/connection.c | 22 +++---
src/wayland-client.c | 12
src/wayland-private.h | 1 +
src/wayland-util.c| 12
tests/sanity-test.c | 7 ++-
5 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index b3d9bd4..6742f19 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -33,7 +33,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -569,16 +568,12 @@ wl_closure_marshal(struct wl_object *sender, uint32_t
opcode,
case 'h':
fd = args[i].h;
dup_fd = wl_os_dupfd_cloexec(fd, 0);
- if (dup_fd < 0) {
- wl_log("dup failed: %m");
- abort();
- }
+ if (dup_fd < 0)
+ wl_abort("dup failed: %s\n", strerror(errno));
closure->args[i].h = dup_fd;
break;
default:
- wl_log("unhandled format code: '%c'\n",
- arg.type);
- assert(0);
+ wl_abort("unhandled format code: '%c'\n", arg.type);
break;
}
}
@@ -771,8 +766,7 @@ wl_connection_demarshal(struct wl_connection *connection,
closure->args[i].h = fd;
break;
default:
- wl_log("unknown type\n");
- assert(0);
+ wl_abort("unknown type\n");
break;
}
}
@@ -906,8 +900,7 @@ convert_arguments_to_ffi(const char *signature, uint32_t
flags,
ffi_args[i] = &args[i].h;
break;
default:
- wl_log("unknown type\n");
- assert(0);
+ wl_abort("unknown type\n");
break;
}
}
@@ -938,9 +931,8 @@ wl_closure_invoke(struct wl_closure *closure, uint32_t
flags,
implementation = target->implementation;
if (!implementation[opcode]) {
- wl_log("listener function for opcode %u of %s is NULL\n",
- opcode, target->interface->name);
- abort();
+ wl_abort("listener function for opcode %u of %s is NULL\n",
+opcode, target->interface->name);
}
ffi_call(&cif, implementation[opcode], NULL, ffi_args);
}
diff --git a/src/wayland-client.c b/src/wayland-client.c
index b1c600f..509be08 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -597,18 +597,14 @@ wl_proxy_marshal_array_constructor(struct wl_proxy *proxy,
}
closure = wl_closure_marshal(&proxy->object, opcode, args, message);
- if (closure == NULL) {
- wl_log("Error marshalling request: %m\n");
- abort();
- }
+ if (closure == NULL)
+ wl_abort("Error marshalling request: %s\n", strerror(errno));
if (debug_client)
wl_closure_print(closure, &proxy->object, true);
- if (wl_closure_send(closure, proxy->display->connection)) {
- wl_log("Error sending request: %m\n");
- abort();
- }
+ if (wl_closure_send(closure, proxy->display->connection))
+ wl_abort("Error sending request: %s\n", strerror(errno));
wl_closure_destroy(closure);
diff --git a/src/wayland-private.h b/src/wayland-private.h
index da9040a..58ac952 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -209,6 +209,7 @@ wl_closure_destroy(struct wl_closure *closure);
extern wl_log_func_t wl_log_handler;
void wl_log(const char *fmt, ...);
+void wl_abort(const char *fmt, ...);
struct wl_display;
diff --git a/src/wayland-util.c b/src/wayland-util.c
index 00265e9..e782309 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -385,3 +385,15 @@ wl_log(const char *fmt, ...)
wl_log_handler(fmt, argp);
va_end(argp);
}
+
+void
+wl_abort(const char *fmt, ...)
+{
+ va_list argp;
+
+ va_start(argp, fmt);
+ wl_log_handler(fmt, argp);
+ va_end(argp);
+
+ abort();
+}
diff --git a/tests/sanity-test.c b/tests/sanity-test.c
index 3f589b5..65d986d 100644
--- a/tests/sanity-test.c
+++ b/tests/sanity-test.c
@@ -31,8 +31,8 @@
#include "test-runner.h"
#include "wayland-util.h"
+#include "wayland-private.h"
-#define WL_HIDE_DEPRECATED
#include "test-compositor.h"
extern int leak_check_enabled;
@@ -56,6 +56,11 @@ FAIL_TEST(fail_abort)
Changing wl_output.transform type to unsigned?
On Sun, 15 Nov 2015 22:17:38 +0100 "Nils Chr. Brause" wrote: > On Sun, Nov 15, 2015 at 9:48 PM, Auke Booij wrote: > > On 9 November 2015 at 18:17, Bill Spitzak wrote: > >> I really do not see the problem with allowing it to be an int argument as > >> long as the enum value 2^31 is not used. Though I am also stumped as to why > >> you can't change the current misused ints into uint in the protocol. It > >> will > >> not change the bit layout in the messages and therefore is not a protocol > >> change. > > > > I don't really know what to do with this final claim. I like the idea, > > and it makes sense. Finally, it will solve this issue and potentially > > future ones as well. Is there any chance it could be implemented or is > > it a crazy idea? > > Bill is absolutely right. And it also doesn't even really change the C API, > because nobody is passing negetive numbers or number greater than 2^31-1 > there anyway. Therefore, I am all for a change. :) Hi, your logic seems sound at first. The things we would need to change in the protocol are: - wl_surface.set_buffer_transform - wl_output.geometry - (possible third party extensions) It would break existing bindings for strongly typed languages that do not allow implicit conversion between signed and unsigned. (Does Java fall into that category?) You don't see any change on the wire, but changing the type changes the C API, which then changes types of variables used in C programs. I can't imagine this having an impact in this particular case, though. Weston seems to use mostly 'enum wl_buffer_transform' as the type, but struct weston_buffer_viewport already uses uint32_t. Ok, I suppose we could try this. The next step would be for someone to propose a patch to change the ints to uints in wayland.xml. Special attention should be given to the commit message: why change this, what benefits it gives, and even though it is breaking the protocol, why it cannot break anything in practice. It is important to write a good commit message, because I expect people to be looking at it a lot, since it is changing stable interfaces. We'll see how that patch is received. If anyone complains it breaks their thing, I think we have to revert it, because it is technically breaking the stability rules. Thanks, pq signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] Fix runtime error caused by missing header inclusion
Hi Yong-Il, On 14 November 2015 at 06:16, Joh, Yong-Il (Tolkien) wrote: > when I run weston on yocto for qemux86 device, > there is an error with following. > > [08:02:07.897] launching '/usr/lib/weston/weston-ivi-shell-user-interface' > [08:02:08.201] /usr/lib/weston/weston-ivi-shell-user-interface died on signal > 11 > > it is caused everytime > when I build yocto software on Ubuntu 12.04 64bit desktop for qemux86 device. > (not qemux86-64) > > to resolve this, > apply following patch. Thanks for the patch - it looks good to me. Can you please send this patch via git-send-email, instead of inline? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland] protocol: Add wl_surface.buffer_damage
Hi, On 14 November 2015 at 07:55, Jason Ekstrand wrote: > On Nov 13, 2015 10:43 AM, "Derek Foreman" wrote: >> Interesting problem just occurred to me... I don't think just not >> mixing damage/buffer_damage within a commit is good enough. >> >> What if a client commits faster than the screen refresh rate? Then >> we're expected to accumulate the damage inside the compositor, right? >> >> So a client could use damage exclusively in one commit, damage_buffer >> exclusively in another, and the compositor still has to mix the result... >> >> Is it too heavy handed to allow the first damage/damage_buffer to set >> what must be used on the surface for its lifetime? > > I think it's better to just let the client damage however it wants and > highly recommend they pick one and stick with it. It's perfectly > well-defined to damage in both and trying to come up with a precise > condition for a protocol error is, as you pointed out, rather difficult. The > only sane condition I can think of is "don't use both in the same commit" > but, as you pointed out, that doesn't actually help the compositor. > Compositors that don't want to deal with it can just stomp to full damage as > soon as things get complicated. I completely agree. Trying to make the spec too rigidly defined will ultimately end up in compositors not quite getting it right and people getting surprised at the variance. If a particular compositor pessimises too hard, then that compositor will be rightly noted for its non-performance and eventually fixed. The worst case would be changing a transform at the same time as submitting damage in both buffer and surface co-ords, at which point you'll probably want to stomp to full damage. Which is fine, as I can't really imagine why you _wouldn't_ be sending full damage when sending a buffer with a totally different transformation to previous. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 1/3] tablet: add missing event type checks for tablet events
Hi,
On 16-11-15 00:31, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer
Series looks good to me, and is:
Reviewed-by: Hans de Goede
Regards,
Hans
---
src/libinput.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/src/libinput.c b/src/libinput.c
index c47f9fc..ed9490f 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1064,48 +1064,97 @@ libinput_event_tablet_get_y_transformed(struct
libinput_event_tablet *event,
LIBINPUT_EXPORT struct libinput_tool *
libinput_event_tablet_get_tool(struct libinput_event_tablet *event)
{
+ require_event_type(libinput_event_get_context(&event->base),
+ event->base.type,
+ 0,
+ LIBINPUT_EVENT_TABLET_AXIS,
+ LIBINPUT_EVENT_TABLET_TIP,
+ LIBINPUT_EVENT_TABLET_BUTTON,
+ LIBINPUT_EVENT_TABLET_PROXIMITY);
+
return event->tool;
}
LIBINPUT_EXPORT enum libinput_tool_proximity_state
libinput_event_tablet_get_proximity_state(struct libinput_event_tablet *event)
{
+ require_event_type(libinput_event_get_context(&event->base),
+ event->base.type,
+ 0,
+ LIBINPUT_EVENT_TABLET_PROXIMITY);
+
return event->proximity_state;
}
LIBINPUT_EXPORT enum libinput_tool_tip_state
libinput_event_tablet_get_tip_state(struct libinput_event_tablet *event)
{
+ require_event_type(libinput_event_get_context(&event->base),
+ event->base.type,
+ 0,
+ LIBINPUT_EVENT_TABLET_TIP);
+
return event->tip_state;
}
LIBINPUT_EXPORT uint32_t
libinput_event_tablet_get_time(struct libinput_event_tablet *event)
{
+ require_event_type(libinput_event_get_context(&event->base),
+ event->base.type,
+ 0,
+ LIBINPUT_EVENT_TABLET_AXIS,
+ LIBINPUT_EVENT_TABLET_TIP,
+ LIBINPUT_EVENT_TABLET_BUTTON,
+ LIBINPUT_EVENT_TABLET_PROXIMITY);
+
return us2ms(event->time);
}
LIBINPUT_EXPORT uint64_t
libinput_event_tablet_get_time_usec(struct libinput_event_tablet *event)
{
+ require_event_type(libinput_event_get_context(&event->base),
+ event->base.type,
+ 0,
+ LIBINPUT_EVENT_TABLET_AXIS,
+ LIBINPUT_EVENT_TABLET_TIP,
+ LIBINPUT_EVENT_TABLET_BUTTON,
+ LIBINPUT_EVENT_TABLET_PROXIMITY);
+
return event->time;
}
LIBINPUT_EXPORT uint32_t
libinput_event_tablet_get_button(struct libinput_event_tablet *event)
{
+ require_event_type(libinput_event_get_context(&event->base),
+ event->base.type,
+ 0,
+ LIBINPUT_EVENT_TABLET_BUTTON);
+
return event->button;
}
LIBINPUT_EXPORT enum libinput_button_state
libinput_event_tablet_get_button_state(struct libinput_event_tablet *event)
{
+ require_event_type(libinput_event_get_context(&event->base),
+ event->base.type,
+ 0,
+ LIBINPUT_EVENT_TABLET_BUTTON);
+
return event->state;
}
LIBINPUT_EXPORT uint32_t
libinput_event_tablet_get_seat_button_count(struct libinput_event_tablet
*event)
{
+ require_event_type(libinput_event_get_context(&event->base),
+ event->base.type,
+ 0,
+ LIBINPUT_EVENT_TABLET_BUTTON);
+
return event->seat_button_count;
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
