From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A66AF3FB7C7 for ; Fri, 10 Jul 2026 17:01:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783702898; cv=none; b=CDLLThBMq50g0RM/wY6Wi8cPpwaCrzyRu2W01LP0v2Os7sCd7KrP2TcbUjT+7PZMsqnfErV7qUUMOLvyeyY6kg/e0P0I9pusAVMRbICP2yIfM8jJ4yWu07a/BDxjXjf+MCqEQz1ZrPH5yuJnjgrEsIEmdF1kPnPkJPYurcpcUr0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783702898; c=relaxed/simple; bh=GvZfgytVFcjNlrh2tT1YWDpKLlk9i9kn2ssXGiBbbxU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GoziINU+mZtXmks7obrMzi/VVxWM1Z7GEUHJROTeP0RT8kiSMPYEA6Ti/WzW5gGB3BSxXsCLz90dUCW20zWjAZBUJ4DGzMFCzaZZjq2xQNbPKbpv56xkcyGovM0OQmB51c96eWA9MbRWRIeNTNKTs7vttP9jhy9HCn/50chlBeU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=Q754yrp4; arc=none smtp.client-ip=80.241.56.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="Q754yrp4" Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4gxdQk1wVwzKvvm; Fri, 10 Jul 2026 19:01:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1783702894; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SKzHnlIZLuU1Xzuk8UDxJlC4nU1oQy2BzPSlzIVSSK0=; b=Q754yrp4hHbS7WTz4vrIm0drqEWhrSKv+2okAvi4W7B07sDTUWmh+g78x/WBI6PHnlJzY8 CFDLZBnGsMIKQA6wsbmdZ/+twzoA/+zYZMi/HqLfvLMzP1VUZuUEkVXbBrbzFmoLL8mXEZ KJab2YheSWuYrHnJsaMQ9v4eqSBUIEciQCIHrD/DD57minzO62xpx3pvH2PmY7XxNadl4t q9z21u3fDMy7hH03qMjkBrVbz/PnyKoZ0Jg+7RTBs6FoqIl/jFC0msj+Bh/9L6ddZn8bnS DUqngSlSxrbDhxOIWy3P7wNzZGsXNyGHR7GeTpyCeQt8wRMgkT+8xEwcAibCLA== Message-ID: Date: Fri, 10 Jul 2026 19:01:29 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH RFC 0/8] drm: Add DRM_MODE_ATOMIC_RESET flag To: Maxime Ripard , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter Cc: Daniel Stone , Harry Wentland , =?UTF-8?Q?Jonas_=C3=85dahl?= , Pekka Paalanen , Sebastian Wick , Simon Ser , Victoria Brekenfeld , Xaver Hugl , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20260708-drm-reset-state-flag-v1-0-c37dc985485d@kernel.org> From: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Language: en-CA In-Reply-To: <20260708-drm-reset-state-flag-v1-0-c37dc985485d@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-ID: f430b2d2da537883163 X-MBO-RS-META: 5m4tntjbid6zrwgj6ur5y1fq18rhoma1 On 7/8/26 18:08, Maxime Ripard wrote: > > Userspace currently has no atomic way to bring a display pipeline back > to a pristine state. A compositor that wants to start from a known > baseline must explicitly set every property on every KMS object to its > default value, which requires tracking which properties exist and what > their defaults are. This is fragile and must be updated every time a > new property is added to the kernel. > > This series introduces a new DRM_MODE_ATOMIC_RESET flag for the > atomic ioctl. When set, the kernel fills the commit with default > states for all KMS objects before applying the properties supplied in > the request. Properties not explicitly included remain at their > defaults (CRTCs inactive, planes disabled, connectors unbound, and so > on). This allows userspace to describe the desired end state > declaratively, without having to care about the current state or the > full set of properties. Nice! > Patch 8 wires it all up by adding DRM_MODE_ATOMIC_RESET to the atomic > ioctl. The new flag should be accompanied by a new DRM_CAP_* cap, so user space knows when the new flag is valid. > This series is untested and relies on all drivers implementing the > atomic_create_state hook, which is not yet the case. The conversion > is actively in progress but not complete, so this will not work as-is > today. As discussed on IRC, the new cap could be made conditional on the atomic_create_state hook being available. That would allow this series to land before all in-tree drivers are converted. (As a bonus, it would also avoid issues with out-of-tree drivers which might not support the atomic_create_state hook) -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast