On Fri, Jul 6, 2018 at 1:26 AM, David Edmundson
wrote:
This protocol is to address the following use case.
A user clicks on a URL link in an IRC chat and a web browser opens.
We want an existing browser window to raise or if it's a newly
spawned application to claim focus on startup.
Nat
On Thu, Jul 5, 2018 at 4:56 PM, Drew DeVault wrote:
> I'm not sure why an activiation request has to jump through these
> surface export hoops first.
>
I think it's important to distinguish focus/raising from urgent/needs
attention hints.
I'm only interested in focus/raising.
Historically on X
On 2018/7月/05 04:26, David Edmundson wrote:
> This protocol is to address the following use case.
>
> A user clicks on a URL link in an IRC chat and a web browser opens. We want
> an existing browser window to raise or if it's a newly spawned application
> to claim focus on startup.
>
> Naturally
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
---
libweston/compositor-drm.c | 21 +
1 file changed, 1
Now that we have a helper to fill the plane state co-ordinates from a
view, use this for the scanout plane.
We now explicitly check that the view fills exactly the fullscreen area
and nothing else. We then use the new helper to fill out the plane state
values, and do further checks against the fil
We currently do the same thing in two places, and will soon have a
third.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 91 --
1 file changed, 48 insertions(+), 43 deletions(-)
diff --git a/lib
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, 11 insertions(+), 11 deletions(-)
diff --git a/libweston/compositor-drm.
From: Sergi Granell
The per-plane IN_FORMATS property adds information about format
modifiers; we can use these to both feed GBM with the set of modifiers
we want to use for rendering, and also as an early-out test when we're
trying to see if a FB will go on a particular plane.
Signed-off-by: Se
Use the same codepath, which has the added advantage of being able to
import dmabufs.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 53 ++
1 file changed, 13 insertions(+), 40 deletions(-)
diff
Add support for multiple modes: toggling whether or not the renderer
and/or planes are acceptable. This will be used to implement a smarter
plane-placement heuristic when we have support for testing output
states.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c |
In our new and improved helper to determine the src/dest values for a
buffer on a given plane, make sure we account for all buffer
transformations, including viewport clipping.
Rather than badly open-coding it ourselves, just use the helper which
does exactly this.
Signed-off-by: Daniel Stone
Re
When we come to assign_planes, try very hard to ignore views which are
only visible on other outputs, rather than forcibly moving them to the
primary plane, which causes damage all round and unnecessary repaints.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
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, 39 insertions(+), 32 deletions(-)
diff --git a/libweston/compositor-drm.
The atomic API can allow us to test state before we apply it, to see if
it will be valid. Add support for this, which we will later use in
assign_planes to ensure our plane configuration is valid.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 176
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 plane behind views which can.
Signed-off-by: Daniel Stone
Teste
... in order to be able to use it from scanout as well.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 225 -
1 file changed, 122 insertions(+), 103 deletions(-)
diff --git a/libweston/composito
Move drm_assign_planes into two functions: one which proposes a plane
configuration, and another which applies that state to the Weston
internal structures. This will be used to try multiple configurations
and see which is supported.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested
Use the extended GBM allocator interface to support modifiers and
multi-planar BOs.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
configure.ac | 3 ++
libweston/compositor-drm.c | 61 +++---
2 files changed, 53 insertions(+), 11 deletions(-)
Put some more transformation checks in drm_view_transform_supported.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 54 --
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/libweston/compositor-drm.c b/libwesto
Hi,
This is v16 (this time for sure) of the atomic series.
Patches 1 and 2 are new, falling out of previous review.
Patch 5 is a bit less trusting, and now properly clips to CRTC bounds if
required.
Similarly, I've gone through patch 8 and am more confident that it
actually does the right thing
Use the new helper to populate the cursor state as well, with some
special-case handling to account for how we always upload a full-size
BO.
As this now fully takes care of buffer transformations, HiDPI client
cursors work, and we also clip the cursor plane completely to CRTC
bounds.
Signed-off-b
Add support for the GBM_BO_IMPORT_FD_MODIFIER path, which allows us to
import multi-plane dmabufs, as well as format modifiers.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
configure.ac | 6 +-
libweston/compositor-drm.c | 181 +++--
2 fil
Since it doesn't write to the parameter, we can make it const.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index b96e29671..c6b82ac44 100644
--- a/libweston/
e2e80136334f fixed the same issue as df573031d0ba in a different way.
The latter commit (applied earlier in the upstream tree) adds a variable
to assign_planes to keep track of when we successfully assign a view to
the scanout plane, and doesn't call prepare_scanout_view if we have.
The former com
Use the new drmModeAddFB2WithModifiers interface to import buffers with
modifiers.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
configure.ac | 3 +++
libweston/compositor-drm.c | 26 +-
2 files changed, 28 insertions(+)
Pull this into a helper function, so we can use it everywhere.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 162 +
1 file changed, 93 insertions(+), 69 deletions(-)
diff --git a/libweston/comp
Rather than a hardcoded ARGB -> XRGB translation inside a
GBM-specific helper, just determine whether or not the view is opaque,
and use the generic helpers to implement the format translation.
As a consequence of reordering the calls in
drm_output_prepare_overlay_view(), we move the GBM B
Hi Pekka,
On Tue, 30 Jan 2018 at 09:58, Pekka Paalanen wrote:
> On Wed, 20 Dec 2017 12:26:58 +
> Daniel Stone wrote:
> > + for (i = 0; i < plane->count_formats; i++) {
> > + if (plane->formats[i].format == output->gbm_format)
>
> Here it is output->gbm_format...
>
> > +
I'm not sure why an activiation request has to jump through these
surface export hoops first. We export a surface... to do what with it?
Export it to whom? What do they do with it? Instead, we could just
activate the surface (though I'd suggest activating an xdg_toplevel
rather than an arbitrary su
From: Ankit Nautiyal
This patch adds information about the new resolution-format that can
be specified by a user in weston.ini to select a CEA mode. CEA defines
timing of a video mode, which is considered as a standard for
HDMI certification and compliance testing. It defines each and every
param
From: Ankit Nautiyal
The flag bits 19-22 of the connector modes, provide the aspect-ratio
information. This information can be stored in flags bits of the
weston mode structure, so that it can used for setting a mode with a
particular aspect-ratio.
Currently, DRM layer supports aspect-ratio with
From: Ankit Nautiyal
This patch series adds support for parsing aspect-ratio information
for a connector vidoe mode, provided by the DRM layer.
The aspect ratio is stored in the flags bit of the connector modes,
which can be used to distinguish between CEA modes, that have the
aspect-ratio specif
This protocol is to address the following use case.
A user clicks on a URL link in an IRC chat and a web browser opens. We want
an existing browser window to raise or if it's a newly spawned application
to claim focus on startup.
Naturally we also don't want any arbitrary client to be able to rai
wayland-protocols 1.15 is now available.
This version includes a new unstable protocol that enables clients to
allow the compositor to draw window decorations.
The xdg-shell protocol also saw a fix clarifying the requirements for
xdg-popup parents.
Here is the shortlog:
Drew DeVault (1):
On Mon Jul 2 09:10:21 UTC 2018
Pekka Paalanen wrote:
> On Fri, 29 Jun 2018 10:05:58 -0500
> Matt Hoosier wrote:
>
> > Hi all,
> >
> > Pekka's recent comments about wanting to enable set-top boxes built with
> > libweston to do DRM content got me to wondering:
> >
> > Who all is using li
On Wed, 4 Jul 2018 13:21:14 +
"Ray, Ian (GE Healthcare)" wrote:
> > On 21 Jun 2018, at 15.53, Pekka Paalanen wrote:
> >
> > From: Pekka Paalanen
> >
> > This is regression apparently introduced in
> > 0de859ede4bad72b5d3b78e086632f02196d997f, which accidentally swapped the
> > sign of 'de
36 matches
Mail list logo
