Re: [PATCH xwayland] Set the view to NULL when unmapping an X11 window

Ping :) On Fri, Nov 1, 2013 at 12:46 AM, Dima Ryazanov wrote: > Fixes a crash caused by accessing a deleted view in > weston_wm_window_schedule_repaint. It can be easily reproduced by switching > between menus in Firefox. > > Signed-off-by: Dima Ryazanov > --- > src/xwayland/window-manager.c

[PATCH] compositor-drm: Release the correct buffer in drm_output_release_fb

--- My knowledge of the DRM backend is rather small, so I don't know if this is really the right fix. I hit this when the the mode fails to set. See also compositor-drm.c:606 src/compositor-drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compositor-drm.c b/src/comp

[PATCH] input: Fix a segfault in focus checking

Without this, weston will segfault whenever the focus is a non-client surface such as the black surface in fullscreen. --- src/input.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/input.c b/src/input.c index 6637882..b6130d6 100644 --- a/src/input.c +++ b/src/input.c

[PATCH weston 3/5] input: let the pointer motion handlers move the pointer

this allows to implement pointer barriers by using a custom handler --- src/compositor.h | 6 +- src/data-device.c | 5 - src/input.c | 25 ++--- src/shell.c | 29 ++--- 4 files changed, 41 insertions(+), 24 deletions(-) diff --gi

[PATCH weston 1/5] input: add a motion signal to weston_pointer

The signal will be emitted after the pointer is moved. A shell plugin can listen to the signal and activate certain effects when the pointer touches the screen corners, for instance. --- src/compositor.h | 1 + src/input.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/src/compositor

[PATCH weston 2/5] zoom: use the new pointer motion signal to move the zoom frame.

--- src/compositor.h | 3 +++ src/input.c | 8 src/shell.c | 3 +-- src/zoom.c | 27 +++ 4 files changed, 31 insertions(+), 10 deletions(-) diff --git a/src/compositor.h b/src/compositor.h index 624d475..95928a4 100644 --- a/src/compositor.h +++

[PATCH weston 4/5] compositor: add a way to override the default pointer grab

--- src/compositor.c | 16 src/compositor.h | 11 ++- src/input.c | 18 +++--- 3 files changed, 41 insertions(+), 4 deletions(-) diff --git a/src/compositor.c b/src/compositor.c index c6cf682..4c37eb6 100644 --- a/src/compositor.c +++ b/src/compositor.c @

pointer motion signal and default grab handler override

Hi, this series implements two mechanisms to allow implementing things like hot corners in a shell plugin. It adds a signal to weston_pointer which gets firef when the pointer moves and adds a way to override the default grab. The motion handler is now in charge of calling weston_pointer_move() to

[PATCH weston 5/5] shell: override the default pointer grab interface

when a fullscreen surface hides the cursor, such as mpv, we must make sure that the cursor gets hidden also when it is over the underlying black surface. so check if the surface under the pointer is a black surface and focus on its parent surface instead. this results in sending pointer coordinates

Re: [PATCH weston 3/8] westoy: Use subsurfaces for tooltips instead of transient windows

Jasper St. Pierre wrote: Transients, as they existed in wl_shell_surface, have been removed from xdg_shell and aren't coming back. There is a new set_transient_for request, but it's more to provide something like the ICCCM WM_TRANSIENT_FOR property: associating modal dialogs with their "parent

Re: [PATCH weston 7/8] westoy: Schedule a full resize when we add a subsurface

Jasper St. Pierre wrote: It is not a bug in the compositor. It's a bug in toytoolkit. In that case this is fine. May want to put a comment in there as to why it is redrawing the parent window. Jasper St. Pierre wrote: If a client adds a subsurface, we need to make sure it's al

Re: [RFC v2] surface crop & scale protocol extension

Pekka Paalanen wrote: Yes, you cannot use non-integer surface sizes. You cannot express a surface size, that would result in a 1024x1024 area in output pixels, because 1024 is not divisible by output_scale=3. Thanks. That is indeed exactly the problem I am concerned about. This limitation ex

Re: [PATCH] xdg-shell - yet another proposal (this time for real).

Any proposal must merge in the fullscreen/maximized stuff which is really an instruction to remove decorations as well. I see no reason for clients to request whether they "prefer" csd. CSD will always be better, the only reason to "prefer" ssd is because the client can't do it, and you alread

Re: [PATCH] xdg-shell - yet another proposal (this time for real).

And as I explained on IRC, I don't want this in an initial dump. The motivation of this xdg_shell approach is to keep it small and land it now. We can add functionality later, but I'd rather not spend too much time in heated discussions on the list about client-side vs. server-side decorations. If

Re: [PATCH] xdg-shell - yet another proposal (this time for real).

Hello, There has been some discussions on IRC about the possible support of decoration side negociation in xdg_shell. A client would have to support CSD if it uses xdg_shell. And I suggested the folowing mechanism: .when binding to xdg_shell, the client gets an event telling him the compositor

Re: [RFC] Common input device library

I like the generalized architecture of any input handling as well. I didn't look into the code because I will hardly understand it yet. I also don't understand a lot yet but what I'd do is also some sort of dispatcher of the input object queue. I.e. when each device is watched by the wrapper which

[PATCH] Add documentation for wl_shm_buffer_begin/end_access

It's not obvious that these functions are needed so it would be good to have some documentation for them. --- doc/doxygen/Makefile.am | 3 ++- src/wayland-shm.c | 64 + 2 files changed, 66 insertions(+), 1 deletion(-) diff --git a/doc/doxygen

Re: [RFC v2] surface crop & scale protocol extension

On Wed, 13 Nov 2013 12:26:41 -0800 Bill Spitzak wrote: > Pekka Paalanen wrote: > > > Is your whole issue based on the premise, that the output resolution is > > not a multiple of output_scale? > > I think there is some serious confusion here. Everything here is a > multiple of everything else.

Re: [RFC v2] surface crop & scale protocol extension

On Wed, 13 Nov 2013 11:30:19 +0100 Alexander Larsson wrote: > On ons, 2013-11-13 at 11:54 +0200, Pekka Paalanen wrote: > > On Tue, 12 Nov 2013 16:14:36 -0800 > > Bill Spitzak wrote: > > > > > Pekka Paalanen wrote: > > > > > > >> The source rectangle *must* be in buffer pixels. Putting it in >