[PATCH 2/6] gl-renderer: introduce a new struct dmabuf_image

This struct serves as renderer data for linux-dmabuf buffers, and can contain multiple struct egl_image, simplifying this latter in the common non-dmabuf case. Signed-off-by: Emmanuel Gil Peyrot Reviewed-by: Pekka Paalanen

Re: [RFC] Screensaver/blanking inhibition

On 24/11/15 12:46 PM, Bryce Harrington wrote: > On Mon, Nov 23, 2015 at 11:51:07AM -0800, Bill Spitzak wrote: >> I now agree that tying the inhibit to a surface is exactly the right thing >> to do. >> >> Besides preventing blanking of only the correct output, this could also >> allow the

Re: [PATCH] install pkg-config file to arch-independent location

On Sun, Nov 22, 2015 at 08:51:27PM +0100, Igor Gnatenko wrote: > It is arch-independent, so no need to install it to /usr/lib* > > Cc: Jonas Ådahl > Signed-off-by: Igor Gnatenko > Reviewed-by: Quentin Glidic Seems

Re: [RFC wayland-protocols v2] Add screensaver inhibition protocol

On Wed, Nov 25, 2015 at 08:09:16AM +0100, Michal Suchanek wrote: > Hello > > On 25 November 2015 at 07:49, Bryce Harrington wrote: > > This interface allows disabling of screensaver/screenblanking on a > > per-surface basis. As long as the surface remains visible and > >

Re: [RFC] Screensaver/blanking inhibition

On Tue, 24 Nov 2015 14:42:04 -0600 Derek Foreman wrote: > On 24/11/15 12:46 PM, Bryce Harrington wrote: > > > > I'm trying to think of a use case where you have, say, a dual head > > configuration, and are watching something on one monitor but providing > > no input for

Re: [PATCH wayland-protocols] xdg_shell: add missing tags to the 'state' enum entries

On Tue, Nov 10, 2015 at 07:08:26AM +1000, Peter Hutterer wrote: > On Mon, Nov 09, 2015 at 11:14:32AM -0600, Derek Foreman wrote: > > On 08/11/15 09:58 PM, Peter Hutterer wrote: > > > The scanner parses CDATA in but lets it disappear otherwise. To > > > have > > > descriptive text associated with

Re: [PATCH 1/6] linux-dmabuf: Move the attributes part of linux_dmabuf_buffer into its own struct

On Tue, Nov 24, 2015 at 07:28:24PM +, Emmanuel Gil Peyrot wrote: > This allows renderers to use that struct to create their own dmabufs, > in case they can’t import the one provided by the client directly but > know how to convert it into a format they can render. > > Signed-off-by: Emmanuel

[RFC wayland-protocols v2] Add screensaver inhibition protocol

This interface allows disabling of screensaver/screenblanking on a per-surface basis. As long as the surface remains visible and non-occluded it blocks the screensaver, etc. from activating on the output(s) that the surface is visible on. To uninhibit, simply destroy the inhibitor object.

[RFC wayland-protocols v2] Screensaver/blanking inhibition

A "screensaver inhibition protocol" is on the set of needed enhancements for Wayland. This should turn off screen blanking and any running screensaver for a period, then re-enabling it later. An obvious use case is giving presentations. Other use cases include games, kiosk, automotive

Re: [RFC wayland-protocols v2] Add screensaver inhibition protocol

Hello On 25 November 2015 at 07:49, Bryce Harrington wrote: > This interface allows disabling of screensaver/screenblanking on a > per-surface basis. As long as the surface remains visible and > non-occluded it blocks the screensaver, etc. from activating on the >

[ANNOUNCE] wayland-protocols 1.0

The first release of wayland-protocols, version 1.0, is now available. wayland-protocols contains protocols and protocol extensions complementing the Wayland core protocol with additional functionality. As of this release, projects can start to add a build time dependency on wayland-protocols and

