summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-02-07compositor-drm: Enable planes for atomicstuffDaniel Stone1-11/+11
Now that we can sensibly test proposed plane configurations with atomic, sprites are not broken. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1537
2017-02-07compositor-drm: Relax plane restrictions for atomicDaniel Stone1-8/+13
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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1536
2017-02-07compositor-drm: Test plane states before applicationDaniel Stone1-34/+102
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 incrementally attempt to construct a working state, by trying the combination of our old renderer state with planes added one-by-one. If they pass the test commit stage, we can use it, so we stash that state and continue on. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1535
2017-02-07compositor-drm: Return plane state from plane preparationDaniel Stone1-25/+27
Return a pointer to the plane state, rather than indirecting via a weston_plane. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1534
2017-02-07compositor-drm: Add test-only mode to state applicationDaniel Stone1-16/+42
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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1533
2017-02-07compositor-drm: Add modes to drm_output_propose_stateDaniel Stone1-6/+31
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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1532
2017-02-07compositor-drm: Ignore occluded viewsDaniel Stone1-1/+19
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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1531
2017-02-07compositor-drm: Ignore views on other outputsDaniel Stone1-9/+15
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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1530
2017-02-07compositor-drm: Split drm_assign_planes in twoDaniel Stone1-34/+72
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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1529
2017-02-07compositor-drm: Rename region variableDaniel Stone1-5/+6
Make it a bit more clear what the purpose of the variable is. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1528
2017-02-07compositor-drm: Don't need safe view-list traversalDaniel Stone1-2/+2
Nothing in this loop reorders views within the compositor's view_list. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1527
2017-02-07compositor-drm: Support modifiers for drm_fbDaniel Stone2-1/+27
Use the new drmModeAddFB2WithModifiers interface to import buffers with modifiers. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1526
2017-02-07compositor-drm: Avoid GBM for dmabuf importTomohito Esaki2-50/+108
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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1525
2017-02-07compositor-drm: Support multi-planar drm_fbDaniel Stone1-21/+24
Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1524
2017-02-07compositor-drm: Extract drm_fb_addfb into a helperDaniel Stone1-32/+31
We currently do the same thing in two places, and will soon have a third. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1523
2017-02-07compositor-drm: Remove no_addfb2 handlingDaniel Stone1-34/+12
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 for users on old kernels without AddFB2; unfortunately, we cannot detect the complete absence of the ioctl, as the return here is -EINVAL rather than -ENOTTY. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1522
2017-02-07compositor-drm: Use plane FB-import helper for scanoutDaniel Stone1-42/+12
Use the same codepath, which has the added advantage of being able to import dmabufs. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1521
2017-02-07compositor-drm: Extract overlay FB import to helperDaniel Stone1-102/+119
... in order to be able to use it from scanout as well. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1520
2017-02-07compositor-drm: Use plane_coords_for_view for cursorDaniel Stone1-24/+24
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 <daniels@collabora.com> Reported-by: Derek Foreman <derekf@osg.samsung.com> Differential Revision: https://phabricator.freedesktop.org/D1519
2017-02-07compositor-drm: Use plane_state_coords_for_view for scanoutDaniel Stone1-43/+23
Use the shiny new helper we have for working through scanout as well. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1518
2017-02-07[XXX] compositor-drm: Only disallow scaling for overlay planesDaniel Stone1-15/+12
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 analyse that. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1517
2017-02-07compositor-drm: Fully account for buffer transformationDaniel Stone1-33/+17
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 <daniels@collabora.com> Reported-by: Tiago Gomes <tiago.gomes@codethink.co.uk>
2017-02-07compositor-drm: Extract buffer->plane co-ord translationDaniel Stone1-69/+88
Pull this into a helper function, so we can use it everywhere. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1516
2017-02-07compositor-drm: Make alpha-to-opaque handling commonDaniel Stone1-71/+43
Rather than a hardcoded ARGB8888 -> XRGB8888 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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1515
2017-02-07compositor-drm: Atomic modesetting supportDaniel Stone1-5/+203
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: Daniel Stone <daniels@collabora.com> Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Co-authored-by: Louis-Francis Ratté-Boulianne <louis-francis.ratte-boulianne@collabora.com> Co-authored-by: Derek Foreman <derek.foreman@collabora.co.uk>
2017-02-07compositor-drm: Add to_drm_mode helperDaniel Stone1-1/+7
Much like we already have to_drm_output and to_drm_backend. Differential Revision: https://phabricator.freedesktop.org/D1505 Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-02-07compositor-drm: Add blob_id member to drm_modeDaniel Stone1-4/+16
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-off-by: Daniel Stone <daniels@collabora.com>
2017-02-07compositor-drm: Discover atomic propertiesPekka Paalanen2-0/+146
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 <daniels@collabora.com> Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2017-02-07compositor-drm: Don't restore original CRTC modeDaniel Stone1-16/+7
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 Stone <daniels@collabora.com>
2017-02-07compositor-drm: Use apply_state for starting repaintDaniel Stone1-23/+4
Rather than open-coding it ourselves, use the new apply_state helper in drm_output_start_repaint. Signed-off-by: Daniel Stone <daniels@collabora.com> Reported-by: Fabien DESSENNE <fabien.dessenne@st.com> Differential Revision: https://phabricator.freedesktop.org/D1514
2017-02-07compositor-drm: Move DPMS into output stateDaniel Stone1-25/+114
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 <daniels@collabora.com>
2017-02-07compositor-drm: Split repaint into helperDaniel Stone1-22/+38
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.freedesktop.org/D1500 Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-02-07compositor-drm: Don't repaint if no damageDaniel Stone1-2/+13
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 <daniels@collabora.com>
2017-02-07compositor-drm: Use drm_plane for scanout planeDaniel Stone1-45/+87
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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1416
2017-02-07compositor-drm: Track cursor_plane with a drm_planeDaniel Stone1-91/+280
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 cleanup function. This patch introduces a 'special plane' helper, creating a drm_plane either from a real KMS plane when using universal planes, or a fake plane otherwise. Without universal planes, the cursor and primary planes are hidden from us; this helper allows us to pretend otherwise. Differential Revision: https://phabricator.freedesktop.org/D1498 Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-02-07compositor-drm: Introduce drm_plane_state structureDaniel Stone1-60/+270
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 part of output->state_last, and is not directly visible from the plane itself. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1412
2017-02-07compositor-drm: Introduce drm_output_state structureDaniel Stone1-33/+196
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.freedesktop.org/D1497 Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-02-07compositor-drm: Track all plane typesDaniel Stone1-33/+41
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://phabricator.freedesktop.org/D1496 Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-02-07compositor-drm: Add universal plane awarenessPekka Paalanen1-0/+406
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://phabricator.freedesktop.org/D1495 Signed-off-by: Daniel Stone <daniels@collabora.com> Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Co-authored-by: Louis-Francis Ratté-Boulianne <louis-francis.ratte-boulianne@collabora.co.uk>
2017-02-07compositor-drm: Rename fb_plane to scanout_planeDaniel Stone1-5/+6
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 API, and identified by PLANE_TYPE == "Primary" in the universal-plane API. However, Weston uses 'primary_plane' internally to refer to the case where client content is _not_ directly displayed on a plane, but composited via the renderer, with the result of the compositing then shown. Rename to 'scanout_plane' as our least-ambiguous name, and document it a bit. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1415
2017-02-07compositor-drm: Refactor sprite create/destroy into helpersPekka Paalanen1-71/+117
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 drm_sprite to drm_plane, moving some of the logic back into create_sprites(), also symmetrical drm_plane_destroy.] Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1409
2017-02-07compositor-drm: Rename drm_sprite to drm_planeDaniel Stone1-89/+98
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 duplicating a lot of code to deal with them, especially when we come to use an entirely plane-based interface with atomic modesetting. Rename drm_sprite to drm_plane, to reflect that it's actually generic. No functional changes. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net> Differential Revision: https://phabricator.freedesktop.org/D1408
2017-02-07compositor-drm: Clean up page_flip_pending pathDaniel Stone1-8/+11
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: releasing framebuffers back. When using client-supplied framebuffers, it is possible to reuse the same buffer multiple times, and we would send a framebuffer-release event too early. However, since we have a properly reference-counted drm_fb now, we can just drop this test, and rely on the reference counting to prevent too-early release of client framebuffers. page_flip_pending now becomes exactly what the name suggests: a flag which indicates whether or not we are expecting a pageflip event. Add asserts here to verify that we never receive a pageflip event we weren't expecting. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1417
2017-02-07compositor-drm: Turn vblank_pending from bool to refcountDaniel Stone1-3/+4
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 have been promoted to DRM planes. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1418
2017-02-07compositor-drm: Introduce fb_last memberDaniel Stone1-12/+30
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 case, thus leaving us with three unambiguous members: fb_pending is used as a scratch space for a buffer we're about to post, fb_current holds the buffer we last requested to display (whether active yet or not), and fb_last is again scratch space for a buffer which is no longer being displayed after a previous configuration reqeust. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1411
2017-02-07compositor-drm: Return FB directly from renderDaniel Stone1-11/+19
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 <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1419
2017-02-07compositor-drm: Reshuffle drm_output_renderDaniel Stone1-2/+6
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 <daniels@collabora.com>
2017-02-07compositor-drm: Rename current/next FB membersDaniel Stone1-43/+43
'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 last framebuffer for which we know configuration has been fully applied, i.e. CRTC set executed or pageflip requested and event received. Rename these members to fb_current and fb_pending. Signed-off-by: Daniel Stone <daniels@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D1410
2017-02-07compositor-drm: Use drm_fb for cursor buffersDaniel Stone1-20/+53
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 <daniels@collabora.com>
2017-02-07compositor-drm: Use refcounted FBs for PixmanDaniel Stone1-4/+4
When using the Pixman renderer, use drm_fb refcounting explicitly. Differential Revision: https://phabricator.freedesktop.org/D1492 Signed-off-by: Daniel Stone <daniels@collabora.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-15 04:07:43 +0000