Re: [PATCH wayland] tests: fix memory leak
On 1 December 2014 at 11:42, Pekka Paalanen ppaala...@gmail.com wrote:
On Fri, 21 Nov 2014 11:18:33 +0100
Marek Chalupa mchqwe...@gmail.com wrote:
We didn't free the struct client that we got from client_connect()
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
tests/display-test.c| 23 +--
tests/test-compositor.c | 1 +
2 files changed, 14 insertions(+), 10 deletions(-)
Hi,
how did you find these leaks?
By valgrind --trace-children=yes
More importantly, why doesn't our leak checker find these?
That is, the code in test-runner.c, run_test().
Because it is in another fork. It looks like this:
run_test()
int the alloc_count and fds_count
run the TEST function
create_client -- fork
[in fork] alloc, dealloc, whatever
wait for client
check alloc_count and fds_count
The problem is that the forked client has the alloc_count and fds_count
in its own virtual memory, so the leak checker finds only leaks in
TEST function.
I have some patches that extend these leak checks
into the client too, but I ran into problem with filedescriptors there.
The problem is that when forking the client, we pass WAYLAND_SOCKET fd
to wl_display_connect(). wl_display_connect() just uses this fd (no dup),
so wl_display_disconnect() closes this fd.
So the result of leak checker is that the client closed
one more fd that it opened. Hardcoding -1 to client's fds number
is not a solution too, because client does not have to call
wl_display_connect()
So summing it up: using leak checker in clients is possible, but only for
memory
leaks. For fd leaks we'd have to use some more sophisticated solution.
For one, I think those are not thread-safe. Calling exit() in a test
would bypass it too, but I'm not sure that happens.
Huh? What is not thread-safe? you mean leak checks when running only one
test (without fork?)
Yes, it looks like when calling exit in the test, the leak check is
bypassed.
Quick grep though the tests shows that there are no calls to exit in TEST,
just in
the forked clients (which is not a problem _now_ with no leak checks in
clients)
The Valgrind output nowadays is quite messy. Even when I run a single
test from one test binary which should not fork at all, I think I see
two forks in Valgrind output: one is likely the debugger check, maybe
the other is actually a thread for the test compositor or something?
Yes, the first fork is the debugger check and the other is the client
for test compositor. In the tests without the test compositor you should
see only
one fork (the debugger check)
I think Valgrind is saying that there are many more leaks to plug.
Yes
In any case, this patch pushed.
Thanks,
pq
diff --git a/tests/display-test.c b/tests/display-test.c
index aecf341..776a9c9 100644
--- a/tests/display-test.c
+++ b/tests/display-test.c
@@ -155,6 +155,14 @@ bind_seat(struct wl_client *client, void *data,
}
static void
+client_disconnect_nocheck(struct client *c)
+{
+ wl_proxy_destroy((struct wl_proxy *) c-tc);
+ wl_display_disconnect(c-wl_display);
+ free(c);
+}
+
+static void
post_error_main(void)
{
struct client *c = client_connect();
@@ -170,8 +178,7 @@ post_error_main(void)
/* don't call client_disconnect(c), because then the test would be
* aborted due to checks for error in this function */
wl_proxy_destroy((struct wl_proxy *) seat);
- wl_proxy_destroy((struct wl_proxy *) c-tc);
- wl_display_disconnect(c-wl_display);
+ client_disconnect_nocheck(c);
}
TEST(post_error_to_one_client)
@@ -224,8 +231,7 @@ post_error_main3(void)
/* don't call client_disconnect(c), because then the test would be
* aborted due to checks for error in this function */
wl_proxy_destroy((struct wl_proxy *) seat);
- wl_proxy_destroy((struct wl_proxy *) c-tc);
- wl_display_disconnect(c-wl_display);
+ client_disconnect_nocheck(c);
}
/* all the testcases could be in one TEST, but splitting it
@@ -294,8 +300,7 @@ post_nomem_main(void)
assert(wl_display_get_error(c-wl_display) == ENOMEM);
wl_proxy_destroy((struct wl_proxy *) seat);
- wl_proxy_destroy((struct wl_proxy *) c-tc);
- wl_display_disconnect(c-wl_display);
+ client_disconnect_nocheck(c);
}
TEST(post_nomem_tst)
@@ -413,8 +418,7 @@ threading_post_err(void)
test_set_timeout(3);
pthread_join(thread, NULL);
- wl_proxy_destroy((struct wl_proxy *) c-tc);
- wl_display_disconnect(c-wl_display);
+ client_disconnect_nocheck(c);
}
TEST(threading_errors_tst)
@@ -565,8 +569,7 @@ threading_read_after_error(void)
test_set_timeout(3);
pthread_join(thread, NULL);
- wl_proxy_destroy((struct wl_proxy *) c-tc);
- wl_display_disconnect(c-wl_display);
+ client_disconnect_nocheck(c);
Re: [PATCH wayland v2 1/2] client: update obsolete comments
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 @@ -1333,18 +1333,19 @@ wl_display_prepare_read_queue(struct wl_display *display, * wl_display_dispatch(display); * \endcode * - * There are two races here: first, before blocking in poll(), the fd - * could become readable and another thread reads the events. Some of - * these events may be for the main queue and the other thread will - * queue them there and then the main thread will go to sleep in - * poll(). This will stall the application, which could be waiting - * for a event to kick of the next animation frame, for example. - * - * The other race is immediately after poll(), where another thread - * could preempt and read events before the main thread calls - * wl_display_dispatch(). This call now blocks and starves the other + * The race is immediately after poll(), where one thread + * could preempt and read events before the other thread calls + * wl_display_dispatch(). This call now blocks and starves the other * fds in the event loop. * + * Another race would be when using more event queues. + * When one thread calls wl_display_dispatch(_queue)(), then it + * reads all events from display's fd and queues them in appropriate + * queues. Then it dispatches only its own queue and the other events + * are sitting in their queues, waiting for dispatching. If that happens + * before the other thread managed to call poll(), it will + * block with events queued. + * * A correct sequence would be: * \code * while (wl_display_prepare_read(display) != 0) @@ -1358,9 +1359,12 @@ wl_display_prepare_read_queue(struct wl_display *display, * Here we call wl_display_prepare_read(), which ensures that between * returning from that call and eventually calling * wl_display_read_events(), no other thread will read from the fd and - * queue events in our queue. If the call to - * wl_display_prepare_read() fails, we dispatch the pending events and - * try again until we're successful. + * queue events in our queue. If the call to wl_display_prepare_read() fails, + * we dispatch the pending events and try again until we're successful. + * If we have more queues, we may want to use + * wl_display_dispatch_queue_pending() instead of wl_display_dispatch_pending(), + * to be sure that we dispatched all the queues (not only the default one). + * Also use \ref wl_display_prepare_read_queue() in this case. That is inaccurate. wl_display_dispatch_queue_pending() will dispatch only one queue, but the text seems to imply it might dispatch all, and that the default queue would need to be dispatched always. True The wl_display_prepare_read_queue() needs to always match the wl_display_dispatch_queue_pending(). Each thread should dispatch only the queue(s) it owns, never any other queues, and I feel also that is not clearly communicated in this. If a thread has multiple queues, there is no requirement to handle them all at the same time. Each queue usually has a different context where it needs to dispatch, and dispatching elsewhere would be a problem. How about the following: If the relevant queue is not the default queue, then wl_display_prepare_read_queue() and wl_display_dispatch_queue_pending() need to be used instead. Yes, that sounds good * * \memberof wl_display */ @@ -1399,10 +1403,25 @@ wl_display_cancel_read(struct wl_display *display) * Dispatch all incoming events for objects assigned to the given * event queue. On failure -1 is returned and errno set appropriately. * - * This function blocks if there are no events to dispatch. If calling from - * the main thread, it will block reading data from the display fd. For other - * threads this will block until the main thread queues events on the queue - * passed as argument. + * The behaviour of this function is exactly the same as the behaviour of + * wl_display_dispatch(), but it dispatches events on given queue, + * not on the default queue. + * + * This function blocks if
[PATCH] Remove explicit dependency on $(WAYLAND_LIBS)
Hi I was trying to build XWayland as per the recipe from http://wayland.freedesktop.org/xserver.html and ran into an issue because I have the Wayland libs installed in a non-standard location (from http://wayland.freedesktop.org/building.html) Basically, xserver/hw/xwayland/Makefile.am specifies Xwayland_DEPENDENCIES = $(XWAYLAND_LIBS) which will break because XWAYLAND_LIBS also contains the statements -L/path/to/the/lib and that breaks the build with: make[2]: *** No rule to make target '-L/path/to/the/lib', needed by 'Xwayland'. Stop. make[2]: Leaving directory '/home/ofourdan/src/wayland/xserver/hw/xwayland' I am not sure why Xwayland_DEPENDENCIES = $(XWAYLAND_LIBS) was added in the first place, it comes from a huge commit (6e539d88), but I suspect it's not needed and it might be better not have it (at least it builds successfully without), thus the patch attached. HTH, Cheers, Olivier From 090928e71a4c06ee8f22cbf90b65dc4e248ee838 Mon Sep 17 00:00:00 2001 From: Olivier Fourdan ofour...@redhat.com Date: Wed, 3 Dec 2014 13:49:37 +0100 Subject: [PATCH] Remove explicit dependency on $(WAYLAND_LIBS) Xwayland Makefile explicitely set its dependencies on WAYLAND_LIBS. If the ibrairies are installed in a non-standard path, WAYLAND_LIBS contains '-L/path/to/the/lib' which will fail at build time with: No rule to make target '-L/path/to/the/lib', needed by 'Xwayland'. Stop Remove that explicit dependency to avoid the problem (LDADD ought to be enough to get the right libraries linked). Signed-off-by: Olivier Fourdan ofour...@redhat.com --- hw/xwayland/Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am index 4e0e1bb..9945540 100644 --- a/hw/xwayland/Makefile.am +++ b/hw/xwayland/Makefile.am @@ -26,7 +26,6 @@ Xwayland_LDADD =\ $(XWAYLAND_LIBS) \ $(XWAYLAND_SYS_LIBS) \ $(XSERVER_SYS_LIBS) -Xwayland_DEPENDENCIES = $(XWAYLAND_LIBS) Xwayland_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG) -- 2.1.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland v3 2/2] client: update documentation about threading
Remove out-dated documentation and add few more words
about this topic.
v2. replace a paragraph by better explanation from Pekka Paalanen
fix other notes from reviewing
v3. fix typo
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
src/wayland-client.c | 104 ---
1 file changed, 90 insertions(+), 14 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index eae438a..84b15a6 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -909,6 +909,12 @@ static const struct wl_callback_listener sync_listener = {
* Blocks until the server process all currently issued requests and
* sends out pending events on the event queue.
*
+ * \note This function uses wl_display_dispatch_queue() internally. If you
+ * are using wl_display_read_events() from more threads, don't use this
function
+ * (or make sure that calling wl_display_roundtrip_queue() doesn't interfere
+ * with calling wl_display_prepare_read() and wl_display_read_events())
+ *
+ * \sa wl_display_roundtrip()
* \memberof wl_display
*/
WL_EXPORT int
@@ -940,6 +946,11 @@ wl_display_roundtrip_queue(struct wl_display *display,
struct wl_event_queue *qu
* Blocks until the server process all currently issued requests and
* sends out pending events on the default event queue.
*
+ * \note This function uses wl_display_dispatch_queue() internally. If you
+ * are using wl_display_read_events() from more threads, don't use this
function
+ * (or make sure that calling wl_display_roundtrip() doesn't interfere
+ * with calling wl_display_prepare_read() and wl_display_read_events())
+ *
* \memberof wl_display
*/
WL_EXPORT int
@@ -1216,14 +1227,59 @@ cancel_read(struct wl_display *display)
*
* This will read events from the file descriptor for the display.
* This function does not dispatch events, it only reads and queues
- * events into their corresponding event queues. If no data is
+ * events into their corresponding event queues. If no data is
* available on the file descriptor, wl_display_read_events() returns
- * immediately. To dispatch events that may have been queued, call
- * wl_display_dispatch_pending() or
- * wl_display_dispatch_queue_pending().
+ * immediately. To dispatch events that may have been queued, call
+ * wl_display_dispatch_pending() or wl_display_dispatch_queue_pending().
*
* Before calling this function, wl_display_prepare_read() must be
- * called first.
+ * called first. When running in more threads (which is the usual
+ * case, since we'd use wl_display_dispatch() otherwise), every thread
+ * must call wl_display_prepare_read() before calling this function.
+ *
+ * After calling wl_display_prepare_read() there can be some extra code
+ * before calling wl_display_read_events(), for example poll() or alike.
+ * Example of code in a thread:
+ *
+ * \code
+ *
+ * while (wl_display_prepare_read(display) 0)
+ * wl_display_dispatch_pending(display);
+ * wl_display_flush(display);
+ *
+ * ... some code ...
+ *
+ * fds[0].fd = wl_display_get_fd(display);
+ * fds[0].event = POLLIN | POLLHUP | POLLERR;
+ * poll(fds, 1, -1);
+ *
+ * if (!everything_ok()) {
+ * wl_display_cancel_read(display);
+ * handle_error();
+ * }
+ *
+ * if (wl_display_read_events(display) 0)
+ * handle_error();
+ *
+ * ...
+ * \endcode
+ *
+ * After wl_display_prepare_read() succeeds, other threads that enter
+ * wl_display_read_events() will sleep until the very last thread enters
+ * it too or cancels. Therefore when the display fd becomes (or already
+ * is) readable, wl_display_read_events() should be called as soon as
+ * possible to unblock all threads. If wl_display_read_events() will not
+ * be called, then wl_display_cancel_read() must be called instead to let
+ * the other threads continue.
+ *
+ * This function must not be called simultaneously with wl_display_dispatch().
+ * It may lead to deadlock. If programmer wants, for some reason, use
+ * wl_display_dispatch() in one thread and wl_display_prepare_read() with
+ * wl_display_read_events() in another, extra care must be taken to serialize
+ * these calls, i. e. use mutexes or similar (on whole prepare + read sequence)
+ *
+ * \sa wl_display_prepare_read(), wl_display_cancel_read(),
+ * wl_display_dispatch_pending(), wl_display_dispatch()
*
* \memberof wl_display
*/
@@ -1301,17 +1357,17 @@ wl_display_prepare_read_queue(struct wl_display
*display,
return ret;
}
-/** Prepare to read events after polling file descriptor
+/** Prepare to read events from the display's file descriptor
*
* \param display The display context object
* \return 0 on success or -1 if event queue was not empty
*
* This function must be called before reading from the file
- * descriptor using wl_display_read_events(). Calling
- * wl_display_prepare_read() announces the calling threads intention
+ * descriptor using wl_display_read_events(). Calling
+ *
[PATCH wayland v3 1/2] client: update obsolete comments
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 v2. Not only remove out-of-date comment, but fix/remove more things across the wayland-client.[ch] v3. fixes (rephrasing unclear paragraphs etc.) according to Pakka Paalanen notes (thanks) Signed-off-by: Marek Chalupa mchqwe...@gmail.com --- src/wayland-client.c | 82 src/wayland-client.h | 26 +++-- 2 files changed, 62 insertions(+), 46 deletions(-) diff --git a/src/wayland-client.c b/src/wayland-client.c index 36380fe..eae438a 100644 --- a/src/wayland-client.c +++ b/src/wayland-client.c @@ -1333,18 +1333,19 @@ wl_display_prepare_read_queue(struct wl_display *display, * wl_display_dispatch(display); * \endcode * - * There are two races here: first, before blocking in poll(), the fd - * could become readable and another thread reads the events. Some of - * these events may be for the main queue and the other thread will - * queue them there and then the main thread will go to sleep in - * poll(). This will stall the application, which could be waiting - * for a event to kick of the next animation frame, for example. - * - * The other race is immediately after poll(), where another thread - * could preempt and read events before the main thread calls - * wl_display_dispatch(). This call now blocks and starves the other + * The race is immediately after poll(), where one thread + * could preempt and read events before the other thread calls + * wl_display_dispatch(). This call now blocks and starves the other * fds in the event loop. * + * Another race would be when using more event queues. + * When one thread calls wl_display_dispatch(_queue)(), then it + * reads all events from display's fd and queues them in appropriate + * queues. Then it dispatches only its own queue and the other events + * are sitting in their queues, waiting for dispatching. If that happens + * before the other thread managed to call poll(), it will + * block with events queued. + * * A correct sequence would be: * \code * while (wl_display_prepare_read(display) != 0) @@ -1358,9 +1359,12 @@ wl_display_prepare_read_queue(struct wl_display *display, * Here we call wl_display_prepare_read(), which ensures that between * returning from that call and eventually calling * wl_display_read_events(), no other thread will read from the fd and - * queue events in our queue. If the call to - * wl_display_prepare_read() fails, we dispatch the pending events and - * try again until we're successful. + * queue events in our queue. If the call to wl_display_prepare_read() fails, + * we dispatch the pending events and try again until we're successful. + * + * If the relevant queue is not the default queue, then + * wl_display_prepare_read_queue() and wl_display_dispatch_queue_pending() + * need to be used instead. * * \memberof wl_display */ @@ -1399,10 +1403,25 @@ wl_display_cancel_read(struct wl_display *display) * Dispatch all incoming events for objects assigned to the given * event queue. On failure -1 is returned and errno set appropriately. * - * This function blocks if there are no events to dispatch. If calling from - * the main thread, it will block reading data from the display fd. For other - * threads this will block until the main thread queues events on the queue - * passed as argument. + * The behaviour of this function is exactly the same as the behaviour of + * wl_display_dispatch(), but it dispatches events on given queue, + * not on the default queue. + * + * This function blocks if there are no events to dispatch (if there are, + * it only dispatches these events and returns immediately). + * When this function returns after blocking, it means that it read events + * from display's fd and queued them to appropriate queues. + * If among the incoming events were some events assigned to the given queue, + * they are dispatched by this moment. + * + * \note Since Wayland 1.5 the display has an extra queue + * for its own events (i. e. delete_id). This queue is dispatched always, + * no matter what queue we passed as an argument to this function. + * That means that this function can return non-0 value even when it + * haven't dispatched any event for the given queue. + * + * \sa wl_display_dispatch(), wl_display_dispatch_pending(), + * wl_display_dispatch_queue_pending() * * \memberof wl_display */ @@ -1499,15 +1518,15 @@ wl_display_dispatch_queue_pending(struct wl_display *display, * \param display The display context object * \return The number of dispatched events on success or -1 on failure * - * Dispatch the display's main event queue. + *
Re: [PATCH] Weston: fbdev: Remove uneeded semicolon
Hi, On 3 December 2014 at 03:07, nerdopolis bluescreen_aven...@verizon.net wrote: --- 0001-weston-fbdev-remove-uneeded-semicolon.patch | 33 +++ fd | 116 +++ We probably don't need these, either. ;) Instead of using git send-email directly, you can use git format-patch to generate a series of patches, check them over, and then call git send-email on the filenames generated by git format-patch. That can help things like this slipping in. The patch is trivially correct though, so I've merged it in. Thanks! Cheers, Daniel ___ 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
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. 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. Thanks for doing this! It's super-helpful, and magically resolves one of the things on my post-it TODO note. ;) Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/4] doc: Shut off second set of warnings from generating the man pages
On 12/02/2014 07:47 PM, Peter Hutterer wrote: On Tue, Dec 02, 2014 at 06:29:34PM -0800, Bill Spitzak wrote: These warnings are a duplicate of the first set --- doc/doxygen/Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index 83622af..fe6f300 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -42,6 +42,7 @@ man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) echo GENERATE_MAN=YES; \ echo MAN_OUTPUT=man; \ echo JAVADOC_AUTOBRIEF=NO; \ + echo WARN_IF_UNDOCUMENTED=NO; \ echo INPUT= $^; \ ) | doxygen - wouldn't it be better to document all bits rather than silencing the warnings? Yes it would, but I thought it would be nicer to not print the warnings twice. ___ 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 12/02/2014 07:45 PM, Peter Hutterer wrote: On Tue, Dec 02, 2014 at 06:29:33PM -0800, Bill Spitzak wrote: This requires doxygen 1.8 or newer. I could not figure out how to make configure.ac test the doxygen version number. It appears to be really complex. So it will run with any version of doxygen and the doc output is somewhat mangled. I'm missing the reasoning here: why not leave code/endcode? was this explained in some other thread? The main reason is the \comment does not seem to work in code/endcode, but works in the markdown. I also discovered that a code command breaks the tilde version (by making it not remove the asterisks), so you have to use all of one or the other consistently. Both of these are certainly Doxygen bugs. Another reason is that this is reverting a change I previously made. Some people may prefer the markdown/wiki style rather than commands, as it makes the comments more readable directly. Besides the tildes, the same recent versions support indentation by 4 spaces to indicate code, which is common in wiki markup. That may be another alternative. I'm not sure if this is all enough of a reason however. As pointed out by others this makes it not work with doxygen 1.8 and there are several systems that provide earlier versions by default, including Ubuntu LTS 12.04. And I noticed in some libinput patches just posted that code/endcode is used in them. Any opinions? I don't know which way is better. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] doc: Add config check for doxygen 1.8.0+.
Thanks! You know I tried searching for version in the autotools documents, but did not find this. That documentation is pretty incomplete. Note that as far as I can tell the only feature we are using is the tildes for code markup, and that is being questioned right now. On 12/02/2014 09:48 PM, Jon A. Cruz wrote: Add a config time check for a new enough (1.8.0+) version of doxygen. Signed-off-by: Jon A. Cruz j...@osg.samsung.com --- configure.ac | 8 1 file changed, 8 insertions(+) diff --git a/configure.ac b/configure.ac index 6f8220b..317cdae 100644 --- a/configure.ac +++ b/configure.ac @@ -109,6 +109,14 @@ if test x$enable_documentation = xyes; then AC_MSG_ERROR([Documentation build requested but doxygen not found. Install doxygen or disable the documentation using --disable-documentation]) fi + AC_MSG_CHECKING([for compatible doxygen version]) + doxygen_version=`$DOXYGEN --version` + AS_VERSION_COMPARE([$doxygen_version], [1.8.0], + [AC_MSG_RESULT([no]) + AC_MSG_ERROR([Doxygen $doxygen_version too old. Doxygen 1.8+ required for documentation build. Install required doxygen version or disable the documentation using --disable-documentation])], + [AC_MSG_RESULT([yes])], + [AC_MSG_RESULT([yes])]) + AC_PATH_PROG(XMLTO, xmlto) if test x$XMLTO = x; then ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] doc: Add config check for doxygen 1.8.0+.
I'd be fine with this being held off on. In general the next older version support to hold the line at would be 1.6.1 as that's what is in RHEL/CentOS/Scientific 6. That makes me think perhaps I should first submit this updated to start with a check for 1.6.0 and then leave bumping up to 1.8+ as a trivial follow-up when the time is proper. On 12/03/2014 12:39 PM, Bill Spitzak wrote: Thanks! You know I tried searching for version in the autotools documents, but did not find this. That documentation is pretty incomplete. Note that as far as I can tell the only feature we are using is the tildes for code markup, and that is being questioned right now. On 12/02/2014 09:48 PM, Jon A. Cruz wrote: Add a config time check for a new enough (1.8.0+) version of doxygen. Signed-off-by: Jon A. Cruz j...@osg.samsung.com --- configure.ac | 8 1 file changed, 8 insertions(+) diff --git a/configure.ac b/configure.ac index 6f8220b..317cdae 100644 --- a/configure.ac +++ b/configure.ac @@ -109,6 +109,14 @@ if test x$enable_documentation = xyes; then AC_MSG_ERROR([Documentation build requested but doxygen not found. Install doxygen or disable the documentation using --disable-documentation]) fi +AC_MSG_CHECKING([for compatible doxygen version]) +doxygen_version=`$DOXYGEN --version` +AS_VERSION_COMPARE([$doxygen_version], [1.8.0], + [AC_MSG_RESULT([no]) +AC_MSG_ERROR([Doxygen $doxygen_version too old. Doxygen 1.8+ required for documentation build. Install required doxygen version or disable the documentation using --disable-documentation])], + [AC_MSG_RESULT([yes])], + [AC_MSG_RESULT([yes])]) + AC_PATH_PROG(XMLTO, xmlto) if test x$XMLTO = x; then ___ 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/4] doc: Shut off second set of warnings from generating the man pages
On Wed, Dec 03, 2014 at 12:27:54PM -0800, Bill Spitzak wrote: On 12/02/2014 07:47 PM, Peter Hutterer wrote: On Tue, Dec 02, 2014 at 06:29:34PM -0800, Bill Spitzak wrote: These warnings are a duplicate of the first set --- doc/doxygen/Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index 83622af..fe6f300 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -42,6 +42,7 @@ man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) echo GENERATE_MAN=YES; \ echo MAN_OUTPUT=man; \ echo JAVADOC_AUTOBRIEF=NO; \ + echo WARN_IF_UNDOCUMENTED=NO; \ echo INPUT= $^; \ ) | doxygen - wouldn't it be better to document all bits rather than silencing the warnings? Yes it would, but I thought it would be nicer to not print the warnings twice. if it motivates anyone to fix it quicker then I'm all for printing it twice ;) ___ 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 Wed, Dec 03, 2014 at 12:37:40PM -0800, Bill Spitzak wrote: On 12/02/2014 07:45 PM, Peter Hutterer wrote: On Tue, Dec 02, 2014 at 06:29:33PM -0800, Bill Spitzak wrote: This requires doxygen 1.8 or newer. I could not figure out how to make configure.ac test the doxygen version number. It appears to be really complex. So it will run with any version of doxygen and the doc output is somewhat mangled. I'm missing the reasoning here: why not leave code/endcode? was this explained in some other thread? The main reason is the \comment does not seem to work in code/endcode, but what is \comment? I can't find it in the doxygen tag list. works in the markdown. I also discovered that a code command breaks the tilde version (by making it not remove the asterisks), so you have to use all of one or the other consistently. Both of these are certainly Doxygen bugs. Another reason is that this is reverting a change I previously made. Some people may prefer the markdown/wiki style rather than commands, as it makes the comments more readable directly. Besides the tildes, the same recent versions support indentation by 4 spaces to indicate code, which is common in wiki markup. That may be another alternative. I'm not sure if this is all enough of a reason however. As pointed out by others this makes it not work with doxygen 1.8 and there are several systems that provide earlier versions by default, including Ubuntu LTS 12.04. And I noticed in some libinput patches just posted that code/endcode is used in them. yeah, I've used code/endcode in libinput and libevdev but for no other reason than that was what google came up with when looking for it (I think it also pre-dates 1.8.1) Any opinions? I don't know which way is better. I'd say go with the one that's more compatible (code/endcode) and work around the lack of comment support. Cheers, Peter ___ 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 12/03/2014 01:49 PM, Peter Hutterer wrote: what is \comment? I can't find it in the doxygen tag list. That stumped me for a while, too. It's an alias defined in the wayland.doxygen file. As far as I can tell aliases are not really commands, they are instead more like macros. This explains why they work in the ~~~ while no other commands do. And it seems the code command does disable them. Possibly one of these is a bug. Any opinions? I don't know which way is better. I'd say go with the one that's more compatible (code/endcode) and work around the lack of comment support. Okay I think this patch should be dropped, and doxygen 1.8 is not required. I did some web searches, and the consensus is that Doxygen has done a great job of making it impossible to put a C-style comment into a code sample. Either use C++ comments (which is what I did), or maybe something can be done by the xslt translator (but it won't show up in the man pages). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/4] doc: Shut off second set of warnings from generating the man pages
Yea, ignore this patch. I think I can get Doxygen to produce both outputs in one pass, which will be faster and only produce one set of warnings. On 12/03/2014 01:42 PM, Peter Hutterer wrote: On Wed, Dec 03, 2014 at 12:27:54PM -0800, Bill Spitzak wrote: On 12/02/2014 07:47 PM, Peter Hutterer wrote: On Tue, Dec 02, 2014 at 06:29:34PM -0800, Bill Spitzak wrote: These warnings are a duplicate of the first set --- doc/doxygen/Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index 83622af..fe6f300 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -42,6 +42,7 @@ man/man3/wl_display.3: $(scanned_src_files_client) $(scanned_src_files_server) echo GENERATE_MAN=YES; \ echo MAN_OUTPUT=man; \ echo JAVADOC_AUTOBRIEF=NO; \ + echo WARN_IF_UNDOCUMENTED=NO; \ echo INPUT= $^; \ ) | doxygen - wouldn't it be better to document all bits rather than silencing the warnings? Yes it would, but I thought it would be nicer to not print the warnings twice. if it motivates anyone to fix it quicker then I'm all for printing it twice ;) ___ 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 Wed, Dec 03, 2014 at 02:20:50PM -0800, Bill Spitzak wrote: On 12/03/2014 01:49 PM, Peter Hutterer wrote: what is \comment? I can't find it in the doxygen tag list. That stumped me for a while, too. It's an alias defined in the wayland.doxygen file. As far as I can tell aliases are not really commands, they are instead more like macros. This explains why they work in the ~~~ while no other commands do. And it seems the code command does disable them. Possibly one of these is a bug. Any opinions? I don't know which way is better. I'd say go with the one that's more compatible (code/endcode) and work around the lack of comment support. Okay I think this patch should be dropped, and doxygen 1.8 is not required. I did some web searches, and the consensus is that Doxygen has done a great job of making it impossible to put a C-style comment into a code sample. doxygen is designed for source file commenting. you couldn't compile a nested C-style comment, doxygen doesn't come into effect here anyway. Cheers, Peter Either use C++ comments (which is what I did), or maybe something can be done by the xslt translator (but it won't show up in the man pages). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2] doc: Add config check for doxygen 1.6.0+.
Add a config time check for a new enough (1.6.0+) version of doxygen. v2. require 1.6.0+ instead of 1.8.0+ Signed-off-by: Jon A. Cruz j...@osg.samsung.com --- configure.ac | 8 1 file changed, 8 insertions(+) diff --git a/configure.ac b/configure.ac index 6f8220b..12dd94c 100644 --- a/configure.ac +++ b/configure.ac @@ -109,6 +109,14 @@ if test x$enable_documentation = xyes; then AC_MSG_ERROR([Documentation build requested but doxygen not found. Install doxygen or disable the documentation using --disable-documentation]) fi + AC_MSG_CHECKING([for compatible doxygen version]) + doxygen_version=`$DOXYGEN --version` + AS_VERSION_COMPARE([$doxygen_version], [1.6.0], + [AC_MSG_RESULT([no]) + AC_MSG_ERROR([Doxygen $doxygen_version too old. Doxygen 1.6+ required for documentation build. Install required doxygen version or disable the documentation using --disable-documentation])], + [AC_MSG_RESULT([yes])], + [AC_MSG_RESULT([yes])]) + AC_PATH_PROG(XMLTO, xmlto) if test x$XMLTO = x; then -- 1.9.1 ___ 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 12/03/2014 02:37 PM, Peter Hutterer wrote: I did some web searches, and the consensus is that Doxygen has done a great job of making it impossible to put a C-style comment into a code sample. doxygen is designed for source file commenting. you couldn't compile a nested C-style comment, doxygen doesn't come into effect here anyway. What I meant is there does not appear to be any way to get doxygen to print an asterisk and slash next to each other in the output if the input is inside a C comment. I did not expect a literal C comment to work. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput v2 1/2] Introduce unaccelerated motion event vectors
For certain applications (such as FPS games) it is necessary to use
unaccelerated motion events (the motion vector that is passed to the
acceleration filter) to get a more natural feeling. Supply this
information by passing both accelerated and unaccelerated motion
vectors to the existing motion event.
Note that the unaccelerated motion event is not equivalent to 'raw'
events as read from devices.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
Changes since v1:
Renamed non-accelerated to unaccelerated and don't abbreviate in the
public API.
Made the tested motion vectors longer in order to have the acceleration
to potentially affect it.
Improved documentation (assumes 1000 DPI patch has been applied).
For tests assuming valid accelerated motion vectors, wait for a motion
vector with a length more than zero.
Jonas
src/evdev-mt-touchpad-edge-scroll.c | 2 +-
src/evdev-mt-touchpad.c | 20 ++--
src/evdev-mt-touchpad.h | 4 +-
src/evdev.c | 19 ++--
src/libinput-private.h | 4 +-
src/libinput.c | 22 -
src/libinput.h | 42 +
test/pointer.c | 91 +
test/touchpad.c | 8 +++-
9 files changed, 188 insertions(+), 24 deletions(-)
diff --git a/src/evdev-mt-touchpad-edge-scroll.c
b/src/evdev-mt-touchpad-edge-scroll.c
index 1dca0ea..d68fc68 100644
--- a/src/evdev-mt-touchpad-edge-scroll.c
+++ b/src/evdev-mt-touchpad-edge-scroll.c
@@ -338,7 +338,7 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp, uint64_t
time)
}
tp_get_delta(t, dx, dy);
- tp_filter_motion(tp, dx, dy, time);
+ tp_filter_motion(tp, dx, dy, NULL, NULL, time);
if (fabs(*delta) t-scroll.threshold)
continue;
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 8f76ddb..15120da 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -58,13 +58,20 @@ tp_motion_history_offset(struct tp_touch *t, int offset)
void
tp_filter_motion(struct tp_dispatch *tp,
-double *dx, double *dy, uint64_t time)
+double *dx, double *dy,
+double *dx_unaccel, double *dy_unaccel,
+uint64_t time)
{
struct motion_params motion;
motion.dx = *dx * tp-accel.x_scale_coeff;
motion.dy = *dy * tp-accel.y_scale_coeff;
+ if (dx_unaccel)
+ *dx_unaccel = motion.dx;
+ if (dy_unaccel)
+ *dy_unaccel = motion.dy;
+
if (motion.dx != 0.0 || motion.dy != 0.0)
filter_dispatch(tp-device-pointer.filter, motion, tp, time);
@@ -426,7 +433,7 @@ tp_post_twofinger_scroll(struct tp_dispatch *tp, uint64_t
time)
dx /= nchanged;
dy /= nchanged;
- tp_filter_motion(tp, dx, dy, time);
+ tp_filter_motion(tp, dx, dy, NULL, NULL, time);
evdev_post_scroll(tp-device, time, dx, dy);
}
@@ -586,6 +593,7 @@ tp_post_events(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) {
@@ -617,10 +625,12 @@ tp_post_events(struct tp_dispatch *tp, uint64_t time)
return;
tp_get_delta(t, dx, dy);
- tp_filter_motion(tp, dx, dy, time);
+ tp_filter_motion(tp, dx, dy, dx_unaccel, dy_unaccel, time);
- if (dx != 0.0 || dy != 0.0)
- pointer_notify_motion(tp-device-base, time, dx, dy);
+ if (dx != 0.0 || dy != 0.0 || dx_unaccel != 0.0 || dy_unaccel != 0.0) {
+ pointer_notify_motion(tp-device-base, time,
+ dx, dy, dx_unaccel, dy_unaccel);
+ }
}
static void
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index b2603b4..da9c091 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -276,7 +276,9 @@ tp_set_pointer(struct tp_dispatch *tp, struct tp_touch *t);
void
tp_filter_motion(struct tp_dispatch *tp,
-double *dx, double *dy, uint64_t time);
+double *dx, double *dy,
+double *dx_unaccel, double *dy_unaccel,
+uint64_t time);
int
tp_tap_handle_state(struct tp_dispatch *tp, uint64_t time);
diff --git a/src/evdev.c b/src/evdev.c
index 908a8ba..1942539 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -198,6 +198,7 @@ evdev_flush_pending_event(struct evdev_device *device,
uint64_t time)
{
struct libinput *libinput = device-base.seat-libinput;
struct motion_params motion;
+ double dx_unaccel, dy_unaccel;
int32_t cx, cy;
int32_t x, y;
int slot;
@@ -211,8 +212,10 @@ evdev_flush_pending_event(struct
[PATCH libinput 2/2] test: Don't send two motion events when button scrolling
Button scrolling motion events don't pass through the acceleration filter so no need to assume the initial event will be absorbed. Signed-off-by: Jonas Ådahl jad...@gmail.com --- test/litest.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/test/litest.c b/test/litest.c index e2ec90d..2ab802b 100644 --- a/test/litest.c +++ b/test/litest.c @@ -810,12 +810,6 @@ litest_button_scroll(struct litest_device *dev, litest_timeout_buttonscroll(); libinput_dispatch(li); - /* Send two deltas, as the first one may be eaten up by an -* acceleration filter. */ - litest_event(dev, EV_REL, REL_X, dx); - litest_event(dev, EV_REL, REL_Y, dy); - litest_event(dev, EV_SYN, SYN_REPORT, 0); - litest_event(dev, EV_REL, REL_X, dx); litest_event(dev, EV_REL, REL_Y, dy); litest_event(dev, EV_SYN, SYN_REPORT, 0); -- 1.8.5.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] Always check for INVALID configs first
Always check for invalid input first, then check if the input is supported by
the actual device.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/libinput.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/libinput.c b/src/libinput.c
index 0d380fa..60505f6 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1462,12 +1462,12 @@ LIBINPUT_EXPORT enum libinput_config_status
libinput_device_config_accel_set_speed(struct libinput_device *device,
double speed)
{
- if (!libinput_device_config_accel_is_available(device))
- return LIBINPUT_CONFIG_STATUS_UNSUPPORTED;
-
if (speed -1.0 || speed 1.0)
return LIBINPUT_CONFIG_STATUS_INVALID;
+ if (!libinput_device_config_accel_is_available(device))
+ return LIBINPUT_CONFIG_STATUS_UNSUPPORTED;
+
return device-config.accel-set_speed(device, speed);
}
@@ -1576,9 +1576,6 @@ LIBINPUT_EXPORT enum libinput_config_status
libinput_device_config_scroll_set_method(struct libinput_device *device,
enum libinput_config_scroll_method
method)
{
- if ((libinput_device_config_scroll_get_methods(device) method) !=
method)
- return LIBINPUT_CONFIG_STATUS_UNSUPPORTED;
-
/* Check method is a single valid method */
switch (method) {
case LIBINPUT_CONFIG_SCROLL_NO_SCROLL:
@@ -1590,6 +1587,9 @@ libinput_device_config_scroll_set_method(struct
libinput_device *device,
return LIBINPUT_CONFIG_STATUS_INVALID;
}
+ if ((libinput_device_config_scroll_get_methods(device) method) !=
method)
+ return LIBINPUT_CONFIG_STATUS_UNSUPPORTED;
+
if (device-config.scroll_method)
return device-config.scroll_method-set_method(device, method);
else /* method must be _NO_SCROLL to get here */
@@ -1618,13 +1618,13 @@ LIBINPUT_EXPORT enum libinput_config_status
libinput_device_config_scroll_set_button(struct libinput_device *device,
uint32_t button)
{
- if ((libinput_device_config_scroll_get_methods(device)
-LIBINPUT_CONFIG_SCROLL_ON_BUTTON_DOWN) == 0)
- return LIBINPUT_CONFIG_STATUS_UNSUPPORTED;
-
if (button !libinput_device_has_button(device, button))
return LIBINPUT_CONFIG_STATUS_INVALID;
+ if ((libinput_device_config_scroll_get_methods(device)
+LIBINPUT_CONFIG_SCROLL_ON_BUTTON_DOWN) == 0)
+ return LIBINPUT_CONFIG_STATUS_UNSUPPORTED;
+
return device-config.scroll_method-set_button(device, button);
}
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput v2 1/2] Introduce unaccelerated motion event vectors
On Thu, Dec 04, 2014 at 11:44:09AM +0800, Jonas Ådahl wrote:
For certain applications (such as FPS games) it is necessary to use
unaccelerated motion events (the motion vector that is passed to the
acceleration filter) to get a more natural feeling. Supply this
information by passing both accelerated and unaccelerated motion
vectors to the existing motion event.
Note that the unaccelerated motion event is not equivalent to 'raw'
events as read from devices.
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
Changes since v1:
Renamed non-accelerated to unaccelerated and don't abbreviate in the
public API.
Made the tested motion vectors longer in order to have the acceleration
to potentially affect it.
Improved documentation (assumes 1000 DPI patch has been applied).
For tests assuming valid accelerated motion vectors, wait for a motion
vector with a length more than zero.
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
for both with a minor nitpick below.
src/evdev-mt-touchpad-edge-scroll.c | 2 +-
src/evdev-mt-touchpad.c | 20 ++--
src/evdev-mt-touchpad.h | 4 +-
src/evdev.c | 19 ++--
src/libinput-private.h | 4 +-
src/libinput.c | 22 -
src/libinput.h | 42 +
test/pointer.c | 91
+
test/touchpad.c | 8 +++-
9 files changed, 188 insertions(+), 24 deletions(-)
diff --git a/src/evdev-mt-touchpad-edge-scroll.c
b/src/evdev-mt-touchpad-edge-scroll.c
index 1dca0ea..d68fc68 100644
--- a/src/evdev-mt-touchpad-edge-scroll.c
+++ b/src/evdev-mt-touchpad-edge-scroll.c
@@ -338,7 +338,7 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp,
uint64_t time)
}
tp_get_delta(t, dx, dy);
- tp_filter_motion(tp, dx, dy, time);
+ tp_filter_motion(tp, dx, dy, NULL, NULL, time);
if (fabs(*delta) t-scroll.threshold)
continue;
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 8f76ddb..15120da 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -58,13 +58,20 @@ tp_motion_history_offset(struct tp_touch *t, int offset)
void
tp_filter_motion(struct tp_dispatch *tp,
- double *dx, double *dy, uint64_t time)
+ double *dx, double *dy,
+ double *dx_unaccel, double *dy_unaccel,
+ uint64_t time)
{
struct motion_params motion;
motion.dx = *dx * tp-accel.x_scale_coeff;
motion.dy = *dy * tp-accel.y_scale_coeff;
+ if (dx_unaccel)
+ *dx_unaccel = motion.dx;
+ if (dy_unaccel)
+ *dy_unaccel = motion.dy;
+
if (motion.dx != 0.0 || motion.dy != 0.0)
filter_dispatch(tp-device-pointer.filter, motion, tp, time);
@@ -426,7 +433,7 @@ tp_post_twofinger_scroll(struct tp_dispatch *tp, uint64_t
time)
dx /= nchanged;
dy /= nchanged;
- tp_filter_motion(tp, dx, dy, time);
+ tp_filter_motion(tp, dx, dy, NULL, NULL, time);
evdev_post_scroll(tp-device, time, dx, dy);
}
@@ -586,6 +593,7 @@ tp_post_events(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) {
@@ -617,10 +625,12 @@ tp_post_events(struct tp_dispatch *tp, uint64_t time)
return;
tp_get_delta(t, dx, dy);
- tp_filter_motion(tp, dx, dy, time);
+ tp_filter_motion(tp, dx, dy, dx_unaccel, dy_unaccel, time);
- if (dx != 0.0 || dy != 0.0)
- pointer_notify_motion(tp-device-base, time, dx, dy);
+ if (dx != 0.0 || dy != 0.0 || dx_unaccel != 0.0 || dy_unaccel != 0.0) {
+ pointer_notify_motion(tp-device-base, time,
+ dx, dy, dx_unaccel, dy_unaccel);
+ }
}
static void
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index b2603b4..da9c091 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -276,7 +276,9 @@ tp_set_pointer(struct tp_dispatch *tp, struct tp_touch
*t);
void
tp_filter_motion(struct tp_dispatch *tp,
- double *dx, double *dy, uint64_t time);
+ double *dx, double *dy,
+ double *dx_unaccel, double *dy_unaccel,
+ uint64_t time);
int
tp_tap_handle_state(struct tp_dispatch *tp, uint64_t time);
diff --git a/src/evdev.c b/src/evdev.c
index 908a8ba..1942539 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -198,6 +198,7 @@ evdev_flush_pending_event(struct evdev_device *device,
uint64_t time)
{
struct libinput *libinput = device-base.seat-libinput;
struct
