Commits on Source (26)
-
Daniel Stone authored
It's possible to write this with a few less twisty special cases. Tested manually with a randomly-distributed input tree as well as manually trying to hit special cases around first/last entries. Signed-off-by: Daniel Stone <daniels@collabora.com>
7ca7c145 -
Daniel Stone authored
Rather than constructing a zpos-sorted list every time, just have plane_list be pre-sorted. Signed-off-by: Daniel Stone <daniels@collabora.com>
66098404 -
Daniel Stone authored
Signed-off-by: Daniel Stone <daniels@collabora.com>
af42fc1e -
Daniel Stone authored
GBM is how we import all our client content into DRM FBs, so don't try anything other than renderer-only without it. Signed-off-by: Daniel Stone <daniels@collabora.com>
075c4ac2 -
Daniel Stone authored
Each output is hardcoded to the use of a single 'special' (primary or cursor) plane; make sure we don't try to steal them from other outputs which might not be happy to discover that we've taken it off them. Signed-off-by: Daniel Stone <daniels@collabora.com>
d5ec9a1a -
Daniel Stone authored
It won't work. Signed-off-by: Daniel Stone <daniels@collabora.com>
66244856 -
Daniel Stone authored
If we have a SHM buffer, it can only go into a cursor plane - and only then if it's of the right format. Signed-off-by: Daniel Stone <daniels@collabora.com>
ca4c2865 -
Daniel Stone authored
We know what our limit is for cursor planes, so don't try to assign a view which is too large. Signed-off-by: Daniel Stone <daniels@collabora.com>
6aec64b2 -
Daniel Stone authored
If we're in renderer-only mode, we can only use the renderer and the cursor plane. Don't even try to import client buffers as it makes no sense. Signed-off-by: Daniel Stone <daniels@collabora.com>
9c6a0694 -
Daniel Stone authored
For better or worse, cursor planes can only be used by uploaded SHM buffers right now, so ignore them when we're calculating the acceptable plane mask for client dmabufs. Signed-off-by: Daniel Stone <daniels@collabora.com>
26c2f9a6 -
Daniel Stone authored
Signed-off-by: Daniel Stone <daniels@collabora.com>
23257c07 -
Daniel Stone authored
When we introduced support for variable zpos, we did so by filtering the list of acceptable planes and then creating a separate zpos-ordered list. Now that the planes are already zpos-sorted in the backend list, and we have more early filtering, we can replace this with a single plane-list walk. Signed-off-by: Daniel Stone <daniels@collabora.com>
e5ad3c88 -
Daniel Stone authored
No point trying to place a cursor buffer on a plane when we can't do cursor planes. Signed-off-by: Daniel Stone <daniels@collabora.com>
ae60745b -
Daniel Stone authored
No point trying to put something on the scanout plane in mixed mode. Signed-off-by: Daniel Stone <daniels@collabora.com>
0ecd6c3d -
Daniel Stone authored
This makes it a bit more clear and easy to follow, rather than diving through if nesting. Signed-off-by: Daniel Stone <daniels@collabora.com>
b3d7df5c -
Daniel Stone authored
We shouldn't get down into trying to place a view on a cursor plane if these checks are not met, so change them to asserts rather than early returns. Signed-off-by: Daniel Stone <daniels@collabora.com>
5e41b44b -
Daniel Stone authored
For views which cover the entire output, we always attempt to place them on the primary plane, to avoid a situation where we place a fullscreen view into an overlay plane and then have to disable the primary plane, which doesn't always work. Move this check earlier, so we don't consider overlay planes to be candidates for fullscreen views. This check should be changed in future to only filter for opaque views, but that's for another time. Signed-off-by: Daniel Stone <daniels@collabora.com>
dc0de9ee -
Daniel Stone authored
You'd think this would go without saying, but no, we just sort of buried that. Signed-off-by: Daniel Stone <daniels@collabora.com>
6b828c7b -
Daniel Stone authored
We already guarantee this from the caller. Signed-off-by: Daniel Stone <daniels@collabora.com>
1b34c5cd -
Daniel Stone authored
No need for this to be specialised within both overlay and scanout plane paths. Signed-off-by: Daniel Stone <daniels@collabora.com>
2dd3af3c -
Daniel Stone authored
At some point this got hobbled, such that NO_PLANES and NO_PLANES_ACCEPTED became the same thing, so we can just check if the returned plane_state is NULL or not. Signed-off-by: Daniel Stone <daniels@collabora.com>
e1114228 -
Daniel Stone authored
Signed-off-by: Daniel Stone <daniels@collabora.com>
873e3213 -
Daniel Stone authored
We just copy the SHM buffer straight into a separately-allocated GBM BO, so no need to take a reference on the buffer itself or keep it from being released. All drm_output_try_view_on_plane really does at this point is to call the prepare_*_view function for the requisite plane type, and take a ref on the weston_buffer from the client. Given that we don't need to keep the client buffer alive, we can short-circuit drm_output_try_view_on_plane, and instead just call drm_output_prepare_cursor_view directly when we have a cursor plane. This also makes it easier to just remove drm_output_try_view_on_plane in following patches when we merge the overlay/scanout plane path into one. Doing so gives us two clearly-separated paths: one for copying a SHM client buffer into a cursor, and another for directly scanning out client content. Signed-off-by: Daniel Stone <daniels@collabora.com>
81e74ff3 -
Daniel Stone authored
There's no real reason for these to be separate now that the eligibility checks have been moved up so we don't call them unless it makes sense. Signed-off-by: Daniel Stone <daniels@collabora.com>
0ace8b66 -
Daniel Stone authored
This lets us clean up a bit of code. Signed-off-by: Daniel Stone <daniels@collabora.com>
a2c5709e -
Daniel Stone authored
Specifically log if there were no suitable planes for us to use, or if we tried to place it on a plane but were told no by the kernel. Signed-off-by: Daniel Stone <daniels@collabora.com>
30de9386
This diff is collapsed.