[PATCH v2 weston] compositor-drm: Use view transform in cursor plane setup

Make sure a view's transform is viable for a cursor plane and then actually apply it before setting the cursor plane location. Now if a subsurface ends up in the cursor plane, the plane will be properly positioned. Signed-off-by: Derek Foreman --- Change from V1: Reject

Re: [PATCH] Introduce the authorizer protocol

On 24/11/15 09:16 AM, Giulio Camuffo wrote: > This new extension is used by clients wanting to execute priviledged > actions such as taking a screenshot. > The usual way of granting special priviledged to apps is to fork and > exec them in the compositor, and then checking if the client is the >

Re: [PATCH] Introduce the authorizer protocol

2015-11-24 18:16 GMT+02:00 Mariusz Ceier : > Hi, > How the clients will know: > a) which interface is restricted and which is not ? It doesn't, but does it need to know it? It can still ask for authorization even if the interface is not. > b) that the compositor

Re: [PATCH] Introduce the authorizer protocol

Hi, On 24 November 2015 at 17:35, Giulio Camuffo wrote: > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier : > > Hi, > > How the clients will know: > > a) which interface is restricted and which is not ? > > It doesn't, but does it need to know it?

Re: [PATCH] Introduce the authorizer protocol

Hi, How the clients will know: a) which interface is restricted and which is not ? b) that the compositor implements restricted interface ? should they be visible in the registry ? If the client would like to use many restricted interfaces, it would have to issue multiple authorize requests -

Re: [PATCH v2 weston] compositor-drm: Use view transform in cursor plane setup

On 24 November 2015 at 17:39, Derek Foreman wrote: > Make sure a view's transform is viable for a cursor plane and > then actually apply it before setting the cursor plane location. > > Now if a subsurface ends up in the cursor plane, the plane will be > properly

Re: [PATCH v2 weston] compositor-drm: Use view transform in cursor plane setup

On 24/11/15 12:00 PM, Daniel Stone wrote: > On 24 November 2015 at 17:39, Derek Foreman wrote: >> Make sure a view's transform is viable for a cursor plane and >> then actually apply it before setting the cursor plane location. >> >> Now if a subsurface ends up in the

[PATCH 1/6] linux-dmabuf: Move the attributes part of linux_dmabuf_buffer into its own struct

This allows renderers to use that struct to create their own dmabufs, in case they can’t import the one provided by the client directly but know how to convert it into a format they can render. Signed-off-by: Emmanuel Gil Peyrot Reviewed-by: Pekka Paalanen

[PATCH 3/6] gl-renderer: Add support for a few YUV dmabuf formats

Namely the single-planar YUYV, the two-planar NV12, and the three-planar YUV420, using the shaders already present in Weston. Signed-off-by: Emmanuel Gil Peyrot Maniphest Tasks: T13 Differential Revision: https://phabricator.freedesktop.org/D334 ---

[PATCH 5/6] clients: Fix a few issues in simple-dmabuf-intel

Those were found while working on simple-dmabuf-v4l, as found in the next patch of this series. After each buffer’s params were ready to be submitted to the compositor, a roundtrip was done, which is wasteful since we can do it only once after having queued all the params we want. Removing those

[PATCH 4/6] clients: rename simple-dmabuf into simple-dmabuf-intel

This client was using an Intel-specific way to allocate a dmabuf, so it makes sense to have that in its name. Signed-off-by: Emmanuel Gil Peyrot Reviewed-by: Pekka Paalanen Reviewed-by: Daniel Stone

[PATCH 0/6] Add YUV formats support to dmabuf, and a v4l2 client

This series makes the gl-renderer accept the YUYV, NV12 and YUV420 dmabuf formats using the existing shader path. There is no implementation in pixman-renderer, nor any drm passthrough in case the hardware supports this. It also adds a new client, weston-simple-dmabuf-v4l, which retrieves dmabuf

