Hi Ruben, On 4/1/26 03:18, Ruben Wauters wrote: > Hi > > This does work, however this ends up returning 0, which implies that > the atomic check succeded. In my opinion in this case, -EINVAL should > be returned, as both the crtc and fb don't exist, therefore the check > should not succeed. I would personally prefer a more explicit check > that does return -EINVAL instead of 0 from > drm_atomic_helper_check_planes()
> As a side note, I'm not sure if there's a reasoning as to why > drm_atomic_helper_check_planes() returns 0 if fb is NULL instead of > -EINVAL, I'm assuming it's not designed to come across this specific > case. Either way it's not too much of an issue but maybe one of the drm > maintainers can clarify why it's this way. Maybe this is a result of the atomic conversions? It's possible that now we get passed NULLs on hotplug and display disables. (I didn't know enough about DRM to be sure and didn't reference that commit in the previous email). I think a return of 0 should be it - both exynos_plane_atomic_check()[1] and virtio_gpu_plane_atomic_check()[2] return 0 on either a NULL fb or crtc - I've tried returning -EINVAL and KDE can no longer disable the display because the rejection is being propagated back to userspace. I'll respin this patch to return 0 after an explicit check and include another NULL dereference fix in the plane update path. Thanks, Shenghao [1] https://elixir.bootlin.com/linux/v6.18.2/source/drivers/gpu/drm/exynos/exynos_drm_plane.c#L231 [2] https://elixir.bootlin.com/linux/v6.18.2/C/ident/virtio_gpu_plane_atomic_check
