On Tue, 10 Jul 2018 18:58:41 +0100
Daniel Stone wrote:
> When the sprites_are_broken variable is set, do not attempt to promote
> client surfaces to the scanout plane.
>
> We are currently assuming that every client buffer will be compatible
> with the scanout plane, but that is not the case,
On Wed, 11 Jul 2018 12:21:07 +0300
Pekka Paalanen wrote:
> On Tue, 10 Jul 2018 18:58:42 +0100
> Daniel Stone wrote:
>
> > Add support for multiple modes to drm_output_propose_state. Currently we
> > intend to operate in three modes: planes-only (no renderer buffer,
> > client buffers in planes
Adding more people to CC.
On Tue, 10 Jul 2018 17:53:15 +0200
Emilio Pozuelo Monfort wrote:
> No need to write libdrm driver specific code for each supported
> driver, we can just let GBM call the right one for us now.
>
> Signed-off-by: Emilio Pozuelo Monfort
> ---
>
> Hi,
>
> This
Hi,
On Tue, Jul 10, 2018 at 05:53:15PM +0200, Emilio Pozuelo Monfort wrote:
> No need to write libdrm driver specific code for each supported
> driver, we can just let GBM call the right one for us now.
>
> Signed-off-by: Emilio Pozuelo Monfort
> ---
>
> Hi,
>
> This simplifies the code a lot,
Hi,
On Wed, 11 Jul 2018 at 09:16, Pekka Paalanen wrote:
> On Tue, 10 Jul 2018 17:53:15 +0200 Emilio Pozuelo Monfort
> wrote:
> > No need to write libdrm driver specific code for each supported
> > driver, we can just let GBM call the right one for us now.
> >
> > Signed-off-by: Emilio Pozuelo
On Tue, 10 Jul 2018 18:58:42 +0100
Daniel Stone wrote:
> Add support for multiple modes to drm_output_propose_state. Currently we
> intend to operate in three modes: planes-only (no renderer buffer,
> client buffers in planes only), mixed-mode (promote client buffers to
> planes where possible,
On Tue, 10 Jul 2018 at 18:59, Daniel Stone wrote:
> @@ -3388,7 +3414,18 @@ drm_output_propose_state(struct weston_output
> *output_base,
> pixman_region32_fini(_region);
> pixman_region32_fini(_region);
>
> + /* Check to see if this state will actually work. */
> +
Hi Pekka,
On Wed, 11 Jul 2018 at 10:21, Pekka Paalanen wrote:
> On Tue, 10 Jul 2018 18:58:42 +0100 Daniel Stone wrote:
> > @@ -3339,13 +3347,16 @@ drm_output_propose_state(struct weston_output
> > *output_base,
> > next_plane = primary;
> >
On Tue, 10 Jul 2018 18:58:44 +0100
Daniel Stone wrote:
> The atomic API can allow us to test state before we apply it, to see if
> it will be valid. Use this when we construct a plane configuration, to
> see if it has a chance of ever working. If not, we can fail
> assign_planes early.
>
> This
Hi,
On Wed, 11 Jul 2018 at 11:20, Pekka Paalanen wrote:
> On Tue, 10 Jul 2018 18:58:44 +0100 Daniel Stone wrote:
> > @@ -2610,9 +2612,16 @@ drm_pending_state_apply_atomic(struct
> > drm_pending_state *pending_state,
> > case DRM_STATE_APPLY_ASYNC:
> > flags |=
On Tue, 10 Jul 2018 18:58:43 +0100
Daniel Stone wrote:
> Return a pointer to the plane state, rather than returning its
> underlying weston_plane.
>
> Signed-off-by: Daniel Stone
> Tested-by: Emre Ucan
> ---
> libweston/compositor-drm.c | 53 ++
> 1 file
On Wed, 11 Jul 2018 10:31:09 +0100
Daniel Stone wrote:
> Hi Pekka,
> On Wed, 11 Jul 2018 at 10:21, Pekka Paalanen wrote:
> > On Tue, 10 Jul 2018 18:58:42 +0100 Daniel Stone
> > wrote:
> > > @@ -3339,13 +3347,16 @@ drm_output_propose_state(struct weston_output
> > > *output_base,
> > >
Return a pointer to the plane state, rather than returning its
underlying weston_plane.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 63 +++---
1 file changed, 31 insertions(+), 32 deletions(-)
diff --git a/libweston/compositor-drm.c
Now that we can sensibly test proposed plane configurations with atomic,
sprites are not broken.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
---
libweston/compositor-drm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
Add support for multiple modes to drm_output_propose_state. Currently we
intend to operate in three modes: planes-only (no renderer buffer,
client buffers in planes only), mixed-mode (promote client buffers to
planes where possible, falling back to the renderer where not), and
renderer-only (no
Since we now incrementally test atomic state as we build it, we can
loosen restrictions on what we can do with planes, and let the kernel
tell us whether or not it's OK.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
---
libweston/compositor-drm.c | 20
1 file
In the plane-only mode, we try to place every view on a hardware plane,
and fail if we can't do this. This requires a full walk of the scene
graph to come up with a complete configuration in order to be able to
test.
In mixed mode, we know at least some visible views will fail to be
promoted to
When the sprites_are_broken variable is set, do not attempt to promote
client surfaces to the scanout plane.
We are currently assuming that every client buffer will be compatible
with the scanout plane, but that is not the case, particularly with more
exotic tiled/compressed buffers. Once we
The scanout plane strictly stacks under all overlay planes, and the
cursor plane above. However, the stacking of overlay planes with respect
to each other is undefined.
We can control the stacking order of overlay planes with the zpos
property, though this significantly complicates plane
Hi,
Another revision after Pekka's review. There is a memory leak fix in
testing atomic commits, as well as cosmetic changes inside
drm_output_propose_state.
The largest change is that if we enter drm_output_propose_state in
renderer-only mode, we no longer return early. This matches the
Add a new mode, which attempts to construct a scene exclusively using
planes. This is a building block for incrementally testing and
constructing state: in the plane-only mode, we test the state exactly
once, when we have constructed a full set of planes and want to know if
it works or not.
When
This will never work, so don't even try to do it.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 65079eac0..c7ca6ef79 100644
--- a/libweston/compositor-drm.c
+++
The atomic API can allow us to test state before we apply it, to see if
it will be valid. Use this when we construct a plane configuration, to
see if it has a chance of ever working. If not, we can fail
assign_planes early.
This will be used in later patches to incrementally build state by
On Wed, 11 Jul 2018 11:41:27 +0100
Daniel Stone wrote:
> Add support for multiple modes to drm_output_propose_state. Currently we
> intend to operate in three modes: planes-only (no renderer buffer,
> client buffers in planes only), mixed-mode (promote client buffers to
> planes where possible,
On Wed, 11 Jul 2018 11:41:29 +0100
Daniel Stone wrote:
> The atomic API can allow us to test state before we apply it, to see if
> it will be valid. Use this when we construct a plane configuration, to
> see if it has a chance of ever working. If not, we can fail
> assign_planes early.
>
> This
Hi,
On Wed, 11 Jul 2018 at 14:07, Pekka Paalanen wrote:
> On Wed, 11 Jul 2018 13:16:18 +0100 Daniel Stone wrote:
> > @@ -3426,17 +3426,6 @@ drm_output_propose_state(struct weston_output
> > *output_base,
> > if (pixman_region32_not_empty(_overlap))
> >
On Wed, 11 Jul 2018 11:41:28 +0100
Daniel Stone wrote:
> Return a pointer to the plane state, rather than returning its
> underlying weston_plane.
>
> Signed-off-by: Daniel Stone
> ---
> libweston/compositor-drm.c | 63 +++---
> 1 file changed, 31
The first patch is new, makes us always parse the formats / modifiers.
Currently we don't parse them if we end up binding to version 1 or 2,
which can cause us to abort for no good reason.
The last patch is just to show how we could remove the libdrm
dependency. The problem there is the lack of
Hi,
On Wed, 11 Jul 2018 at 12:43, Pekka Paalanen wrote:
> On Wed, 11 Jul 2018 11:41:29 +0100 Daniel Stone wrote:
> > @@ -2610,9 +2612,18 @@ drm_pending_state_apply_atomic(struct
> > drm_pending_state *pending_state,
> > case DRM_STATE_APPLY_ASYNC:
> > flags |=
On Wed, 11 Jul 2018 11:41:31 +0100
Daniel Stone wrote:
> Add a new mode, which attempts to construct a scene exclusively using
> planes. This is a building block for incrementally testing and
> constructing state: in the plane-only mode, we test the state exactly
> once, when we have constructed
On Wed, 11 Jul 2018 13:16:17 +0100
Daniel Stone wrote:
> In the plane-only mode, we try to place every view on a hardware plane,
> and fail if we can't do this. This requires a full walk of the scene
> graph to come up with a complete configuration in order to be able to
> test.
>
> In mixed
On Wed, 11 Jul 2018 13:16:18 +0100
Daniel Stone wrote:
> a0f8276fe814 ("compositor-drm: Disallow overlapping overlay planes") was
> a little too pessimistic in rejecting occluded views. Whilst it
> correctly prevented overlay planes from occluding each other, it also
> prevented overlay planes
On Wed, 11 Jul 2018 14:10:55 +0100
Daniel Stone wrote:
> a0f8276fe814 ("compositor-drm: Disallow overlapping overlay planes") was
> a little too pessimistic in rejecting occluded views. Whilst it
> correctly prevented overlay planes from occluding each other, it also
> prevented overlay planes
On Wed, 11 Jul 2018 11:41:30 +0100
Daniel Stone wrote:
> This will never work, so don't even try to do it.
>
True, even more generally than just solid surfaces which are a special
case of a surface that currently does not have a buffer (anymore). This
catches also all wl_shm surfaces with
No need to write libdrm driver specific code for each supported
driver, we can just let GBM call the right one for us now.
Signed-off-by: Emilio Pozuelo Monfort
---
v2: we now pass the correct modifier to fill_content and
zwp_linux_buffer_params_v1_add(). Added a new note since I'm not sure
if
Just rely on getting the supported formats through the dmabuf
extension.
Signed-off-by: Emilio Pozuelo Monfort
---
v3: this now drops the dependency on libEGL
clients/simple-dmabuf-drm.c | 11 ---
configure.ac| 2 +-
2 files changed, 1 insertion(+), 12 deletions(-)
Signed-off-by: Emilio Pozuelo Monfort
---
clients/simple-dmabuf-drm.c | 32 +++-
configure.ac| 2 +-
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index 1d452183..a6c3b16d
We effectively require it as we don't react to dmabuf_format,
only to dmabuf_modifiers, so there's a chance we may not get
the supported formats information at all.
Signed-off-by: Emilio Pozuelo Monfort
---
clients/simple-dmabuf-drm.c | 12 +---
1 file changed, 1 insertion(+), 11
a0f8276fe814 ("compositor-drm: Disallow overlapping overlay planes") was
a little too pessimistic in rejecting occluded views. Whilst it
correctly prevented overlay planes from occluding each other, it also
prevented overlay planes from occluding the scanout plane.
This is undesirable: the
In the plane-only mode, we try to place every view on a hardware plane,
and fail if we can't do this. This requires a full walk of the scene
graph to come up with a complete configuration in order to be able to
test.
In mixed mode, we know at least some visible views will fail to be
promoted to
Hi,
After a long discussion on IRC, patch 1 has been extensively rewritten.
Firstly, the handling of temporarily placing the old renderer
framebuffer has been localised to drm_output_propose_state, reducing the
damage. Secondly, the viciously ugly state_old handling in
prepare_scanout_view has
Now that we can sensibly test proposed plane configurations with atomic,
sprites are not broken.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
---
libweston/compositor-drm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
Hi Pekka,
On Wed, 11 Jul 2018 at 14:26, Pekka Paalanen wrote:
> On Wed, 11 Jul 2018 14:10:55 +0100 Daniel Stone wrote:
> > a0f8276fe814 ("compositor-drm: Disallow overlapping overlay planes") was
> > a little too pessimistic in rejecting occluded views. Whilst it
> > correctly prevented overlay
Hi Emilio,
On Wed, 11 Jul 2018 at 12:53, Emilio Pozuelo Monfort wrote:
> As for NV12 support: I tried to make gbm support that in
> backends/dri/gbm_dri.c by adding a mapping to gbm_dri_visuals_table
> from GBM_FORMAT_NV12 to __DRI_IMAGE_FOURCC_NV12 or DRM_FORMAT_NV12,
> but that didn't work.
a0f8276fe814 ("compositor-drm: Disallow overlapping overlay planes") was
a little too pessimistic in rejecting occluded views. Whilst it
correctly prevented overlay planes from occluding each other, it also
prevented overlay planes from occluding the scanout plane.
This is undesirable: the
Hi All,
I have a question related to the wl_client creation in the compositor. I
followed these step like weston did:
1. create socketpair.
2. fork a process and close `socket[0]` in child, close `socket[1]` in in
parent process.
3. set the `WAYLAND_SOCKET` to `socket[1]`.
4. exec the program.
Thanks, I'll get myself working on it.
On Thu, Jul 12, 2018, 08:19 Peter Hutterer wrote:
> On Tue, Jul 10, 2018 at 01:06:17PM +0530, Sagar Tewari wrote:
> > I would like to work on implementing right and middle click drag as
> > two/three finger tap followed by a single tap drag, the way it
On Tue, Jul 10, 2018 at 01:06:17PM +0530, Sagar Tewari wrote:
> I would like to work on implementing right and middle click drag as
> two/three finger tap followed by a single tap drag, the way it works in
> synaptics driver. I found that this topic has been discussed previously:
>
48 matches
Mail list logo
