Re: [PATCH] Refine compositor grabs behavior

Hi, On 30 November 2015 at 23:20, Peter Hutterer wrote: > On Mon, Nov 30, 2015 at 09:56:16PM +, Daniel Stone wrote: >> On 23 November 2015 at 00:19, Peter Hutterer >> wrote: >> > double pointer case when split across frames: >> > p1.leave, p1.frame, *FOCUS OUT* \ >> > p2.leave, p2.frame *

Re: [PATCH libinput v9 0/2] add orientation, size and pressure of touch

On Wed, Nov 25, 2015 at 03:30:58PM +0100, Andreas Pokorny wrote: > Hi, > > On Tue, Nov 24, 2015 at 1:41 AM, Peter Hutterer > wrote: > > > On Mon, Nov 23, 2015 at 07:58:28PM +0100, Andreas Pokorny wrote: > > [...] > > > measured values on the e4.5 jumped a lot further. I need a more accurate > >

Re: black surface in desktop shell fullscreen mode

Hello all, Reading the mail thread, I tried to figure out the problem by myself. Until now, I couldn't find any reason to make fullscreen application totally opaque. As I found in git history, in my opinion, the author of fullscreen implementation just thought that fullscreen has black surface beh

Re: [PATCH wayland] protocol: specify behavior of get_pointer when capabilities change

On Mon, Nov 30, 2015 at 09:46:36PM +, Daniel Stone wrote: > Hi, > > On 30 November 2015 at 03:25, Peter Hutterer wrote: > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index f9e6d76..370fafc 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -1350,6 +

Re: [PATCH] Refine compositor grabs behavior

On Mon, Nov 30, 2015 at 09:56:16PM +, Daniel Stone wrote: > Hi, > > On 23 November 2015 at 00:19, Peter Hutterer wrote: > > double pointer case when split across frames: > > p1.leave, p1.frame, *FOCUS OUT* \ > > p2.leave, p2.frame *FOCUS OUT* \ > > p1.enter, p1.frame *FOCUS IN* \ > > p2

Re: [PATCH] main: Remove unused function load_backend_new()

On Mon, Nov 30, 2015 at 02:54:41PM -0600, Derek Foreman wrote: > On 30/11/15 02:51 PM, Chris Michael wrote: > > This function is unused throughout the entire weston source tree, so > > remove it. It seems that the "load_backend" function is the one > > currently being used > > > > Signed-off-by: C

Re: [PATCH] Refine compositor grabs behavior

Hi, On 23 November 2015 at 00:19, Peter Hutterer wrote: > double pointer case when split across frames: > p1.leave, p1.frame, *FOCUS OUT* \ > p2.leave, p2.frame *FOCUS OUT* \ > p1.enter, p1.frame *FOCUS IN* \ > p2.enter, p2.frame *FOCUS IN* > > double pointer case merged: > p1.leave, p1.ent

Re: [PATCH] Refine compositor grabs behavior

On Sun, Nov 22, 2015 at 4:19 PM, Peter Hutterer wrote: > > p1.leave, p2.leave, \ > p1.enter, p2.enter,\ > p1.frame *FOCUS TRANSITIONED*, p2.frame *FOCUS TRANSITIONED* > > we have the same issue where two surfaces are focused simultaneously though > at least in this case it's detectable. I don

Re: Lifetime of wl_seat objects (was Re: [PATCH wayland-protocols 1/2] Introduce wp_relative_pointer) interface

Hi, On 24 November 2015 at 06:39, Jonas Ådahl wrote: >> > Meh. This just spells out what weston does, and then asks clients not to >> > rely on it. Spelling it out that it might work I suspect will just >> > confuse users. >> >> I'm aware of that, but the important bit here is that *it spells it

Re: Lifetime of wl_seat objects (was Re: [PATCH wayland-protocols 1/2] Introduce wp_relative_pointer) interface

On 24 November 2015 at 00:21, Peter Hutterer wrote: > bad. in X we had cases where a client would run multiple versions of the > same protocol (the toolkit would support XI2.0, a toolkit plugin XI2.2). I > don't know whether that's likely to happen in wayland, but generally you > cannot define the

Re: [PATCH wayland] protocol: specify behavior of get_pointer when capabilities change

Hi, On 30 November 2015 at 03:25, Peter Hutterer wrote: > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index f9e6d76..370fafc 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1350,6 +1350,24 @@ > This is emitted whenever a seat gains or loses the pointe