[PATCH 6/6] clients: add simple-v4l-dmabuf client

This client opens a V4L2 device, usually exposed as /dev/videoN, and retrieves its frames as dmabuf for later import into the compositor. It supports both single- and multi-planar devices, and any format exposed by the V4L2 device the Wayland compositor accepts. This client never changes the

Re: [PATCH weston] Fix runtime error caused by missing header inclusion

On Tue, Nov 17, 2015 at 07:32:20AM +, Joh, Yong-Il (Tolkien) wrote: > Hi Daniel. > > here it is. :-) > > thank you. > __ > Yong-iL Joh, Sr.MTS, Wind River  Thanks, applied and pushed: 6172c38..cd9bb71 master -> master > > -Original Message- > From: Daniel Stone

xdg-shell's set_parent method

Hi, xdg-shell's set_parent [1] request is used by toolkits and compositors to achieve what is done with transients in X11. But the ICCCM in X11 allows for transients to be "None", in which case the dialog will be treated as a transient for the group by most X11 window managers. Some

Re: [PATCH weston v3] drm: port the drm backend to the new init api

2015-11-20 11:38 GMT+02:00 Quentin Glidic : > For now, I will just comment on the part I am not too happy with. > > On 31/10/2015 12:08, Giulio Camuffo wrote: >> >> [snip] >> >> diff --git a/src/main.c b/src/main.c >> index 292f8e0..bde27ee 100644 >> ---

[PATCH] Introduce the authorizer protocol

This new extension is used by clients wanting to execute priviledged actions such as taking a screenshot. The usual way of granting special priviledged to apps is to fork and exec them in the compositor, and then checking if the client is the known one when it binds the restricted global

Re: [RFC] Screensaver/blanking inhibition

I now agree that tying the inhibit to a surface is exactly the right thing to do. 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. I also think there is no

Re: [PATCH weston] compositor-drm: Use view transform in cursor plane setup

Hi, On 23 November 2015 at 22:33, Derek Foreman wrote: > diff --git a/src/compositor-drm.c b/src/compositor-drm.c > index a84d869..d872dd0 100644 > --- a/src/compositor-drm.c > +++ b/src/compositor-drm.c > @@ -1095,6 +1095,8 @@ drm_output_prepare_cursor_view(struct

Re: [PATCH v3 wayland 1/2] protocol: Add wl_surface.damage_buffer

You are correct that it is equally valid to convert buffer_damage coordinates to surface coordinates and store the union of those. More importantly, I think you are correct that the "new" transform should be used. Ideally the last transform the client sent (even though it is not committed yet). I

Re: Changing wl_output.transform type to unsigned?

On Mon, Nov 16, 2015 at 11:46 AM, Pekka Paalanen wrote: > On Sun, 15 Nov 2015 22:17:38 +0100 > "Nils Chr. Brause" wrote: > >> On Sun, Nov 15, 2015 at 9:48 PM, Auke Booij wrote: >> > On 9 November 2015 at 18:17, Bill Spitzak

Re: Changing wl_output.transform type to unsigned?

On 24 November 2015 at 12:41, Nils Chr. Brause wrote: > On Mon, Nov 16, 2015 at 11:46 AM, Pekka Paalanen wrote: >> On Sun, 15 Nov 2015 22:17:38 +0100 >> "Nils Chr. Brause" wrote: >> >>> On Sun, Nov 15, 2015 at 9:48 PM, Auke

Re: Changing wl_output.transform type to unsigned?

On Tue, Nov 24, 2015 at 01:41:03PM +0100, Nils Chr. Brause wrote: > On Mon, Nov 16, 2015 at 11:46 AM, Pekka Paalanen wrote: > > On Sun, 15 Nov 2015 22:17:38 +0100 > > "Nils Chr. Brause" wrote: > > > >> On Sun, Nov 15, 2015 at 9:48 PM, Auke Booij