Touchpad on an XPS 13 9360

Hi! First, I hope that this is the correct place to post, as I'm not really a developer, but don't know where else to go. I'm running Ubuntu Gnome 16.10 and using the libinput that is packaged with Ubuntu. I *think* It's the 1.6 version, but I really don't know and that's actually one of my

Re: [PATCH weston v2] compositor-drm: Fix disabling cursor plane

On 13/04/17 03:23 PM, Daniel Stone wrote: Hi Derek, On 13 April 2017 at 21:11, Derek Foreman wrote: commit a7cba1d4cd4c9013c3ac6cb074fcb7842fb39283 changed the way the cursor plane is setup. Previously it was pre-emptively set disabled for the next frame, and that

Re: [PATCH weston v2] compositor-drm: Fix disabling cursor plane

Hi Derek, On 13 April 2017 at 21:11, Derek Foreman wrote: > commit a7cba1d4cd4c9013c3ac6cb074fcb7842fb39283 changed the way > the cursor plane is setup. Previously it was pre-emptively set > disabled for the next frame, and that would be changed at next > frame time if

[PATCH weston v2] compositor-drm: Fix disabling cursor plane

commit a7cba1d4cd4c9013c3ac6cb074fcb7842fb39283 changed the way the cursor plane is setup. Previously it was pre-emptively set disabled for the next frame, and that would be changed at next frame time if the cursor plane was to be used. It was changed to be disabled at plane assignment time. We

[PATCH weston] libweston-desktop/xdg-shell: Consolidate configure event sending

From: Quentin Glidic When switching a state twice in a row, we were overwriting the old value without setting it back, sending a wrong state to the client. Now we update our requested state, then check if we need to schedule a configure event, if we have one

[PATCH weston] compositor-drm: Fix disabling cursor plane

commit a7cba1d4cd4c9013c3ac6cb074fcb7842fb39283 changed the way the cursor plane is setup. Previously it was pre-emptively set disabled for the next frame, and that would be changed at next frame time if the cursor plane was to be used. It was changed to be disabled at plane assignment time. We

[PATCH v2 wayland 11/11] tests: Check for wrong fd delivery with zombie objects

Until recently, if an event attempting to deliver an fd to a zombie object was demarshalled after the object was made into a zombie, we leaked the fd and left it in the buffer. If another event attempting to deliver an fd to a live object was in that same buffer, the zombie's fd would be

[PATCH v2 wayland 08/11] client: Consume file descriptors destined for zombie proxies

We need to close file descriptors sent to zombie proxies to avoid leaking them, and perhaps more importantly, to prevent them from being dispatched in events on other objects (since they would previously be left in the buffer and potentially fed to following events destined for live proxies)

[PATCH v2 wayland 10/11] tests: Add a test for fd leaks on zombie objects

Until recently, if a client destroying a resource raced with the server generating an event on that resource that delivered a file descriptor, we would leak the fd. This tests for a leaked fd from that race condition. Signed-off-by: Derek Foreman --- Makefile.am

[PATCH v2 wayland 09/11] connection: Use wl_buffer_size() for all buffer size calculations

There were two places where we did the same calculation manually. Signed-off-by: Derek Foreman --- src/connection.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/connection.c b/src/connection.c index 2bfdd82..bd66e94 100644 ---

[PATCH v2 wayland 07/11] client: Replace the singleton zombie with bespoke zombies

Using the singleton zombie object doesn't allow us to posthumously retain object interface information, which makes it difficult to properly inter future events destined for the recently deceased proxy. Notably, this makes it impossible for zombie proxy destined file descriptors to be properly

[PATCH v2 wayland 05/11] client: Simplify some logic in queue_event

Both the blocks in this if/else clause do the same thing, so combine the comparisons into one. No functional change. Reviewed-by: Bryce Harrington Signed-off-by: Derek Foreman --- src/wayland-client.c | 5 + 1 file changed, 1 insertion(+), 4

[PATCH v2 wayland 04/11] connection: Make wl_closure_destroy() close fds of undispatched closures

When we have a closure that can't be dispatched for some reason, and it contains file descriptors, we must close those descriptors to prevent leaking them. Signed-off-by: Derek Foreman --- src/connection.c | 35 ---

[PATCH v2 wayland 06/11] util: Pass flags to map iterators

On the client side we're going to need to know if an object from the map is a zombie before we attempt to dereference it, so we need to pass this to the iterator. Signed-off-by: Derek Foreman --- src/wayland-private.h | 3 ++- src/wayland-server.c | 21

[PATCH v2 wayland 03/11] connection: Close fds from half demarshalled closures

If we fail to demarshal a closure we need to close any fds we've already removed from the buffer. The rest will be cleaned up when client_destroy results in a connection_flush. Signed-off-by: Derek Foreman --- src/connection.c | 5 + 1 file changed, 5 insertions(+)

[PATCH v2 wayland 00/11] Stop leaking file descriptors

Changes since the first edition: Moved the test cases to the end so they're not introduced in a failed state. Reworked the removal of the global zombie singleton patch - we now create a wl_zombie at proxy creation time and store the number of fds for each opcode in that. If no signature requires

[PATCH v2 wayland 01/11] connection: close_fds() should only remove fds it closed from the buffer

All current callers close all fds, so this has gone unnoticed, but if we close less than all fds with close_fds() we leak all the unclosed ones and ruin further event demarshalling. A future patch will close less than the full buffer's worth of fds, so this is now noticed. Signed-off-by: Derek

Re: [PATCH weston v3] ivi-shell: add_screen_remove_layer API

2017-03-02 9:47 GMT+01:00 Ucan, Emre (ADITG/SW1) : > It is analagous to layer_remove_surface API. > The API removes a layer from the render order > of the screen. > > v3: > add the new vfunc at the end of > the ivi_layout_interface struct. > > Signed-off-by: Emre Ucan

Re: [PATCH weston v3 0/3] Initial Xwayland window positioning, with XWM reordering

Hi Pekka, On 18 January 2017 at 13:37, Pekka Paalanen wrote: > having 20 patches from the series already merged, it is time to re-send the > remaining ones rebased. And now that Louis-Francis has had time to look at them more carefully, and me a little bit (this takes a

Re: [weston 0/8] Implement NET_WM_SYNC_REQUEST basic support

Hi Louis-Francis, On 11 April 2017 at 21:52, Louis-Francis Ratté-Boulianne wrote: > Implement NET_WM_SYNC_REQUEST protocol for throtting X11 window resizes > in Weston's XWM. We wait for the window to be drawn (by setting an > alarm on the sync counter) before configuring the