Re: [PATCH 0/5] Give the wayland backend an actual frame

We probably don't want to apply these just yet. There's problems with a few input and cursor setting things. I'll get it fixed and send out a new parch series next week sometime. Hopefully that series will also include pixman/SHM fallback (I almost have that done). In the mean time a review would

Re: Fwd: Re: [PATCH 0/2] Add New XWayland API

I suggest putting the XWayland API in a separate library. There's still many things to fix (handling of the cursor for example), and if we keep XWayland outside of the Xserver, I believe it's going to be easier to update the API, and eventually break it when it is needed. I've looked closer at

[PATCH weston] Fix some window frame related bugs

In a few places window frame functions were being called on windows without frames. Signed-off-by: Trevor McCort --- src/xwayland/window-manager.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c index

[PATCH 3/5] compositor-wayland: Add an actual frame around the compositor window

This adds a window frame with a close button. Similar to the X11 backend, The window supports dragging but not resizing. Signed-off-by: Jason Ekstrand --- configure.ac | 2 +- src/compositor-wayland.c | 411 ++- 2 files changed, 340 inse

[PATCH 2/5] gl-renderer: Add support for per-output multi-texture borders.

The first advantage of this new API is that it is per-output instead of global to the gl_renderer instance. This means that different windows can have different titles, different button states, etc. The new api also uses four textures (one for each side) instead of one. This allows you to draw r

Re: input handlig in separate thread

Ok! this sounds very promising this should decouple the rendering thread and the input handling thread. so i can set to the wl_seat client object a new queue and then pass this queue to wl_display_dispatch_queue call in the input thread. but one question to this: the documentation of wl_display_d

Re: input handlig in separate thread

Hi Bill, 2013/10/18 Bill Spitzak > Giulio Camuffo wrote: > >> And what is it that doesn't work? As a wild bet I'd say you probably >> want to look at wl_event_queue. >> See http://wayland.freedesktop.**org/docs/html/chap-Library.** >> html#sect-Library-Client

Re: input handlig in separate thread

You can move a client-side wayland object to a queue using the function void wl_proxy_set_queue(struct wl_proxy *proxy, struct wl_event_queue *queue). All the client-side objects are really wl_proxy, so you can safely cast them. If you move to a queue an object which creates new objects and dispatc

[PATCH 5/5] compositor-wayland: Flush the display on commit

This fixes the problem where animations will wait to play until input is recieved. In general, it also makes the backend far more responsive. Signed-off-by: Jason Ekstrand --- src/compositor-wayland.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/compositor-wayland.c b/src/composit

[PATCH 4/5] gl-renderer: Remove the renderer-global border support

This was only ever used by the wayland backend and is no longer used there. Signed-off-by: Jason Ekstrand --- src/gl-renderer.c | 173 +- src/gl-renderer.h | 4 -- 2 files changed, 1 insertion(+), 176 deletions(-) diff --git a/src/gl-rendere

[PATCH 3/5] compositor-wayland: Add an actual frame around the compositor window

This adds a window frame with a close button that supports dragging (but not resizing). Signed-off-by: Jason Ekstrand --- configure.ac | 2 +- src/compositor-wayland.c | 413 ++- 2 files changed, 342 insertions(+), 73 deletions(-) diff -

[PATCH 1/5] compositor-wayland: Rename structure members and make things more consistant

Signed-off-by: Jason Ekstrand --- src/compositor-wayland.c | 76 ++-- 1 file changed, 41 insertions(+), 35 deletions(-) diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c index 7b670d9..df487ad 100644 --- a/src/compositor-wayland.c +++ b/

[PATCH 2/5] gl-renderer: Add support for per-output multi-texture borders.

This new border API is sufficiently powerful border suffort for doing a full window frame. Signed-off-by: Jason Ekstrand --- src/gl-renderer.c | 132 -- src/gl-renderer.h | 39 2 files changed, 168 insertions(+), 3 deletions(-

[PATCH 0/5] Give the wayland backend an actual frame

This series of patches makes a few improvements to the wayland backend. The first three patches add an actual frame with a title and a close button. The fourth patch removes some now-unneeded code from the GL renderer. The final patch is a general performance improvement. Jason Ekstrand (5): c

Re: Fwd: Re: [PATCH 0/2] Add New XWayland API

On Sat, Oct 19, 2013 at 01:55:42PM +0200, Axel Davy wrote: > > On Sat, Oct 19, 2013 at 10:49:04AM +0200, Axel Davy wrote: > >> I've tried benchmarking AsyncSwap with the phoronix-test-suite, > >> and I was surprised to see a regression with Openarena and Xonotic. > >> According to dri devs, it is b

Re: Fwd: Re: [PATCH 0/2] Add New XWayland API

> On Sat, Oct 19, 2013 at 10:49:04AM +0200, Axel Davy wrote: >> I've tried benchmarking AsyncSwap with the phoronix-test-suite, >> and I was surprised to see a regression with Openarena and Xonotic. >> According to dri devs, it is because, since I do an exchange, the >> application >> is fullscreen

Re: Fwd: Re: [PATCH 0/2] Add New XWayland API

On Sat, Oct 19, 2013 at 10:49:04AM +0200, Axel Davy wrote: > I've tried benchmarking AsyncSwap with the phoronix-test-suite, > and I was surprised to see a regression with Openarena and Xonotic. > According to dri devs, it is because, since I do an exchange, the > application > is fullscreen and th

Fwd: Re: [PATCH 0/2] Add New XWayland API

Given the recent discussion on the xorg-devel mailing list, I think this new API shouldn't be merged within the X server. The clear goal of the xorg team is toward dri3, and I was told no patch enabling AsyncSwap for dri2 would be merged. To implement the Present extension and composite efficie