Re: [PATCH 3/6] cairo-util: Kill a duplicate test

On Mon, Apr 28, 2014 at 11:19:29AM -0400, Jasper St. Pierre wrote: > If !(x < margin), then clearly margin <= x. No need to test for it again. Yep, this looks correct, and clearer logic. Reviewed-by: Bryce Harrington > --- > shared/cairo-util.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 del

Re: [PATCH 1/6] compositor: Fix the documentation for surface->configure

On Mon, Apr 28, 2014 at 11:19:27AM -0400, Jasper St. Pierre wrote: > It's called on commit, not on attach. Additionally, correct the > interface name to be wl_surface, not surface. > --- > src/compositor.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/compositor

[PATCH libinput v2] evdev-mt-touchpad: check calloc result

Check the value returned by calloc. Signed-off-by: Carlos Olmedo Escobar --- src/evdev-mt-touchpad.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c index 6355364..109441d 100644 --- a/src/evdev-mt-touchpad.c +++ b/src/evdev-mt-touchpad.c @

[PATCH] Wrong bo handles can be referenced in func call, drmModeAddFB2 due to uninitialized array elements in handles[4]

Need all bo handles in the array, handles[4] to be initialized with integer value that indicates "NOT VALID handle" to prevent any of those uninitialized from being processed as "VALID" handles. If any of these incorrect handles are passed to the Kernel, it either returns error saying "invalid

Re: [PATCH libinput v2] evdev-mt-touchpad: check calloc result

On Wed, Apr 23, 2014 at 01:03:33PM +0200, Carlos Olmedo Escobar wrote: > Check the value returned by calloc. sorry for the delay, still catching up on emails. we use signed-off-by tags in libinput. If I can have yours for this patch, I'll push it out asap, thanks. Cheers, Peter > --- > src/e

[PATCH] terminal: Convert all *alloc's to x*alloc's.

This ensures the allocation results are checked for NULL (out of memory), and terminates the program in such a case. Signed-off-by: Bryce Harrington --- clients/terminal.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/clients/terminal.c b/clients/terminal.c index 5

Re: [PATCH 3/3] clients: Check zalloc return for out of memory situation

On Thu, Apr 24, 2014 at 04:26:20PM +0300, Pekka Paalanen wrote: > On Mon, 21 Apr 2014 23:51:03 + > "Bryce W. Harrington" wrote: > > terminal = xzalloc(sizeof *terminal); > > + if (terminal == NULL) > > + return NULL; > > No need to check 'terminal', xzalloc() will exit() if it

Re: [PATCH libinput] Name-space the scroll event types

On Mon, Apr 28, 2014 at 02:55:24PM +0200, Hans de Goede wrote: > Hi, > > On 04/28/2014 07:38 AM, Peter Hutterer wrote: > > To provide a generic naming system of type_direction. That will become more > > important once we add new axes as part of the ongoing work to support > > graphics > > tablets

[PATCH 2/6] compositor: Remove the edges parameter from send_configure

send_configure was originally modelled after wl_shell_surface::send_configure, which takes these arguments. However, the X WM and xdg_surface::configure variants don't use these arguments. We already store the resize edges for a surface while it's being resized, so just use the saved state in the

[PATCH 3/6] cairo-util: Kill a duplicate test

If !(x < margin), then clearly margin <= x. No need to test for it again. --- shared/cairo-util.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/shared/cairo-util.c b/shared/cairo-util.c index 3948572..a1568ff 100644 --- a/shared/cairo-util.c +++ b/shared/cairo-util.c @@ -

[PATCH 1/6] compositor: Fix the documentation for surface->configure

It's called on commit, not on attach. Additionally, correct the interface name to be wl_surface, not surface. --- src/compositor.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/compositor.h b/src/compositor.h index 03d8992..c913f54 100644 --- a/src/compositor.h +++ b/

[PATCH 4/6] cairo-util: Don't show a resize cursor on edges when we're maximized

This is substantially confusing to users, namely me. --- shared/cairo-util.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/shared/cairo-util.c b/shared/cairo-util.c index a1568ff..a77d0b6 100644 --- a/shared/cairo-util.c +++ b/shared/cairo-util.c @@ -487,11 +487

[PATCH 5/6] window: Clean up buffer type choosing

Extracting it to a function makes this cleaner and more understandable. --- clients/window.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/clients/window.c b/clients/window.c index e2f7010..d822af7 100644 --- a/clients/window.c +++ b/clients/window.c @@

[PATCH 6/6] window: Add a simple getenv to force SHM rendering

--- clients/window.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/clients/window.c b/clients/window.c index d822af7..3897440 100644 --- a/clients/window.c +++ b/clients/window.c @@ -4338,11 +4338,11 @@ surface_create(struct window *window) return surface; } -s

[PATCH weston] screen-share: Set new environment variable to identify server display

Some background on this: I am writing a fullscreen shell implementation to share Wayland displays over VNC, which can be launched in place of weston from weston's screen-share module. In screen-share, variables WAYLAND_DISPLAY and WAYLAND_SOCKET are removed from the environment when launching the

Re: [PATCH libinput] Name-space the scroll event types

Hi, On 04/28/2014 07:38 AM, Peter Hutterer wrote: > To provide a generic naming system of type_direction. That will become more > important once we add new axes as part of the ongoing work to support graphics > tablets. > > Signed-off-by: Peter Hutterer Looks good: Reviewed-by: Hans de Goede

Re: Deep Color support

On Mon, 28 Apr 2014 10:30:02 +0300 Pekka Paalanen wrote: > Oh, that's the DRM set-master related thing. Once we move on to render > nodes, you don't even need a VT to simply work on the GPU, let alone a > display server. IOW, render nodes will just fix that, and you can use > the GPU for computat

Re: Question about multi-display on wayland protocol

On Mon, 28 Apr 2014 07:17:06 + Yang Andy wrote: > To: Pekka > > Thank you very much for your reply. > > > what exactly do you want to do, what is the use case? > > Is it for desktop or some non-desktop (e.g. phone, STB or IVI) environment? > > I am developing a IVI software which use wayl

Re: Deep Color support

On Mon, 28 Apr 2014 01:42:43 +0200 Wolfgang Draxinger wrote: > On Sun, 27 Apr 2014 18:25:45 +0300 > Pekka Paalanen > wrote: > > > I guess I just don't understand what "switching X11 servers" means > > here. > > It means, that if you have multiple X11 servers running on the same > machine, each

RE: Question about multi-display on wayland protocol

To: Pekka Thank you very much for your reply. > what exactly do you want to do, what is the use case? > Is it for desktop or some non-desktop (e.g. phone, STB or IVI) environment? I am developing a IVI software which use wayland protocal. > Would the maximize/fullscreen protocol with the set_