Re: wl_surface::attach(NULL) release previous buffer?
On Fri, 22 Sep 2023 15:47:13 +0100 John Cox wrote: > Hi > > >On 9/14/23 14:24, John Cox wrote: > > > >> Hi > >> > >> A, hopefully, simple question - should I expect a wl_buffer::release > >> event from the buffer previously committed to a surface after I've > >> attached (and invalidated & committed) a NULL buffer to the surface? it > >> doesn't seem to happen for me (I have WAYLAND_DEBUG=1 logs showing it > >> not happening). > >> > >> If I shouldn't expect a release - when is it safe to reuse/free the > >> buffer storage? > > > >The compositor may continue using the buffer even if you attach a null > >buffer to the wl_surface. For example, the compositor may do it to play > >an animation if the window is unmapped. > > You've completely lost me with this example. Are you suggesting that > the compositor is reusing my buffer for its own purposes? Not re-using, but simply for needing the old surface contents for longer than the client would expect. Window closing animations are a good example of that: if the window is unmapped (e.g. removing the contents by committing a NULL wl_buffer is a way to unmap a surface, if the surface role allows it), instead of removing the window from screen in the very next refresh, the compositor may start an animation instead where it needs the last known contents of the surface. The window might fade out, shrink and disappear, or fly away, whatever. The compositor needs the last contents to be able to draw that animation over time. From client perspective there is no difference on the wl_surface though, the window is unmapped immediately when the compositor processes the unmapping request. The client does not know about any closing animation, it only sees the buffer release taking a relatively long time. During the closing animation, the compositor won't send input on the wl_surface etc. because from the client perspective it was already unmapped. What's being animated is just a ghost of a window. Thanks, pq pgp84W8o3j3VK.pgp Description: OpenPGP digital signature
Re: [PATCH RFC v6 09/10] drm/msm/dpu: Use DRM solid_fill property
On Tue, 29 Aug 2023 at 03:06, Jessica Zhang wrote:
>
> Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
> determine if the plane is solid fill. In addition drop the DPU plane
> color_fill field as we can now use drm_plane_state.solid_fill instead,
> and pass in drm_plane_state.alpha to _dpu_plane_color_fill_pipe() to
> allow userspace to configure the alpha value for the solid fill color.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 37
> +--
> 1 file changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index 114c803ff99b..639ecbeeacf8 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -42,7 +42,6 @@
> #define SHARP_SMOOTH_THR_DEFAULT 8
> #define SHARP_NOISE_THR_DEFAULT2
>
> -#define DPU_PLANE_COLOR_FILL_FLAG BIT(31)
> #define DPU_ZPOS_MAX 255
>
> /*
> @@ -82,7 +81,6 @@ struct dpu_plane {
>
> enum dpu_sspp pipe;
>
> - uint32_t color_fill;
> bool is_error;
> bool is_rt_pipe;
> const struct dpu_mdss_cfg *catalog;
> @@ -606,19 +604,35 @@ static void _dpu_plane_color_fill_pipe(struct
> dpu_plane_state *pstate,
> _dpu_plane_setup_scaler(pipe, fmt, true, &pipe_cfg, pstate->rotation);
> }
>
> +static uint32_t _dpu_plane_get_abgr_fill_color(struct drm_plane_state *state)
> +{
> + struct drm_solid_fill solid_fill = state->solid_fill;
> +
> + uint32_t ret = 0;
> + uint8_t a = state->alpha & 0xFF;
> + uint8_t b = solid_fill.b >> 24;
> + uint8_t g = solid_fill.g >> 24;
> + uint8_t r = solid_fill.r >> 24;
> +
> + ret |= a << 24;
> + ret |= b << 16;
> + ret |= g << 8;
> + ret |= r;
> +
> + return ret;
> +}
> +
> /**
> * _dpu_plane_color_fill - enables color fill on plane
> * @pdpu: Pointer to DPU plane object
> * @color: RGB fill color value, [23..16] Blue, [15..8] Green, [7..0] Red
> * @alpha: 8-bit fill alpha value, 255 selects 100% alpha
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:632: warning: Excess
function parameter 'alpha' description in '_dpu_plane_color_fill'
> */
> -static void _dpu_plane_color_fill(struct dpu_plane *pdpu,
> - uint32_t color, uint32_t alpha)
> +static void _dpu_plane_color_fill(struct dpu_plane *pdpu, uint32_t color)
> {
> const struct dpu_format *fmt;
> const struct drm_plane *plane = &pdpu->base;
> struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
> - u32 fill_color = (color & 0xFF) | ((alpha & 0xFF) << 24);
>
> DPU_DEBUG_PLANE(pdpu, "\n");
>
> @@ -633,11 +647,11 @@ static void _dpu_plane_color_fill(struct dpu_plane
> *pdpu,
>
> /* update sspp */
> _dpu_plane_color_fill_pipe(pstate, &pstate->pipe,
> &pstate->pipe_cfg.dst_rect,
> - fill_color, fmt);
> + color, fmt);
>
> if (pstate->r_pipe.sspp)
> _dpu_plane_color_fill_pipe(pstate, &pstate->r_pipe,
> &pstate->r_pipe_cfg.dst_rect,
> - fill_color, fmt);
> + color, fmt);
> }
>
> static int dpu_plane_prepare_fb(struct drm_plane *plane,
> @@ -976,10 +990,9 @@ void dpu_plane_flush(struct drm_plane *plane)
> */
> if (pdpu->is_error)
> /* force white frame with 100% alpha pipe output on error */
> - _dpu_plane_color_fill(pdpu, 0xFF, 0xFF);
> - else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
> - /* force 100% alpha */
> - _dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
> + _dpu_plane_color_fill(pdpu, 0x);
> + else if (drm_plane_solid_fill_enabled(plane->state))
> + _dpu_plane_color_fill(pdpu,
> _dpu_plane_get_abgr_fill_color(plane->state));
> else {
> dpu_plane_flush_csc(pdpu, &pstate->pipe);
> dpu_plane_flush_csc(pdpu, &pstate->r_pipe);
> @@ -1024,7 +1037,7 @@ static void dpu_plane_sspp_update_pipe(struct drm_plane
> *plane,
> }
>
> /* override for color fill */
> - if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG) {
> + if (drm_plane_solid_fill_enabled(plane->state)) {
> _dpu_plane_set_qos_ctrl(plane, pipe, false);
>
> /* skip remaining processing on color fill */
>
> --
> 2.42.0
>
--
With best wishes
Dmitry
Re: Questions about object ID lifetimes
On Wed, 20 Sep 2023 10:05:51 -0400 jleivent wrote: > .. > Here's a very wild suggestion that would eliminate it and still > be compatible with Wayland 1. Add a delete_id request without > modifying the existing protocol. I have a delete_id request hack, enhanced zombies everywhere, a LRU ring for zombie reuse (when there's no delete_id requests) on the server, all with full compatibility maintained and no protocol additions (so it's fully drop-in compatible for clients and servers) building and running in my limited testing on my jonleivent/wayland-idfix fork. My README explains it in depth. I would like this to eventually become a pull request, but I need to do more testing first. Which brings me to my question: How do I get CI/CD capability turned on? I tried building the unit tests locally, but get errors that suggest those tests need to be run in CI. Issue 540 says I need to apply for the guest role - how do I do that? Thanks, Jon
race between (say) wl_display_sync and wl_callback_add_listener?
Hi Assuming I have a separate poll/read_events/dispatch_queue thread to my main thread. If I go wl_display_sync/wl_callback_add_listener on the main thread is there a race condition between those two calls where the other thread can read & dispatch the callback before the listener is added or is there some magic s.t. adding the listener will always work as expected? I assume it must be safe if dispatch & create/add_listener are in the same thread. The same question applies to adding listeners after binding (say) the shm extension where the bind provokes a set of events giving formats. Is there a safe way of doing this? (mutex around the dispatch and create/add_listener pairs would seem plausible even if really not what I want to do) Many thanks John Cox
