Re: [PATCH] xdg-shell: require that popups intersect with parent surfaces

On Thu, Dec 08, 2016 at 11:00:10AM -0500, Mike Blumenkrantz wrote: > some restrictions must be placed on this or else it becomes legal for > the compositor to place popups in unexpected locations > > Signed-off-by: Mike Blumenkrantz > --- >

Re: [RFC wayland-protocols] Color management protocol

Carsten Haitzler (The Rasterman) wrote: Hi, > but is the intent that compositors MUST support color management and > applications will fail entirely or fail to display even partly correctly if > compositor doesnt support color management or doesnt support the color > profile/space requested by

Re: [RFC wayland-protocols] Color management protocol

On Thu, 8 Dec 2016 17:32:37 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > > i'm curious... is the intent to make it requird that all compositors support > > color management (and thus have to support all the possible colorspaces > > defined)... or

Re: [RFC PATCH 0/8] Meson build system [for libinput this time]

On Thu, Dec 08, 2016 at 12:39:18PM +, Daniel Stone wrote: > Hey Peter, > > On 7 December 2016 at 22:33, Peter Hutterer wrote: > > On Tue, Nov 29, 2016 at 04:59:39PM +, Daniel Stone wrote: > >> [meson is like totally super duper] > > > > I tried the same for

Re: [RFC wayland] wayland-server: assert instead of posting events with wrong client objects

On 08/12/16 02:54 PM, Pekka Paalanen wrote: On Thu, 8 Dec 2016 13:28:41 -0600 Derek Foreman wrote: On 02/12/16 02:07 AM, Pekka Paalanen wrote: On Thu, 1 Dec 2016 17:19:41 -0600 Derek Foreman wrote: Check that all the objects in an event

Re: [RFC wayland] wayland-server: assert instead of posting events with wrong client objects

On Thu, 8 Dec 2016 13:28:41 -0600 Derek Foreman wrote: > On 02/12/16 02:07 AM, Pekka Paalanen wrote: > > On Thu, 1 Dec 2016 17:19:41 -0600 > > Derek Foreman wrote: > > > >> Check that all the objects in an event belong to the same client as >

[PATCH wayland v2] wayland-server: abort instead of posting events with wrong client objects

Check that all the objects in an event belong to the same client as the resource posting it. This prevents a compositor from accidentally mixing client objects and posting an event that causes a client to kill itself. It's intended that the compositor killing itself be easier to debug than the

Re: [RFC wayland] wayland-server: assert instead of posting events with wrong client objects

On 02/12/16 02:07 AM, Pekka Paalanen wrote: On Thu, 1 Dec 2016 17:19:41 -0600 Derek Foreman wrote: Check that all the objects in an event belong to the same client as the resource posting it. This prevents a compositor from accidentally mixing client objects and

[PATCH] xdg-shell: require that popups intersect with parent surfaces

some restrictions must be placed on this or else it becomes legal for the compositor to place popups in unexpected locations Signed-off-by: Mike Blumenkrantz --- unstable/xdg-shell/xdg-shell-unstable-v6.xml | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff

Re: [PATCH weston v4] libweston-desktop: fix stale ping when a wl_shell_surface is destroyed

On 08/12/2016 16:52, Giulio Camuffo wrote: 2016-12-08 16:46 GMT+01:00 Quentin Glidic : On 08/12/2016 16:20, Giulio Camuffo wrote: When sending a ping event to a surface using the wl_shell interface, if that surface is destroyed before we receive the pong we

Re: [PATCH weston v4] libweston-desktop: fix stale ping when a wl_shell_surface is destroyed

2016-12-08 16:46 GMT+01:00 Quentin Glidic : > On 08/12/2016 16:20, Giulio Camuffo wrote: >> >> When sending a ping event to a surface using the wl_shell interface, >> if that surface is destroyed before we receive the pong we will never >> receive it, even if the

Re: [PATCH weston v4] libweston-desktop: fix stale ping when a wl_shell_surface is destroyed

On 08/12/2016 16:20, Giulio Camuffo wrote: When sending a ping event to a surface using the wl_shell interface, if that surface is destroyed before we receive the pong we will never receive it, even if the client is actually responsive, since the interface does not exist anymore. So when the

Re: Proposal to add 'raise' and 'lower' to xdg-shell in wayland-protocols

Allowing clients to raise/lower has nothing to do with trust and everything to do with control. If clients can affect stacking, they can affect the compositor's window placement policy. Wayland is all about having the compositor be in absolute control of this to the point of clients having the

[PATCH weston v4] libweston-desktop: fix stale ping when a wl_shell_surface is destroyed

When sending a ping event to a surface using the wl_shell interface, if that surface is destroyed before we receive the pong we will never receive it, even if the client is actually responsive, since the interface does not exist anymore. So when the surface if destroyed pretend it's a pong and

[PATCH weston v3] libweston-desktop: fix stale ping when a wl_shell_surface is destroyed

When sending a ping event to a surface using the wl_shell interface, if that surface is destroyed before we receive the pong we will never receive it, even if the client is actually responsive, since the interface does not exist anymore. So when the surface if destroyed pretend it's a pong and

Re: [PATCH weston v5 30/42] compositor-drm: Introduce drm_output_state structure

On 08/12/16 13:58, Daniel Stone wrote: > Hi Fabien, > > On 21 November 2016 at 14:58, Fabien DESSENNE wrote: >> On 11/16/2016 03:25 PM, Daniel Stone wrote: >>> +/** >>> + * Mark a drm_output_state (the output's last state) as complete. This >>> handles >>> + * any

Re: [PATCH weston v5 30/42] compositor-drm: Introduce drm_output_state structure

Hi Fabien, On 21 November 2016 at 14:58, Fabien DESSENNE wrote: > On 11/16/2016 03:25 PM, Daniel Stone wrote: >> +/** >> + * Mark a drm_output_state (the output's last state) as complete. This >> handles >> + * any post-completion actions such as updating the repaint

Re: [RFC PATCH 0/8] Meson build system [for libinput this time]

Hey Peter, On 7 December 2016 at 22:33, Peter Hutterer wrote: > On Tue, Nov 29, 2016 at 04:59:39PM +, Daniel Stone wrote: >> [meson is like totally super duper] > > I tried the same for libinput, work available in > https://github.com/whot/libinput/tree/wip/meson >

Re: [PATCH weston v2] libweston-desktop: don't crash when getting the pid for X clients

On 08/12/2016 09:21, Giulio Camuffo wrote: X client's don't have a wl_client associated with their weston_desktop_client, so make sure to not use it. Signed-off-by: Giulio Camuffo Pushed: 2295a62..f15320f master -> master Thanks, --- v2: use -1 as the pid unset

Re: [PATCH weston v2] libweston-desktop: don't crash when getting the pid for X clients

On 08/12/2016 09:21, Giulio Camuffo wrote: X client's don't have a wl_client associated with their weston_desktop_client, so make sure to not use it. Signed-off-by: Giulio Camuffo Perfect: Reviewed-by: Quentin Glidic Cheers, --- v2:

[PATCH weston v2] libweston-desktop: don't crash when getting the pid for X clients

X client's don't have a wl_client associated with their weston_desktop_client, so make sure to not use it. Signed-off-by: Giulio Camuffo --- v2: use -1 as the pid unset value, and initialize the pid to 0 for xwayland surfaces. This means the branch where we use the