Re: [RFC PATCH libinput 1/2] Add a string-based input API
Hi, On 09-12-14 03:49, Bill Spitzak wrote: On 12/08/2014 06:37 PM, Peter Hutterer wrote: On Mon, Dec 08, 2014 at 11:03:58AM -0800, Bill Spitzak wrote: Shouldn't this use the same api as the input methods, since it is in fact an input method? please explain Never mind, I think this is not talking about text input, but about using UTF-8 strings to identify keys rather than the keysym or keycode enumerations. No this is about input-method like functionality. This is mostly the result of a discussion on accessibility held at XDC Bordeaux. Some braille keyboards do all braille processing in firmware, and send out ready to use strings. So this is to for devices which have input-method like functionality including things like combining a sequence of braille dots into text, build into the device. We would like to support these devices at the libinput level (and from there on also at higher levels of the stack). Currently (IIRC) these devices do double translation, so the ready to use text gets converted into keycodes again, and then back, which is bound to be lossy, and a bad idea in general, so we want to get rid of the double translation for these. We're by no means experts in this area so feedback is very much welcome. Regards, Hans ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Where should project Weston go?
On 9.12.2014 1:26, Bryce Harrington wrote: But I imagine 'minimal' is intended here in more of an engineering sense, and interpret it myself to mean something like: Focuses on principle features not superfluous stuff better handled by other projects; doesn't overengineer algorithms to squeeze a few drops of performance; feature selection by what fits nicely and makes sense, not I would like to ask, what/where are those other projects. As long as there are no such projects, weston is the one used and also the metrics to judge overall project in terms of quality and performance. I've noticed over the years, that I can say until I'm blue in the face that Wayland is just a protocol, Weston is just a reference implementation, and you need to look at desktop environments to provide Wayland compositors; but people still keep asking me, Okay, but when can I ditch X and just use Wayland as my desktop? If it wants to be just protocol and reference implementation, Documentation needs to improve vastly. At the current level of documentation and ease-of-use for example of libwayland, I'm not holding my breath waiting to see anything product quality built ground-up based on what Wayland project produces. Now it looks like someone's GUI engine programming experiment. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Where should project Weston go?
2014-12-09 11:18 GMT+02:00 Jussi Laako jussi.la...@linux.intel.com: On 9.12.2014 1:26, Bryce Harrington wrote: But I imagine 'minimal' is intended here in more of an engineering sense, and interpret it myself to mean something like: Focuses on principle features not superfluous stuff better handled by other projects; doesn't overengineer algorithms to squeeze a few drops of performance; feature selection by what fits nicely and makes sense, not I would like to ask, what/where are those other projects. As long as there are no such projects, weston is the one used and also the metrics to judge overall project in terms of quality and performance. Well, GNOME for example. But there is also Enlightement, KDE, Hawaii, Orbital, Maynard,.. You can say none of those are there yet, but they already provide a better desktop experience than weston. I've noticed over the years, that I can say until I'm blue in the face that Wayland is just a protocol, Weston is just a reference implementation, and you need to look at desktop environments to provide Wayland compositors; but people still keep asking me, Okay, but when can I ditch X and just use Wayland as my desktop? If it wants to be just protocol and reference implementation, Documentation needs to improve vastly. At the current level of documentation and ease-of-use for example of libwayland, I'm not holding my breath waiting to see anything product quality built ground-up based on what Wayland project produces. I think you're being unfair here. Documentation is lacking, but i don't find libwayland hard to use at all. If we compare it to xlib or xcb, i find it much easier to use and more documented. Yet that didn't stop anyone from building X DEs. Besides, i would argue that the weston compositor (not the shell, just the compositor) is already product quality. Now it looks like someone's GUI engine programming experiment. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] doc: Minor makefile cleanup.
Split out directory creation to leverage order only prerequisites. Signed-off-by: Jon A. Cruz j...@osg.samsung.com --- doc/doxygen/Makefile.am | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index f8d636e..7276f5c 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -22,22 +22,24 @@ scanned_src_files_server = \ # all-local below) dist_man3_MANS = $(shell test -d man find man/man3 -name wl_*.3 -printf man/man3/%P\n) -xml/client/index.xml: $(scanned_src_files_client) wayland.doxygen - $(AM_V_GEN)$(MKDIR_P) xml/client \ - (cat wayland.doxygen; \ +# Listing various directories that might need to be created. +alldirs := xml/client xml/server man/man3 + +xml/client/index.xml: $(scanned_src_files_client) wayland.doxygen | xml/client + $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_XML=YES; \ echo XML_OUTPUT=xml/client; \ echo INPUT= $(scanned_src_files_client); \ ) | $(DOXYGEN) - -xml/server/index.xml: $(scanned_src_files_server) wayland.doxygen - $(AM_V_GEN)$(MKDIR_P) xml/server \ - (cat wayland.doxygen; \ + +xml/server/index.xml: $(scanned_src_files_server) wayland.doxygen | xml/server + $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_XML=YES; \ echo XML_OUTPUT=xml/server; \ echo INPUT= $(scanned_src_files_server); \ ) | $(DOXYGEN) - -man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) +man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) wayland.doxygen | man/man3 $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_MAN=YES; \ echo MAN_OUTPUT=man; \ @@ -45,6 +47,10 @@ man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) echo INPUT= $^; \ ) | $(DOXYGEN) - +# general rule to create one of the listed directories. +$(alldirs): + $(AM_V_GEN)$(MKDIR_P) $@ + # there is no man-local all-local: man/man3/wl_display.3 -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] doc: General makefile cleanup.
This is a general cleanup of the makefile in order to bring it more inline
with standard make practices. Cleanups included more use of automatic
variables, switching AM_V_GEN to AM_V_at to have one 'GEN' visible per file,
splitting copy operations to proper rules, and using order only dependencies
to properly create directories on-demand.
Changes also correct missing use of $(builddir) that has gone unnoticed as
it defaults to the current directory ('.').
Signed-off-by: Jon A. Cruz j...@osg.samsung.com
---
doc/publican/Makefile.am | 77 +---
1 file changed, 46 insertions(+), 31 deletions(-)
diff --git a/doc/publican/Makefile.am b/doc/publican/Makefile.am
index 0b2cd09..8ed3815 100644
--- a/doc/publican/Makefile.am
+++ b/doc/publican/Makefile.am
@@ -13,6 +13,7 @@
# * WaylandServerAPI.xml is generated from the doxygen output and saved in
# $(builddir)/en-US
# * run xmlto on $(builddir)/en-US, output to $(builddir)/Wayland/en-US
+
publican_sources = \
$(srcdir)/sources/Wayland.ent \
$(srcdir)/sources/Wayland.xml \
@@ -37,6 +38,7 @@ css_sources = \
$(srcdir)/sources/css/default.css \
$(srcdir)/sources/css/epub.css \
$(srcdir)/sources/css/print.css
+
img_sources = \
$(srcdir)/sources/images/icon.svg \
$(srcdir)/sources/images/wayland-architecture.png \
@@ -45,71 +47,84 @@ img_sources = \
if HAVE_XMLTO
if HAVE_XSLTPROC
-noinst_DATA = Wayland $(publican_targets)
+noinst_DATA = $(builddir)/Wayland $(publican_targets)
XMLTO_PARAM = \
--skip-validation \
--stringparam chunk.section.depth=0 \
--stringparam toc.section.depth=1 \
--stringparam html.stylesheet=css/default.css
+doxydir := $(top_builddir)/doc/doxygen
+
html_destdir = $(builddir)/Wayland/en-US/html
-Wayland: $(publican_targets)
- $(AM_V_GEN)$(MKDIR_P) -p $(html_destdir)/css
- $(AM_V_GEN)cp -f $(css_sources) $(html_destdir)/css/
- $(AM_V_GEN)$(MKDIR_P) -p $(html_destdir)/images
- $(AM_V_GEN)cp -f $(img_sources) $(html_destdir)/images/
- $(AM_V_GEN)$(XMLTO) $(XMLTO_PARAM) html en-US/Wayland.xml -o
$(html_destdir)
- @touch Wayland
+# Listing various directories that might need to be created.
+alldirs := $(builddir)/en-US $(builddir)/en-US/images $(html_destdir)
$(html_destdir)/css $(html_destdir)/images
+
+
+html_css_targets = $(addprefix $(html_destdir)/css/,$(notdir $(css_sources)))
+html_img_targets = $(addprefix $(html_destdir)/images/,$(notdir
$(img_sources)))
+
+$(builddir)/Wayland: $(publican_targets) $(html_css_targets)
$(html_img_targets) | $(builddir)/en-US
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_PARAM) html $(builddir)/en-US/Wayland.xml
-o $(html_destdir)
+ @touch $@
+
+$(html_destdir)/css/%: $(srcdir)/sources/css/% | $(html_destdir)/css
+ $(AM_V_GEN)cp -f $ $@
+
+$(html_destdir)/images/%: $(srcdir)/sources/images/% | $(html_destdir)/images
+ $(AM_V_GEN)cp -f $ $@
pubdir = $(docdir)/Wayland/en-US
-publican_targets = $(publican_sources:$(srcdir)/sources%=$(builddir)/en-US%) \
- en-US/ProtocolSpec.xml en-US/ProtocolInterfaces.xml \
- en-US/WaylandClientAPI.xml en-US/WaylandServerAPI.xml
+publican_targets = $(publican_sources:$(srcdir)/sources/%=$(builddir)/en-US/%)
\
+ $(builddir)/en-US/ProtocolSpec.xml
$(builddir)/en-US/ProtocolInterfaces.xml \
+ $(builddir)/en-US/WaylandClientAPI.xml
$(builddir)/en-US/WaylandServerAPI.xml
# The Protocol.xml is purely generated and required before running publican
-en-US/ProtocolSpec.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-to-docbook.xsl
- $(AM_V_GEN)$(MKDIR_P) en-US/images
+$(builddir)/en-US/ProtocolSpec.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-to-docbook.xsl | $(builddir)/en-US
$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-to-docbook.xsl \
- $(top_srcdir)/protocol/wayland.xml en-US/ProtocolSpec.xml
+ $(top_srcdir)/protocol/wayland.xml $@
-en-US/ProtocolInterfaces.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-interfaces-to-docbook.xsl
- $(AM_V_GEN)$(MKDIR_P) en-US/images
+$(builddir)/en-US/ProtocolInterfaces.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-interfaces-to-docbook.xsl
$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-interfaces-to-docbook.xsl \
- $(top_srcdir)/protocol/wayland.xml
en-US/ProtocolInterfaces.xml
+ $(top_srcdir)/protocol/wayland.xml $@
# * we don't want wayland-{server|client}_8h.xml to avoid duplicating output
methods,
# move it out of the way first.
# * use doxygen's combine.xslt to merge the xml files into one single file
# * move wayland-foo_8h.xml back to its original location
-en-US/%API.xml.tmp: $(top_builddir)/doc/doxygen/xml/%/index.xml
- $(AM_V_GEN)mv $(top_builddir)/doc/doxygen/xml/$*/wayland-$*_8h.xml \
- $(top_builddir)/doc/doxygen/xml/
- $(AM_V_GEN)$(XSLTPROC)
[PATCH 0/2] doc: General makefile cleanup.
These cover some basic makefile cleanup to improve dependency graph generation in preparation for including more generated content in the DocBook output. Jon A. Cruz (2): doc: General makefile cleanup. doc: Minor makefile cleanup. doc/doxygen/Makefile.am | 20 - doc/publican/Makefile.am | 77 +--- 2 files changed, 59 insertions(+), 38 deletions(-) -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Where should project Weston go?
On Tue, Dec 09, 2014 at 11:18:16AM +0200, Jussi Laako wrote: On 9.12.2014 1:26, Bryce Harrington wrote: But I imagine 'minimal' is intended here in more of an engineering sense, and interpret it myself to mean something like: Focuses on principle features not superfluous stuff better handled by other projects; doesn't overengineer algorithms to squeeze a few drops of performance; feature selection by what fits nicely and makes sense, not I would like to ask, what/where are those other projects. As long as there are no such projects, weston is the one used and also the metrics to judge overall project in terms of quality and performance. Already many such other projects have sprung up: Protocol dumpers, advanced terminal clients, keyboard and input libraries, and of course the desktop environments themselves. My expectation is that if Wayland/Weston maintain a tight focus on core functionalities and intentionally ignore the more peripheral things, then that will create holes/opportunities that third parties can fulfil. I've noticed over the years, that I can say until I'm blue in the face that Wayland is just a protocol, Weston is just a reference implementation, and you need to look at desktop environments to provide Wayland compositors; but people still keep asking me, Okay, but when can I ditch X and just use Wayland as my desktop? If it wants to be just protocol and reference implementation, Documentation needs to improve vastly. Certainly, I agree with this. At the current level of documentation and ease-of-use for example of libwayland, I'm not holding my breath waiting to see anything product quality built ground-up based on what Wayland project produces. Now it looks like someone's GUI engine programming experiment. Let's keep critiques to be constructive. Perhaps the situation could be improved via some patches from you? Bryce ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/4] doc: use markdown tildes for code blocks
On Mon, 08 Dec 2014 11:06:00 -0800 Bill Spitzak spit...@gmail.com wrote: However I think the decision was to only require Doxygen 1.6 and therefore the tildes don't work, and you must use \code. Is this correct? This is what is currently in git head. There is no tilde mark-up in upstream at the moment. If you know tildes would not work with doxygen 1.6, then we should keep using code/endcode. The comment style in the example code in documentation for wl_list is now in C++(/C99?) style, but that's ok, everyone can read it. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/3] touchpad: Add a tp_post_pointer_motion helper function
Split out the pointer-motion handling into a helper function.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/evdev-mt-touchpad.c | 46 ++
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 5938080..7d2e21a 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -591,32 +591,13 @@ tp_post_process_state(struct tp_dispatch *tp, uint64_t
time)
tp-queued = TOUCHPAD_EVENT_NONE;
}
-
static void
-tp_post_events(struct tp_dispatch *tp, uint64_t time)
+tp_post_pointer_motion(struct tp_dispatch *tp, uint64_t time)
{
struct tp_touch *t = tp_current_touch(tp);
double dx, dy;
- int filter_motion = 0;
double dx_unaccel, dy_unaccel;
- /* Only post (top) button events while suspended */
- if (tp-device-suspended) {
- tp_post_button_events(tp, time);
- return;
- }
-
- filter_motion |= tp_tap_handle_state(tp, time);
- filter_motion |= tp_post_button_events(tp, time);
-
- if (filter_motion || tp-sendevents.trackpoint_active) {
- tp_stop_scroll_events(tp, time);
- return;
- }
-
- if (tp_post_scroll_events(tp, time) != 0)
- return;
-
if (!t-is_pointer) {
tp_for_each_touch(tp, t) {
if (t-is_pointer)
@@ -639,6 +620,31 @@ tp_post_events(struct tp_dispatch *tp, uint64_t time)
}
static void
+tp_post_events(struct tp_dispatch *tp, uint64_t time)
+{
+ int filter_motion = 0;
+
+ /* Only post (top) button events while suspended */
+ if (tp-device-suspended) {
+ tp_post_button_events(tp, time);
+ return;
+ }
+
+ filter_motion |= tp_tap_handle_state(tp, time);
+ filter_motion |= tp_post_button_events(tp, time);
+
+ if (filter_motion || tp-sendevents.trackpoint_active) {
+ tp_stop_scroll_events(tp, time);
+ return;
+ }
+
+ if (tp_post_scroll_events(tp, time) != 0)
+ return;
+
+ tp_post_pointer_motion(tp, time);
+}
+
+static void
tp_handle_state(struct tp_dispatch *tp,
uint64_t time)
{
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 3/3] touchpad: Use TOUCHPAD_MIN_SAMPLES in tp_get_delta
Use TOUCHPAD_MIN_SAMPLES in tp_get_delta rather then hardcoding 4.
Also remove the superfluous TOUCHPAD_MIN_SAMPLES check before calling
tp_get_delta in tp_get_pointer_delta, this is not necessary as tp_get_delta
already checks itself.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/evdev-mt-touchpad.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 7cee73d..397b8b9 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -177,7 +177,7 @@ tp_estimate_delta(int x0, int x1, int x2, int x3)
void
tp_get_delta(struct tp_touch *t, double *dx, double *dy)
{
- if (t-history.count 4) {
+ if (t-history.count TOUCHPAD_MIN_SAMPLES) {
*dx = 0;
*dy = 0;
return;
@@ -607,9 +607,7 @@ tp_get_pointer_delta(struct tp_dispatch *tp, double *dx,
double *dy)
}
}
- if (!t-is_pointer ||
- !t-dirty ||
- t-history.count TOUCHPAD_MIN_SAMPLES)
+ if (!t-is_pointer || !t-dirty)
return;
tp_get_delta(t, dx, dy);
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Time in wayland presentation extension
On Tue, 09 Dec 2014 11:21:31 +0100
Dan Oscarsson dan.oscars...@tieto.com wrote:
Hi
While I have been looking at Wayland for a long time I have not yet
tried it.
I have for a long time worked with video players and used VDPAU as the
best way to get video working well.
I have not yet studied the Wayland protocols very much to see how things
will work there. Hopefully we can get VDPAU for it too.
vdpau have a timing and a presentation queue and it works very well.
The basic needs for best video display is if you can:
- get info when (the time) vsyncs occur.
- get the time between vsyncs.
- schedule frame display at a specific vsync and get back if it was
displayed correctly.
Hi,
yes, the more eyes on a spec, the merrier. Welcome. :-)
Looking at the wayland presentation extension I see that you send time
in the format: seconds plus nanoseconds.
This is bad as you all the time have to convert between time and the
split into seconds+nanoseconds.
Why not just send nanoseconds?
64-bits of nanoseconds is long enough for many years in the future.
Y2K ;-)
Seriously though, why is it bad to use timespec format in the protocol?
clock_gettime uses struct timespec, and if you use anything less, you
risk losing something. It's hard to imagine the burden of converting or
even computing with it to be measurable.
But if you really have a benchmark to show that the difference is
measurable in, say, a video player, I would be very interested.
Anyway, what goes on the wire is a different thing than what is stored
inside your application. You are free to use any format you want. The
conversions will happen only at the protocol interface, which is in the
order of twice per frame in a video player.
We don't even have (and cannot add) a u64 wire type, so each 64-bit
quantity is split into two u32 anyway.
Using a single value for time is much easier to use. When you schedule
video frame display you do calculations on time and you do not want to
keep time in split seconds+nanosecond values.
You can use a single value format, this is only the protocol.
However, the protocol deals with absolute timestamps, where the base is
unspecified from the protocol point of view, and a possible wraparound
might become a problem.
One also has to be able to read the clock that the compositor is using.
On Linux, it is defined that the clock can be read with clock_gettime,
which returns a struct timespec. Now if the protocol used something
else as the time format, it would need to define the conversion.
Defining a standard conversion in a future-proof way is something I
rather avoid and just send the complete data through.
This way you can choose the conversion that suits your data types the
best, be it u32 milliseconds, u64 nanoseconds, { s16 seconds, u16
milliseconds }, or whatever, while still being given the whole original
time data. If you lose anything, it's your own choice.
I am not sure that the way the compositor picks the update to do is
good. The protocol says the update with the highest timestamp no later
than a half frame period after the predicted presentation time. When I
plan for a video frame to be displayed, I queue it at a suitable time
before the vsync it should be display on. It may not be display on an
earlier vsync. It may be that the plan here is to allow applications to
queue frames for display without knowing when they will be displayed
letting the compositor show them at the best vsync. But for me who want
as good display as possible while keeping audio in sync, I calculate
best vsync and then queue it for presentation - the compositor may not
move the display time backwards - it may move it forward if it misses
the correct vsync to the next vsync if the application is informed of
that (in good time so the application can discard ned planned frame).
This is very much how Presentation queueing was designed to work.
Foremost it guarantees that frames cannot be displayed out of order,
where the order is dictated by the target timestamps.
The above semantics are intended to give zero latency on average if the
target times are uniformly distributed compared to vsync. This is good
for programs that do not lock on to the vsync cycle and maintain the
vsync-clock association. It also good for display systems that do
not have a stable vsync frequency (FreeSync, Adaptive-Sync, Nvidia
G-sync). The compositor presumably knows the instantaneous frame cycle
length, but clients are always behind in that knowledge.
Those clients that do synchronize to vblanks explicitly and maintain the
association, they also know how the compositor picks the frame to be
presented. If you want not before semantics, you could mangle (or use
flags) your target timestamps to get it, assuming there is a stable
vsync frequency.
OTOH, if the vsync frequency is dynamic, you can't really lock your
frame queue to it. Instead, you need to rely on the compositor to lock
the vsync frequency to your frame
[PATCH 2/3] touchpad: When a clickpad is clicked post combined motion of all touches
When clicking a clickpad the user may want to switch fingers to move the
pointer around, without lifting so as to not release the button.
Switch to using combined motion of all touches when a clickpad is clicked to
allow this.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86807
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/evdev-mt-touchpad.c | 43 +++
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 7d2e21a..7cee73d 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -453,6 +453,10 @@ tp_twofinger_scroll_post_events(struct tp_dispatch *tp,
uint64_t time)
if (tp_tap_dragging(tp))
return 0;
+ /* No 2fg scrolling while a clickpad is clicked */
+ if (tp-buttons.is_clickpad tp-buttons.state)
+ return 0;
+
/* Only count active touches for 2 finger scrolling */
tp_for_each_touch(tp, t) {
if (tp_touch_active(tp, t))
@@ -592,11 +596,9 @@ tp_post_process_state(struct tp_dispatch *tp, uint64_t
time)
}
static void
-tp_post_pointer_motion(struct tp_dispatch *tp, uint64_t time)
+tp_get_pointer_delta(struct tp_dispatch *tp, double *dx, double *dy)
{
struct tp_touch *t = tp_current_touch(tp);
- double dx, dy;
- double dx_unaccel, dy_unaccel;
if (!t-is_pointer) {
tp_for_each_touch(tp, t) {
@@ -610,7 +612,40 @@ tp_post_pointer_motion(struct tp_dispatch *tp, uint64_t
time)
t-history.count TOUCHPAD_MIN_SAMPLES)
return;
- tp_get_delta(t, dx, dy);
+ tp_get_delta(t, dx, dy);
+}
+
+static void
+tp_get_active_touches_delta(struct tp_dispatch *tp, double *dx, double *dy)
+{
+ struct tp_touch *t;
+ double tdx, tdy;
+ unsigned int i;
+
+ for (i = 0; i tp-real_touches; i++) {
+ t = tp_get_touch(tp, i);
+
+ if (!tp_touch_active(tp, t) || !t-dirty)
+ continue;
+
+ tp_get_delta(t, tdx, tdy);
+ *dx += tdx;
+ *dy += tdy;
+ }
+}
+
+static void
+tp_post_pointer_motion(struct tp_dispatch *tp, uint64_t time)
+{
+ double dx = 0.0, dy = 0.0;
+ double dx_unaccel, dy_unaccel;
+
+ /* When a clickpad is clicked, combine motion of all active touches */
+ if (tp-buttons.is_clickpad tp-buttons.state)
+ tp_get_active_touches_delta(tp, dx, dy);
+ else
+ tp_get_pointer_delta(tp, dx, dy);
+
tp_filter_motion(tp, dx, dy, dx_unaccel, dy_unaccel, time);
if (dx != 0.0 || dy != 0.0 || dx_unaccel != 0.0 || dy_unaccel != 0.0) {
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Where should project Weston go?
2014-12-08 14:01 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: Dear Wayland community, I would like to start a discussion on what Weston really is, and where it should go, if only to confirm that our concensus still holds. I feel the need for it, because I personally find it sometimes hard to judge whether a big new feature is a good idea or out of scope. If I am lacking a clear vision, I can only imagine it is even harder for others to decide, and I believe lack of vision can also hinder our patch review. It is too easy to postpone reviewing a patch series if one is not completely sure it belongs in Weston. Our website defines Weston as follows: Part of the Wayland project is also the Weston reference implementation of a Wayland compositor. ... The Weston compositor is a minimal and fast compositor and is suitable for many embedded and mobile use cases. To reiterate the main points: - the reference implementation - minimal - fast (performant?) - suitable for embedded and mobile (and now automotive?) I'm not sure it can be said it's minimal anymore. After all it has many backends, three different renderers and two different shells, with many additional protocols that a really minimal compositor may not want to support. Weston is also a test bed for new protocols and features. We tend to land experimental protocols in Weston, try them out there (while in this stage, third party projects need to copy the XML files from Weston), and when they stabilize, we move protocols into the Wayland project and install the XML files from there for everyone to use. Perhaps the most striking omission in the above is that the desktop for PC is not mentioned. The desktop is in scope only through the reference implementation. What does it mean? I believe it means, that Weston needs to implement all the important desktop-related protocol extensions, obviously starting from xdg_shell. This is the reference implementation. However, other desktop-oriented protocol extensions might not be that obvious. How would we judge them? I guess it has to be case by case, which makes it hard for any one person to do. On the other hand, it also means that Weston does not need to, and maybe even should not, implement many desktop features that do not include a protocol extension to be standardized across Wayland servers. Where to draw the line? How to keep Weston minimal and fast, while we would likely want to make Weston more usable as a desktop server too? In my opinion Weston is not anymore a simple reference compositor implementation, and i see it as a good thing. Implementing a compositor with the same feature set weston has is not an easy feat and takes a lot of time. Additionally, thanks to the very few dependencies it can be used in many different applications and environments. I don't think the compositor needs to be really simple to read, i don't think many people want to write a compositor from scratch. However, i see very often people asking how to make a wayland wm. This i think is where weston could shine, thanks to the plugin API or a libweston, and act as a base for many wayland wms. For this reason, i think, the desktop shell in weston should be a simple reference implementation. We don't have documentation, so shell.c is the only thing someone can look at to understand how to write a shell plugin. In my opinion it's already far too complex (shell.c is more than 6000 LOCs with little structure) and on the other hand i don't see the manpower to write and maintain a usable desktop shell, and adding a little feature here and there will not do much for that, but may make it a lot more complex to understand. This is not to say we shold not have, say, a xdg_shell implementation. That is a very basic building block of a wayland desktop shell, so it fits perfectly there. Stuff like expose or the broken virtual desktops implementation, not so well, imho. -- Giulio Should we add one more goal for Weston: a simple desktop environment? But how simple? Would it include, say, a tool to do permanent video mode changes? A real screen lock? A task list? Also see the note about camp agnostic below, which limits the realistic possibilities a lot. Before one says Yes!, we need to think about maintainability. Can we write a test that would run during 'make check' and see that the feature keeps on working? I agree with the saying that if something is not tested, you can assume it's broken. It is also a reason why I am so thrilled about the test suite improvements. So far the desktop shell implementation in Weston has not been considered anything more than a reference implementation of wl_shell and xdg_shell. Proper, more user friendly DEs are external projects that build Weston plugins. A problem there is that if Weston has to have a feature that is not used from the Weston project itself, it may easily break. There is also the problem that the plugin ABI is not stable.
Re: FOSDEM15: Graphics DevRoom: call for speakers.
On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote: Hi, At FOSDEM on the 31st of january and the 1st of February 2015, there will be another graphics DevRoom. URL: https://fosdem.org/2015/ Slots will be handed out on a first come, first serve basis. The best slots will go to those who apply the earliest. The amount of slots is currently not known yet, but i expect there to be around 16 available (8 on each day), so act quickly. As for deadlines, i hope to have a pretty much complete schedule between christmas and the new year. The rockhard printed schedule deadline is probably January 9th, after that you will not be featured in the booklet and you will have a lot less visitors. I will hopefully be able to lock down entries and descriptions after that date. It's been more than 2 months since the original email, it's less than two months away from the event, and one month away from what usually is the deadline for the booklet. File your talk now, while there are still some useful slots available. Also, for those who have filed already but who have left their abstracts open, please get those filed in ASAP. Your talk will be only be ordered in when at least the basics are provided. Thanks, Luc Verhaegen. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] evdev: Ensure the libevdev object receives the new fd on resume
Otherwise, input_events will be attempted to read from the wrong place,
which also leaves the right/current fd with pending data to be read,
making the epoll fd wake up constantly.
Signed-off-by: Carlos Garnacho carl...@gnome.org
---
src/evdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index c8ca384..137c20c 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2012,6 +2012,9 @@ evdev_device_resume(struct evdev_device *device)
return -ENODEV;
}
+ libevdev_change_fd(device-evdev, fd);
+ libevdev_set_clock_id(device-evdev, CLOCK_MONOTONIC);
+
device-source =
libinput_add_fd(libinput, fd, evdev_device_dispatch, device);
if (!device-source) {
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Time in wayland presentation extension
Hi, On Tue, 09 Dec 2014 14:49:01 +0100 Dan Oscarsson dan.oscars...@tieto.com wrote: tis 2014-12-09 klockan 14:10 +0200 skrev Pekka Paalanen: On Tue, 09 Dec 2014 11:21:31 +0100 Dan Oscarsson dan.oscars...@tieto.com wrote: Looking at the wayland presentation extension I see that you send time in the format: seconds plus nanoseconds. This is bad as you all the time have to convert between time and the split into seconds+nanoseconds. Why not just send nanoseconds? 64-bits of nanoseconds is long enough for many years in the future. Y2K ;-) Yes, but you will get that with two 32-bit values too. No, seconds is 64-bit in the protocol currently. Seriously though, why is it bad to use timespec format in the protocol? clock_gettime uses struct timespec, and if you use anything less, you risk losing something. It's hard to imagine the burden of converting or even computing with it to be measurable. 64-bits in nanoseconds can contain longer time than 32-bit for seconds and 32-bits for nanoseconds. So you do not lose anything by specifying time as a 64-bit nanoseconds value. But if you really have a benchmark to show that the difference is measurable in, say, a video player, I would be very interested. Anyway, what goes on the wire is a different thing than what is stored inside your application. You are free to use any format you want. The conversions will happen only at the protocol interface, which is in the order of twice per frame in a video player. Yes, it is not that bad. But looking at code in mplayer/mpv there are many places with time conversions: struct timespec - floating - double - 32-bit - 64-bits. A large mess, many places where a misstake can be done. It would be much cleaner with a single simple representation of time that could be used anywhere. The simplest is one integer value or one double value (though double might lose some nanoseconds in some calculations I suspect). Unfortunately that is a not a problem that Wayland could solve. Also timestamps vs. time intervals often deserve different types. For instance float is not appropriate for a timestamp at all while double might. And yes, the computations you want to do affect also what type want to choose. I do not think there is one type that can fit all. Luckily the type used in the protocol only needs to represent a value accurately. We don't even have (and cannot add) a u64 wire type, so each 64-bit quantity is split into two u32 anyway. When all modern hardware supports 64 bits well. Yeah, it was an oversight, that got written into stone, when libwayland ABI was stabilized. We realised it only long after the fact. Though it is very easy to send 64 bits as two 32-bit values. It is much worse to convert an integer into seconds and nanoseconds - especially if you want to do it on old 32-bit hardware. Anyway, I mostly wanted a simple value in the protocol. Just like I would have preferred clock_gettime to return a 64-bit value instead. Sorry, I'm quite hesitant to go back there. The above semantics are intended to give zero latency on average if the target times are uniformly distributed compared to vsync. This is good for programs that do not lock on to the vsync cycle and maintain the vsync-clock association. It also good for display systems that do not have a stable vsync frequency (FreeSync, Adaptive-Sync, Nvidia G-sync). The compositor presumably knows the instantaneous frame cycle length, but clients are always behind in that knowledge. I have expected FreeSync, Adaptive-Sync, Nvidia G-sync to actually allow the video player (not the compositor) to play video and get each frame to be displayed at exactly the correct time for all movie speeds. It would also handle videos with variable frame rate to be display correctly. Yes, but always through the compositor. It can bypass compositing, but not the compositor. X11 has special let's use a hardware overlay protocol extension, but we deliberately do not want such thing in Wayland. The compositor is always in full control of all presentation. Using a hardware overlay is an internal decision that the compositor does every output frame. This way the compositor will composite when it has to, and use hardware resources when it can. This leads to optimal usage of display hardware resources without complicated negotiations with clients. With dynamic refresh, the compositor could adapt to the requirements of all the running clients. Most clients just present frames ASAP, but if a video player uses queueing, it obviously cares about timing, and the compositor can prioritize it. The point is, that the compositor knows everything that happens on the display, so it can make optimal decisions. Clients cannot hurt other clients by hijacking hardware resources. Clients also cannot do optimal decisions about hardware usage, because one client does not know what other clients do. When
Re: [PATCH wayland v2 1/2] client: update obsolete comments
On Wed, 3 Dec 2014 13:05:16 +0100 Marek Chalupa mchqwe...@gmail.com wrote: On 28 November 2014 at 14:30, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 28 Nov 2014 12:18:55 +0100 Marek Chalupa mchqwe...@gmail.com wrote: 1) there is nothing like main thread since 3c7e8bfbb4745315b7bcbf69fa746c3d6718c305 anymore, so remove it from documentation and update the doc accordingly. 2) use calling 'default queue' instead of 'main queue'. In the code we use display-default_queue, so it'll be easier the understand. 3) update some obsolete or unprecise pieces of documentation Signed-off-by: Marek Chalupa mchqwe...@gmail.com --- src/wayland-client.c | 80 src/wayland-client.h | 26 - 2 files changed, 61 insertions(+), 45 deletions(-) diff --git a/src/wayland-client.c b/src/wayland-client.c index 36380fe..0ab94e9 100644 --- a/src/wayland-client.c +++ b/src/wayland-client.c ... + + * \note Display queue (for wl_display events like delete_id or so) + * is dispatched always. I wonder if referring to the display queue is just confusing, because I don't see us really explaining what it is anywhere. And it's not the default queue. In fact, I don't think the users of libwayland would even care about it. True. Hmm, just thinking about it - I should rephrase the thing about checking return value of wl_display_dispatch_queue(). Because when it dispatched some events in display_queue, then it won't return 0 even when it dispatched none of the queue-assigned events, so what I wrote in the comment to wl_display_dispatch_queue() is wrong. But to clarify that it can return non-0 even when it dispatched no events, I have to say the thing about display queue, don't I? Huh. I wonder if that should be fixed in code instead? Could anything outside libwayland-client care about when the hidden internal display queue dispatches? Errors maybe? Dispatching the display queue cannot create requests one might need to flush, right? Hmm, but the correction you did to the doc is good, accurate to the code AFAIK, and not doing a non-obvious change in the code is probably for the better. Yeah, nevermind, I think. :-) Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v3 2/2] client: update documentation about threading
On Fri, 5 Dec 2014 14:03:28 +0100 Marek Chalupa mchqwe...@gmail.com wrote: On 3 December 2014 at 17:04, Daniel Stone dan...@fooishbar.org wrote: Hi, On 3 December 2014 at 14:53, Marek Chalupa mchqwe...@gmail.com wrote: + * fds[0].fd = wl_display_get_fd(display); + * fds[0].event = POLLIN | POLLHUP | POLLERR; POLLHUP and POLLERR are not valid for fds[0].events (note spelling); they can be returned in revents if these events happened, but you don't explicitly select for them. Well, to be precise -- they are valid but have no effect (according to man pages). Fixed, thanks :) Other than that, these look good to me, with the caveat that it might be nice to invert the order of prepare_read()'s documentation: currently it talks about the problem the function solves, and only later goes on to explain the pattern you should actually use. It would be nice to just explain what to do, and only later explain why you shouldn't do anything else. Yeah, that sounds reasonable. I swapped these parts and also changed the example code a little bit. Thanks for doing this! It's super-helpful, and magically resolves one of the things on my post-it TODO note. ;) Both patches pushed. I took the liberty to add R-b Daniel, too. Awesome. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 1/2] compositor: Propagate errors from module_init
On 05/12/14 07:49 PM, Ondřej Majerech wrote: load_modules currently ignores errors signalled by both weston_load_module and module_init, and instead always returns 0. Its return value appears to be checked in callers, so we most likely want to propagate any errors. Signed-off-by: Ondřej Majerech majerec...@gmail.com --- src/compositor.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/compositor.c b/src/compositor.c index 53f6220..867 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -4423,8 +4423,10 @@ load_modules(struct weston_compositor *ec, const char *modules, end = strchrnul(p, ','); snprintf(buffer, sizeof buffer, %.*s, (int) (end - p), p); module_init = weston_load_module(buffer, module_init); - if (module_init) - module_init(ec, argc, argv); + if (!module_init) + return -1; + if (module_init(ec, argc, argv) 0) + return -1; This looks like a good idea to me - wouldn't mind seeing a weston_log() here to let us know what failed and why, but even so: Reviewed-by: Derek Foreman der...@osg.samsung.com p = end; while (*p == ',') p++; ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Adding notes regarding Arch Linux dependencies for DocBook.
On 08/12/14 08:49 AM, Jon A. Cruz wrote: Adding simple notes on DocBook dependencies needed when building on Arch Linux. Without these being present the documentation build will attempt network access and fail outright or warn and then not produce correct results when no Internet access is present. Any way we can print a more descriptive error at failure time instead of just hiding a clue in the docs? Or can we just disable docbook if deps aren't present? I'm not certain Arch will be the only distribution to ever have this problem, and the comment could get a little unwieldy... (Why is this reaching out over the internet anyway? Is this a bug that should be brought up with an Arch package maintainer?) Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=86515 Signed-off-by: Jon A. Cruz j...@osg.samsung.com --- building.html | 4 1 file changed, 4 insertions(+) diff --git a/building.html b/building.html index 401069b..fbedfae 100644 --- a/building.html +++ b/building.html @@ -42,6 +42,8 @@ Linux Mint 17/a, which is derived from Ubuntu 14.04./li liFor building Weston for a href=http://www.raspberrypi.org/;Raspberry Pi/a, see a href=raspberrypi.htmlRaspberry Pi build guide/a./li +liFor building Wayland on Arch note that a href=https://wiki.archlinux.org/index.php/Docbook#Setting_up_Docbook_in_Arch;DocBook dependencies/a will be needed when building documentation./li + /ul h2Hardware / Drivers/h2 @@ -119,6 +121,8 @@ $ cd .. liYou can avoid the a href=http://www.stack.nl/~dimitri/doxygen/;Doxygen/a dependency with code--disable-documentation/code./li +liUnder Arch Linux, a href=https://wiki.archlinux.org/index.php/Docbook#Setting_up_Docbook_in_Arch;DocBook dependencies/a will be needed when building documentation. These include codedocbook-xml/code and codedocbook-xsl/code./li + /ul h2Mesa/h2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/3] screenshooter: fix various memory handling
On 05/12/14 06:49 AM, Marek Chalupa wrote:
There were unchecked malloc and free of conditionally allocated
memory without checking if the memory was really allocated.
Also simplify error handling in one function.
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
src/screenshooter.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/src/screenshooter.c b/src/screenshooter.c
index 6246cda..b7b1fd0 100644
--- a/src/screenshooter.c
+++ b/src/screenshooter.c
@@ -464,8 +464,11 @@ weston_recorder_free(struct weston_recorder *recorder)
{
if (recorder == NULL)
return;
+
+ if (recorder-tmpbuf)
+ free(recorder-tmpbuf);
+
free(recorder-rect);
- free(recorder-tmpbuf);
I think recorder-tmpbuf should be NULL if it was never required
(recorder is allocated with zalloc), and free(NULL); is a NOP...
free(recorder-frame);
free(recorder);
}
@@ -495,12 +498,16 @@ weston_recorder_create(struct weston_output *output,
const char *filename)
if ((recorder-frame == NULL) || (recorder-rect == NULL)) {
weston_log(%s: out of memory\n, __func__);
- weston_recorder_free(recorder);
- return;
+ goto err_recorder;
}
- if (!do_yflip)
+ if (!do_yflip) {
recorder-tmpbuf = malloc(size);
+ if (recorder-tmpbuf == NULL) {
+ weston_log(%s: out of memory\n, __func__);
+ goto err_recorder;
+ }
Yup, we need this bit.
And I like the goto err_recorder stuff as well, though I guess that's a
matter of preference.
+ }
header.magic = WCAP_HEADER_MAGIC;
@@ -514,8 +521,7 @@ weston_recorder_create(struct weston_output *output,
const char *filename)
break;
default:
weston_log(unknown recorder format\n);
- weston_recorder_free(recorder);
- return;
+ goto err_recorder;
}
recorder-fd = open(filename,
@@ -523,8 +529,7 @@ weston_recorder_create(struct weston_output *output,
const char *filename)
if (recorder-fd 0) {
weston_log(problem opening output file %s: %m\n, filename);
- weston_recorder_free(recorder);
- return;
+ goto err_recorder;
}
header.width = output-current_mode-width;
@@ -535,6 +540,12 @@ weston_recorder_create(struct weston_output *output,
const char *filename)
wl_signal_add(output-frame_signal, recorder-frame_listener);
output-disable_planes++;
weston_output_damage(output);
+
+ return;
+
+err_recorder:
+ weston_recorder_free(recorder);
+ return;
}
static void
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 1/2] compositor: Propagate errors from module_init
On Tue, 09 Dec 2014 10:19:22 -0600 Derek Foreman der...@osg.samsung.com wrote: On 05/12/14 07:49 PM, Ondřej Majerech wrote: load_modules currently ignores errors signalled by both weston_load_module and module_init, and instead always returns 0. Its return value appears to be checked in callers, so we most likely want to propagate any errors. Signed-off-by: Ondřej Majerech majerec...@gmail.com --- src/compositor.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/compositor.c b/src/compositor.c index 53f6220..867 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -4423,8 +4423,10 @@ load_modules(struct weston_compositor *ec, const char *modules, end = strchrnul(p, ','); snprintf(buffer, sizeof buffer, %.*s, (int) (end - p), p); module_init = weston_load_module(buffer, module_init); - if (module_init) - module_init(ec, argc, argv); + if (!module_init) + return -1; + if (module_init(ec, argc, argv) 0) + return -1; This looks like a good idea to me - wouldn't mind seeing a weston_log() here to let us know what failed and why, but even so: weston_load_module already says what failed, so no need to report that again. And for an error coming from module_init, you don't really know what the problem might be (other than that the initialisation has failed), so I think it should be the job of module_init to report what's wrong. Reviewed-by: Derek Foreman der...@osg.samsung.com p = end; while (*p == ',') p++; ___ 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 2/2] ivi-shell: Say something when configuration is missing
On Tue, 9 Dec 2014 09:29:15 +0900
Tanibata, Nobuhiko (ADITJ/SWG) ntanib...@jp.adit-jv.com wrote:
How about adding more info like following to clearly say which shell
output this log? weston_log(ivi-shell: No ivi-module set in
weston.conf\n);
Yes, clearly identifying the shell sounds like a good idea. :-)
BR,
Nobuhiko Tanibata
-Original Message-
From: wayland-devel
[mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of
Ond?ej Majerech
Sent: Saturday, December 06, 2014 9:39 AM
To: wayland-devel@lists.freedesktop.org
Cc: Ondřej Majerech
Subject: [PATCH 2/2] ivi-shell: Say something when configuration is
missing
When ivi-module is not set in weston.conf, we probably want to tell
the user about their error instead of just dying.
Signed-off-by: Ondřej Majerech majerec...@gmail.com
---
ivi-shell/ivi-shell.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c index
a14010e..02fbafb 100644
--- a/ivi-shell/ivi-shell.c
+++ b/ivi-shell/ivi-shell.c
@@ -385,6 +385,7 @@ ivi_shell_setting_create(struct
ivi_shell_setting *dest,
if (weston_config_section_get_string(
section, ivi-module, dest-ivi_module, NULL) !=
0) {
+ weston_log(No ivi-module set in weston.conf\n);
result = -1;
}
--
1.9.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 v2 1/2] compositor: Propagate errors from module_init
On 09/12/14 12:29 PM, Ondřej Majerech wrote: On Tue, 09 Dec 2014 10:19:22 -0600 Derek Foreman der...@osg.samsung.com wrote: On 05/12/14 07:49 PM, Ondřej Majerech wrote: load_modules currently ignores errors signalled by both weston_load_module and module_init, and instead always returns 0. Its return value appears to be checked in callers, so we most likely want to propagate any errors. Signed-off-by: Ondřej Majerech majerec...@gmail.com --- src/compositor.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/compositor.c b/src/compositor.c index 53f6220..867 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -4423,8 +4423,10 @@ load_modules(struct weston_compositor *ec, const char *modules, end = strchrnul(p, ','); snprintf(buffer, sizeof buffer, %.*s, (int) (end - p), p); module_init = weston_load_module(buffer, module_init); - if (module_init) - module_init(ec, argc, argv); + if (!module_init) + return -1; + if (module_init(ec, argc, argv) 0) + return -1; This looks like a good idea to me - wouldn't mind seeing a weston_log() here to let us know what failed and why, but even so: weston_load_module already says what failed, so no need to report that again. And for an error coming from module_init, you don't really know what the problem might be (other than that the initialisation has failed), so I think it should be the job of module_init to report what's wrong. A-ha, you are correct. :) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v1 02/17] tests: link tests against libtoytoolkit
On 05/12/14 07:36 AM, Marek Chalupa wrote:
We want to use toytoolkit in tests. This patch also
removes collisions of symbols defined in libtoytoolkit
with symbols defined in tests (i. e. shm_listener)
This patch introduces a compiler warning over the definition of
xzalloc() in presentation-test.c.
It's fixed later in the series, so I'm being pretty pedantic here. :)
Why link all existing tests against toytoolkit instead of just ones that
use toytoolkit functionality? (I see this patch makes toytoolkit
provide xzalloc to all the tests, is that why?)
I don't think I see any harm in it, and doing this seems to put us
within reach of having exactly one definition of xzalloc() in the source
tree. ;)
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
Makefile.am | 26 +++---
tests/weston-test-client-helper.c | 5 +++--
tests/weston-test-client-helper.h | 14 ++
tests/weston-test-runner.h| 2 ++
4 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 4f4bb28..47c44dc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1003,51 +1003,55 @@ libtest_client_la_SOURCES = \
nodist_libtest_client_la_SOURCES = \
protocol/wayland-test-protocol.c\
protocol/wayland-test-client-protocol.h
-libtest_client_la_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
-libtest_client_la_LIBADD = $(TEST_CLIENT_LIBS) libshared.la libtest-runner.la
+libtest_client_la_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
$(CLIENT_CFLAGS)
+libtest_client_la_LIBADD = \
+ $(TEST_CLIENT_LIBS) \
+ libshared.la\
+ libtest-runner.la \
+ libtoytoolkit.la
bad_buffer_weston_SOURCES = tests/bad-buffer-test.c
-bad_buffer_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
+bad_buffer_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
$(CLIENT_CFLAGS)
bad_buffer_weston_LDADD = libtest-client.la
keyboard_weston_SOURCES = tests/keyboard-test.c
-keyboard_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
+keyboard_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS) $(CLIENT_CFLAGS)
keyboard_weston_LDADD = libtest-client.la
event_weston_SOURCES = tests/event-test.c
-event_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
+event_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS) $(CLIENT_CFLAGS)
event_weston_LDADD = libtest-client.la
button_weston_SOURCES = tests/button-test.c
-button_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
+button_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS) $(CLIENT_CFLAGS)
button_weston_LDADD = libtest-client.la
text_weston_SOURCES = tests/text-test.c
nodist_text_weston_SOURCES = \
protocol/text-protocol.c\
protocol/text-client-protocol.h
-text_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
+text_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS) $(CLIENT_CFLAGS)
text_weston_LDADD = libtest-client.la
subsurface_weston_SOURCES = tests/subsurface-test.c
-subsurface_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
+subsurface_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
$(CLIENT_CFLAGS)
subsurface_weston_LDADD = libtest-client.la
presentation_weston_SOURCES = tests/presentation-test.c
nodist_presentation_weston_SOURCES = \
protocol/presentation_timing-protocol.c \
protocol/presentation_timing-client-protocol.h
-presentation_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
+presentation_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
$(CLIENT_CFLAGS)
presentation_weston_LDADD = libtest-client.la
roles_weston_SOURCES = tests/roles-test.c
-roles_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
+roles_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS) $(CLIENT_CFLAGS)
roles_weston_LDADD = libtest-client.la
if ENABLE_EGL
weston_tests += buffer-count.weston
buffer_count_weston_SOURCES = tests/buffer-count-test.c
-buffer_count_weston_CFLAGS = $(GCC_CFLAGS) $(EGL_TESTS_CFLAGS)
+buffer_count_weston_CFLAGS = $(GCC_CFLAGS) $(EGL_TESTS_CFLAGS)
$(CLIENT_CFLAGS)
buffer_count_weston_LDADD = libtest-client.la $(EGL_TESTS_LIBS)
endif
diff --git a/tests/weston-test-client-helper.c
b/tests/weston-test-client-helper.c
index e374a96..45c2957 100644
--- a/tests/weston-test-client-helper.c
+++ b/tests/weston-test-client-helper.c
@@ -30,6 +30,7 @@
#include sys/mman.h
#include ../shared/os-compatibility.h
+#include ../clients/window.h
#include weston-test-client-helper.h
int
@@ -328,7 +329,7 @@ shm_format(void *data, struct wl_shm *wl_shm, uint32_t
format)
client-has_argb = 1;
}
-struct wl_shm_listener shm_listener = {
+struct wl_shm_listener wl_shm_listener = {
shm_format
};
@@ -466,7 +467,7 @@ handle_global(void *data, struct
Re: Where should project Weston go?
Bryce, Thanks for your thoughts. I've got a few of my own, but I decided to reply to your e-mail as it seemed the best branch-point for the actual discussion without replying to everything. On Mon, Dec 8, 2014 at 3:26 PM, Bryce Harrington br...@osg.samsung.com wrote: On Mon, Dec 08, 2014 at 02:01:32PM +0200, Pekka Paalanen wrote: Dear Wayland community, I would like to start a discussion on what Weston really is, and where it should go, if only to confirm that our concensus still holds. Thanks for opening discussion on this. I suspect a lot of us have been pondering these questions for a while. To reiterate the main points: - the reference implementation - fast (performant?) - suitable for embedded and mobile (and now automotive?) Performance is really only relevant in context to a use case; otherwise this can lead us to pre-maturely optimizing stuff that no one cares about. So, maybe fast for embedded/mobile/automotive. Or maybe there's an implied use case in the original statement (i.e. fast desktop) that should be made explicit. I think that Weston's performance matters a lot in some respects and not much in others. We don't want to overcomplicate things by prematurely optimizing or squeezing out every clock cycle we can. However, Weston does give us the opportunity to show off some of cool performance things the Wayland protocol allows us to do. One example of this is the planes support in the drm backend. Weston may be the only desktop compositor around today that take a single subsurface out of a window, put it in a plane, and flip it directly to the screen. This is fantastic for performance and power usage and is one of the advantages of the Wayland protocol. If people come to us complaining that you can't do that in Wayland just because GNOME or KWin aren't doing it, we can point to Weston and say, See, yes you can, they just aren't. Another fantastic example of this is the way the RPi backend uses planes. So I think showing off performance things we can do thanks to Wayland is important, squeezing out clock cycles isn't. - minimal :-) When I see a FOSS project describe itself as lightweight I read it as We consider our lack of features to be a Feature! But I imagine 'minimal' is intended here in more of an engineering sense, and interpret it myself to mean something like: Focuses on principle features not superfluous stuff better handled by other projects; doesn't overengineer algorithms to squeeze a few drops of performance; feature selection by what fits nicely and makes sense, not by marketing demands; favors short and concise function implementations that are easy to maintain and understand, even if it limits performance/portability/features a bit. Weston is also a test bed for new protocols and features. We tend to land experimental protocols in Weston, try them out there (while in this stage, third party projects need to copy the XML files from Weston), and when they stabilize, we move protocols into the Wayland project and install the XML files from there for everyone to use. Judging from what I've seen on the mailing lists there certainly is a strong demand pushing weston to fulfil this role as a laboratory of experimentation. But Weston's development processes seem to be set up more for product development than for freeform RD. Namely, we have one single true tree with a gatekeeper to control what gets committed, reviewers to catch quality issues, and a growing testsuite. I'm not saying this is wrong, just that this is probably not ideal for facilitating experimentation; folks may prefer to gravitate towards other compositor development projects where they can turn ideas and patches around more swiftly. And that's not necessarily a bad thing... but it's different than considering weston as a test bed. Perhaps what we want here is easily forkable. Not that we want people to be trying to fork the project but that we want to make it easy for someone to work on a feature branch in their own github repo and make things easy to merge back in or rebase on upstream. What does an easily forkable project look like? That's a good question. First would be to encourage people to work in feature branches rather than have to have everything on the list and/or in Weston core. While I think most things may want to be upstream eventually, trying to do upstream everything as you go is hard when people are trying to use it as a test-bed and you're trying to do stable release at the same time. We may even want to allow stuff to go upstream by merges rather then everything as a linear series on the ML. Another thing might be to make things structured a little better to try and structure things in a more compartmentalized model. Right now, Weston has a lot of files that are thousands of lines and should probably be broken up a bit (I'm looking at you, compositor.c). Having things structured a little better
Re: [PATCH 1/2] doc: General makefile cleanup.
Did you see the patch I posted that merged the client/server stuff
together into rules using % so that it is easier to add more
doxygen-produced chapters?
On 12/09/2014 01:34 AM, Jon A. Cruz wrote:
This is a general cleanup of the makefile in order to bring it more inline
with standard make practices. Cleanups included more use of automatic
variables, switching AM_V_GEN to AM_V_at to have one 'GEN' visible per file,
splitting copy operations to proper rules, and using order only dependencies
to properly create directories on-demand.
Changes also correct missing use of $(builddir) that has gone unnoticed as
it defaults to the current directory ('.').
Signed-off-by: Jon A. Cruz j...@osg.samsung.com
---
doc/publican/Makefile.am | 77 +---
1 file changed, 46 insertions(+), 31 deletions(-)
diff --git a/doc/publican/Makefile.am b/doc/publican/Makefile.am
index 0b2cd09..8ed3815 100644
--- a/doc/publican/Makefile.am
+++ b/doc/publican/Makefile.am
@@ -13,6 +13,7 @@
# * WaylandServerAPI.xml is generated from the doxygen output and saved in
# $(builddir)/en-US
# * run xmlto on $(builddir)/en-US, output to $(builddir)/Wayland/en-US
+
publican_sources = \
$(srcdir)/sources/Wayland.ent \
$(srcdir)/sources/Wayland.xml \
@@ -37,6 +38,7 @@ css_sources = \
$(srcdir)/sources/css/default.css \
$(srcdir)/sources/css/epub.css \
$(srcdir)/sources/css/print.css
+
img_sources = \
$(srcdir)/sources/images/icon.svg \
$(srcdir)/sources/images/wayland-architecture.png \
@@ -45,71 +47,84 @@ img_sources = \
if HAVE_XMLTO
if HAVE_XSLTPROC
-noinst_DATA = Wayland $(publican_targets)
+noinst_DATA = $(builddir)/Wayland $(publican_targets)
XMLTO_PARAM = \
--skip-validation \
--stringparam chunk.section.depth=0 \
--stringparam toc.section.depth=1 \
--stringparam html.stylesheet=css/default.css
+doxydir := $(top_builddir)/doc/doxygen
+
html_destdir = $(builddir)/Wayland/en-US/html
-Wayland: $(publican_targets)
- $(AM_V_GEN)$(MKDIR_P) -p $(html_destdir)/css
- $(AM_V_GEN)cp -f $(css_sources) $(html_destdir)/css/
- $(AM_V_GEN)$(MKDIR_P) -p $(html_destdir)/images
- $(AM_V_GEN)cp -f $(img_sources) $(html_destdir)/images/
- $(AM_V_GEN)$(XMLTO) $(XMLTO_PARAM) html en-US/Wayland.xml -o
$(html_destdir)
- @touch Wayland
+# Listing various directories that might need to be created.
+alldirs := $(builddir)/en-US $(builddir)/en-US/images $(html_destdir)
$(html_destdir)/css $(html_destdir)/images
+
+
+html_css_targets = $(addprefix $(html_destdir)/css/,$(notdir $(css_sources)))
+html_img_targets = $(addprefix $(html_destdir)/images/,$(notdir
$(img_sources)))
+
+$(builddir)/Wayland: $(publican_targets) $(html_css_targets)
$(html_img_targets) | $(builddir)/en-US
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_PARAM) html $(builddir)/en-US/Wayland.xml
-o $(html_destdir)
+ @touch $@
+
+$(html_destdir)/css/%: $(srcdir)/sources/css/% | $(html_destdir)/css
+ $(AM_V_GEN)cp -f $ $@
+
+$(html_destdir)/images/%: $(srcdir)/sources/images/% | $(html_destdir)/images
+ $(AM_V_GEN)cp -f $ $@
pubdir = $(docdir)/Wayland/en-US
-publican_targets = $(publican_sources:$(srcdir)/sources%=$(builddir)/en-US%) \
- en-US/ProtocolSpec.xml en-US/ProtocolInterfaces.xml \
- en-US/WaylandClientAPI.xml en-US/WaylandServerAPI.xml
+publican_targets = $(publican_sources:$(srcdir)/sources/%=$(builddir)/en-US/%)
\
+ $(builddir)/en-US/ProtocolSpec.xml
$(builddir)/en-US/ProtocolInterfaces.xml \
+ $(builddir)/en-US/WaylandClientAPI.xml
$(builddir)/en-US/WaylandServerAPI.xml
# The Protocol.xml is purely generated and required before running publican
-en-US/ProtocolSpec.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-to-docbook.xsl
- $(AM_V_GEN)$(MKDIR_P) en-US/images
+$(builddir)/en-US/ProtocolSpec.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-to-docbook.xsl | $(builddir)/en-US
$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-to-docbook.xsl \
- $(top_srcdir)/protocol/wayland.xml en-US/ProtocolSpec.xml
+ $(top_srcdir)/protocol/wayland.xml $@
-en-US/ProtocolInterfaces.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-interfaces-to-docbook.xsl
- $(AM_V_GEN)$(MKDIR_P) en-US/images
+$(builddir)/en-US/ProtocolInterfaces.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-interfaces-to-docbook.xsl
$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-interfaces-to-docbook.xsl \
- $(top_srcdir)/protocol/wayland.xml
en-US/ProtocolInterfaces.xml
+ $(top_srcdir)/protocol/wayland.xml $@
# * we don't want wayland-{server|client}_8h.xml to avoid duplicating output
methods,
# move it out of the way first.
# * use doxygen's combine.xslt to merge the xml files into one single file
# * move wayland-foo_8h.xml back to its original location
Re: [PATCH weston v1 05/17] clients: add missing getters for input objects
On 05/12/14 07:36 AM, Marek Chalupa wrote:
We need get wayland objects from toytoolkit display
(there already are display_get_output, input_get_seat, ...),
so that we can use them in the tests. This patch adds:
display_get_input()
input_get_wl_pointer()
input_get_wl_keyboard()
input_get_wl_touch()
Is there any reason we'd want these to be unavailable to toytoolkit apps?
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
clients/window.c | 24
clients/window.h | 12
2 files changed, 36 insertions(+)
diff --git a/clients/window.c b/clients/window.c
index cc1e272..8dbf878 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -5211,6 +5211,24 @@ input_destroy(struct input *input)
free(input);
}
+struct wl_pointer *
+input_get_wl_pointer(struct input *input)
+{
+ return input-pointer;
+}
+
+struct wl_keyboard *
+input_get_wl_keyboard(struct input *input)
+{
+ return input-keyboard;
+}
+
+struct wl_touch *
+input_get_wl_touch(struct input *input)
+{
+ return input-touch;
+}
+
static void
init_workspace_manager(struct display *d, uint32_t id)
{
@@ -5664,6 +5682,12 @@ display_get_output(struct display *display)
return container_of(display-output_list.next, struct output, link);
}
+struct input *
+display_get_input(struct display *display)
+{
+ return container_of(display-input_list.next, struct input, link);
+}
+
struct wl_compositor *
display_get_compositor(struct display *display)
{
diff --git a/clients/window.h b/clients/window.h
index 5247f19..20d3fa0 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -93,6 +93,9 @@ display_get_compositor(struct display *display);
struct output *
display_get_output(struct display *display);
+struct input *
+display_get_input(struct display *display);
+
uint32_t
display_get_serial(struct display *display);
@@ -613,6 +616,15 @@ output_get_allocation(struct output *output, struct
rectangle *allocation);
struct wl_output *
output_get_wl_output(struct output *output);
+struct wl_pointer *
+input_get_wl_pointer(struct input *input);
+
+struct wl_keyboard *
+input_get_wl_keyboard(struct input *input);
+
+struct wl_touch *
+input_get_wl_touch(struct input *input);
+
enum wl_output_transform
output_get_transform(struct output *output);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v1 07/17] tests-helper: distil the functionality from handlers
Distill has 2 ls...
On 05/12/14 07:36 AM, Marek Chalupa wrote:
Split out the real code from event handlers (like pointer_handle_motion,
etc.) and put it into standalone function. We'll use it in follow-up
patch where we will register handlers for toytoolkit clients and we'll
use the new functions so that the code won't be duplicated.
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
tests/weston-test-client-helper.c | 170
+-
1 file changed, 130 insertions(+), 40 deletions(-)
...
+
+static void
+store_keyboard_modifiers(struct keyboard *keyboard, uint32_t mods_depressed,
+ uint32_t mods_latched, uint32_t mods_locked,
+ uint32_t group)
+{
keyboard-mods_depressed = mods_depressed;
keyboard-mods_latched = mods_latched;
keyboard-mods_locked = mods_locked;
keyboard-group = group;
- fprintf(stderr, test-client: got keyboard modifiers %u %u %u %u\n,
+ fprintf(stderr, test-client: got keyboard modifiers %x %x %x %x\n,
mods_depressed, mods_latched, mods_locked, group);
}
I personally prefer 0x%x to %x on the off chance something comes up that
could be decimal. It can be confusing.
Is this change an important part of the patch?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v1 10/17] window: add display_dispatch
On 05/12/14 07:36 AM, Marek Chalupa wrote:
Split display_run into two functions - display_run and display_dispatch.
display_dispatch is the part that actually does something and
display_run just calls it in a loop. Now we can dispatch toytoolkit
events in tests (display_run is blocking, so we couldn't use that)
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
clients/window.c | 76
+++-
clients/window.h | 3 +++
2 files changed, 50 insertions(+), 29 deletions(-)
+ display-running = 1;
+ while(display-running) {
I think this needs a space to match the coding style of the rest of the
source.
+ ret = display_dispatch(display, -1);
+ if (ret = 0)
+ break;
+ }
+
+ if (ret 0)
+ perror(Dispatching events);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v1 11/17] add get_geometry geometry request/event
On 05/12/14 07:36 AM, Marek Chalupa wrote:
---
protocol/wayland-test.xml | 11 +++
tests/weston-test-client-helper.c | 18 ++
tests/weston-test-client-helper.h | 6 ++
tests/weston-test.c | 23 +++
4 files changed, 58 insertions(+)
diff --git a/protocol/wayland-test.xml b/protocol/wayland-test.xml
index 18b6625..b4a6bc7 100644
--- a/protocol/wayland-test.xml
+++ b/protocol/wayland-test.xml
@@ -3,6 +3,7 @@
I think we need to bump the interface version number when adding new stuff?
+static void
+get_geometry(struct wl_client *client, struct wl_resource *resource,
+ struct wl_resource *surface_resource)
+{
+ struct weston_view *view;
+ struct weston_surface *surface =
+ wl_resource_get_user_data (surface_resource);
I don't think we put a space there...
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v1 16/17] test-helpers: add functions that simulate pointer actions
On 05/12/14 07:36 AM, Marek Chalupa wrote:
Add functions that simulate pointer movement, draging and clicking.
These functions will be handy in more tests, so add them to helpers.
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
tests/weston-test-client-helper.c | 57
+++
tests/weston-test-client-helper.h | 9 +++
2 files changed, 66 insertions(+)
diff --git a/tests/weston-test-client-helper.c
b/tests/weston-test-client-helper.c
index dc34fc4..7f7f4f5 100644
--- a/tests/weston-test-client-helper.c
+++ b/tests/weston-test-client-helper.c
@@ -28,6 +28,7 @@
#include unistd.h
#include errno.h
#include sys/mman.h
+#include linux/input.h
#include ../shared/os-compatibility.h
#include ../clients/window.h
@@ -130,6 +131,62 @@ move_client(struct client *client, int x, int y)
}
}
+void
+pointer_simulate_move(struct client *client, int x1, int y1, int x2, int y2)
+{
+ struct wl_test *wl_test = client-test-wl_test;
+
+ wl_test_move_pointer(wl_test, x1, y1);
+ client_roundtrip(client);
+
+ while (x1 != x2 || y1 != y2) {
+ if (x2 x1)
+ --x1;
+ else if (x2 x1)
+ ++x1;
+
+ if (y2 y1)
+ --y1;
+ else if (y2 y1)
+ ++y1;
+
+ wl_test_move_pointer(wl_test, x1, y1);
+ client_roundtrip(client);
+ }
+}
+
+void
+pointer_simulate_drag(struct client *client, int x1, int y1, int x2, int y2)
+{
+ struct wl_test *wl_test = client-test-wl_test;
+
+ pointer_simulate_move(client, x1 - 50, y1 - 50, x1, y1);
+
+ wl_test_send_button(wl_test, BTN_LEFT, WL_POINTER_BUTTON_STATE_PRESSED);
+ client_roundtrip(client);
+
+ pointer_simulate_move(client, x1, y1, x2, y2);
+
+ wl_test_send_button(wl_test, BTN_LEFT,
WL_POINTER_BUTTON_STATE_RELEASED);
+ client_roundtrip(client);
+}
+
+#define MSEC_TO_USEC(n) ((n) * 1000)
Not sure I like the #define here... but that's just me
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v1 17/17] tests: add interactive tests
This new test fails for me:
interactive.weston: tests/interactive-test.c:115:
focus_tests_one_client: Assertion `c1-input-keyboard-focus ==
c1-surface-wl_surface' failed.
On 05/12/14 07:36 AM, Marek Chalupa wrote:
These tests are using pointer and keyboard simulated events
to interact with client.
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
Makefile.am | 7 ++-
tests/interactive-test.c | 135
+++
2 files changed, 141 insertions(+), 1 deletion(-)
create mode 100644 tests/interactive-test.c
diff --git a/Makefile.am b/Makefile.am
index 57882cd..f59b52a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -932,7 +932,8 @@ weston_tests =\
presentation.weston \
roles.weston\
subsurface.weston \
- test-suite-tests.weston
+ test-suite-tests.weston \
+ interactive.weston
AM_TESTS_ENVIRONMENT = \
@@ -1053,6 +1054,10 @@ test_suite_tests_weston_SOURCES =
tests/test-suite-test.c
test_suite_tests_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
$(CLIENT_CFLAGS)
test_suite_tests_weston_LDADD = libtest-client.la
+interactive_weston_SOURCES = tests/interactive-test.c
+interactive_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
$(CLIENT_CFLAGS)
+interactive_weston_LDADD = libtest-client.la
+
if ENABLE_EGL
weston_tests += buffer-count.weston
buffer_count_weston_SOURCES = tests/buffer-count-test.c
diff --git a/tests/interactive-test.c b/tests/interactive-test.c
new file mode 100644
index 000..07b3686
--- /dev/null
+++ b/tests/interactive-test.c
@@ -0,0 +1,135 @@
+/*
+ * Copyright © 2014 Red Hat, Inc.
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission. The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose. It is provided as is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include unistd.h
+#include time.h
+#include linux/input.h
+
+#include weston-test-client-helper.h
+
+/* relative position where to grab the client when dragging*/
+#define GRAB_SHIFT_X 150
+#define GRAB_SHIFT_Y 45
+
+static void
+drag_and_check(struct client *client, int x, int y)
+{
+ wl_test_get_geometry(client-test-wl_test,
client-surface-wl_surface);
+ client_roundtrip(client);
+
+ fprintf(stderr, dragging from %dx%d to %dx%d\n,
+ client-test-geometry.x, client-test-geometry.y,
+ x, y);
+ fflush(stderr);
+
+ pointer_simulate_drag(client,
+ client-test-geometry.x + GRAB_SHIFT_X,
+ client-test-geometry.y + GRAB_SHIFT_Y,
+ x + GRAB_SHIFT_X, y + GRAB_SHIFT_Y);
+ client_roundtrip(client);
+
+ wl_test_get_geometry(client-test-wl_test,
client-surface-wl_surface);
+ client_roundtrip(client);
+
+ assert(!window_is_maximized(client-toytoolkit-window));
+ assert(!window_is_fullscreen(client-toytoolkit-window));
+ assert(client-test-geometry.x == x);
+ assert(client-test-geometry.y == y);
+}
+
+#define MSEC_TO_USEC(n) ((n) * 1000)
There's that define again... maybe it should be in a header somewhere if
it's used in a few places?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Toytoolkit interactive tests
Realy happy to see something like this! :) I've already commented on individual patches, almost entirely cosmetic crap. Patch 1 and 8 I think are correct, but I'm not confident enough to say that out loud ;) (especially wrt the XXX comments in patch 8) Otherwise, Reviewed-by: Derek Foreman der...@osg.samsung.com Very nice! :) On 05/12/14 07:36 AM, Marek Chalupa wrote: Hi, This series of patches adds possibility to create a test client that uses toytoolkit and to easily interact with it. If accepted, this solves the bug: https://bugs.freedesktop.org/show_bug.cgi?id=83990 Makefile.am | 38 +- clients/window.c | 137 -- clients/window.h | 17 + protocol/wayland-test.xml | 11 + tests/event-test.c| 5 +- tests/interactive-test.c | 135 ++ tests/keyboard-test.c | 6 +- tests/test-suite-test.c | 92 tests/text-test.c | 2 +- tests/weston-test-client-helper.c | 648 +--- tests/weston-test-client-helper.h | 52 ++- tests/weston-test-runner.h| 2 + tests/weston-test.c | 92 ++-- 13 files changed, 1045 insertions(+), 192 deletions(-) ___ 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 weston 14/17] Introduce pointer locking and confinement protocol
On 08/12/14 08:07 AM, Jonas Ådahl wrote: On Tue, Dec 02, 2014 at 02:39:21PM -0800, Bill Spitzak wrote: On 12/02/2014 05:49 AM, Jonas Ådahl wrote: +request name=lock_pointer + description summary=lock pointer to a position +The lock_pointer request lets the client disable absolute pointer +movements, locking the pointer to a position. + +There may not be another lock of any kind active when requesting a lock, +and if there is, an error will be raised. + +The intersection of the region passed with this request and the input +region of the surface is used to determine where the pointer must be +in order for the lock to activate. It is up to the compositor to warp +the pointer, or require some kind of user interaction for the lock to +activate. If the region is null, then an infinit region is used. s/infinit/infinite/ + +The request will create a new object wl_locked_pointer which is used to +interact with the lock as well as receive updates about its state. See +the the description of wl_locked_pointer for further information. + +Note that while a locked pointer doesn't move its absolute position, it +may still emit relative motion events via the wl_relative_pointer +object. + /description + + arg name=id type=new_id interface=_wl_locked_pointer/ + arg name=surface type=object interface=wl_surface + summary=surface to lock pointer to/ + arg name=seat type=object interface=wl_seat + summary=seat where the pointer should be locked/ + arg name=region type=object interface=wl_region allow-null=true + summary=region of surface/ +/request - Does this need some id of the triggering event? Mostly to determine if the surface had the pointer focus at the time the request was made. It does not, and the lock is postponed until that trigger event happens. For example a surface can lock the pointer, but the lock may not activate until the user clicks the surface. It should not be hard coded exactly what type of event should trigger a lock. This bit is confusing me. A windowed game starts and asks for a pointer lock, but the window isn't focused, so the lock is postponed... At this point another app could request a lock and get a lock object, which may or may not also be postponed. However, if the first lock was already active at the time the second app requested a lock, it wouldn't received a postponed lock object, just an error? So there could be a dozen postponed locks across many applications as long as they're all set up while there isn't an active lock, and that's ok. But as soon as a lock triggers no new ones can be set up until it's released? Why the restriction? Why can't apps set up locks at any time they want, since they won't trigger until some time after the old lock is released anyway? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH libinput 1/2] Add a string-based input API
On 12/09/2014 12:48 AM, Hans de Goede wrote: No this is about input-method like functionality. Okay, in that case I think the api should be designed such that a text editor gets the UTF-8 to insert in *exactly* the same way whether the language is English or Chinese or Russian and whether or not this device is being used. This includes things that are often built into clients, such as compose keys and typing alt+u+digits to insert random Unicode points. All of these should be done by the input method api. Currently (IIRC) these devices do double translation, so the ready to use text gets converted into keycodes again, and then back, which is bound to be lossy, and a bad idea in general, so we want to get rid of the double translation for these. I certainly agree this is a problem with how Wayland is being done now. My main concern is with remote display on some device that delivers keystrokes already translated into keysyms. My personal feeling is that it would be better to have libinput or the compositor look up keysyms, rather than clients link with xkb. No more or fewer events are sent than currently, but attached to key transitions are the keysym (possibly none) produced by that transition. This would allow arbitrary code installed along with the device to do the translation which would allow your input device to work. There is however very strong disagreement with this idea from the Wayland developers. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH libinput 1/2] Add a string-based input API
You bring this up every single time somebody mentions keyboard input, and every single time we explain in excruciating detail exactly how you're wrong, why you're wrong, and why the use cases you cite are broken work perfectly today. Please stop bringing it up. This is your second warning. On Tue, Dec 9, 2014 at 3:45 PM, Bill Spitzak spit...@gmail.com wrote: On 12/09/2014 12:48 AM, Hans de Goede wrote: No this is about input-method like functionality. Okay, in that case I think the api should be designed such that a text editor gets the UTF-8 to insert in *exactly* the same way whether the language is English or Chinese or Russian and whether or not this device is being used. This includes things that are often built into clients, such as compose keys and typing alt+u+digits to insert random Unicode points. All of these should be done by the input method api. Currently (IIRC) these devices do double translation, so the ready to use text gets converted into keycodes again, and then back, which is bound to be lossy, and a bad idea in general, so we want to get rid of the double translation for these. I certainly agree this is a problem with how Wayland is being done now. My main concern is with remote display on some device that delivers keystrokes already translated into keysyms. My personal feeling is that it would be better to have libinput or the compositor look up keysyms, rather than clients link with xkb. No more or fewer events are sent than currently, but attached to key transitions are the keysym (possibly none) produced by that transition. This would allow arbitrary code installed along with the device to do the translation which would allow your input device to work. There is however very strong disagreement with this idea from the Wayland developers. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Where should project Weston go?
Since when it started I was following the list: -First weston announce: http://lists.freedesktop.org/archives/wayland-devel/2012-January/001763.html -Some questions to Kristian about the same subject(with reply): [Weston SDK] http://lists.freedesktop.org/archives/wayland-devel/2013-February/007419.html -[Clarifying scope and goals for weston] http://lists.freedesktop.org/archives/wayland-devel/2013-April/008659.html Seems like one of the intial goals was to have a simple core product-quality-ready for certain applications. Other goals I remember were to be a testing bench for new software and a reference implementation of wayland for other compositors. Weston was born from wayland, splitting up the code and adopting a new name. It could be done again if the filosophy changes and the software splits. -- Samuele ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 1/6] Drop deprecated symbols
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev.c| 7 ---
src/libinput.c | 16
src/libinput.h | 27 ---
3 files changed, 50 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 0873c99..ad167b2 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1604,13 +1604,6 @@ err:
return unhandled_device ? EVDEV_UNHANDLED_DEVICE : NULL;
}
-int
-evdev_device_get_keys(struct evdev_device *device, char *keys, size_t size)
-{
- memset(keys, 0, size);
- return 0;
-}
-
const char *
evdev_device_get_output(struct evdev_device *device)
{
diff --git a/src/libinput.c b/src/libinput.c
index 279cce0..fbefbb3 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1272,22 +1272,6 @@ libinput_device_led_update(struct libinput_device
*device,
}
LIBINPUT_EXPORT int
-libinput_device_get_keys(struct libinput_device *device,
-char *keys, size_t size)
-{
- return evdev_device_get_keys((struct evdev_device *) device,
-keys,
-size);
-}
-
-LIBINPUT_EXPORT void
-libinput_device_calibrate(struct libinput_device *device,
- float calibration[6])
-{
- evdev_device_calibrate((struct evdev_device *) device, calibration);
-}
-
-LIBINPUT_EXPORT int
libinput_device_has_capability(struct libinput_device *device,
enum libinput_device_capability capability)
{
diff --git a/src/libinput.h b/src/libinput.h
index 57d9ded..e2a3eef 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -1554,33 +1554,6 @@ libinput_device_led_update(struct libinput_device
*device,
/**
* @ingroup device
*
- * Set the bitmask in keys to the bitmask of the keys present on the device
- * (see linux/input.h), up to size characters.
- *
- * @param device A current input device
- * @param keys An array filled with the bitmask for the keys
- * @param size Size of the keys array
- *
- * @return The number of valid bytes in keys, or a negative errno on failure
- */
-int
-libinput_device_get_keys(struct libinput_device *device,
-char *keys, size_t size)
- LIBINPUT_ATTRIBUTE_DEPRECATED;
-
-/**
- * @ingroup device
- *
- * @deprecated Use libinput_device_config_calibration_set_matrix() instead.
- */
-void
-libinput_device_calibrate(struct libinput_device *device,
- float calibration[6])
- LIBINPUT_ATTRIBUTE_DEPRECATED;
-
-/**
- * @ingroup device
- *
* Check if the given device has the specified capability
*
* @return 1 if the given device has the capability or 0 if not
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 6/6] doc: put some extra warning in for libinput_event_destroy()
Unlike all other structs, events aren't refcounted and will get destroyed immediately. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- src/libinput.h | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/libinput.h b/src/libinput.h index 7e5d93c..f7cb169 100644 --- a/src/libinput.h +++ b/src/libinput.h @@ -335,6 +335,9 @@ struct libinput_seat; * * The base event type. Use libinput_event_get_pointer_event() or similar to * get the actual event type. + * + * @warning Unlike other structs events are considered transient and + * bnot/b refcounted. */ struct libinput_event; @@ -382,7 +385,12 @@ struct libinput_event_touch; /** * @ingroup event * - * Destroy the event. + * Destroy the event, freeing all associated data. Data obtained from this + * event must be considered invalid after this call. + * + * @warning Unlike other structs events are considered transient and + * bnot/b refcounted. Calling libinput_event_destroy() bwill/b + * destroy the event. * * @param event An event retrieved by libinput_get_event(). */ -- 2.1.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 2/6] Use symbol versioning
This isn't the final 0.8.0 API yet, but we might as well get started.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/Makefile.am | 5 ++-
src/libinput.sym | 117 +++
2 files changed, 120 insertions(+), 2 deletions(-)
create mode 100644 src/libinput.sym
diff --git a/src/Makefile.am b/src/Makefile.am
index 0968459..eeaf439 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -46,7 +46,8 @@ libinput_util_la_CFLAGS = -I$(top_srcdir)/include \
$(LIBUDEV_CFLAGS) \
$(GCC_CFLAGS)
-libinput_la_LDFLAGS = -version-info $(LIBINPUT_LT_VERSION) -shared
+libinput_la_LDFLAGS = -version-info $(LIBINPUT_LT_VERSION) -shared \
+ -Wl,--version-script=$(srcdir)/libinput.sym
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = libinput.pc
@@ -54,4 +55,4 @@ pkgconfig_DATA = libinput.pc
AM_CFLAGS = $(GCC_CFLAGS)
DISTCLEANFILES = libinput-version.h
-EXTRA_DIST = libinput-version.h.in
+EXTRA_DIST = libinput-version.h.in libinput.sym
diff --git a/src/libinput.sym b/src/libinput.sym
new file mode 100644
index 000..f35a0cd
--- /dev/null
+++ b/src/libinput.sym
@@ -0,0 +1,117 @@
+/* in alphabetical order! */
+
+LIBINPUT_0.8.0 {
+global:
+ libinput_config_status_to_str;
+ libinput_device_config_accel_get_default_speed;
+ libinput_device_config_accel_get_speed;
+ libinput_device_config_accel_is_available;
+ libinput_device_config_accel_set_speed;
+ libinput_device_config_buttons_get_default_left_handed;
+ libinput_device_config_buttons_get_left_handed;
+ libinput_device_config_buttons_has_left_handed;
+ libinput_device_config_buttons_set_left_handed;
+ libinput_device_config_calibration_get_default_matrix;
+ libinput_device_config_calibration_get_matrix;
+ libinput_device_config_calibration_has_matrix;
+ libinput_device_config_calibration_set_matrix;
+ libinput_device_config_scroll_get_button;
+ libinput_device_config_scroll_get_default_button;
+ libinput_device_config_scroll_get_default_method;
+ libinput_device_config_scroll_get_default_natural_scroll_enabled;
+ libinput_device_config_scroll_get_methods;
+ libinput_device_config_scroll_get_method;
+ libinput_device_config_scroll_get_natural_scroll_enabled;
+ libinput_device_config_scroll_has_natural_scroll;
+ libinput_device_config_scroll_set_button;
+ libinput_device_config_scroll_set_method;
+ libinput_device_config_scroll_set_natural_scroll_enabled;
+ libinput_device_config_send_events_get_default_mode;
+ libinput_device_config_send_events_get_modes;
+ libinput_device_config_send_events_get_mode;
+ libinput_device_config_send_events_set_mode;
+ libinput_device_config_tap_get_default_enabled;
+ libinput_device_config_tap_get_enabled;
+ libinput_device_config_tap_get_finger_count;
+ libinput_device_config_tap_set_enabled;
+ libinput_device_get_context;
+ libinput_device_get_id_product;
+ libinput_device_get_id_vendor;
+ libinput_device_get_name;
+ libinput_device_get_output_name;
+ libinput_device_get_seat;
+ libinput_device_get_size;
+ libinput_device_get_sysname;
+ libinput_device_get_udev_device;
+ libinput_device_get_user_data;
+ libinput_device_has_button;
+ libinput_device_has_capability;
+ libinput_device_led_update;
+ libinput_device_ref;
+ libinput_device_set_seat_logical_name;
+ libinput_device_set_user_data;
+ libinput_device_unref;
+ libinput_dispatch;
+ libinput_event_destroy;
+ libinput_event_device_notify_get_base_event;
+ libinput_event_get_context;
+ libinput_event_get_device_notify_event;
+ libinput_event_get_device;
+ libinput_event_get_keyboard_event;
+ libinput_event_get_pointer_event;
+ libinput_event_get_touch_event;
+ libinput_event_get_type;
+ libinput_event_keyboard_get_base_event;
+ libinput_event_keyboard_get_key_state;
+ libinput_event_keyboard_get_key;
+ libinput_event_keyboard_get_seat_key_count;
+ libinput_event_keyboard_get_time;
+ libinput_event_pointer_get_absolute_x;
+ libinput_event_pointer_get_absolute_x_transformed;
+ libinput_event_pointer_get_absolute_y;
+ libinput_event_pointer_get_absolute_y_transformed;
+ libinput_event_pointer_get_axis;
+ libinput_event_pointer_get_axis_value;
+ libinput_event_pointer_get_base_event;
+ libinput_event_pointer_get_button_state;
+ libinput_event_pointer_get_button;
+ libinput_event_pointer_get_dx;
+ libinput_event_pointer_get_dx_unaccelerated;
+ libinput_event_pointer_get_dy;
+ libinput_event_pointer_get_dy_unaccelerated;
+ libinput_event_pointer_get_seat_button_count;
+
[PATCH libinput 5/6] doc: document the base structures so they show up in doxygen
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/libinput.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/src/libinput.h b/src/libinput.h
index d6e0446..7e5d93c 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -302,8 +302,31 @@ enum libinput_event_type {
LIBINPUT_EVENT_TOUCH_FRAME
};
+/**
+ * @ingroup base
+ * @struct libinput
+ *
+ * The base handle for accessing libinput. This struct is refcounted, use
+ * libinput_ref() and libinput_unref().
+ */
struct libinput;
+
+/**
+ * @ingroup device
+ * @struct libinput_device
+ *
+ * The base handle for accessing libinput devices. This struct is
+ * refcounted, use libinput_device_ref() and libinput_device_unref().
+ */
struct libinput_device;
+
+/**
+ * @ingroup seat
+ * @struct libinput_seat
+ *
+ * The base handle for accessing libinput seats. This struct is
+ * refcounted, use libinput_seat_ref() and libinput_seat_unref().
+ */
struct libinput_seat;
/**
@@ -919,6 +942,17 @@ libinput_event_touch_get_base_event(struct
libinput_event_touch *event);
* @defgroup base Initialization and manipulation of libinput contexts
*/
+/**
+ * @ingroup base
+ * @struct libinput_interface
+ *
+ * libinput does not open file descriptors to devices directly, instead
+ * open_restricted() and close_restricted() are called for each path that
+ * must be opened.
+ *
+ * @see libinput_udev_create_context
+ * @see libinput_path_create_context
+ */
struct libinput_interface {
/**
* Open the device at the given path with the flags provided and
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 3/6] doc: include README as mainpage
doxygen supports markdown so we can expand the README with general interesting
information in markdown format and have it be the front page of the
documentation at the same time.
This requires renaming README to README.txt, but that's a relatively small
price to pay.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
README | 25 -
README.txt | 30 ++
doc/Makefile.am | 3 ++-
doc/libinput.doxygen.in | 3 ++-
src/libinput.h | 7 ---
5 files changed, 34 insertions(+), 34 deletions(-)
delete mode 100644 README
create mode 100644 README.txt
diff --git a/README b/README
deleted file mode 100644
index f55d7c8..000
--- a/README
+++ /dev/null
@@ -1,25 +0,0 @@
-libinput
-
-libinput is a library that handles input devices for display servers and other
-applications that need to directly deal with input devices.
-
-It provides device detection, device handling, input device event processing
-and abstraction so minimize the amount of custom input code the user of
-libinput need to provide the common set of functionality that users expect.
-
-Input event processing includes scaling touch coordinates, generating
-pointer events from touchpads, pointer acceleration, etc.
-
-libinput originates from weston, the Wayland reference compositor.
-
-The source code of libinput can be found at:
-http://cgit.freedesktop.org/wayland/libinput
-
-For more information, visit:
-http://www.freedesktop.org/wiki/Software/libinput/
-
-Bugs can be filed in the libinput component of Wayland:
-https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland
-
-Online API documentation:
-http://wayland.freedesktop.org/libinput/doc/latest/modules.html
diff --git a/README.txt b/README.txt
new file mode 100644
index 000..fabe304
--- /dev/null
+++ b/README.txt
@@ -0,0 +1,30 @@
+/*!@mainpage
+
+libinput
+
+
+libinput is a library that handles input devices for display servers and other
+applications that need to directly deal with input devices.
+
+It provides device detection, device handling, input device event processing
+and abstraction so minimize the amount of custom input code the user of
+libinput need to provide the common set of functionality that users expect.
+
+Input event processing includes scaling touch coordinates, generating
+pointer events from touchpads, pointer acceleration, etc.
+
+libinput originates from weston, the Wayland reference compositor.
+
+The source code of libinput can be found at:
+http://cgit.freedesktop.org/wayland/libinput
+
+For more information, visit:
+http://www.freedesktop.org/wiki/Software/libinput/
+
+Bugs can be filed in the libinput component of Wayland:
+https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland
+
+Online API documentation:
+http://wayland.freedesktop.org/libinput/doc/latest/modules.html
+
+*/
diff --git a/doc/Makefile.am b/doc/Makefile.am
index a33638d..8f05bd2 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -5,7 +5,8 @@ if HAVE_DOXYGEN
noinst_DATA = html/index.html
header_files = \
- $(top_srcdir)/src/libinput.h
+ $(top_srcdir)/src/libinput.h \
+ $(top_srcdir)/README.txt
html/index.html: libinput.doxygen $(header_files)
$(AM_V_GEN)$(DOXYGEN) $
diff --git a/doc/libinput.doxygen.in b/doc/libinput.doxygen.in
index 865cf97..9800f80 100644
--- a/doc/libinput.doxygen.in
+++ b/doc/libinput.doxygen.in
@@ -753,7 +753,8 @@ WARN_LOGFILE =
# spaces.
# Note: If this tag is empty the current directory is searched.
-INPUT = @top_srcdir@/src/libinput.h
+INPUT = @top_srcdir@/src/libinput.h \
+@top_srcdir@/README.txt
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
diff --git a/src/libinput.h b/src/libinput.h
index e2a3eef..682e16f 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -36,13 +36,6 @@ extern C {
#define LIBINPUT_ATTRIBUTE_DEPRECATED __attribute__ ((deprecated))
/**
- * @mainpage
- * libinput is a generic input device handling library. It abstracts
- * commonly-used concepts such as keyboard, pointer and touchpad handling
- * behind an API.
- */
-
-/**
* @page tpbuttons Touchpad button behavior
*
* For touchpad devices without physical buttons, libinput enables an
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 4/6] doc: add the various events to the doxygen groups
Makes them show up on the respective page and in the data structures list doxygen generates. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- src/libinput.h | 29 + 1 file changed, 29 insertions(+) diff --git a/src/libinput.h b/src/libinput.h index 682e16f..d6e0446 100644 --- a/src/libinput.h +++ b/src/libinput.h @@ -306,9 +306,38 @@ struct libinput; struct libinput_device; struct libinput_seat; +/** + * @ingroup event + * @struct libinput_event + * + * The base event type. Use libinput_event_get_pointer_event() or similar to + * get the actual event type. + */ struct libinput_event; + +/** + * @ingroup event + * @struct libinput_event_device_notify + * + * An event notifying the caller of a device being added or removed. + */ struct libinput_event_device_notify; + +/** + * @ingroup event_keyboard + * @struct libinput_event_keyboard + * + * A keyboard event representing a key press/release. + */ struct libinput_event_keyboard; + +/** + * @ingroup event_pointer + * @struct libinput_event_pointer + * + * A pointer event representing relative or absolute pointer movement, + * a button press/release or scroll axis events. + */ struct libinput_event_pointer; /** -- 2.1.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: Ensure the libevdev object receives the new fd on resume
On Tue, Dec 09, 2014 at 03:55:32PM +0100, Carlos Garnacho wrote:
Otherwise, input_events will be attempted to read from the wrong place,
which also leaves the right/current fd with pending data to be read,
making the epoll fd wake up constantly.
Signed-off-by: Carlos Garnacho carl...@gnome.org
huh, this seems like something the test should've caught. I'll look into
that, meanwhile - merged locally, thanks
Cheers,
Peter
---
src/evdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index c8ca384..137c20c 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2012,6 +2012,9 @@ evdev_device_resume(struct evdev_device *device)
return -ENODEV;
}
+ libevdev_change_fd(device-evdev, fd);
+ libevdev_set_clock_id(device-evdev, CLOCK_MONOTONIC);
+
device-source =
libinput_add_fd(libinput, fd, evdev_device_dispatch, device);
if (!device-source) {
--
2.1.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
[PATCH 5/5] doc: Make it easier to add a new doxygen page
The repetitive parts of generating the server and client documentation are merged, so it is easier to add another doxygen chapter: add a new line to $publican_sources in publican/Makefile.am, and a list of C source files to doxygen/Makefile.am. --- doc/doxygen/Makefile.am | 23 -- doc/publican/Makefile.am | 35 ++ doc/publican/doxygen-to-publican.xsl |5 ++--- doc/publican/sources/Wayland.xml |4 ++-- 4 files changed, 26 insertions(+), 41 deletions(-) diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index 8d563f4..8c4618a 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -1,24 +1,24 @@ -noinst_DATA = xml/client/index.xml xml/server/index.xml +noinst_DATA = xml/Client/index.xml xml/Server/index.xml dist_noinst_DATA = wayland.doxygen.in scanned_src_files_shared = \ $(top_srcdir)/src/wayland-util.c\ $(top_srcdir)/src/wayland-util.h -scanned_src_files_client = \ +scanned_src_files_Client = \ $(scanned_src_files_shared) \ $(top_srcdir)/src/wayland-client.c \ $(top_srcdir)/src/wayland-client.h -scanned_src_files_server = \ +scanned_src_files_Server = \ $(scanned_src_files_shared) \ $(top_srcdir)/src/wayland-server.c \ $(top_srcdir)/src/wayland-server.h \ $(top_srcdir)/src/wayland-shm.c scanned_src_files_man =\ - $(scanned_src_files_server) \ + $(scanned_src_files_Server) \ $(top_srcdir)/src/wayland-client.c \ $(top_srcdir)/src/wayland-client.h @@ -28,20 +28,13 @@ scanned_src_files_man = \ 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/client xml/server man/man3 +alldirs := xml/Client xml/Server man/man3 -xml/client/index.xml: $(scanned_src_files_client) wayland.doxygen | xml/client +xml/%/index.xml: $(scanned_src_files_%) wayland.doxygen | xml/% $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_XML=YES; \ - echo XML_OUTPUT=xml/client; \ - echo INPUT= $(scanned_src_files_client); \ - ) | $(DOXYGEN) - - -xml/server/index.xml: $(scanned_src_files_server) wayland.doxygen | xml/server - $(AM_V_GEN)(cat wayland.doxygen; \ - echo GENERATE_XML=YES; \ - echo XML_OUTPUT=xml/server; \ - echo INPUT= $(scanned_src_files_server); \ + echo XML_OUTPUT=xml/$*; \ + echo INPUT= $(scanned_src_files_$*); \ ) | $(DOXYGEN) - man/man3/wl_display.3: $(scanned_src_files_man) wayland.doxygen | man/man3 diff --git a/doc/publican/Makefile.am b/doc/publican/Makefile.am index c109795..ac32c03 100644 --- a/doc/publican/Makefile.am +++ b/doc/publican/Makefile.am @@ -8,9 +8,7 @@ # * ProtocolSpec.xml is generated from $(top_srcdir)/protocol/wayland.xml, # changed into docbook via XSLT and saved in $(builddir)/en-US/ # * ProtocolInterfaces.xml, same as above, uses a different XSLT -# * WaylandClientAPI.xml is generated from the doxygen output and saved in -# $(builddir)/en-US -# * WaylandServerAPI.xml is generated from the doxygen output and saved in +# * *API.xml is generated from the doxygen output and saved in # $(builddir)/en-US # * run xmlto on $(builddir)/en-US, output to $(builddir)/Wayland/en-US @@ -29,7 +27,11 @@ publican_sources = \ $(srcdir)/sources/images/icon.svg \ $(srcdir)/sources/images/wayland-architecture.png \ $(srcdir)/sources/images/wayland.png \ - $(srcdir)/sources/images/x-architecture.png + $(srcdir)/sources/images/x-architecture.png \ + en-US/ProtocolSpec.xml \ + en-US/ProtocolInterfaces.xml \ + en-US/ClientAPI.xml \ + en-US/ServerAPI.xml css_sources = \ $(srcdir)/sources/css/brand.css \ @@ -76,9 +78,7 @@ $(html_destdir)/images/%: $(srcdir)/sources/images/% | $(html_destdir)/images pubdir = $(docdir)/Wayland/en-US -publican_targets = $(publican_sources:$(srcdir)/sources/%=$(builddir)/en-US/%) \ - $(builddir)/en-US/ProtocolSpec.xml $(builddir)/en-US/ProtocolInterfaces.xml \ - $(builddir)/en-US/WaylandClientAPI.xml $(builddir)/en-US/WaylandServerAPI.xml +publican_targets = $(publican_sources:$(srcdir)/sources%=$(builddir)/en-US/%) # The Protocol.xml is purely generated and required before running publican $(builddir)/en-US/ProtocolSpec.xml: $(top_srcdir)/protocol/wayland.xml $(srcdir)/protocol-to-docbook.xsl | $(builddir)/en-US @@ -94,28 +94,21 @@ $(builddir)/en-US/ProtocolInterfaces.xml: $(top_srcdir)/protocol/wayland.xml
[PATCH 1/5] doc: General makefile cleanup.
From: Jon A. Cruz j...@osg.samsung.com
This is a general cleanup of the makefile in order to bring it more inline
with standard make practices. Cleanups included more use of automatic
variables, switching AM_V_GEN to AM_V_at to have one 'GEN' visible per file,
splitting copy operations to proper rules, and using order only dependencies
to properly create directories on-demand.
Changes also correct missing use of $(builddir) that has gone unnoticed as
it defaults to the current directory ('.').
Signed-off-by: Jon A. Cruz j...@osg.samsung.com
---
doc/publican/Makefile.am | 77 +++---
1 file changed, 46 insertions(+), 31 deletions(-)
diff --git a/doc/publican/Makefile.am b/doc/publican/Makefile.am
index 0b2cd09..8ed3815 100644
--- a/doc/publican/Makefile.am
+++ b/doc/publican/Makefile.am
@@ -13,6 +13,7 @@
# * WaylandServerAPI.xml is generated from the doxygen output and saved in
# $(builddir)/en-US
# * run xmlto on $(builddir)/en-US, output to $(builddir)/Wayland/en-US
+
publican_sources = \
$(srcdir)/sources/Wayland.ent \
$(srcdir)/sources/Wayland.xml \
@@ -37,6 +38,7 @@ css_sources = \
$(srcdir)/sources/css/default.css \
$(srcdir)/sources/css/epub.css \
$(srcdir)/sources/css/print.css
+
img_sources = \
$(srcdir)/sources/images/icon.svg \
$(srcdir)/sources/images/wayland-architecture.png \
@@ -45,71 +47,84 @@ img_sources = \
if HAVE_XMLTO
if HAVE_XSLTPROC
-noinst_DATA = Wayland $(publican_targets)
+noinst_DATA = $(builddir)/Wayland $(publican_targets)
XMLTO_PARAM = \
--skip-validation \
--stringparam chunk.section.depth=0 \
--stringparam toc.section.depth=1 \
--stringparam html.stylesheet=css/default.css
+doxydir := $(top_builddir)/doc/doxygen
+
html_destdir = $(builddir)/Wayland/en-US/html
-Wayland: $(publican_targets)
- $(AM_V_GEN)$(MKDIR_P) -p $(html_destdir)/css
- $(AM_V_GEN)cp -f $(css_sources) $(html_destdir)/css/
- $(AM_V_GEN)$(MKDIR_P) -p $(html_destdir)/images
- $(AM_V_GEN)cp -f $(img_sources) $(html_destdir)/images/
- $(AM_V_GEN)$(XMLTO) $(XMLTO_PARAM) html en-US/Wayland.xml -o
$(html_destdir)
- @touch Wayland
+# Listing various directories that might need to be created.
+alldirs := $(builddir)/en-US $(builddir)/en-US/images $(html_destdir)
$(html_destdir)/css $(html_destdir)/images
+
+
+html_css_targets = $(addprefix $(html_destdir)/css/,$(notdir $(css_sources)))
+html_img_targets = $(addprefix $(html_destdir)/images/,$(notdir
$(img_sources)))
+
+$(builddir)/Wayland: $(publican_targets) $(html_css_targets)
$(html_img_targets) | $(builddir)/en-US
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_PARAM) html $(builddir)/en-US/Wayland.xml
-o $(html_destdir)
+ @touch $@
+
+$(html_destdir)/css/%: $(srcdir)/sources/css/% | $(html_destdir)/css
+ $(AM_V_GEN)cp -f $ $@
+
+$(html_destdir)/images/%: $(srcdir)/sources/images/% | $(html_destdir)/images
+ $(AM_V_GEN)cp -f $ $@
pubdir = $(docdir)/Wayland/en-US
-publican_targets = $(publican_sources:$(srcdir)/sources%=$(builddir)/en-US%) \
- en-US/ProtocolSpec.xml en-US/ProtocolInterfaces.xml \
- en-US/WaylandClientAPI.xml en-US/WaylandServerAPI.xml
+publican_targets = $(publican_sources:$(srcdir)/sources/%=$(builddir)/en-US/%)
\
+ $(builddir)/en-US/ProtocolSpec.xml
$(builddir)/en-US/ProtocolInterfaces.xml \
+ $(builddir)/en-US/WaylandClientAPI.xml
$(builddir)/en-US/WaylandServerAPI.xml
# The Protocol.xml is purely generated and required before running publican
-en-US/ProtocolSpec.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-to-docbook.xsl
- $(AM_V_GEN)$(MKDIR_P) en-US/images
+$(builddir)/en-US/ProtocolSpec.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-to-docbook.xsl | $(builddir)/en-US
$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-to-docbook.xsl \
- $(top_srcdir)/protocol/wayland.xml en-US/ProtocolSpec.xml
+ $(top_srcdir)/protocol/wayland.xml $@
-en-US/ProtocolInterfaces.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-interfaces-to-docbook.xsl
- $(AM_V_GEN)$(MKDIR_P) en-US/images
+$(builddir)/en-US/ProtocolInterfaces.xml: $(top_srcdir)/protocol/wayland.xml
$(srcdir)/protocol-interfaces-to-docbook.xsl
$(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-interfaces-to-docbook.xsl \
- $(top_srcdir)/protocol/wayland.xml
en-US/ProtocolInterfaces.xml
+ $(top_srcdir)/protocol/wayland.xml $@
# * we don't want wayland-{server|client}_8h.xml to avoid duplicating output
methods,
# move it out of the way first.
# * use doxygen's combine.xslt to merge the xml files into one single file
# * move wayland-foo_8h.xml back to its original location
-en-US/%API.xml.tmp: $(top_builddir)/doc/doxygen/xml/%/index.xml
- $(AM_V_GEN)mv $(top_builddir)/doc/doxygen/xml/$*/wayland-$*_8h.xml \
-
[PATCH 3/5] doc: fix doxygen-man command line
It was telling it to scan the doxyfile as well as the C source, and listing some source files more than once. --- doc/doxygen/Makefile.am |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index 7276f5c..8d563f4 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -17,6 +17,11 @@ scanned_src_files_server = \ $(top_srcdir)/src/wayland-server.h \ $(top_srcdir)/src/wayland-shm.c +scanned_src_files_man =\ + $(scanned_src_files_server) \ + $(top_srcdir)/src/wayland-client.c \ + $(top_srcdir)/src/wayland-client.h + # find all man/man3/wl_foo.3 pages # for this to work, we need to create them before the man target (hence # all-local below) @@ -39,12 +44,12 @@ xml/server/index.xml: $(scanned_src_files_server) wayland.doxygen | xml/server echo INPUT= $(scanned_src_files_server); \ ) | $(DOXYGEN) - -man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) wayland.doxygen | man/man3 +man/man3/wl_display.3: $(scanned_src_files_man) wayland.doxygen | man/man3 $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_MAN=YES; \ echo MAN_OUTPUT=man; \ echo JAVADOC_AUTOBRIEF=NO; \ - echo INPUT= $^; \ + echo INPUT= $(scanned_src_files_man); \ ) | $(DOXYGEN) - # general rule to create one of the listed directories. -- 1.7.9.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 4/5] doc: Split libwayland-client and -server into different pages
This was suggested before to make it clearer that things like wl_display are different objects in each of them. I made these into two appendixes because the protocol spec was already an appendix. --- doc/publican/Makefile.am |1 - doc/publican/doxygen-to-publican.xsl | 28 ++-- doc/publican/sources/Library.xml | 27 --- doc/publican/sources/Wayland.xml |3 ++- 4 files changed, 24 insertions(+), 35 deletions(-) delete mode 100644 doc/publican/sources/Library.xml diff --git a/doc/publican/Makefile.am b/doc/publican/Makefile.am index 8ed3815..c109795 100644 --- a/doc/publican/Makefile.am +++ b/doc/publican/Makefile.am @@ -25,7 +25,6 @@ publican_sources = \ $(srcdir)/sources/Introduction.xml \ $(srcdir)/sources/Architecture.xml \ $(srcdir)/sources/Protocol.xml \ - $(srcdir)/sources/Library.xml \ $(srcdir)/sources/Compositors.xml \ $(srcdir)/sources/images/icon.svg \ $(srcdir)/sources/images/wayland-architecture.png \ diff --git a/doc/publican/doxygen-to-publican.xsl b/doc/publican/doxygen-to-publican.xsl index d8f3289..53fc60f 100644 --- a/doc/publican/doxygen-to-publican.xsl +++ b/doc/publican/doxygen-to-publican.xsl @@ -12,13 +12,29 @@ ] ]]/xsl:text - section id=sect-Library-$which + appendix id=sect-Library-$which xsl:attribute name=idsect-Library-xsl:value-of select=$which//xsl:attribute titlexsl:value-of select=$which/ API/title -paraFollowing is the Wayland library classes for the xsl:value-of select=$which/ - (emphasislibwayland-xsl:value-of select=translate($which, 'SC', 'sc')//emphasis). - Note that most of the procedures are related with IPC, which is the main responsibility of - the library. + +para + The open-source reference implementation of Wayland protocol is + split in two C libraries, link + linkend=sect-Library-Clientlibwayland-client/link and link + linkend=sect-Library-Serverlibwayland-server/link. Their + main responsibility is to handle the Inter-process communication + (emphasisIPC/emphasis) with each other, therefore + guaranteeing the protocol objects marshaling and messages + synchronization. +/para + +para + Following is the Wayland library classes for the + xsl:value-of select=$which/ + (emphasislibwayland-xsl:value-of select=translate($which, + 'SC', 'sc')//emphasis). This appendix describes in detail + the library's methods and their helpers, aiming implementors who + are building a Wayland xsl:value-of select=translate($which, + 'SC', 'sc')/. /para xsl:if test=/doxygen/compounddef[@kind='class'] @@ -36,7 +52,7 @@ xsl:apply-templates select=/doxygen/compounddef/sectiondef/memberdef / /variablelist /para - /section + /appendix /xsl:template xsl:template match=parameteritem diff --git a/doc/publican/sources/Library.xml b/doc/publican/sources/Library.xml deleted file mode 100644 index bc8c89e..000 --- a/doc/publican/sources/Library.xml +++ /dev/null @@ -1,27 +0,0 @@ -?xml version='1.0' encoding='utf-8' ? -!DOCTYPE chapter PUBLIC -//OASIS//DTD DocBook XML V4.5//EN http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [ -!ENTITY % BOOK_ENTITIES SYSTEM Wayland.ent -%BOOK_ENTITIES; -] -chapter id=chap-Library - titleWayland Library/title - - para - The open-source reference implementation of Wayland protocol is split in two - C libraries, link linkend=sect-Library-Serverlibwayland-server/link and - link linkend=sect-Library-Clientlibwayland-client/link. Their main - responsibility is to handle the Inter-process communication - (emphasisIPC/emphasis) with each other, therefore guaranteeing the - protocol objects marshaling and messages synchronization. - /para - - para - This Chapter describes in detail each library's methods and their helpers, - aiming implementors who can use for building Wayland clients and servers; - respectively at xref linkend=sect-Library-Client/ and - xref linkend=sect-Library-Server/. - /para - - xi:include href=WaylandClientAPI.xml xmlns:xi=http://www.w3.org/2001/XInclude/ - xi:include href=WaylandServerAPI.xml xmlns:xi=http://www.w3.org/2001/XInclude/ -/chapter diff --git a/doc/publican/sources/Wayland.xml b/doc/publican/sources/Wayland.xml index 24a9876..bdf8930 100644 --- a/doc/publican/sources/Wayland.xml +++ b/doc/publican/sources/Wayland.xml @@ -12,6 +12,7 @@ xi:include href=Architecture.xml xmlns:xi=http://www.w3.org/2001/XInclude; / xi:include href=Protocol.xml xmlns:xi=http://www.w3.org/2001/XInclude; / xi:include href=ProtocolSpec.xml xmlns:xi=http://www.w3.org/2001/XInclude; / - xi:include href=Library.xml xmlns:xi=http://www.w3.org/2001/XInclude; / + xi:include href=WaylandClientAPI.xml xmlns:xi=http://www.w3.org/2001/XInclude/ + xi:include href=WaylandServerAPI.xml xmlns:xi=http://www.w3.org/2001/XInclude/ /book
[PATCH v2] doc: Make each library an appendix
This supersedes the previous patches. The main change is that this is rebased atop Jon A Cruz's patches (which are included here as the first 2). I also merged two related patches and updated the comments. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/5] doc: Minor makefile cleanup.
From: Jon A. Cruz j...@osg.samsung.com Split out directory creation to leverage order only prerequisites. Signed-off-by: Jon A. Cruz j...@osg.samsung.com --- doc/doxygen/Makefile.am | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index f8d636e..7276f5c 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -22,22 +22,24 @@ scanned_src_files_server = \ # all-local below) dist_man3_MANS = $(shell test -d man find man/man3 -name wl_*.3 -printf man/man3/%P\n) -xml/client/index.xml: $(scanned_src_files_client) wayland.doxygen - $(AM_V_GEN)$(MKDIR_P) xml/client \ - (cat wayland.doxygen; \ +# Listing various directories that might need to be created. +alldirs := xml/client xml/server man/man3 + +xml/client/index.xml: $(scanned_src_files_client) wayland.doxygen | xml/client + $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_XML=YES; \ echo XML_OUTPUT=xml/client; \ echo INPUT= $(scanned_src_files_client); \ ) | $(DOXYGEN) - -xml/server/index.xml: $(scanned_src_files_server) wayland.doxygen - $(AM_V_GEN)$(MKDIR_P) xml/server \ - (cat wayland.doxygen; \ + +xml/server/index.xml: $(scanned_src_files_server) wayland.doxygen | xml/server + $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_XML=YES; \ echo XML_OUTPUT=xml/server; \ echo INPUT= $(scanned_src_files_server); \ ) | $(DOXYGEN) - -man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) +man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) wayland.doxygen | man/man3 $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_MAN=YES; \ echo MAN_OUTPUT=man; \ @@ -45,6 +47,10 @@ man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) echo INPUT= $^; \ ) | $(DOXYGEN) - +# general rule to create one of the listed directories. +$(alldirs): + $(AM_V_GEN)$(MKDIR_P) $@ + # there is no man-local all-local: man/man3/wl_display.3 -- 1.7.9.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] doc: General makefile cleanup.
On 12/09/2014 12:00 PM, Bill Spitzak wrote: Did you see the patch I posted that merged the client/server stuff together into rules using % so that it is easier to add more doxygen-produced chapters? Yes, but it did appear to not be much in contention with these. I figured that I could easily rebase onto those if needed, but it appears you've beaten me to the punch on that. My immediate goal is to clean things up, connect publican to doxygen and get diagrams generated as part of the build. This will help some on Wayland docs, but much more on Weston docs/sources. I've not yet caught up to the point of tuning/optimizing the build, which is what more of your patches are looking like. Good news, though, is that a few rounds of back and forth and we should have a much improved build. :-) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 libinput 1/2] evdev: Ensure the libevdev object receives the new fd on resume
From: Carlos Garnacho carl...@gnome.org
Otherwise, input_events will be attempted to read from the wrong place,
which also leaves the right/current fd with pending data to be read,
making the epoll fd wake up constantly.
Signed-off-by: Carlos Garnacho carl...@gnome.org
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Changes to v1:
- sync libevdev's state after change_fd
src/evdev.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index 0873c99..3f15560 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1985,6 +1985,8 @@ evdev_device_resume(struct evdev_device *device)
struct libinput *libinput = device-base.seat-libinput;
int fd;
const char *devnode;
+ struct input_event ev;
+ enum libevdev_read_status status;
if (device-fd != -1)
return 0;
@@ -2011,6 +2013,20 @@ evdev_device_resume(struct evdev_device *device)
return -ENODEV;
}
+ libevdev_change_fd(device-evdev, fd);
+ libevdev_set_clock_id(device-evdev, CLOCK_MONOTONIC);
+
+ /* re-sync libevdev's view of the device, but discard the actual
+ events. Our device is in a neutral state already */
+ libevdev_next_event(device-evdev,
+ LIBEVDEV_READ_FLAG_FORCE_SYNC,
+ ev);
+ do {
+ status = libevdev_next_event(device-evdev,
+LIBEVDEV_READ_FLAG_SYNC,
+ev);
+ } while (status == LIBEVDEV_READ_STATUS_SYNC);
+
device-source =
libinput_add_fd(libinput, fd, evdev_device_dispatch, device);
if (!device-source) {
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 4/6] doc: add the various events to the doxygen groups
On 12/09/2014 04:34 PM, Peter Hutterer wrote: Makes them show up on the respective page and in the data structures list doxygen generates. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- src/libinput.h | 29 + 1 file changed, 29 insertions(+) diff --git a/src/libinput.h b/src/libinput.h index 682e16f..d6e0446 100644 --- a/src/libinput.h +++ b/src/libinput.h @@ -306,9 +306,38 @@ struct libinput; struct libinput_device; struct libinput_seat; +/** + * @ingroup event + * @struct libinput_event + * + * The base event type. Use libinput_event_get_pointer_event() or similar to + * get the actual event type. + */ struct libinput_event; ... The @struct tag should really not be required. One of the better ways to use Doxygen is to use the more modern Javadoc approach and not the outdated Trolltech one. Specific to that point is adding the doc comment just before the thing being commented. It makes the explicit tag redundant. It also prevents issues with typos or of comments getting out of sync. A second aspect of that less-is-more approach is to start with a single sentence that also happens to be the brief description. Thus I'd believe it would be better to place @ingroup at the end of the comment if possible. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] doc: Minor makefile cleanup.
On Tue, Dec 09, 2014 at 01:34:23AM -0800, Jon A. Cruz wrote: Split out directory creation to leverage order only prerequisites. bit beyond my puny make skills but to the best of my abilities both patches: Acked-by: Peter Hutterer peter.hutte...@who-t.net learned a few new tricks though :) Cheers, Peter Signed-off-by: Jon A. Cruz j...@osg.samsung.com --- doc/doxygen/Makefile.am | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index f8d636e..7276f5c 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -22,22 +22,24 @@ scanned_src_files_server = \ # all-local below) dist_man3_MANS = $(shell test -d man find man/man3 -name wl_*.3 -printf man/man3/%P\n) -xml/client/index.xml: $(scanned_src_files_client) wayland.doxygen - $(AM_V_GEN)$(MKDIR_P) xml/client \ - (cat wayland.doxygen; \ +# Listing various directories that might need to be created. +alldirs := xml/client xml/server man/man3 + +xml/client/index.xml: $(scanned_src_files_client) wayland.doxygen | xml/client + $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_XML=YES; \ echo XML_OUTPUT=xml/client; \ echo INPUT= $(scanned_src_files_client); \ ) | $(DOXYGEN) - -xml/server/index.xml: $(scanned_src_files_server) wayland.doxygen - $(AM_V_GEN)$(MKDIR_P) xml/server \ - (cat wayland.doxygen; \ + +xml/server/index.xml: $(scanned_src_files_server) wayland.doxygen | xml/server + $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_XML=YES; \ echo XML_OUTPUT=xml/server; \ echo INPUT= $(scanned_src_files_server); \ ) | $(DOXYGEN) - -man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) +man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) wayland.doxygen | man/man3 $(AM_V_GEN)(cat wayland.doxygen; \ echo GENERATE_MAN=YES; \ echo MAN_OUTPUT=man; \ @@ -45,6 +47,10 @@ man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) echo INPUT= $^; \ ) | $(DOXYGEN) - +# general rule to create one of the listed directories. +$(alldirs): + $(AM_V_GEN)$(MKDIR_P) $@ + # there is no man-local all-local: man/man3/wl_display.3 -- 1.9.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 3/3] touchpad: Use TOUCHPAD_MIN_SAMPLES in tp_get_delta
On Tue, Dec 09, 2014 at 12:47:11PM +0100, Hans de Goede wrote:
Use TOUCHPAD_MIN_SAMPLES in tp_get_delta rather then hardcoding 4.
s/then/than/
Also remove the superfluous TOUCHPAD_MIN_SAMPLES check before calling
tp_get_delta in tp_get_pointer_delta, this is not necessary as tp_get_delta
already checks itself.
Right, though note that you're now passing the initial 0/0 deltas into the
filter and thus feed the velocity trackers. Not that it has any effect,
0 + 0 is still 0...
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
Cheers,
Peter
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/evdev-mt-touchpad.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 7cee73d..397b8b9 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -177,7 +177,7 @@ tp_estimate_delta(int x0, int x1, int x2, int x3)
void
tp_get_delta(struct tp_touch *t, double *dx, double *dy)
{
- if (t-history.count 4) {
+ if (t-history.count TOUCHPAD_MIN_SAMPLES) {
*dx = 0;
*dy = 0;
return;
@@ -607,9 +607,7 @@ tp_get_pointer_delta(struct tp_dispatch *tp, double *dx,
double *dy)
}
}
- if (!t-is_pointer ||
- !t-dirty ||
- t-history.count TOUCHPAD_MIN_SAMPLES)
+ if (!t-is_pointer || !t-dirty)
return;
tp_get_delta(t, dx, dy);
--
2.1.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 2/3] touchpad: When a clickpad is clicked post combined motion of all touches
On Tue, Dec 09, 2014 at 12:47:10PM +0100, Hans de Goede wrote:
When clicking a clickpad the user may want to switch fingers to move the
pointer around, without lifting so as to not release the button.
Switch to using combined motion of all touches when a clickpad is clicked to
allow this.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86807
Signed-off-by: Hans de Goede hdego...@redhat.com
much nicer, thanks.
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
Cheers,
Peter
---
src/evdev-mt-touchpad.c | 43 +++
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 7d2e21a..7cee73d 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -453,6 +453,10 @@ tp_twofinger_scroll_post_events(struct tp_dispatch *tp,
uint64_t time)
if (tp_tap_dragging(tp))
return 0;
+ /* No 2fg scrolling while a clickpad is clicked */
+ if (tp-buttons.is_clickpad tp-buttons.state)
+ return 0;
+
/* Only count active touches for 2 finger scrolling */
tp_for_each_touch(tp, t) {
if (tp_touch_active(tp, t))
@@ -592,11 +596,9 @@ tp_post_process_state(struct tp_dispatch *tp, uint64_t
time)
}
static void
-tp_post_pointer_motion(struct tp_dispatch *tp, uint64_t time)
+tp_get_pointer_delta(struct tp_dispatch *tp, double *dx, double *dy)
{
struct tp_touch *t = tp_current_touch(tp);
- double dx, dy;
- double dx_unaccel, dy_unaccel;
if (!t-is_pointer) {
tp_for_each_touch(tp, t) {
@@ -610,7 +612,40 @@ tp_post_pointer_motion(struct tp_dispatch *tp, uint64_t
time)
t-history.count TOUCHPAD_MIN_SAMPLES)
return;
- tp_get_delta(t, dx, dy);
+ tp_get_delta(t, dx, dy);
+}
+
+static void
+tp_get_active_touches_delta(struct tp_dispatch *tp, double *dx, double *dy)
+{
+ struct tp_touch *t;
+ double tdx, tdy;
+ unsigned int i;
+
+ for (i = 0; i tp-real_touches; i++) {
+ t = tp_get_touch(tp, i);
+
+ if (!tp_touch_active(tp, t) || !t-dirty)
+ continue;
+
+ tp_get_delta(t, tdx, tdy);
+ *dx += tdx;
+ *dy += tdy;
+ }
+}
+
+static void
+tp_post_pointer_motion(struct tp_dispatch *tp, uint64_t time)
+{
+ double dx = 0.0, dy = 0.0;
+ double dx_unaccel, dy_unaccel;
+
+ /* When a clickpad is clicked, combine motion of all active touches */
+ if (tp-buttons.is_clickpad tp-buttons.state)
+ tp_get_active_touches_delta(tp, dx, dy);
+ else
+ tp_get_pointer_delta(tp, dx, dy);
+
tp_filter_motion(tp, dx, dy, dx_unaccel, dy_unaccel, time);
if (dx != 0.0 || dy != 0.0 || dx_unaccel != 0.0 || dy_unaccel != 0.0) {
--
2.1.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
[PATCH] doc: Reduce the validation errors of the docbook input
This removes all the validation errors except for missing link
targets. You can test this by removing the --skip-validation
from doc/publican/Makefile.am.
Main changes are to add simpara to lists, remove some extra
para commands, and prefix all the id's so that collisions
between libclient and libserver are avoided.
The remaining errors are due to missing links, due to it not
copying doxygen's output for struct, union, and a macro. Turning
on HIDE_UNDOC in wayland.doxygen.in fixes a lot of these but
not all of them.
PS: it would be useful if somebody who actually knows something
about xslt would come up with a way to translate a block of text
makde of para commands unchanged, but add para around plain
text. Most of the difficulty is that doxygen's output is rather
inconsistent here.
---
doc/publican/doxygen-to-publican.xsl| 44 +--
doc/publican/protocol-interfaces-to-docbook.xsl |8 +++--
doc/publican/protocol-to-docbook.xsl| 10 +++---
3 files changed, 27 insertions(+), 35 deletions(-)
diff --git a/doc/publican/doxygen-to-publican.xsl
b/doc/publican/doxygen-to-publican.xsl
index 47bdc5a..5adbfa6 100644
--- a/doc/publican/doxygen-to-publican.xsl
+++ b/doc/publican/doxygen-to-publican.xsl
@@ -37,20 +37,16 @@
/para
xsl:if test=/doxygen/compounddef[@kind='class']
- para
-variablelist
- xsl:apply-templates select=/doxygen/compounddef /
-/variablelist
- /para
+ variablelist
+xsl:apply-templates select=/doxygen/compounddef /
+ /variablelist
/xsl:if
paraMethods for the respective classes./para
-para
variablelist
-xsl:apply-templates select=/doxygen/compounddef/sectiondef/memberdef /
+ xsl:apply-templates select=/doxygen/compounddef/sectiondef/memberdef
/
/variablelist
-/para
/appendix
/xsl:template
@@ -60,7 +56,7 @@
xsl:apply-templates select=parameternamelist/parametername/
/term
listitem
-xsl:apply-templates select=parameterdescription/
+simparaxsl:apply-templates select=parameterdescription//simpara
/listitem
/varlistentry
/xsl:template
@@ -74,7 +70,7 @@
/xsl:template
xsl:template match=ref
- link linkend={@refid}xsl:value-of select=. //link
+ link linkend={$which}{@refid}xsl:value-of select=. //link
/xsl:template
xsl:template match=simplesect[@kind='return']
@@ -82,22 +78,18 @@
varlistentry
termReturns:/term
listitem
-xsl:apply-templates /
+simparaxsl:apply-templates //simpara
/listitem
/varlistentry
/variablelist
/xsl:template
xsl:template match=simplesect[@kind='see']
- para
-See also: xsl:apply-templates /
- /para
+ See also: xsl:apply-templates /
/xsl:template
xsl:template match=simplesect[@kind='since']
- para
-Since: xsl:apply-templates /
- /para
+ Since: xsl:apply-templates /
/xsl:template
xsl:template match=simplesect[@kind='note']
@@ -131,7 +123,7 @@
!-- methods --
xsl:template match=memberdef
xsl:if test=@kind = 'function' and @static = 'no'
-varlistentry id={@id}
+varlistentry id={$which}{@id}
term
xsl:value-of select=name/
xsl:if test=normalize-space(briefdescription) != ''
@@ -139,21 +131,19 @@
/xsl:if
/term
listitem
- para
-synopsis
- xsl:apply-templates select=definition/xsl:apply-templates
select=argsstring/
-/synopsis
- /para
+ synopsis
+xsl:apply-templates select=definition/xsl:apply-templates
select=argsstring/
+ /synopsis
xsl:apply-templates select=detaileddescription /
/listitem
/varlistentry
-/xsl:if
+ /xsl:if
/xsl:template
!-- classes --
xsl:template match=compounddef
-xsl:if test=@kind = 'class'
-varlistentry id={@id}
+ xsl:if test=@kind = 'class'
+varlistentry id={$which}{@id}
term
xsl:value-of select=compoundname /
xsl:if test=normalize-space(briefdescription) != ''
@@ -165,6 +155,6 @@
xsl:apply-templates select=detaileddescription /
/listitem
/varlistentry
-/xsl:if
+ /xsl:if
/xsl:template
/xsl:stylesheet
diff --git a/doc/publican/protocol-interfaces-to-docbook.xsl
b/doc/publican/protocol-interfaces-to-docbook.xsl
index fb1a816..57b3139 100644
--- a/doc/publican/protocol-interfaces-to-docbook.xsl
+++ b/doc/publican/protocol-interfaces-to-docbook.xsl
@@ -37,11 +37,13 @@
term
link linkend=protocol-spec-interface-{@name}
xsl:value-of select=@name /
- xsl:if test=description/@summary
-- xsl:value-of select=description/@summary /
- /xsl:if
/link
/term
+ listitem
+simpara
+ xsl:value-of select=description/@summary /
+/simpara
+ /listitem
/varlistentry
/xsl:template
diff --git a/doc/publican/protocol-to-docbook.xsl
Re: Where should project Weston go?
On Tue, Dec 09, 2014 at 11:36:42AM -0800, Jason Ekstrand wrote: Bryce, Thanks for your thoughts. I've got a few of my own, but I decided to reply to your e-mail as it seemed the best branch-point for the actual discussion without replying to everything. On Mon, Dec 8, 2014 at 3:26 PM, Bryce Harrington br...@osg.samsung.com wrote: Performance is really only relevant in context to a use case; otherwise this can lead us to pre-maturely optimizing stuff that no one cares about. So, maybe fast for embedded/mobile/automotive. Or maybe there's an implied use case in the original statement (i.e. fast desktop) that should be made explicit. I think that Weston's performance matters a lot in some respects and not much in others. We don't want to overcomplicate things by prematurely optimizing or squeezing out every clock cycle we can. However, Weston does give us the opportunity to show off some of cool performance things the Wayland protocol allows us to do. One example of this is the planes support in the drm backend. Weston may be the only desktop compositor around today that take a single subsurface out of a window, put it in a plane, and flip it directly to the screen. This is fantastic for performance and power usage and is one of the advantages of the Wayland protocol. If people come to us complaining that you can't do that in Wayland just because GNOME or KWin aren't doing it, we can point to Weston and say, See, yes you can, they just aren't. Another fantastic example of this is the way the RPi backend uses planes. So I think showing off performance things we can do thanks to Wayland is important, squeezing out clock cycles isn't. Right. So perhaps: Demonstrate performance characteristics of Wayland. Perhaps what we want here is easily forkable. Not that we want people to be trying to fork the project but that we want to make it easy for someone to work on a feature branch in their own github repo and make things easy to merge back in or rebase on upstream. What does an easily forkable project look like? That's a good question. First would be to encourage people to work in feature branches rather than have to have everything on the list and/or in Weston core. While I think most things may want to be upstream eventually, trying to do upstream everything as you go is hard when people are trying to use it as a test-bed and you're trying to do stable release at the same time. We may even want to allow stuff to go upstream by merges rather then everything as a linear series on the ML. Another thing might be to make things structured a little better to try and structure things in a more compartmentalized model. Right now, Weston has a lot of files that are thousands of lines and should probably be broken up a bit (I'm looking at you, compositor.c). Having things structured a little better may make it easier for people to rebase. That said, restructuring is a lot of churn and makes it hard to rebase, so that has to be taken into account too. Many projects also get good mileage out of plugin systems, where experimentation can be done outside the core. Some plugins can be pulled into core once they're ready; others will remain on the fringe. The trick seems to be to provide the community with some sort of mechanism that allows convenient distribution of unofficial plugins outside the official release process. The other trick is providing a really good plugin API... The other area (that Bryce mentioned in a different area) is tools. Protocol dumpers are great. Other things that allow for better introspection or make it easier to implement the protocol would be fantastic. Nice thing about tools is they can be distributed separately, so can be handled in their own repository. Diagnostic tools might be useful as well; particular if they work cross-compositor. I know from looking at patchwork lately how big of a workload this is for one person. I would be more than happy to lend a hand with maintenance; I do maintenance on Cairo, am release manager for Inkscape and used to maintain the X stack for Ubuntu, so have some experience here. Samsung has a strong interest in Wayland right now, so the maintenance work would be a day job priority. If your managers at Samsung are ok with it, that would be fantastic! If nothing else, making sure things get reviewed. They're quite ok with it, it's in fact part of our team's charter to help upstreams with maintenance work, and Wayland's high on Samsung's priority list. Bryce ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 4/5] test: run clickfinger test for all clickpad-capable devices
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/touchpad.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/test/touchpad.c b/test/touchpad.c
index 01dabfd..44b403b 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -828,8 +828,13 @@ END_TEST
START_TEST(touchpad_1fg_clickfinger)
{
- struct litest_device *dev = litest_create_device(LITEST_BCM5974);
+ struct litest_device *dev = litest_current_device();
struct libinput *li = dev-libinput;
+ enum libinput_config_status status;
+
+ status = libinput_device_config_click_set_method(dev-libinput_device,
+
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
litest_drain_events(li);
@@ -846,15 +851,18 @@ START_TEST(touchpad_1fg_clickfinger)
LIBINPUT_BUTTON_STATE_PRESSED);
litest_assert_button_event(li, BTN_LEFT,
LIBINPUT_BUTTON_STATE_RELEASED);
-
- litest_delete_device(dev);
}
END_TEST
START_TEST(touchpad_2fg_clickfinger)
{
- struct litest_device *dev = litest_create_device(LITEST_BCM5974);
+ struct litest_device *dev = litest_current_device();
struct libinput *li = dev-libinput;
+ enum libinput_config_status status;
+
+ status = libinput_device_config_click_set_method(dev-libinput_device,
+
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
litest_drain_events(li);
@@ -873,8 +881,6 @@ START_TEST(touchpad_2fg_clickfinger)
LIBINPUT_BUTTON_STATE_PRESSED);
litest_assert_button_event(li, BTN_RIGHT,
LIBINPUT_BUTTON_STATE_RELEASED);
-
- litest_delete_device(dev);
}
END_TEST
@@ -2180,8 +2186,8 @@ int main(int argc, char **argv) {
litest_add(touchpad:tap, clickpad_1fg_tap_click, LITEST_CLICKPAD,
LITEST_ANY);
litest_add(touchpad:tap, clickpad_2fg_tap_click, LITEST_CLICKPAD,
LITEST_SINGLE_TOUCH|LITEST_APPLE_CLICKPAD);
- litest_add_no_device(touchpad:clickfinger, touchpad_1fg_clickfinger);
- litest_add_no_device(touchpad:clickfinger, touchpad_2fg_clickfinger);
+ litest_add(touchpad:clickfinger, touchpad_1fg_clickfinger,
LITEST_CLICKPAD, LITEST_ANY);
+ litest_add(touchpad:clickfinger, touchpad_2fg_clickfinger,
LITEST_CLICKPAD, LITEST_ANY);
litest_add(touchpad:click, touchpad_click_defaults_clickfinger,
LITEST_APPLE_CLICKPAD, LITEST_ANY);
litest_add(touchpad:click, touchpad_click_defaults_btnarea,
LITEST_CLICKPAD, LITEST_APPLE_CLICKPAD);
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 5/5] tests: add a few clickfinger tests
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/touchpad.c | 293
1 file changed, 293 insertions(+)
diff --git a/test/touchpad.c b/test/touchpad.c
index 44b403b..c044fee 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -884,6 +884,198 @@ START_TEST(touchpad_2fg_clickfinger)
}
END_TEST
+START_TEST(touchpad_clickfinger_to_area_method)
+{
+ struct litest_device *dev = litest_current_device();
+ enum libinput_config_status status;
+ struct libinput *li = dev-libinput;
+
+ litest_drain_events(li);
+
+ status = libinput_device_config_click_set_method(dev-libinput_device,
+
LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+
+ litest_touch_down(dev, 0, 90, 90);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 0);
+ libinput_dispatch(li);
+
+ litest_assert_button_event(li, BTN_RIGHT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ litest_assert_button_event(li, BTN_RIGHT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+ status = libinput_device_config_click_set_method(dev-libinput_device,
+
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+
+ litest_drain_events(li);
+
+ /* use bottom right corner to catch accidental softbutton right */
+ litest_touch_down(dev, 0, 90, 90);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 0);
+ libinput_dispatch(li);
+
+ litest_assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ litest_assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+}
+END_TEST
+
+START_TEST(touchpad_clickfinger_to_area_method_while_down)
+{
+ struct litest_device *dev = litest_current_device();
+ enum libinput_config_status status;
+ struct libinput *li = dev-libinput;
+
+ litest_drain_events(li);
+
+ status = libinput_device_config_click_set_method(dev-libinput_device,
+
LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+
+ litest_touch_down(dev, 0, 90, 90);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ libinput_dispatch(li);
+ litest_assert_button_event(li, BTN_RIGHT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+
+ status = libinput_device_config_click_set_method(dev-libinput_device,
+
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 0);
+ libinput_dispatch(li);
+
+ litest_assert_button_event(li, BTN_RIGHT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+
+ litest_drain_events(li);
+
+ /* use bottom right corner to catch accidental softbutton right */
+ litest_touch_down(dev, 0, 90, 90);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_touch_up(dev, 0);
+ libinput_dispatch(li);
+
+ litest_assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ litest_assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+
+}
+END_TEST
+
+START_TEST(touchpad_area_to_clickfinger_method)
+{
+ struct litest_device *dev = litest_current_device();
+ enum libinput_config_status status;
+ struct libinput *li = dev-libinput;
+
+ status = libinput_device_config_click_set_method(dev-libinput_device,
+
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+
+ litest_drain_events(li);
+
+ /* use bottom right corner to catch accidental softbutton right */
+ litest_touch_down(dev, 0, 90, 90);
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
[PATCH libinput 2/5] touchpad: hook up click method configuration
Allow switching between softbuttons and clickfinger on any mt-capable
clickpad.
This disables top software buttons on T440s when switching to clickfingers.
That's left as a future project for those that need this exact behavior...
The top buttons will work if the touchpad is disabled though.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad-buttons.c | 163 ++--
src/evdev-mt-touchpad.c | 6 +-
src/evdev-mt-touchpad.h | 15 +++-
src/libinput.h | 6 ++
4 files changed, 160 insertions(+), 30 deletions(-)
diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index 6af3fcf..746d663 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -494,10 +494,9 @@ tp_release_all_buttons(struct tp_dispatch *tp,
}
}
-void
+static void
tp_init_softbuttons(struct tp_dispatch *tp,
- struct evdev_device *device,
- double topbutton_size_mult)
+ struct evdev_device *device)
{
int width, height;
const struct input_absinfo *absinfo_x, *absinfo_y;
@@ -523,6 +522,26 @@ tp_init_softbuttons(struct tp_dispatch *tp,
}
tp-buttons.bottom_area.rightbutton_left_edge = width/2 + xoffset;
+}
+
+void
+tp_init_top_softbuttons(struct tp_dispatch *tp,
+ struct evdev_device *device,
+ double topbutton_size_mult)
+{
+ int width, height;
+ const struct input_absinfo *absinfo_x, *absinfo_y;
+ int xoffset, yoffset;
+ int yres;
+
+ absinfo_x = device-abs.absinfo_x;
+ absinfo_y = device-abs.absinfo_y;
+
+ xoffset = absinfo_x-minimum,
+ yoffset = absinfo_y-minimum;
+ yres = absinfo_y-resolution;
+ width = abs(absinfo_x-maximum - absinfo_x-minimum);
+ height = abs(absinfo_y-maximum - absinfo_y-minimum);
if (tp-buttons.has_topbuttons) {
/* T440s has the top button line 5mm from the top, event
@@ -545,6 +564,88 @@ tp_init_softbuttons(struct tp_dispatch *tp,
}
}
+static inline uint32_t
+tp_button_config_click_get_methods(struct libinput_device *device)
+{
+ struct evdev_device *evdev = (struct evdev_device*)device;
+ struct tp_dispatch *tp = (struct tp_dispatch*)evdev-dispatch;
+ uint32_t methods = LIBINPUT_CONFIG_CLICK_METHOD_NONE;
+
+ if (tp-buttons.is_clickpad) {
+ methods |= LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS;
+ if (tp-has_mt)
+ methods |= LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER;
+ }
+
+ return methods;
+}
+
+static void
+tp_switch_click_method(struct tp_dispatch *tp)
+{
+ if (tp-buttons.click_method == tp-buttons.want_click_method)
+ return;
+
+ tp-buttons.click_method = tp-buttons.want_click_method;
+
+ tp_clear_state(tp);
+
+ switch (tp-buttons.click_method) {
+ case LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS:
+ tp_init_softbuttons(tp, tp-device);
+ break;
+ case LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER:
+ case LIBINPUT_CONFIG_CLICK_METHOD_NONE:
+ tp-buttons.bottom_area.top_edge = INT_MAX;
+ break;
+ }
+}
+
+static enum libinput_config_status
+tp_button_config_click_set_method(struct libinput_device *device,
+ enum libinput_config_click_method method)
+{
+ struct evdev_device *evdev = (struct evdev_device*)device;
+ struct tp_dispatch *tp = (struct tp_dispatch*)evdev-dispatch;
+
+ tp-buttons.want_click_method = method;
+
+ if (tp-buttons.active == 0)
+ tp_switch_click_method(tp);
+
+ return LIBINPUT_CONFIG_STATUS_SUCCESS;
+}
+
+static enum libinput_config_click_method
+tp_button_config_click_get_method(struct libinput_device *device)
+{
+ struct evdev_device *evdev = (struct evdev_device*)device;
+ struct tp_dispatch *tp = (struct tp_dispatch*)evdev-dispatch;
+
+ /* return the one we want, even if it's not active yet */
+ return tp-buttons.want_click_method;
+}
+
+static enum libinput_config_click_method
+tp_click_get_default_method(struct tp_dispatch *tp)
+{
+ if (!tp-buttons.is_clickpad)
+ return LIBINPUT_CONFIG_CLICK_METHOD_NONE;
+ else if (libevdev_get_id_vendor(tp-device-evdev) == VENDOR_ID_APPLE)
+ return LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER;
+ else
+ return LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS;
+}
+
+static enum libinput_config_click_method
+tp_button_config_click_get_default_method(struct libinput_device *device)
+{
+ struct evdev_device *evdev = (struct evdev_device*)device;
+ struct tp_dispatch *tp = (struct tp_dispatch*)evdev-dispatch;
+
+ return tp_click_get_default_method(tp);
+}
+
int
tp_init_buttons(struct tp_dispatch *tp,
[PATCH libinput 3/5] test: add tests for clickfinger defaults
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/touchpad.c | 85 +
1 file changed, 85 insertions(+)
diff --git a/test/touchpad.c b/test/touchpad.c
index 934674c..01dabfd 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -745,6 +745,87 @@ START_TEST(touchpad_3fg_tap_btntool_inverted)
}
END_TEST
+START_TEST(touchpad_click_defaults_clickfinger)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput_device *device = dev-libinput_device;
+ uint32_t methods, method;
+ enum libinput_config_status status;
+
+ /* call this test for apple touchpads */
+
+ methods = libinput_device_config_click_get_methods(device);
+ ck_assert(methods LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS);
+ ck_assert(methods LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+
+ method = libinput_device_config_click_get_method(device);
+ ck_assert_int_eq(method, LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ method = libinput_device_config_click_get_default_method(device);
+ ck_assert_int_eq(method, LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+
+ status = libinput_device_config_click_set_method(device,
+
LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+ status = libinput_device_config_click_set_method(device,
+
LIBINPUT_CONFIG_CLICK_METHOD_NONE);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+}
+END_TEST
+
+START_TEST(touchpad_click_defaults_btnarea)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput_device *device = dev-libinput_device;
+ uint32_t methods, method;
+ enum libinput_config_status status;
+
+ /* call this test for non-apple clickpads */
+
+ methods = libinput_device_config_click_get_methods(device);
+ ck_assert(methods LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ ck_assert(methods LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS);
+
+ method = libinput_device_config_click_get_method(device);
+ ck_assert_int_eq(method, LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS);
+ method = libinput_device_config_click_get_default_method(device);
+ ck_assert_int_eq(method, LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS);
+
+ status = libinput_device_config_click_set_method(device,
+
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+ status = libinput_device_config_click_set_method(device,
+
LIBINPUT_CONFIG_CLICK_METHOD_NONE);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+}
+END_TEST
+
+START_TEST(touchpad_click_defaults_none)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput_device *device = dev-libinput_device;
+ uint32_t methods, method;
+ enum libinput_config_status status;
+
+ /* call this test for non-clickpads */
+
+ methods = libinput_device_config_click_get_methods(device);
+ ck_assert_int_eq(methods, 0);
+
+ method = libinput_device_config_click_get_method(device);
+ ck_assert_int_eq(method, LIBINPUT_CONFIG_CLICK_METHOD_NONE);
+ method = libinput_device_config_click_get_default_method(device);
+ ck_assert_int_eq(method, LIBINPUT_CONFIG_CLICK_METHOD_NONE);
+
+ status = libinput_device_config_click_set_method(device,
+
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_UNSUPPORTED);
+ status = libinput_device_config_click_set_method(device,
+
LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_UNSUPPORTED);
+}
+END_TEST
+
+
START_TEST(touchpad_1fg_clickfinger)
{
struct litest_device *dev = litest_create_device(LITEST_BCM5974);
@@ -2102,6 +2183,10 @@ int main(int argc, char **argv) {
litest_add_no_device(touchpad:clickfinger, touchpad_1fg_clickfinger);
litest_add_no_device(touchpad:clickfinger, touchpad_2fg_clickfinger);
+ litest_add(touchpad:click, touchpad_click_defaults_clickfinger,
LITEST_APPLE_CLICKPAD, LITEST_ANY);
+ litest_add(touchpad:click, touchpad_click_defaults_btnarea,
LITEST_CLICKPAD, LITEST_APPLE_CLICKPAD);
+ litest_add(touchpad:click, touchpad_click_defaults_none,
LITEST_TOUCHPAD, LITEST_CLICKPAD);
+
litest_add(touchpad:click, touchpad_btn_left, LITEST_TOUCHPAD,
LITEST_CLICKPAD);
litest_add(touchpad:click, clickpad_btn_left, LITEST_CLICKPAD,
LITEST_ANY);
litest_add(touchpad:click,
[PATCH libinput 1/5] Add a config interface for click methods
Two methods are provided:
* button area - used on most clickpads, a click with a touch within a given
area generates left/middle/right clicks
* clickfinger - used on apple touchpads, a click with 1/2/3 fingers on the
touchpad generates a left, right, middle click
Both methods already exist in the touchpad code, this is just the
configuration interface.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
I fully admit, I'm not happy with the naming but I can't come up with
something nicer.
src/libinput-private.h | 9 +
src/libinput.c | 50
src/libinput.h | 102 +
3 files changed, 161 insertions(+)
diff --git a/src/libinput-private.h b/src/libinput-private.h
index b36dc95..dce0e78 100644
--- a/src/libinput-private.h
+++ b/src/libinput-private.h
@@ -146,6 +146,14 @@ struct libinput_device_config_scroll_method {
uint32_t (*get_default_button)(struct libinput_device *device);
};
+struct libinput_device_config_click_method {
+ uint32_t (*get_methods)(struct libinput_device *device);
+ enum libinput_config_status (*set_method)(struct libinput_device
*device,
+ enum
libinput_config_click_method method);
+ enum libinput_config_click_method (*get_method)(struct libinput_device
*device);
+ enum libinput_config_click_method (*get_default_method)(struct
libinput_device *device);
+};
+
struct libinput_device_config {
struct libinput_device_config_tap *tap;
struct libinput_device_config_calibration *calibration;
@@ -154,6 +162,7 @@ struct libinput_device_config {
struct libinput_device_config_natural_scroll *natural_scroll;
struct libinput_device_config_left_handed *left_handed;
struct libinput_device_config_scroll_method *scroll_method;
+ struct libinput_device_config_click_method *click_method;
};
struct libinput_device {
diff --git a/src/libinput.c b/src/libinput.c
index 279cce0..d917cb4 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1584,6 +1584,56 @@
libinput_device_config_buttons_get_default_left_handed(struct libinput_device *d
}
LIBINPUT_EXPORT uint32_t
+libinput_device_config_click_get_methods(struct libinput_device *device)
+{
+ if (device-config.click_method)
+ return device-config.click_method-get_methods(device);
+ else
+ return 0;
+}
+
+LIBINPUT_EXPORT enum libinput_config_status
+libinput_device_config_click_set_method(struct libinput_device *device,
+ enum libinput_config_click_method
method)
+{
+ if ((libinput_device_config_click_get_methods(device) method) !=
method)
+ return LIBINPUT_CONFIG_STATUS_UNSUPPORTED;
+
+ /* Check method is a single valid method */
+ switch (method) {
+ case LIBINPUT_CONFIG_CLICK_METHOD_NONE:
+ case LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS:
+ case LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER:
+ break;
+ default:
+ return LIBINPUT_CONFIG_STATUS_INVALID;
+ }
+
+ if (device-config.click_method)
+ return device-config.click_method-set_method(device, method);
+ else /* method must be _NONE to get here */
+ return LIBINPUT_CONFIG_STATUS_SUCCESS;
+}
+
+LIBINPUT_EXPORT enum libinput_config_click_method
+libinput_device_config_click_get_method(struct libinput_device *device)
+{
+ if (device-config.click_method)
+ return device-config.click_method-get_method(device);
+ else
+ return LIBINPUT_CONFIG_CLICK_METHOD_NONE;
+}
+
+LIBINPUT_EXPORT enum libinput_config_click_method
+libinput_device_config_click_get_default_method(struct libinput_device *device)
+{
+ if (device-config.click_method)
+ return device-config.click_method-get_default_method(device);
+ else
+ return LIBINPUT_CONFIG_CLICK_METHOD_NONE;
+}
+
+LIBINPUT_EXPORT uint32_t
libinput_device_config_scroll_get_methods(struct libinput_device *device)
{
if (device-config.scroll_method)
diff --git a/src/libinput.h b/src/libinput.h
index 57d9ded..0f0b01f 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -2212,6 +2212,108 @@
libinput_device_config_buttons_get_default_left_handed(struct libinput_device *d
/**
* @ingroup config
*
+ * The click method defines when to generate software-emulated
+ * buttons, usually on a device that does not have a specific physical
+ * button available.
+ */
+enum libinput_config_click_method {
+ /**
+* Do not send software-emulated button events. This has no effect
+* on physical button generations.
+*/
+ LIBINPUT_CONFIG_CLICK_METHOD_NONE = 0,
+ /**
+* Use software-button areas (see @ref tpbuttons) to generate button
+* events.
+*/
+ LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS = (1
Re: [PATCH v2] doc: Make each library an appendix
On Tue, Dec 09, 2014 at 05:01:08PM -0800, Bill Spitzak wrote: This supersedes the previous patches. The main change is that this is rebased atop Jon A Cruz's patches (which are included here as the first 2). I also merged two related patches and updated the comments. This supersedes the chap5/appendexB patch I posted yesterday. Aside from the copyedits to the fourth patch, the rest LGTM. Reviewed-by: Bryce Harrington b.harring...@samsung.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Adding notes regarding Arch Linux dependencies for DocBook.
On 12/09/2014 08:35 AM, Derek Foreman wrote: Any way we can print a more descriptive error at failure time instead of just hiding a clue in the docs? Or can we just disable docbook if deps aren't present? I'm not certain Arch will be the only distribution to ever have this problem, and the comment could get a little unwieldy... I'd been thinking the same. However it turns out that a check is non-trivial and most likely involves bringing in another GPL'd file or two. In the meantime documenting the requirement can reduce the number of times it trips people up. (Why is this reaching out over the internet anyway? Is this a bug that should be brought up with an Arch package maintainer?) Some depends on what xmlto passes internally to the xslt processor. It appears a switch for this was changed at some point. Simple ways to block it are not immediately present in xmlto. However, it is a case of it attempting to fetch primary stylesheets that were to be used for main processing as opposed to merely fetching the DTDs for files as they were processed (a different common problem). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
