From patchwork Mon Jun 23 08:19:22 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= X-Patchwork-Id: 23623 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id 9AD56C3237 for ; Mon, 23 Jun 2025 08:19:29 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id A740C68DE5; Mon, 23 Jun 2025 10:19:28 +0200 (CEST) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="JxwoQ3Mo"; dkim-atps=neutral Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id C415F61533 for ; Mon, 23 Jun 2025 10:19:26 +0200 (CEST) Received: from pb-laptop.local (185.221.143.107.nat.pool.zt.hu [185.221.143.107]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 19BDED77; Mon, 23 Jun 2025 10:19:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1750666750; bh=RTM2GRhF6kpTbiaBEF6o46PS5c5ERNWe+rvtJT7TwYs=; h=From:To:Subject:Date:From; b=JxwoQ3MoK6tV6nMH5+w+6PM7sOVnzVMAgympPVUTMu9BNvzR+Xk+GzaiAOvhezs6p Xlw/Ax2HKIyUKvfvXsen5WK7jac7LxF6CyW7Q75oqelVPXU8CDspwtTLxGYM1nH1UA RjjrtVh4W1LbFskb1ZSfIInH14sP6LePwjKfUC5M= From: =?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= To: libcamera-devel@lists.libcamera.org, David Plowman , Naushir Patuck Subject: [PATCH v1] libcamera: controls: Clarify units of `FrameWallClock` Date: Mon, 23 Jun 2025 10:19:22 +0200 Message-ID: <20250623081922.96900-1-barnabas.pocze@ideasonboard.com> X-Mailer: git-send-email 2.50.0 MIME-Version: 1.0 X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" The description of the control mentions SensorTimestamp multiple times, but it omits that the two do not have the same units. Clarify that. Signed-off-by: Barnabás Pőcze Reviewed-by: Naushir Patuck --- Or could it easily be converted to nanoseconds? Is there an overflow issue in the ClockRecovery class in that case? What was the motivation for making it μs? (I suppose nanosecond resolution is not that useful when synchronizing across a network, etc?) --- src/libcamera/control_ids_core.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.50.0 diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml index 028919ef3..0708ec7cc 100644 --- a/src/libcamera/control_ids_core.yaml +++ b/src/libcamera/control_ids_core.yaml @@ -1272,7 +1272,8 @@ controls: description: | This timestamp corresponds to the same moment in time as the SensorTimestamp, but is represented as a wall clock time as measured by - the CLOCK_REALTIME clock. + the CLOCK_REALTIME clock. Note that this control measures time in units + of microseconds as opposed to nanoseconds in case of SensorTimestamp. Being a wall clock measurement, it can be used to synchronise timing across different devices.