On 10 July 2018 6:03:26 pm AEST, David Edmundson
wrote:
>>Hm. If you wanted to, you could make this explicit by requiring an
>event serial in the export_surface request rather than the wl_surface.
>
>Certainly an option. Though I'm not sure we have a use case of needing
>to limit a client
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
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
Now that we can sensibly test proposed plane configurations with atomic,
sprites are not broken.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff
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
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 f7a364837..282d6d67f 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
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
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 20
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
Hi,
I believe this should resolve all the issues Pekka pointed out in the
(too hurried) v18. It's also been split up into a few different patches
with much more detailed commit messages, so should be much easier to
reason about and review.
Cheers,
Daniel
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
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 changed, 25 insertions(+), 28 deletions(-)
diff --git
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, using gbm_bo as Emil suggested. Some problems
I still see:
- NV12 doesn't work, it seems
On 10/07/18 15:16, Pekka Paalanen wrote:
> On Mon, 9 Jul 2018 17:38:49 +0200
> Emilio Pozuelo Monfort wrote:
>
>> This code calls into EGL to see if the dmabuf import modifiers
>> extension is available, and if not it assumes XRGB is supported.
>>
>> Rather than disabling this client
On 10/07/18 14:52, Pekka Paalanen wrote:
> On Tue, 3 Jul 2018 16:46:29 +0100
> Emil Velikov wrote:
>
>> Hi Emilio,
>>
>> On 2 July 2018 at 16:22, Emilio Pozuelo Monfort wrote:
>>> Signed-off-by: Emilio Pozuelo Monfort
>>> ---
>>> I tried a build with --disable-egl as I didn't have the headers
On 2018-07-03 04:33 PM, Derek Foreman wrote:
> Hi all,
>
> Just a quick reminder that we're due for alpha shortly, with the
> following intended release schedule:
I'd like to push this back to Friday, it looks like some atomic patches
are just about ready to land, and it seems a shame to block
On Tue, 10 Jul 2018 14:56:18 +0100
Daniel Stone wrote:
> Return a pointer to the plane state, rather than indirecting via a
> weston_plane.
>
> Signed-off-by: Daniel Stone
> Tested-by: Emre Ucan
> ---
> libweston/compositor-drm.c | 58 --
> 1 file changed,
On Tue, 10 Jul 2018 14:56:17 +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 14:56:16 +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 Tue, 10 Jul 2018 14:56:15 +0100
Daniel Stone wrote:
> 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
Return a pointer to the plane state, rather than indirecting via a
weston_plane.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 58 --
1 file changed, 30 insertions(+), 28 deletions(-)
diff --git
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,
A couple of changes after Pekka's review of the second two patches,
including two preparatory patches pulled out.
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
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
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
On Mon, 9 Jul 2018 17:38:49 +0200
Emilio Pozuelo Monfort wrote:
> This code calls into EGL to see if the dmabuf import modifiers
> extension is available, and if not it assumes XRGB is supported.
>
> Rather than disabling this client doesn't get build if one disables
> EGL, we can just
On Tue, 3 Jul 2018 16:46:29 +0100
Emil Velikov wrote:
> Hi Emilio,
>
> On 2 July 2018 at 16:22, Emilio Pozuelo Monfort wrote:
> > Signed-off-by: Emilio Pozuelo Monfort
> > ---
> > I tried a build with --disable-egl as I didn't have the headers
> > installed, and it broke here. The EGL usage
On Tue, 10 Jul 2018 11:47:15 +0900
Tomohito Esaki wrote:
> Since the repaint status of the flushed output may be reset if a output
> repaint is failed, it is necessary to clear the repainted flag
> immediately after output repaint flush/cancel.
>
> Signed-off-by: Tomohito Esaki
> ---
>
On Mon, 9 Jul 2018 14:23:20 +0100
Daniel Stone wrote:
> Now that we can sensibly test proposed plane configurations with atomic,
> sprites are not broken.
>
> Signed-off-by: Daniel Stone
> Tested-by: Emre Ucan
> ---
> libweston/compositor-drm.c | 22 +++---
> 1 file changed,
On Mon, 9 Jul 2018 14:23:19 +0100
Daniel Stone wrote:
> 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
> Tested-by: Emre Ucan
> ---
>
On Mon, 9 Jul 2018 14:23:17 +0100
Daniel Stone wrote:
> Return a pointer to the plane state, rather than indirecting via a
> weston_plane.
>
> Signed-off-by: Daniel Stone
> Tested-by: Emre Ucan
> ---
> libweston/compositor-drm.c | 71 +-
> 1 file changed,
Hi,
On Tue, 10 Jul 2018 at 10:06, Pekka Paalanen wrote:
> On Mon, 9 Jul 2018 14:23:15 +0100 Daniel Stone wrote:
> > @@ -3302,6 +3319,9 @@ drm_output_propose_state(struct weston_output
> > *output_base,
> > if (next_plane == NULL)
> > next_plane =
On Tue, 10 Jul 2018 12:06:00 +0300
Pekka Paalanen wrote:
> On Mon, 9 Jul 2018 14:23:15 +0100
> Daniel Stone wrote:
>
> > When trying to assign planes, keep track of the areas which are
> > already occluded, and ignore views which are completely occluded. This
> > allows us to build a state
On Tue, 10 Jul 2018 08:53:54 +0100
Daniel Stone wrote:
> Hi,
> On Mon, 29 Jan 2018 at 10:55, Pekka Paalanen wrote:
> > On Mon, 29 Jan 2018 09:17:49 + Daniel Stone
> > wrote:
> > > On 26 January 2018 at 14:04, Pekka Paalanen wrote:
> > > > On Wed, 20 Dec 2017 12:26:52 +
> > > >
On Mon, 9 Jul 2018 14:23:15 +0100
Daniel Stone wrote:
> When trying to assign planes, keep track of the areas which are
> already occluded, and ignore views which are completely occluded. This
> allows us to build a state using planes only, when there are occluded
> views which cannot go into a
>Hm. If you wanted to, you could make this explicit by requiring an event
>serial in the export_surface request rather than the wl_surface.
Certainly an option. Though I'm not sure we have a use case of needing
to limit a client releasing its focus?
>Does this interface need to exist?
It
Hi,
On Mon, 29 Jan 2018 at 13:59, Pekka Paalanen wrote:
> On Wed, 20 Dec 2017 12:26:55 + Daniel Stone wrote:
> > @@ -1818,12 +1819,10 @@ drm_output_prepare_scanout_view(struct
> > drm_output_state *output_state,
> > drm_plane_state_coords_for_view(state, ev);
> >
> > /* The
Hi,
On Mon, 29 Jan 2018 at 10:55, Pekka Paalanen wrote:
> On Mon, 29 Jan 2018 09:17:49 + Daniel Stone wrote:
> > On 26 January 2018 at 14:04, Pekka Paalanen wrote:
> > > On Wed, 20 Dec 2017 12:26:52 +
> > > Daniel Stone wrote:
> > >> +enum drm_output_propose_state_mode {
> > >> +
On Tue, 10 Jul 2018 08:41:46 +0100
Daniel Stone wrote:
> Hi Pekka,
>
> On Mon, 29 Jan 2018 at 15:01, Pekka Paalanen wrote:
> > On Wed, 20 Dec 2017 12:26:57 + Daniel Stone
> > wrote:
> > > @@ -212,6 +212,9 @@ if test x$enable_drm_compositor = xyes; then
> > >
Hi Pekka,
On Mon, 29 Jan 2018 at 15:01, Pekka Paalanen wrote:
> On Wed, 20 Dec 2017 12:26:57 + Daniel Stone wrote:
> > @@ -212,6 +212,9 @@ if test x$enable_drm_compositor = xyes; then
> >PKG_CHECK_MODULES(DRM_COMPOSITOR_ATOMIC, [libdrm >= 2.4.78],
> >
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:
https://lists.freedesktop.org/archives/wayland-devel/2017-September/034926.html
But
41 matches
Mail list logo
