- Jul 11, 2018
-
-
Daniel Stone authored
Now that we can sensibly test proposed plane configurations with atomic, sprites are not broken. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
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> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
a0f8276f ("compositor-drm: Disallow overlapping overlay planes") was a little too pessimistic in rejecting occluded views. Whilst it correctly prevented overlay planes from occluding each other, it also prevented overlay planes from occluding the scanout plane. This is undesirable: the primary/scanout plane is specified to stack strictly below all overlay planes, so there is no need to reject a plane from consideration for scanout due to being occluded by an overlay plane. Shift the check downwards so it only applies to overlay rather than scanout planes. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
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 planes and must be composited via the renderer. In order to still use some planes where possible, we use atomic modesetting's test-only mode to incrementally test configurations. We know that the renderer output will always be visible, and because it is the renderer, that it will be occupying the scanout plane underneath everything else. The actual renderer buffer doesn't materialise until after assign_planes, because it cannot know what to render until then. However, in order to test whether a configuration is valid, we need the renderer buffer in the scanout plane. For testing, we fake this by temporarily stealing the old buffer - if it seems sufficiently compatible - and placing it in the state we construct. This is used to test whether or not a renderer buffer will work with the addition of overlay planes. Doing this incremental testing will allow us to enable plane usage for atomic by default, since we know ahead of time that our chosen plane configuration will work. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
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 using the renderer, we need to incrementally test views one by one to see if they will work on planes, falling back to the renderer if not. This test is different, since the scanout plane will be occupied by the renderer's buffer. Testing using the renderer or client buffers may have completely different characteristics, so we need two passes: first, constructing a state with only planes and testing if that succeeds, falling back later to a mixed renderer/plane mode which tests incrementally. This implements the first mode, and preferentially attempts to use it. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
This will never work, so don't even try to do it. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
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 proposing and testing potential configurations one at a time. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
Return a pointer to the plane state, rather than returning its underlying weston_plane. This eliminates any ambiguity between placing client buffers on planes, and placing them through the renderer. drm_output_propose_state is only concerned with preparing, testing, and returning DRM state objects. Assigning views to weston_planes only happens later, inside drm_assign_planes. This makes that split more clear. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
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 plane usage at all). We want to use the first (planes-only) mode where possible: it can avoid us having to allocate buffers for the renderer, and it also gives us the best chance of the optimal configuration, with no composition. In this mode, we walk the scene looking at all views, trying to put them in planes, and failing as soon as we find a view we cannot place in a plane. In the second mode, rather than failing, we assign those views which cannot be on a plane to the renderer, and allow the renderer to composite them. In the third mode, planes are not usable, so everything but the cursor goes to the renderer. We will use this when we cannot use the planes-only mode (because some views cannot be placed in planes), but also cannot use the 'mixed' mode because we have no renderer buffer yet. Since we walk the scene graph from top to bottom, using atomic modesetting we will determine if planes can be promoted in mixed mode by placing a renderer buffer at the bottom of the scene, placing a cursor buffer if applicable, then testing if we can add overlay planes to this mode. Without a buffer from the renderer, we cannot do these tests, so we push everything through the renderer and then switch to mixed mode on the next repaint. This patch implements the mixed and renderer-only modes (previously differentiated only by the sprites_are_broken flag), with the planes-only mode being left for a later patch. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
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 promote the client buffer to scanout, there is no going back: if the repaint fails, we do not mark this as failed and go back to repaint through composition. This permanently removes the ability for scanout bypass when using the non-atomic path. Future patches lift the restriction when using atomic modesetting, as we can actually test and ensure that the view is compatible with scanout. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reported-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
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 assignment. In the meantime, simply disallow assigning a view to an overlay, when it overlaps another view which is already on an overlay. This ensures stacking order is irrelevant, since the planes never intersect each other. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
- Jul 10, 2018
-
-
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 <etom@igel.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
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> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
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> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
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> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
- Jul 09, 2018
-
-
Daniel Stone authored
Now that we collect information about which modifiers are supported for KMS display, and are able to create KMS framebuffers with modifiers, begin using the modifier-aware GBM API. Client buffers from dmabuf already store multi-plane and modifier information into drm_fb. Extend this to drm_fb_get_from_bo(), used for wl_buffer, cursor, and gbm_surface buffers. wl_buffer buffers should by convention not require modifiers. Cursor buffers must not require modifiers, as they should be linear. Prior to this patch, GBM buffers must have been single-planar, and able to used without explicitly naming modifiers. Using gbm_surface_create_with_modifiers allows us to pass the list of modifiers acceptable to KMS for scanout to GBM, so it can allocate multi-planar buffers or those which are otherwise only addressible with modifiers. On platforms supporting and preferring modifiers for scanout, this means that the gbm_bos we get from our scanout surface need to use the extended API to query multiple planes, offsets, modifiers, etc. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
The per-plane IN_FORMATS KMS property describes the format/modifier combinations supported for display on this plane. Read and parse this format, storing the data in each plane, so we can know which combinations might work, and which combinations definitely will not work. Similarly to f11ec02c ("compositor-drm: Extract overlay FB import to helper"), we now use this when considering promoting a view to overlay planes. If the framebuffer's modifier is definitely not supported by the plane, we do not attempt to use that plane for that view. This will also be used in a follow-patch, passing the list of modifiers to GBM surface allocation to allow it to allocate more optimal buffers. Signed-off-by: Sergi Granell <xerpi.g.12@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
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 <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com> Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/113
-
Daniel Stone authored
Collect the fallback definitions of static_assert() from desktop-shell and the test shell, and move them to helpers.h. This allows code throughout the tree to use static_assert() for build-time assertions, where it is supported by the compiler. As GCC goes out of its way to only add static_assert() when C11 has been explicitly requested - which we don't do - make sure to use the more widely available _Static_assert() if that is provided. This will be used in future patches to ensure two array lengths don't go out of sync. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
When creating a drm_fb from client (wl_buffer/dmabuf), gbm_surface, or client buffers, set fb->size to 0. The size member is only used for dumb buffers, where we mmap the whole buffer, and need the size recorded to later pass to munmap. Determining the full size of multi-planar buffers is difficult, as auxiliary planes are not guaranteed to have a (height*stride) allocation, e.g. if they are subsampled or if they do not contain pixel data at all but, e.g., compression information. Single-plane tiled buffers also often pad the buffer allocation to a multiple of tile height, making our existing calculation incorrect. Though it does no harm to record incorrect information, it also does no good as we never use it; remove it in order to avoid any confusion. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Daniel Stone authored
ARRAY_LENGTH returns a size_t; rather than casting its result to int so we can compare to our signed index variable, just declare the index as a compatible type in the first place. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
The DPMS connector property is an enum property in KMS, which made our property handling complain at startup as we weren't defining its enums. Fix our definition so we parse the enum values. The only user of the property is the legacy path, which can continue using fixed values as those values are part of the KMS ABI. The atomic path does not need any changes, since atomic uses routing and CRTC active to determine the connector's power state, rather than a property. Signed-off-by: Daniel Stone <daniels@collabora.com> Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/125 Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
The weston.ini.man describes the mode-formats that a user can specify for selecting a video mode. The DRM specific examples are already provided in weston-drm.man, so this inofrmation is redundant and can be removed. This patch removes the DRM specific mode option details from the description of mode configuration in weston.ini.man. A pointer to weston-drm.man is given, which has complete information about the mode-format options supported by DRM backend. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
- Jul 06, 2018
-
-
Daniel Stone authored
Use the new drmModeAddFB2WithModifiers interface to import buffers with modifiers. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
We currently do the same thing in two places, and will soon have a third. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
Use the same codepath, which has the added advantage of being able to import dmabufs. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
... in order to be able to use it from scanout as well. In doing this, the check for format compatibility is moved from after selecting a plane to before selecting a plane. If different planes have disjoint format support, this ensures that we don't reject the view from all overlay consideration, just because the first plane we found didn't support its format. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
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-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reported-by: Derek Foreman <derekf@osg.samsung.com> Tested-by: Emre Ucan <eucan@de.adit-jv.com> Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/118
-
Daniel Stone authored
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 filled-in co-ordinates, i.e. that we're not trying to show an offset into the buffer, or to scale the image. This now allows cases where the buffer -> surface -> view -> output transform chain cancels each other out for scaling: previously, we would never consider a buffer for scanout unless its scale matched the output's. We now only look at the final result of the buffer -> output transformation, to check that this does not result in translation or scaling. An audit of the error paths found some places where we would leave a plane state hanging; this makes them all consistent. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
When considering a view for placement into an overlay plane, we previously checked that the buffer's transform and scale were identical to the output's, and that there were no transformations applied. We now use a more consistent set of checks through drm_plane_state_coords_for_view. This checks the complete transformation chain, allowing only translation and scaling; at the end, we check if the total buffer -> surface -> view -> output chain requires scaling or rotation, and disallow it if so. This allows scaling in the cases where the transformation chain cancels itself out to produce a 1:1 buffer -> output pixel scale. An erroneously disallowed case is where buffer -> view -> output rotations cancel each other out; we prevent a view from being on an overlay plane if rotation is involved at all. Fixing this would require a complete analysis of the overall transformation matrix. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
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> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reported-by: Tiago Gomes <tiago.gomes@codethink.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
Pull this into a helper function, so we can use it everywhere. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
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. As a consequence of reordering the calls in drm_output_prepare_overlay_view(), we move the GBM BO dereference into a different failure path, before it gets captured by the plane state. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
e2e80136 fixed the same issue as df573031 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 commit adds this checking inside prepare_scanout_view: if the pending output state already has a framebuffer assigned to the scanout plane, we drop out of prepare_scanout_view early. The picked_scanout variable inside assign_planes can thus be removed. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Emre Ucan <eucan@de.adit-jv.com>
-
Daniel Stone authored
Since it doesn't write to the parameter, we can make it const. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
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 atomic-modesetting by default. For legacy modeset path, the user-space needs to set the drm client cap for aspect-ratio, if it wants aspect-ratio information in modes. This patch: - preserves aspect-ratio flags from kernel video modes and accommodates it in wayland mode. - uses aspect-ratio to pick the appropriate mode during modeset. - changes the mode format in configuration file weston.ini to accommodate aspect-ratio information as: WIDTHxHEIGHT@REFRESH-RATE ASPECT-RATIO The aspect-ratio can take the following values : 4:3, 16:9, 64:27, 256:135. v2: As per recommendation from Pekka Paalanen, Quentin Glidic, Daniel Stone, dropped the aspect-ratio info from wayland protocol, thereby avoiding exposure of aspect-ratio to the client. v3: As suggested by Pekka Paalanen, added aspect_ratio field to store aspect-ratio information from the drm. Also added drm client capability for aspect-ratio, as recommended by Daniel Vetter. v4: Minor modifications and fixes as suggested by Pekka Paalanen. v5: Rebased, fixed some styling issues, and added aspect-ratio information while printing weston_modes. v6: Moved the man pages changes to a different patch. Minor reorganization of code as suggested by Pekka Paalanen. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> [Pekka: replace ARRAY_SIZE with ARRAY_LENGTH] Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
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 parameter, of a video mode, like h/vactive,h/vfront h/vback etc., including aspect-ratio information. The drm layer, specifies the aspect-ratio information in user-mode flag bits 19-22. For the non-CEA modes a value of 0 is given in the aspect-ratio flag bits. Each CEA-mode is identified by a unique, Video Identification Code (VIC). For example, VIC=4 is 1280x720@60 aspect-ratio 16:9. This mode will be different than a non-CEA mode 1280x720@60 0:0. The new mode-format helps to differentiate between the CEA and non-CEA modes, by letting user specify aspect-ratio along with other paremeters: mode=widthxheight@rr ratio. This helps when certification testing is done, in tests like 7-27, the HDMI analyzer applies a particular CEA mode, and expects the applied mode to be with exactly same timings, including the aspect-ratio and VIC field. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
- Jul 05, 2018
-
-
Pekka Paalanen authored
This is regression apparently introduced in 0de859ed, which accidentally swapped the sign of 'delta_width' in the original call site. If one removes an output, the remaining outputs on the right are getting moved even further to the right. The outputs to the right should be moved to the left instead, to close the gap left by the removed output. Reported-by: Tomasz Olszak <olszak.tomasz@gmail.com> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Ian Ray <ian.ray@ge.com>
-
Pekka Paalanen authored
When the compositor has multiple outputs (not clones) and one of them is removed, the ones remaining to the right will be moved to close the gap. Because reflowing the remaining outputs happens before removing the wl_output global, we get the new output x,y before the removal. This causes us to consider the remaining output immediately to the right of the removed output to be a clone of the removed output whose x,y don't get updated. That will then hit the two assertions this patch removes. The reason the assertions were not actually hit is because of a compositor bug which moved the remaining outputs in the wrong direction. The next patch will fix the reflow, so we need this patch first to avoid the asserts. Remove the assertions and hand over the background and panel if the "clone" does not already have them. If the clone already has them, we destroy the unnecessary background and panel. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Marius Vlad <marius-cristian.vlad@nxp.com>
-
- Jul 03, 2018
-
-
Some modeline generators put out e.g. +HSync instead of +hsync. Accept that too since it's not ambigous. Signed-off-by: Guido Günther <agx@sigxcpu.org> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-