From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5ED9FC02183 for ; Fri, 17 Jan 2025 11:32:36 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3871B10EAD0; Fri, 17 Jan 2025 11:32:35 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="PNyhJPE0"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) by gabe.freedesktop.org (Postfix) with ESMTPS id CF9E110EAD0 for ; Fri, 17 Jan 2025 11:32:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737113553; x=1768649553; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=AfDGpHESyc1zgDyFDFxzT4DuGT0R/BIGxgTzd17JmLs=; b=PNyhJPE0W+I6IJvi4YmbUAjq+DdFOFmM594uFZWYDFlM9/WhqTI3TFwc 6MaFJaf/uGZ7UM+8e30fyua2IbYFQhvnWopwVAYISPi6jaPYmJubkxrMG f40Vm/Wg8ZXGvASnhDvbSdqIFrvjC0P7Ai9KKgkRjNATArnN/dzgACFpG r40TTLSkFRyUqcrUWQcLpojWY104Q+kVK1/1IoNXtEpoKV3EGNyrXBot/ FAFuT69nHZdLDygIZ279h9hQ3OXE71FtN53chDxrjjPCyYkT0riVZumUQ 8S6zni4u2X6SOWVpZg32M7PnL+WQbBPd3cMO2t4yGaBBzudfkHCrrUY/G A==; X-CSE-ConnectionGUID: ANCRALzqTWm1aadn+8iS2A== X-CSE-MsgGUID: NM+RfAAARpWOtXm8EvNXVg== X-IronPort-AV: E=McAfee;i="6700,10204,11317"; a="37454494" X-IronPort-AV: E=Sophos;i="6.13,212,1732608000"; d="scan'208";a="37454494" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2025 03:32:33 -0800 X-CSE-ConnectionGUID: zyUisJjVSgm4qN8pfEJjZw== X-CSE-MsgGUID: eRVSpHkqRGScfSUOe8aRMw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,212,1732608000"; d="scan'208";a="105968500" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.74]) by fmviesa008.fm.intel.com with SMTP; 17 Jan 2025 03:32:31 -0800 Received: by stinkbox (sSMTP sendmail emulation); Fri, 17 Jan 2025 13:32:30 +0200 Date: Fri, 17 Jan 2025 13:32:30 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Simon Ser Cc: dri-devel@lists.freedesktop.org, Simona Vetter , Pekka Paalanen , David Turner Subject: Re: [PATCH] drm: document DRM_MODE_PAGE_FLIP_EVENT interactions with atomic Message-ID: References: <20250116162528.2235991-1-contact@emersion.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250116162528.2235991-1-contact@emersion.fr> X-Patchwork-Hint: comment X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Jan 16, 2025 at 04:25:35PM +0000, Simon Ser wrote: > It's not obvious off-hand which CRTCs will get a page-flip event > when using this flag in an atomic commit, because it's all > implicitly implied based on the contents of the atomic commit. > Document requirements for using this flag and > > Note, because prepare_signaling() runs right after > drm_atomic_set_property() calls, page-flip events are not delivered > for CRTCs pulled in later by DRM core (e.g. on modeset by > drm_atomic_helper_check_modeset()) or the driver (e.g. other CRTCs > sharing a DP-MST connector). > > Signed-off-by: Simon Ser > Cc: Simona Vetter > Cc: Ville Syrjälä > Cc: Pekka Paalanen > Cc: David Turner > --- > include/uapi/drm/drm_mode.h | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index c082810c08a8..a122bea25593 100644 > --- a/include/uapi/drm/drm_mode.h > +++ b/include/uapi/drm/drm_mode.h > @@ -962,6 +962,14 @@ struct hdr_output_metadata { > * Request that the kernel sends back a vblank event (see > * struct drm_event_vblank) with the &DRM_EVENT_FLIP_COMPLETE type when the > * page-flip is done. > + * > + * When used with atomic uAPI, one event will be delivered per CRTC included in > + * the atomic commit. A CRTC is included in an atomic commit if one of its > + * properties is set, or if a property is set on a connector or plane linked > + * via the CRTC_ID property to the CRTC. At least one CRTC must be included, > + * and all pulled in CRTCs must be either previously or newly powered on (in > + * other words, a powered off CRTC which stays off cannot be included in the > + * atomic commit). I don't understand all this stuff about powered off crtcs? If someone sucks in a powered off thing then things will generally work just fine. There is a bit of corner case with the way we internally complete the commits for disabled things (not just crtcs, but also planes and connectors) and that can apparently happen a bit later than the commit completion for the enabled things. That seems to be causing a bit of grief for sway which insists on adding all kinds of disabled planes to every commit: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13410 -- Ville Syrjälä Intel