I was testing out the new pressure-based touch detection in libinput
(on a new MBP where the sensitivy is such that it's been possible to
move the mouse without actually touching the touchpad, so this new
feature is very welcome) and realized that it appears the drivers must
send actual ABS_MT_PRE
Split repaint into two stages, as implied by the grouped-repaint
interface: drm_output_repaint generates the repaint state only, and
drm_repaint_flush applies it.
This also moves DPMS into output state. Previously, the usual way to
DPMS off was that repaint would be called and apply its state, fol
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
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 54 --
1 file
Use the extended GBM allocator interface to support modifiers and
multi-planar BOs.
XXX: Depends on bwidawsk's 'modifiers' tree.
Signed-off-by: Daniel Stone
---
configure.ac | 4
libweston/compositor-drm.c | 52 +++---
libweston/meson.
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
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.]
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
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
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 +
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.
Differential Revision: https://phabricator.freedesktop.org/D1502
Signed-off-by: Daniel St
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
Signed-off-by: Daniel Stone
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
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
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
Rather than a more piecemeal approach at backend creation, explicitly
track connectors and CRTCs we do not intend to use, so we can ensure
they are disabled where appropriate.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 53 ++
1 file c
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
Signed-off-by: Daniel Stone
---
Nothing in this loop reorders views within the compositor's view_list.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1527
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
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
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
Now that we have better types in drm_fb, use it for cursor buffers as
well. This gives us easier refcounting for our cursors, as well as a
unified buffer-destruction path.
Currently this makes no difference, as the KMS legacy cursor update API
uses GEM names directly, and never touches DRM FBs. Ho
Pull this into a helper function, so we can use it everywhere.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1516
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 157 +
1 file changed, 88 insert
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
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
... in order to be able to use it from scanout as well.
Differential Revision: https://phabricator.freedesktop.org/D1520
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 221 -
1 file changed, 119 insertions(+), 102 deletions(-)
diff --gi
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
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 29 +---
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1524
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 45 -
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/libweston/compositor-drm.c
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
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a
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
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.
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
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 22 +++---
1 file changed,
Use the new drmModeAddFB2WithModifiers interface to import buffers with
modifiers.
Signed-off-by: Daniel Stone
Differential Revision: https://phabricator.freedesktop.org/D1526
Signed-off-by: Daniel Stone
---
configure.ac | 3 +++
libweston/compositor-drm.c | 25
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.
Following patches change drm_fb to be explicitly reference counted; in
order to reduce churn, rename drm_output_relea
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
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 63 +++---
1 file changed
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.
Differential Revision: https://phabricator.freedesktop.org/D1533
Signed-off-by: Daniel Stone
---
l
When using the Pixman renderer, use drm_fb refcounting explicitly.
Differential Revision: https://phabricator.freedesktop.org/D1492
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
---
libweston/compositor-drm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
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
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 66 --
1 file changed, 23
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
Signed-off-by: Daniel Stone
---
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
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 54 +++---
1
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
drm_pending_state is currently skeletal, but will be used to retain
data through begin_repaint -> assign_planes -> repaint -> repaint_flush.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 100 +
1 file changed, 100 insertions(+)
v9: New
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
GetPlane2 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.
XXX: Depends on krh/bwidawsk's unmerged kernel/libdrm patches.
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
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
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 130 ++
Add a cache for DRM property IDs and values, and use it for the two
connector properties we currently update: DPMS and EDID.
As DRM property ID values are not stable, we need to do a name -> ID
lookup each run in order to discover the property IDs and enum values to
use for those properties. Rathe
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.
Differential Revision: https://phabricator.freedesktop.org/D1495
Signed-off-by: Daniel St
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
page_flip_pending is only be set when do a pageflip to a newly-rendered
buffer; if the flag is not set, we have landed in the start_repaint_loop
path where the vblank query fails, and thus we must pageflip to the same
buffer.
This test was not sufficient for what it was supposed to guard:
releasin
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.
This fixes unexpected behaviour when multiple views per output ha
If we have an unused CRTC or connector, explicitly disable it during the
end of the repaint cycle, or when we get VT-switched back in.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 46 ++
1 file changed, 46 insertions(+)
v9: New. See ch
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:
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
This uses the new pixel-format helpers, so we can also replace depth/bpp
with these.
Differential Revision: https://phabricator.freedesktop.org/D1513
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
---
libweston/compositor-drm.c | 44
1 file
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
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
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
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.
drm_fb_get_from_bo has a path where it may reuse a drm_fb, if
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
'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
Hi all,
Building on the previous series, as well as the global repaint timer
series which I've just sent out for more review (thanks Pekka!), here
is v9 of atomic. The most interesting feature is that it is now atomic.
As mentioned in the patch changelogs, in order to use the atomic API
correctly,
Rather than duplicating knowledge of pixel formats across several
components, create a custom central repository.
Differential Revision: https://phabricator.freedesktop.org/D1511
Signed-off-by: Daniel Stone
---
Makefile.am | 2 +
libweston/pixel-formats.c | 403 +
Differential Revision: https://phabricator.freedesktop.org/D1512
Signed-off-by: Daniel Stone
---
libweston/meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/libweston/meson.build b/libweston/meson.build
index db4347f..8127602 100644
--- a/libweston/meson.build
+++ b/libweston/meson
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
Reviewed-by: Derek Foreman
---
libweston/composit
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.
In doing so, the test for dumb images (destroying them, but only if
they're not the 'live' ones) is removed. This was dead code, as the only
path which cou
repaint_scheduled is actually cleverly a quad-state, disguised as a
boolean. There are four possible conditions for the repaint loop to be
in at any time:
- loop idle; no repaint will occur until specifically requested, which
may be never (repaint_scheduled == 0)
- loop schedule to begin: t
From: Pekka Paalanen
This documents all the public API related to wl_event_loop and
wl_event_source objects.
Signed-off-by: Pekka Paalanen
---
doc/doxygen/Makefile.am | 1 +
src/event-loop.c | 244 +-
src/wayland-server-core.h | 77
This API is used to rotate the contents of
application's buffer. But it is not needed
because an application can rotate its buffers
with set_buffer_transform request of
wl_surface interface.
Signed-off-by: Emre Ucan
---
ivi-shell/ivi-layout-export.h|9 -
ivi-shell/ivi-layout.c
This API is used to rotate the contents of
application's buffer, which are in the render
order list of the layer. But this API is not
needed because an application can rotate
its buffers with set_buffer_transform request
of wl_surface interface
Signed-off-by: Emre Ucan
---
ivi-shell/ivi-layout-e
Signed-off-by: Emre Ucan
---
ivi-shell/ivi-layout.c | 80 +++-
1 file changed, 4 insertions(+), 76 deletions(-)
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index ef11e74..a931542 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/iv
These APIs are used to rotate the contents of
application's buffer. But they are not needed
because an application can rotate its buffers
with set_buffer_transform request of
wl_surface interface.
Emre Ucan (3):
ivi-shell: remove surface_set_orientation API
ivi-shell: remove layer_set_orientat
70 matches
Mail list logo
