On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill said:
> 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 ma
On Fri, 9 Dec 2016 15:51:10 +0100 Giulio Camuffo said:
> 2016-12-08 20:36 GMT+01:00 Derek Foreman :
> > 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 tha
On Fri, 09 Dec 2016 14:06:46 +0100 Niels Ole Salscheider
said:
> Am Freitag, 9. Dezember 2016, 12:02:07 CET schrieb Carsten Haitzler:
> > 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
On Fri, 09 Dec 2016 14:38:37 +0100 Niels Ole Salscheider
said:
> Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> > Niels Ole Salscheider wrote:
> > > Therefore I think that the situation has changed and I'd like to propose
> > > this protocol for inclusion in wayland-protocol
On Fri, 09 Dec 2016 14:29:14 +0100 Niels Ole Salscheider
said:
> Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
> > Niels Ole Salscheider wrote:
> >
> > Hi,
> >
> > > The first version of my proposal had such a flag. I removed it and
> > > replaced it by the described versio
Hi Yong,
On 6 December 2016 at 15:21, Yong Bakos wrote:
> Despite their clear names, wl_array and wl_list members are undocumented,
> resulting in doxygen warnings[1] when building documentation.
>
> Document these members, suppressing the warnings.
Not a difficult review; pushed.
Cheers,
Danie
Hi Armin,
On 9 December 2016 at 21:58, Armin Krezović wrote:
> +#ifdef ENABLE_EGL /* Defined but not used */
> +#ifdef ENABLE_EGL /* Force pixman when EGL support is disabled */
> b->use_pixman = new_config->use_pixman;
> +#else
> + b->use_pixman = true;
> +#endif
Bikeshedding a bi
Overall, I like the idea - it seems to solve the issues with raise/lower,
etc.
I wonder, though, if removing the explicit move/resize/etc. requests makes
it too restrictive. Suppose that, for whatever reason, the client wants to
trigger a move or a resize using the right or middle button. Maybe it
Compositors currently receive "move", "resize", and "show_window_menu"
requests from clients whose decorations have been interacted with.
Clients currently implement key- and mouse-binding policies to
determine which one of these requests to send to the compositor in
response to user action.
Deskt
Hi,
There were many different opinions and suggestions for how to allow
for raise and lower to be bound to mouse clicks in titlebars. This
is one possible way forward. It removes some of the semantic requests
in xdg-shell and replaces it with a "interact_with_decoration"
request that lets more win
There are no changes in this from v6 to v7, that will come next.
Signed-off-by: Adam Goode
---
unstable/xdg-shell/xdg-shell-unstable-v7.xml | 1041 ++
1 file changed, 1041 insertions(+)
create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v7.xml
diff --git a/unstabl
On 09.12.2016 22:30, Daniel Stone wrote:
> Hi,
>
Hi,
> On 9 December 2016 at 20:37, Armin Krezović wrote:
>> On 09.12.2016 20:57, Daniel Stone wrote:
>>> libweston/pixel-formats.c | 398
>>> ++
>>> libweston/pixel-formats.h | 112 +
>>
>>
Signed-off-by: Armin Krezović
---
Makefile.am| 1 +
configure.ac | 9 ++---
libweston/compositor-wayland.c | 23 ++-
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 2219e3d5..704d17af 1
Hi,
On 9 December 2016 at 19:58, Daniel Stone wrote:
> This is v2 of the atomic patchset, which incorporates quite a few
> fixups on the original code, and extends it far enough to flip
> sprites_are_broken off for atomic. \o/
And it lives here:
git://git.collabora.com/git/user/daniels/weston#wi
Hi,
On 9 December 2016 at 20:37, Armin Krezović wrote:
> On 09.12.2016 20:57, Daniel Stone wrote:
>> libweston/pixel-formats.c | 398
>> ++
>> libweston/pixel-formats.h | 112 +
>
> Where are corresponding build system modifications?
Missi
Hi Armin,
On 9 December 2016 at 20:37, Armin Krezović wrote:
>> diff --git a/libweston/meson.build b/libweston/meson.build
>> index d396c00..aee444a 100644
>> --- a/libweston/meson.build
>> +++ b/libweston/meson.build
>> @@ -19,6 +19,7 @@ srcs_libweston = [
>> 'noop-renderer.c',
>> 'p
On 09.12.2016 20:57, Daniel Stone wrote:
> When leaving Weston, don't attempt to restore the previous CRTC
> settings. The framebuffer may well have disappeared, and in every
> likelihood, whoever gets the KMS device afterwards will be repainting
> anyway.
>
> XXX: This breaks gamma. Need to work
On 09.12.2016 20:57, Daniel Stone wrote:
> We only need it for the GBM surface the FB was originally created
> against; a mismatch here is very bad indeed, so no reason to pass it in
> explictly every time rather than store it.
>
> Differential Revision: https://phabricator.freedesktop.org/D1490
>
On 09.12.2016 20:57, Daniel Stone wrote:
> This uses the new pixel-format helpers, so we can also replace depth/bpp
> with these.
>
> Signed-off-by: Daniel Stone
>
> Differential Revision: https://phabricator.freedesktop.org/D1513
So, this is where code added by patch 1 is being used. I suggest
On 09.12.2016 20:57, Daniel Stone wrote:
> This will be used so we can later determine the compatibility of drm_fbs
> without needing to introspect external state.
>
> Differential Revision: https://phabricator.freedesktop.org/D1487
>
> Signed-off-by: Daniel Stone
Looks fine.
Reviewed-by: Armi
On 09.12.2016 20:57, Daniel Stone wrote:
> This makes it sign-compatible with weston_output->{width,height}.
>
> Differential Revision: https://phabricator.freedesktop.org/D1486
>
> Signed-off-by: Daniel Stone
> Reviewed-by: Quentin Glidic
Makes sense
Reviewed-by: Armin Krezović
> ---
> li
On 09.12.2016 20:57, Daniel Stone wrote:
> Everyone else uses fb->fd rather than pulling the FD back out of GBM.
> Use that in the destroy callback too.
>
> Signed-off-by: Daniel Stone
>
Makes sense.
Reviewed-by: Armin Krezović
> Differential Revision: https://phabricator.freedesktop.org/D14
On 09.12.2016 20:57, Daniel Stone wrote:
> Try to harmonise the various plane-import paths a little bit, starting
> with reshuffling and commenting the conditions to do so.
>
> Signed-off-by: Daniel Stone
>
This makes code more readable and understandable. So have a
Reviewed-by: Armin Krezović
On 09.12.2016 20:57, Daniel Stone wrote:
> No functional change.
>
> Differential Revision: https://phabricator.freedesktop.org/D1484
>
> Signed-off-by: Daniel Stone
Nice
Reviewed-by: Armin Krezović
> ---
> libweston/compositor-drm.c | 26 +++---
> 1 file changed, 15 ins
On 09.12.2016 20:57, Daniel Stone wrote:
> Even if we do have a framebuffer matching the mode, we immediately
> schedule a repaint, meaning we either do work for no reason, or show
> stale content before we bring up the new content.
>
> Delete this and just let repaint deal with it.
>
> Different
On 09.12.2016 20:57, Daniel Stone wrote:
> Clarify the difference between crtc_id (DRM object) and pipe (index into
> drmModeRes->crtcs array, possible_crtcs bitmask).
>
> Signed-off-by: Daniel Stone
> Reviewed-by: Quentin Glidic
> Differential Revision: https://phabricator.freedesktop.org/D1405
On 09.12.2016 20:57, Daniel Stone wrote:
> Differential Revision: https://phabricator.freedesktop.org/D1512
> ---
> libweston/meson.build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libweston/meson.build b/libweston/meson.build
> index d396c00..aee444a 100644
> --- a/libweston/meson.
On 09.12.2016 20:57, Daniel Stone wrote:
> Rather than duplicating knowledge of pixel formats across several
> components, create a custom central repository.
>
Hi,
> Signed-off-by: Daniel Stone
>
> Differential Revision: https://phabricator.freedesktop.org/D1511
> ---
> libweston/pixel-forma
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
Differential Revision: https://phabricator.freedesktop.
'next' is used as a framebuffer which has either been rendered but not
had a configuration request (pageflip or CRTC set) applied to it, or
when for a framebuffer that has had configuration requested but not
applied (delayed pageflip where the event has not been applied).
'current' is used as the
Return a pointer to the plane state, rather than indirecting via a
weston_plane.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1534
---
libweston/compositor-drm.c | 52 --
1 file changed, 27 insertions(+), 25
Track dynamic plane state (CRTC, FB, position) in separate structures,
rather than as part of the plane. This will make it easier to handle
state management later, and much more closely tracks what the kernel
does with atomic modesets.
The fb_last pointer previously used in drm_plane now becomes p
When leaving Weston, don't attempt to restore the previous CRTC
settings. The framebuffer may well have disappeared, and in every
likelihood, whoever gets the KMS device afterwards will be repainting
anyway.
XXX: This breaks gamma. Need to work around that.
Differential Revision: https://phabrica
Rather than magically trying to infer what the buffer is and what we
should do with it when we go to destroy it, add an explicit type
instead.
Differential Revision: https://phabricator.freedesktop.org/D1488
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 50 +++
No need to walk the CRTC list every time looking for CRTC indices, when we
already have the CRTC index stashed away. Taking the plane as an argument
also simplifies things a little for callers, and future-proofs for a
potential future KMS API which passes a list of supported CRTC IDs rather
than a
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
Differential Revision: https://phabricator.freedesktop.org/D1533
---
l
Generate an output state in two stages. Firstly, attempt to run through
and generate a configuration with all views in planes. If this succeeds,
we can bypass the renderer completely.
If this fails, we know we need to have the renderer output used as a
base on the scanout plane, and can incrementa
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
Differential Revision: https://pha
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
Differential Revision: https://phabricator.freedesktop.org/D1536
---
libweston/compositor-drm.c |
Use the new drmModeAddFB2WithModifiers interface to import buffers with
modifiers.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1526
---
configure.ac | 3 +++
libweston/compositor-drm.c | 25 -
2 files changed, 27
Use the shiny new helper we have for working through scanout as well.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1518
---
libweston/compositor-drm.c | 66 --
1 file changed, 23 insertions(+), 43 deletions(-
From: Tomohito Esaki
Rather than relying on GBM for dmabuf import, perform the import
directly through libdrm. This creates a specialised drm_fb type for
dmabufs.
This also supports multi-planar dmabuf.
[daniels: Rebased on top of recent drm_fb/drm_plane_state/etc.]
Signed-off-by: Daniel Stone
If AddFB2 ever fails for any reason, we fall back to legacy AddFB, which
doesn't support the same swathe of formats, or multi-planar formats, or
modifiers.
This can happen with arbitrary client buffers, condemning us to the
fallback forever more. Remove this, at the cost of an unnecessary ioctl
fo
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
Diff
Nothing in this loop reorders views within the compositor's view_list.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1527
---
libweston/compositor-drm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libweston/compositor-drm.c b
Retain drm_plane tracking objects for all actual DRM planes when using
universal planes, not just overlay planes. Rename uses of 'sprite' to
'plane' to make it clear that it can now be any kind of plane, not just
an overlay/sprite.
These are currently unused.
Differential Revision: https://phabri
Use the same codepath, which has the added advantage of being able to
import dmabufs.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1521
---
libweston/compositor-drm.c | 54 +++---
1 file changed, 12 insertions(+)
Now that we can sensibly test proposed plane configurations with atomic,
sprites are not broken.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1537
---
libweston/compositor-drm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletion
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.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1515
-
Use a real drm_plane to back the scanout plane, displacing
output->fb_{last,cur,pending} to their plane-tracked equivalents.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1416
---
libweston/compositor-drm.c | 132 +---
Add support for using the atomic-modesetting API to apply output state.
Unlike previous series, this commit does not unflip sprites_are_broken,
until further work has been done with assign_planes to make it reliable.
Differential Revision: https://phabricator.freedesktop.org/D1507
Signed-off-by:
Now we have a more comprehensive overview of the transform we're going
to apply, use this to explicitly disallow scaling and rotation.
XXX: This does not actually disallow rotation for square surfaces.
We would have to build up a full buffer->view->output transform
matrix, and then analy
All planes being displayed have a framebuffer. What makes 'fb_plane'
special is that it's being displayed as the primary plane by KMS.
Previous patchsets renamed this to 'primary_plane' to match the KMS
terminology, namely the CRTC's base plane, which is controlled by
drmModeSetCrtc in the legacy
Make it a bit more clear what the purpose of the variable is.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1528
---
libweston/compositor-drm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libweston/compositor-drm.c b/
... in order to be able to use it from scanout as well.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1520
---
libweston/compositor-drm.c | 200 -
1 file changed, 109 insertions(+), 91 deletions(-)
diff --git
We currently do the same thing in two places, and will soon have a
third.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1523
---
libweston/compositor-drm.c | 63 +++---
1 file changed, 31 insertions(+), 32 deletio
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
Differential Revision: https://phabricator.freedesktop
Instead of setting state members directly in the drm_output_render
functions (to paint using Pixman or GL), just return a drm_fb, and let
the core function place it in state.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1419
---
libweston/compositor-dr
From: Pekka Paalanen
Set the atomic client cap, where it exists, and use this to discover the
plane/CRTC/connector properties we require for atomic modesetting.
Differential Revision: https://phabricator.freedesktop.org/D1503
Signed-off-by: Daniel Stone
Co-authored-by: Pekka Paalanen
---
con
Change the type of cursor_plane from a weston_plane (base tracking
structure) to a drm_plane (wrapper containing additional DRM-specific
details), and make it a dynamically-allocated pointer.
Using the standard drm_plane allows us to reuse code which already deals
with drm_planes, e.g. a common cl
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1524
---
libweston/compositor-drm.c | 45 -
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
For atomic modesetting support, the mode is identified by a blob
property ID, rather than being passed inline. Add a blob_id member to
drm_mode to handle this, including refactoring mode destruction into a
helper function.
Differential Revision: https://phabricator.freedesktop.org/D1504
Signed-of
Pull this into a helper function, so we can use it everywhere.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1516
---
libweston/compositor-drm.c | 157 +
1 file changed, 88 insertions(+), 69 deletions(-)
diff
Sometimes we need to duplicate an existing drm_fb, e.g. when
pageflipping to the same buffer to kickstart the repaint loop. To handle
situations like these, and simplify resource management for dumb and
cursor buffers, refcount drm_fb.
Differential Revision: https://phabricator.freedesktop.org/D14
From: Pekka Paalanen
This moves the single sprite creation code from create_sprites() into a
new function. The readability clean-up is small, but my intention is to
write an alternate version of create_sprites(), and sharing the single
sprite creation code is useful.
[daniels: Genericised from d
Currently this doesn't actually really do anything, but will be used in
the future to track the state for both modeset and repaint requests.
Completion of the request gives us a single request-completion path for
both pageflip and vblank events.
Differential Revision: https://phabricator.freedeskt
We can separate repainting into two phases: one performing the actual
repaint (essentially drm_output_render) and populating the plane state
that wasn't already populated by drm_output_assign_planes, and another
applying this state to the device.
Differential Revision: https://phabricator.freedesk
Extend drm_output_state to also cover DPMS, so we can use it to enable
and disable outputs, and always keep a coherent state.
Differential Revision: https://phabricator.freedesktop.org/D1501
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 139 +--
When using the Pixman renderer, use drm_fb refcounting explicitly.
Differential Revision: https://phabricator.freedesktop.org/D1492
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libweston/compositor-drm.c b
If we don't have any damage for the primary plane, then don't force a
repaint; simply reuse the old buffer we already have.
Differential Revision: https://phabricator.freedesktop.org/D1499
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 15 +--
1 file changed, 13 insert
Forcing DPMS on when we lose our session may force an expensive modeset
operation, which is pointless if the next consumer (another compositor,
or the console) is going to do a modeset. These should force DPMS on
regardless.
This actively causes problems for the DRM backend, in that it may
actuall
Rather than open-coding it ourselves, use the new apply_state helper in
drm_output_start_repaint.
Signed-off-by: Daniel Stone
Reported-by: Fabien DESSENNE
Differential Revision: https://phabricator.freedesktop.org/D1514
---
libweston/compositor-drm.c | 27 ---
1 file ch
Much like we already have to_drm_output and to_drm_backend.
Differential Revision: https://phabricator.freedesktop.org/D1505
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libweston/compositor-drm.c b/libwest
From: Pekka Paalanen
Add awareness of, rather than support for, universal planes. Activate
the client cap when we start if possible, and if this is activated,
studiously ignore non-overlay planes. For now.
[daniels: Rebased, split up, otherwise modified.]
Differential Revision: https://phabrica
page_flip_pending is set when we do a no-effect pageflip, and thus don't
need to release the buffer as we don't have a new one pending.
Now we have last/cur/pending properly broken out, we can just use these
consistently, and test if last != current (the effect), rather than the
specific path whic
vblank_pending is currently a bool, which is reset on every vblank
requests (i.e. sprite pageflip). This can occur more than once per
frame, so turn it into a callback, so we only fire frame-done when we've
collected all the events.
Signed-off-by: Daniel Stone
Differential Revision: https://phab
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.
Signed-off-by: Daniel Stone
Reported-by: Derek Foreman
Differential Revision: https://phabricator.freedesktop.org/D1519
---
libweston/compositor-drm.c |
This will be used so we can later determine the compatibility of drm_fbs
without needing to introspect external state.
Differential Revision: https://phabricator.freedesktop.org/D1487
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 24 +---
1 file changed, 13 in
We only need it for the GBM surface the FB was originally created
against; a mismatch here is very bad indeed, so no reason to pass it in
explictly every time rather than store it.
Differential Revision: https://phabricator.freedesktop.org/D1490
Signed-off-by: Daniel Stone
---
libweston/composi
Rather than duplicating knowledge of pixel formats across several
components, create a custom central repository.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1511
---
libweston/pixel-formats.c | 398 ++
libw
This uses the new pixel-format helpers, so we can also replace depth/bpp
with these.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1513
---
libweston/compositor-drm.c | 43 +++
1 file changed, 27 insertions(+), 16
Don't import buffers which span multiple outputs, short-cut any attempt
to import SHM buffers, and ignore buffers with a global alpha set.
I'm not convinced all of these conditions entirely make sense, but this
at least makes them equally nonsensical.
Signed-off-by: Daniel Stone
Differential Re
Clean up some ambiguity around current/next: current could previously
have referred to a buffer which was being displayed, or the last buffer
being displayed whilst we waited for a configuration we'd requested to
take effect.
Introduce a new variable, fb_last, which exclusively holds the latter
ca
Make drm_output_set_cursor more deterministic, by calculating more state
and performing more plane manipulation, inside
drm_output_prepare_cursor_view.
Differential Revision: https://phabricator.freedesktop.org/D1485
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 39 ++
Now that we have better types in drm_fb, use it for cursor buffers as
well.
Differential Revision: https://phabricator.freedesktop.org/D1493
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 73 +-
1 file changed, 53 insertions(+), 20 delet
Call drm_output_render unconditionally, doing an early exit if we're
already rendering a client buffer on the primary plane, and asserting
for damage on the way out.
Differential Revision: https://phabricator.freedesktop.org/D1494
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 8 +
From: Tomohito Esaki
The drm_fb destroy callback to mostly the same thing regardless of
whether the buffer is a dumb buffer or gbm buffer. This patch refactors
the common parts into a new function that can be called for both cases.
[daniels: Rebased on top of fb->fd changes, cosmetic changes.]
We make the differentiation where planes are an abstract framebuffer
with a position within a CRTC/output, and sprites are special cases of
planes that are neither the primary (base/framebuffer) nor cursor plane.
drm_sprite, OTOH, contains nothing that's actually specific to sprites,
and we end up
Everyone else uses fb->fd rather than pulling the FD back out of GBM.
Use that in the destroy callback too.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1406
---
libweston/compositor-drm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -
This makes it sign-compatible with weston_output->{width,height}.
Differential Revision: https://phabricator.freedesktop.org/D1486
Signed-off-by: Daniel Stone
Reviewed-by: Quentin Glidic
---
libweston/compositor-drm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --gi
Differential Revision: https://phabricator.freedesktop.org/D1512
---
libweston/meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/libweston/meson.build b/libweston/meson.build
index d396c00..aee444a 100644
--- a/libweston/meson.build
+++ b/libweston/meson.build
@@ -19,6 +19,7 @@ srcs_
Try to harmonise the various plane-import paths a little bit, starting
with reshuffling and commenting the conditions to do so.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1413
---
libweston/compositor-drm.c | 79 --
This always changes the state to ACTIVE when we enter the session,
whereas the previous implementation preserved the state (i.e. if state
was SLEEPING on exit, it would be restored to SLEEPING, but also with a
repaint). This seems more helpful behaviour, however: if you enter a
session, it's probab
No functional change.
Differential Revision: https://phabricator.freedesktop.org/D1484
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-dr
Even if we do have a framebuffer matching the mode, we immediately
schedule a repaint, meaning we either do work for no reason, or show
stale content before we bring up the new content.
Delete this and just let repaint deal with it.
Differential Revision: https://phabricator.freedesktop.org/D1481
Clarify the difference between crtc_id (DRM object) and pipe (index into
drmModeRes->crtcs array, possible_crtcs bitmask).
Signed-off-by: Daniel Stone
Reviewed-by: Quentin Glidic
Differential Revision: https://phabricator.freedesktop.org/D1405
---
libweston/compositor-drm.c | 4 ++--
1 file cha
Hi all,
This is v2 of the atomic patchset, which incorporates quite a few
fixups on the original code, and extends it far enough to flip
sprites_are_broken off for atomic. \o/
Compared to earlier versions, drm_output_state is introduced much
earlier, and everything hangs off this. This made a lot
Hi,
On 9 December 2016 at 16:35, Daniel Stone wrote:
> However, this is undesirable for DRM. In a multi-output situation,
> we would see a view only visible on another output, reasonably decide we
> didn't want it in a plane on our output, and move it to the primary
> plane, causing damage, and a
When we create a new view, assign it to the primary plane from the
beginning.
This made no difference before, since the next surface repaint would
forcibly assign all views to a plane, either through DRM's
assign_planes() hook, or the fallback inside core repaint.
However, this is undesirable for
On 09/12/16 08:51 AM, Giulio Camuffo wrote:
2016-12-08 20:36 GMT+01:00 Derek Foreman :
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
kil
1 - 100 of 106 matches
Mail list logo