Re: [RFC] Declare enumeration wl_output.transform as bitfield.

Hi, On 26 November 2015 at 14:47, Nils Chr. Brause wrote: > On Wed, Nov 25, 2015 at 10:01 PM, Bryce Harrington > wrote: >> On Wed, Nov 25, 2015 at 03:25:55PM +, Daniel Stone wrote: >>> Sure, we can fix Weston, and with a strict version requirement on the >>> protocol, we can make sure it doe

Re: Re: [PATCH 2/5] wayland-server: Add code docs for new display socket API's

On Mon, Nov 23, 2015 at 7:54 PM, 이상진 wrote: > >> Also (on the patch) it looks like if there is an error it destroys the > >> wl_socket object, could this do the wrong thing if the fd was supplied > from > >> outside? > > > So like if the socket object couldn't be initted or added to the display >

Re: [PATCH weston] compositor: change rounding in weston_surface_to_buffer_rect()

On 30/11/15 03:21 PM, Daniel Stone wrote: > Hi, > > On 30 November 2015 at 19:33, Derek Foreman wrote: >> Rounding both corners of the rectangle down can result in a 0 >> width/height rectangle before passing to weston_transformed_rect. >> >> This showed up as missing damage in weston-simple-dama

Re: [RFC] Screensaver/blanking inhibition

On Tue, Nov 24, 2015 at 10:46 AM, Bryce Harrington wrote: > > > Besides preventing blanking of only the correct output, this could also > > allow the compositor to show popup notifications when the compositor > knows > > they will not interfere with the surface. > > Not sure what you mean here -

Re: [PATCH weston] compositor: change rounding in weston_surface_to_buffer_rect()

Hi, On 30 November 2015 at 19:33, Derek Foreman wrote: > Rounding both corners of the rectangle down can result in a 0 > width/height rectangle before passing to weston_transformed_rect. > > This showed up as missing damage in weston-simple-damage (the > bouncing ball would leave green trails whe

Re: [PATCH] main: Remove unused function load_backend_new()

On 30/11/15 02:51 PM, Chris Michael wrote: > This function is unused throughout the entire weston source tree, so > remove it. It seems that the "load_backend" function is the one > currently being used > > Signed-off-by: Chris Michael That warning's been bugging me for a while - I think it's fo

[PATCH] main: Remove unused function load_backend_new()

This function is unused throughout the entire weston source tree, so remove it. It seems that the "load_backend" function is the one currently being used Signed-off-by: Chris Michael --- src/main.c | 17 - 1 file changed, 17 deletions(-) diff --git a/src/main.c b/src/main.c inde

[PATCH weston] compositor: change rounding in weston_surface_to_buffer_rect()

Rounding both corners of the rectangle down can result in a 0 width/height rectangle before passing to weston_transformed_rect. This showed up as missing damage in weston-simple-damage (the bouncing ball would leave green trails when --use-viewport was used) Also, add a big fat warning for users

Re: [PATCH weston 11/11] simple-damage: Add --use-buffer-damage flag

On 30/11/15 01:47 AM, Pekka Paalanen wrote: > On Fri, 27 Nov 2015 14:55:13 -0600 > Derek Foreman wrote: > >> On 27/11/15 07:47 AM, Pekka Paalanen wrote: >>> On Wed, 18 Nov 2015 16:32:34 -0600 >>> Derek Foreman wrote: >>> Add a new flag for testing damage in buffer co-ordinates

[PATCH wayland v5] protocol: Add wl_surface.damage_buffer

wl_surface.damage uses surface local co-ordinates. Buffer scale and buffer transforms came along, and EGL surfaces have no understanding of them. Theoretically, clients pass damage rectangles - in Y-inverted surface co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation passed them

Re: [PATCH weston 10/11] simple-damage: Offset drawing co-ordinates not buffer start

On 27/11/15 04:20 AM, Pekka Paalanen wrote: > On Wed, 18 Nov 2015 16:32:33 -0600 Derek Foreman > wrote: > >> We've been setting up the viewport by moving the start pointer of >> the draw buffer, but later when we want to post damage in buffer >> co-ordinates we'll need to keep track of the x,y of

[PATCH] compositor: Remove unused weston_surface_to_buffer function

The function 'weston_surface_to_buffer' is unused by compositor and clients inside weston, so it should be safe to remove this function Signed-off-by: Chris Michael --- src/compositor.c | 13 - src/compositor.h | 3 --- 2 files changed, 16 deletions(-) diff --git a/src/compositor.c