[{"id":38606,"web_url":"https://patchwork.libcamera.org/comment/38606/","msgid":"","date":"2026-04-13T14:00:04","subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","submitter":{"id":143,"url":"https://patchwork.libcamera.org/api/people/143/","name":"Jacopo Mondi","email":"jacopo.mondi@ideasonboard.com"},"content":"Hi Hans\n let me ask a few questions\n\nOn Wed, Apr 08, 2026 at 01:56:27PM +0200, Hans de Goede wrote:\n> Hi All,\n>\n> On Qualcomm chips any CSI-phy can be connected to any CSI-decoder and\n> any CSI-decoder can be connected to any Video-Front-End (VFE, DMA write\n> engine and co). Basically there are 2 big cross-switches between PHYs\n> and decoders and between decoders and VFEs which can be controlled through\n> media-controller links.\n>\n> As such the entite CAMSS block with CSI-phys, decoders and VFEs is\n> represented to userspace as a single /dev/media# node.\n>\n> As long as active links from unrelated cameras are not touched when setting\n> up a new camera 2 independent raw data-streams can be run and managed by 2\n> different libcamera instances.\n>\n> But the standard locking of the /dev/media# node by the first libcamera\n> instance to start streaming from one of the cameras blocks this.\n>\n> This patch series allows pipeline-handlers to opt-out of the base\n> PipelineHandler MediaDevice locking and adds 2 helpers for pipeline\n> handlers to implement finer grained locking.\n>\n\nFirst one I have is: why 2 libcamera instances ? Doesn't libcamera\nregister one camera for each connected CSI-2 input ?\n\nI guess, however, limiting to a single libcamera instance where there\nactually is no need to, might be too restrictive ?\n\n> This is the second of 3 series which together introduce the camss pipeline\n> handler. Here is a branch with all 3 series:\n> https://github.com/jwrdegoede/libcamera/commits/camss_pipeline_v1/\n>\n> I hope to get this prep series merged while work continues on the camss\n> pipeline handler itself.\n>\n> For an example of how to use this, see this commmit implementing finer\n> grained locking for the camss pipeline handler:\n>\n> https://github.com/jwrdegoede/libcamera/commit/4ffd7b47119978940b543ad0914bf46c767573ad\n>\n> For the first patch an alternative approach would be add a lockingRequired\n> flag to the MediaDevice class, allowing opting out of the locking on a per\n> media device base.\n\nTo me this indeed sounds like we need a finer grained control over the\nlocking of the media devices.\n\nCould 'bool PipelineHandler::acquire(Camera *camera);' become a virtual\nfunction to delegate the finer-grained locking to pipeline handlers ?\n\n>\n> Regards,\n>\n> Hans\n>\n>\n> Hans de Goede (3):\n> libcamera: pipeline: Allow pipeline-handlers to opt out of locking the\n> media devices\n> libcamera: media_object: Add MediaEntity::disableLinks()\n> libcamera: v4l2_device: add lock() and unlock() methods\n>\n> include/libcamera/internal/media_object.h | 1 +\n> include/libcamera/internal/pipeline_handler.h | 2 +\n> include/libcamera/internal/v4l2_device.h | 3 ++\n> src/libcamera/media_device.cpp | 16 ++------\n> src/libcamera/media_object.cpp | 27 ++++++++++++++\n> src/libcamera/pipeline_handler.cpp | 8 ++--\n> src/libcamera/v4l2_device.cpp | 37 +++++++++++++++++++\n> 7 files changed, 77 insertions(+), 17 deletions(-)\n>\n> --\n> 2.53.0\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id ABD40C32BB\n\tfor ;\n\tMon, 13 Apr 2026 14:00:09 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id C05DC62E90;\n\tMon, 13 Apr 2026 16:00:08 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 4CE316271A\n\tfor ;\n\tMon, 13 Apr 2026 16:00:07 +0200 (CEST)","from ideasonboard.com (93-46-82-201.ip106.fastwebnet.it\n\t[93.46.82.201])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 50D7C7FE;\n\tMon, 13 Apr 2026 15:58:35 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"XE60e4Tn\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1776088715;\n\tbh=XN2BAN8r/QLSsyqLWBHNFhhl6TrLmjSTqc7gvWJq4QQ=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=XE60e4TnJrA3RUd9Wdjlglng12JJ7PoTjCk6u4S2OsAJIpWXRZLpXkINm8JilxAop\n\t+hTWLSQaP54j328EEJBT3GJhflIFBTZMdmVzGoNsEHkWuF8NCbf1RtJKiAnkiSR0Kb\n\toY4g52zE84mbqByQLEYbvzVUwMsDisIc7VKC/AGc=","Date":"Mon, 13 Apr 2026 16:00:04 +0200","From":"Jacopo Mondi ","To":"Hans de Goede ","Cc":"libcamera-devel@lists.libcamera.org, \n\tLoic Poulain ","Subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","Message-ID":"","References":"<20260408115630.12456-1-johannes.goede@oss.qualcomm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20260408115630.12456-1-johannes.goede@oss.qualcomm.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":38607,"web_url":"https://patchwork.libcamera.org/comment/38607/","msgid":"","date":"2026-04-13T14:10:57","subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","submitter":{"id":242,"url":"https://patchwork.libcamera.org/api/people/242/","name":"Hans de Goede","email":"johannes.goede@oss.qualcomm.com"},"content":"Hi,\n\nOn 13-Apr-26 4:00 PM, Jacopo Mondi wrote:\n> Hi Hans\n> let me ask a few questions\n> \n> On Wed, Apr 08, 2026 at 01:56:27PM +0200, Hans de Goede wrote:\n>> Hi All,\n>>\n>> On Qualcomm chips any CSI-phy can be connected to any CSI-decoder and\n>> any CSI-decoder can be connected to any Video-Front-End (VFE, DMA write\n>> engine and co). Basically there are 2 big cross-switches between PHYs\n>> and decoders and between decoders and VFEs which can be controlled through\n>> media-controller links.\n>>\n>> As such the entite CAMSS block with CSI-phys, decoders and VFEs is\n>> represented to userspace as a single /dev/media# node.\n>>\n>> As long as active links from unrelated cameras are not touched when setting\n>> up a new camera 2 independent raw data-streams can be run and managed by 2\n>> different libcamera instances.\n>>\n>> But the standard locking of the /dev/media# node by the first libcamera\n>> instance to start streaming from one of the cameras blocks this.\n>>\n>> This patch series allows pipeline-handlers to opt-out of the base\n>> PipelineHandler MediaDevice locking and adds 2 helpers for pipeline\n>> handlers to implement finer grained locking.\n>>\n> \n> First one I have is: why 2 libcamera instances ? Doesn't libcamera\n> register one camera for each connected CSI-2 input ?\n\nYes it does.\n\n> I guess, however, limiting to a single libcamera instance where there\n> actually is no need to, might be too restrictive ?\n\nRight, e.g. users may want to use gst-launch twice to launch 2 gst-pipelines\neach accessing a single camera.\n\n\n> \n>> This is the second of 3 series which together introduce the camss pipeline\n>> handler. Here is a branch with all 3 series:\n>> https://github.com/jwrdegoede/libcamera/commits/camss_pipeline_v1/\n>>\n>> I hope to get this prep series merged while work continues on the camss\n>> pipeline handler itself.\n>>\n>> For an example of how to use this, see this commmit implementing finer\n>> grained locking for the camss pipeline handler:\n>>\n>> https://github.com/jwrdegoede/libcamera/commit/4ffd7b47119978940b543ad0914bf46c767573ad\n>>\n>> For the first patch an alternative approach would be add a lockingRequired\n>> flag to the MediaDevice class, allowing opting out of the locking on a per\n>> media device base.\n> \n> To me this indeed sounds like we need a finer grained control over the\n> locking of the media devices.\n> \n> Could 'bool PipelineHandler::acquire(Camera *camera);' become a virtual\n> function to delegate the finer-grained locking to pipeline handlers ?\n\nThat would also be an option yes. But currently the locking is something\n\"owned\" by the core which must not be touched by pipeline handlers I tried\nto preserve that for pipeline handlers not opting out.\n\nE.g. MediaDevice::lock()'s doxygen comment says:\n\nWith that said I've no objection against making PipelineHandler::acquire()\nvirtual and updating the doc text here a bit to say, e.g. :\n\n * The base PipelineHandler implementation handles MediaDevice locking\n * on behalf of the specified implementation, so this function should not be\n * called from a pipeline handler implementation directly.\n * Optionally a pipeline handler may opt out of the base PipelineHandler\n * locking by overriding PipelineHandler::acquire().\n\nRegards,\n\nHans\n\n\n\n>> Hans de Goede (3):\n>> libcamera: pipeline: Allow pipeline-handlers to opt out of locking the\n>> media devices\n>> libcamera: media_object: Add MediaEntity::disableLinks()\n>> libcamera: v4l2_device: add lock() and unlock() methods\n>>\n>> include/libcamera/internal/media_object.h | 1 +\n>> include/libcamera/internal/pipeline_handler.h | 2 +\n>> include/libcamera/internal/v4l2_device.h | 3 ++\n>> src/libcamera/media_device.cpp | 16 ++------\n>> src/libcamera/media_object.cpp | 27 ++++++++++++++\n>> src/libcamera/pipeline_handler.cpp | 8 ++--\n>> src/libcamera/v4l2_device.cpp | 37 +++++++++++++++++++\n>> 7 files changed, 77 insertions(+), 17 deletions(-)\n>>\n>> --\n>> 2.53.0\n>>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 11351BDCBD\n\tfor ;\n\tMon, 13 Apr 2026 14:11:08 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 3A7C962E93;\n\tMon, 13 Apr 2026 16:11:07 +0200 (CEST)","from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com\n\t[205.220.180.131])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 16D366271A\n\tfor ;\n\tMon, 13 Apr 2026 16:11:04 +0200 (CEST)","from pps.filterd (m0279869.ppops.net [127.0.0.1])\n\tby mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n\t63DCZE3G3989205 for ;\n\tMon, 13 Apr 2026 14:11:01 GMT","from mail-vk1-f199.google.com (mail-vk1-f199.google.com\n\t[209.85.221.199])\n\tby mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4dh0mfrd78-1\n\t(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)\n\tfor ;\n\tMon, 13 Apr 2026 14:11:01 +0000 (GMT)","by mail-vk1-f199.google.com with SMTP id\n\t71dfb90a1353d-56b6751339fso9513628e0c.1\n\tfor ;\n\tMon, 13 Apr 2026 07:11:01 -0700 (PDT)","from [10.40.99.10] ([78.108.130.194])\n\tby smtp.gmail.com with ESMTPSA id\n\t4fb4d7f45d1cf-67070815d27sm2448229a12.24.2026.04.13.07.10.58\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 13 Apr 2026 07:10:58 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=qualcomm.com header.i=@qualcomm.com\n\theader.b=\"SHuHhXfD\"; dkim=pass (2048-bit key;\n\tunprotected) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com\n\theader.b=\"A4Z8ZY95\"; dkim-atps=neutral","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=\n\tcc:content-transfer-encoding:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to; s=qcppdkim1; bh=\n\t/PD99OwfdiHRcMCxzgB0gNRRQGk76NAqnnVuzvXEKys=; b=SHuHhXfDJau2dVRL\n\t0M3Fz1EIh8reucA+Qv4m0qI3538D+5mpJsCAMPanIIQIgszwbABanPv68s9KkHTk\n\tDBm7bYPo4zqf3PjZK8C5CYxVyDkfshjZkzipWjFs+smzySpwrHgB+mkmL945CYKU\n\t05aV1VTnB5eUl3QWH+4QavVYOPamClCiQar/7r17m4mjrowIpE+dBRCWEC8jMM0B\n\tkwrLfxt2dxk1iBUZsUaTL2eMB2UrVYzbj4ZfO2+peIFe5jB0/wHLta3zT5jQ0nHM\n\tkE/tsT+dOSNnoBNIPKIitwuRO2+uQ46pYs+zQhak+k5FbxD+8zYyWPtxXLR1lnbC\n\tcPOmQQ==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=oss.qualcomm.com; s=google; t=1776089460; x=1776694260;\n\tdarn=lists.libcamera.org; \n\th=content-transfer-encoding:in-reply-to:content-language:references\n\t:cc:to:subject:from:user-agent:mime-version:date:message-id:from:to\n\t:cc:subject:date:message-id:reply-to;\n\tbh=/PD99OwfdiHRcMCxzgB0gNRRQGk76NAqnnVuzvXEKys=;\n\tb=A4Z8ZY95xGdk05xEOMutfwlF6P4mFb+F2XzpnE7HGxSUWn9zGj9kY1c4yVLgyoi+hw\n\tNQJpaAh3fhU9SjKU+E8FPArg7M3gMtHEqrN0wy2NYvNatuAE35VQnkiAYGdHrzGkSXst\n\tTztYZeDmYlg/wEfg2nqpXdle5E1dEp/RUYrY3fAThQ9ACeVupKvxFsqTvfohmyCvI1ku\n\tk93XJPTR4FEBS2TqmCSYlEN6aZzkwnGo+afQzE6uoufysaWoJKNGe6T+AxMXDZZFkNaS\n\tPqXfeOJ69TYSqsCQUvS1cPGa5Ofkjy4qsOtlmSv4M36qeRbjFEcISAT7QfXTDFZrTRmz\n\tlMbQ=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20251104; t=1776089460; x=1776694260;\n\th=content-transfer-encoding:in-reply-to:content-language:references\n\t:cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg\n\t:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n\tbh=/PD99OwfdiHRcMCxzgB0gNRRQGk76NAqnnVuzvXEKys=;\n\tb=sIxgSlm6qYSRhDrlU1ZZmLbhe+hkSMk07zRq9xNPPnBbbjxKEY/7NGFTh7xrUtO3VS\n\tAx+vb0TYprA8x/n/6hVGir1JLMNblejPJvGUn4yyvaMHxNJabKqAsraBZnc0p6FKrHNH\n\tIuN7yPYze1nMT0XQ37TGKmUkkQOb7rELvw8mO+qWNcE9ZA/0m5WrZOYa2vNWKBzQtw3h\n\tG5YZFt++2CRvrLFtIUjIP3oZ/3F43/sUIrNJ7ZRWJXi+YL4TEWF5EjH7LPzXfBCD1/un\n\tQMVDxjWmoOoYgOl6cTLWMHgVeOrQODXhn6sdW8emfvc9IMhAmkRVfDS5x5tC9oUqvl5/\n\to+sg==","X-Gm-Message-State":"AOJu0YzN8W8TQcz0AAksohwVk1KDjDvbRZYEUIxaFEYmlJcLKII2LDm1\n\tWvGkmDdZwXiZnJEk8BKlSUEtpU5tf7A8kRPL9wE9Bl3tr5/42yxseFYYZFb9wKiWMk84Vdaa2RV\n\tuV1IzkdOCyOa/HS3JZQU6+SxQQkRiJBaxdxm1xg+0bCFSU1/gMGxpXzaiv8GbsKW4nd/1qE1y4y\n\tP8","X-Gm-Gg":"AeBDiesIS8qHHU8u6WYNm+x/gszBXC7fPE/SB5pGJ5p3e4kzuxd80/6oEPCYVC/GU+d\n\tu4FxAOKANTQ+P+L4Cso14kX42vAVB22+yY6I78DLda3w+YK9cR9bv1yNlozT/GYqOLKcIQQDKai\n\tmBzxjs0nETkM9zZxe1dkigpj2qJHUOgHj9IPxM1cDqkTfXT9ZRhj3dmcixW7pTv0HM5eRjzxYRS\n\t4LnHu4qO1vObX8S+VIOgv+2lkHo10UC3//81+0CN3dCoGengarGamlpv2LEL/b3ALlw3kshoi28\n\tqmaOw07IReYvOMXDgpPrlBnc/V4ltUWTZQWmpJ61BSYP5f7b0LaCymwicksYxEOjH7ND11EImff\n\tV5aXyRlysjuBsTEvxdPdqCVGXHvOD9mliM+AaHsI/","X-Received":["by 2002:a05:6122:6e0e:b0:56b:8003:c2 with SMTP id\n\t71dfb90a1353d-56f29211237mr6693358e0c.8.1776089460453; \n\tMon, 13 Apr 2026 07:11:00 -0700 (PDT)","by 2002:a05:6122:6e0e:b0:56b:8003:c2 with SMTP id\n\t71dfb90a1353d-56f29211237mr6693322e0c.8.1776089459936; \n\tMon, 13 Apr 2026 07:10:59 -0700 (PDT)"],"Message-ID":"","Date":"Mon, 13 Apr 2026 16:10:57 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","From":"Hans de Goede ","Subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","To":"Jacopo Mondi ","Cc":"libcamera-devel@lists.libcamera.org,\n\tLoic Poulain ","References":"<20260408115630.12456-1-johannes.goede@oss.qualcomm.com>\n\t","Content-Language":"en-US, nl","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-Proofpoint-GUID":"T9_cfkBUC-SAtX1FeMSFHumAv-bhWels","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDEzMDEzOSBTYWx0ZWRfX32aUBx/syeMz\n\tuFVTtV0Wa8a2WPAKEffid/TApA6DpUgRG+X18nkiya02TW436erqFfDyxEEtU3hAGtVJNpnabqd\n\tqMwyRMGMjR42si9iQbVQ6JEVdju39eb/XQJjeytzIn0sr0J4Yef/SFwpPQ0jeByBrjnXUOI5jEb\n\te/3Dbi1XR41vVccuN+6hxcNqXWx2k7og+DtpMhqLugW9Oji10jLQE9d5wCR5ity8fsNaoDX3ek5\n\tKWbkk5eWWfeaStBGP4T4aaxx05LxJ+kO3SgqamPFPYP+dyLEPQQJtg+s6cqcuMny7N5h835Ue/C\n\tUr3oGE92L7e8klaePRFIIEqVaupiwru7tERWhhlIKnkxoTozwUzwLJgu3NXm6PoxTALwElD2j39\n\tSUMBux4YwZexnJQ8woe5dyziTvKmlEOZMvMnIINJshbxdzzPfGB4pVXN6qaC4Dwt2Fo5ECZ2TPt\n\tsn+PCy7t9dSYy4HWfgg==","X-Authority-Analysis":"v=2.4 cv=cMvQdFeN c=1 sm=1 tr=0 ts=69dcf975 cx=c_pps\n\ta=+D9SDfe9YZWTjADjLiQY5g==:117 a=rrvG0T/C2D967D07Ol03YQ==:17\n\ta=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=s4-Qcg_JpJYA:10\n\ta=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22\n\ta=_glEPmIy2e8OvE2BGh3C:22\n\ta=NEAV23lmAAAA:8 a=iMHkaabtj9LsoQxCflEA:9 a=QEXdDO2ut3YA:10\n\ta=vmgOmaN-Xu0dpDh8OwbV:22","X-Proofpoint-ORIG-GUID":"T9_cfkBUC-SAtX1FeMSFHumAv-bhWels","X-Proofpoint-Virus-Version":"vendor=baseguard\n\tengine=ICAP:2.0.293, Aquarius:18.0.1143, Hydra:6.1.51,\n\tFMLib:17.12.100.49\n\tdefinitions=2026-04-13_03,2026-04-13_03,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tsuspectscore=0 spamscore=0 priorityscore=1501 adultscore=0\n\timpostorscore=0\n\tmalwarescore=0 bulkscore=0 phishscore=0 clxscore=1015\n\tlowpriorityscore=0\n\tclassifier=typeunknown authscore=0 authtc= authcc= route=outbound\n\tadjust=0\n\treason=mlx scancount=1 engine=8.22.0-2604010000\n\tdefinitions=main-2604130139","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":38608,"web_url":"https://patchwork.libcamera.org/comment/38608/","msgid":"","date":"2026-04-13T14:30:53","subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","submitter":{"id":143,"url":"https://patchwork.libcamera.org/api/people/143/","name":"Jacopo Mondi","email":"jacopo.mondi@ideasonboard.com"},"content":"Hi Hans\n\nOn Mon, Apr 13, 2026 at 04:10:57PM +0200, Hans de Goede wrote:\n> Hi,\n>\n> On 13-Apr-26 4:00 PM, Jacopo Mondi wrote:\n> > Hi Hans\n> > let me ask a few questions\n> >\n> > On Wed, Apr 08, 2026 at 01:56:27PM +0200, Hans de Goede wrote:\n> >> Hi All,\n> >>\n> >> On Qualcomm chips any CSI-phy can be connected to any CSI-decoder and\n> >> any CSI-decoder can be connected to any Video-Front-End (VFE, DMA write\n> >> engine and co). Basically there are 2 big cross-switches between PHYs\n> >> and decoders and between decoders and VFEs which can be controlled through\n> >> media-controller links.\n> >>\n> >> As such the entite CAMSS block with CSI-phys, decoders and VFEs is\n> >> represented to userspace as a single /dev/media# node.\n> >>\n> >> As long as active links from unrelated cameras are not touched when setting\n> >> up a new camera 2 independent raw data-streams can be run and managed by 2\n> >> different libcamera instances.\n> >>\n> >> But the standard locking of the /dev/media# node by the first libcamera\n> >> instance to start streaming from one of the cameras blocks this.\n> >>\n> >> This patch series allows pipeline-handlers to opt-out of the base\n> >> PipelineHandler MediaDevice locking and adds 2 helpers for pipeline\n> >> handlers to implement finer grained locking.\n> >>\n> >\n> > First one I have is: why 2 libcamera instances ? Doesn't libcamera\n> > register one camera for each connected CSI-2 input ?\n>\n> Yes it does.\n>\n> > I guess, however, limiting to a single libcamera instance where there\n> > actually is no need to, might be too restrictive ?\n>\n> Right, e.g. users may want to use gst-launch twice to launch 2 gst-pipelines\n> each accessing a single camera.\n>\n\nI would say this is fair requirement\n\n>\n> >\n> >> This is the second of 3 series which together introduce the camss pipeline\n> >> handler. Here is a branch with all 3 series:\n> >> https://github.com/jwrdegoede/libcamera/commits/camss_pipeline_v1/\n> >>\n> >> I hope to get this prep series merged while work continues on the camss\n> >> pipeline handler itself.\n> >>\n> >> For an example of how to use this, see this commmit implementing finer\n> >> grained locking for the camss pipeline handler:\n> >>\n> >> https://github.com/jwrdegoede/libcamera/commit/4ffd7b47119978940b543ad0914bf46c767573ad\n> >>\n> >> For the first patch an alternative approach would be add a lockingRequired\n> >> flag to the MediaDevice class, allowing opting out of the locking on a per\n> >> media device base.\n> >\n> > To me this indeed sounds like we need a finer grained control over the\n> > locking of the media devices.\n> >\n> > Could 'bool PipelineHandler::acquire(Camera *camera);' become a virtual\n> > function to delegate the finer-grained locking to pipeline handlers ?\n>\n> That would also be an option yes. But currently the locking is something\n> \"owned\" by the core which must not be touched by pipeline handlers I tried\n> to preserve that for pipeline handlers not opting out.\n\nI'm suggesting a virtual not a pure virtual, so pipelines that are\nfine with the currently implemented mechanism won't need any change.\n\n>\n> E.g. MediaDevice::lock()'s doxygen comment says:\n\nDid you mean to paste:\n\n * \\brief Lock the device to prevent it from being used by other instances of\n * libcamera\n *\n * Multiple instances of libcamera might be running on the same system, at the\n * same time. To allow the different instances to coexist, system resources in\n * the form of media devices must be accessible for enumerating the cameras\n * they provide at all times, while still allowing an instance to lock a\n * resource while it prepares to actively use a camera from the resource.\n *\n * This function shall not be called from a pipeline handler implementation\n * directly, as the base PipelineHandler implementation handles this on the\n * behalf of the specified implementation.\n *\n\nThis however prevents designs like yours to work. It might be ideal for\ninline pipelines or m2m ones where each CSI-2 input lives in its own\nmedia graph, but it won't work if all CSI-2 inputs are part of the\nsame media graph; and I don't have argument against such designs at\nthe kernel level even if I might be missing them right now.\n\nGoing forward we actually want (ideally) a single system-wide media\ngraph. I don't think the locking granularity we have implemented today\nwould work there.\n\n>\n> With that said I've no objection against making PipelineHandler::acquire()\n> virtual and updating the doc text here a bit to say, e.g. :\n>\n> * The base PipelineHandler implementation handles MediaDevice locking\n> * on behalf of the specified implementation, so this function should not be\n> * called from a pipeline handler implementation directly.\n> * Optionally a pipeline handler may opt out of the base PipelineHandler\n> * locking by overriding PipelineHandler::acquire().\n>\n\nProviding a method override for PipelineHandler::lock() would be\nfunctionally an opt-out :)\n\nLet's see what others think\n\n> Regards,\n>\n> Hans\n>\n>\n>\n> >> Hans de Goede (3):\n> >> libcamera: pipeline: Allow pipeline-handlers to opt out of locking the\n> >> media devices\n> >> libcamera: media_object: Add MediaEntity::disableLinks()\n> >> libcamera: v4l2_device: add lock() and unlock() methods\n> >>\n> >> include/libcamera/internal/media_object.h | 1 +\n> >> include/libcamera/internal/pipeline_handler.h | 2 +\n> >> include/libcamera/internal/v4l2_device.h | 3 ++\n> >> src/libcamera/media_device.cpp | 16 ++------\n> >> src/libcamera/media_object.cpp | 27 ++++++++++++++\n> >> src/libcamera/pipeline_handler.cpp | 8 ++--\n> >> src/libcamera/v4l2_device.cpp | 37 +++++++++++++++++++\n> >> 7 files changed, 77 insertions(+), 17 deletions(-)\n> >>\n> >> --\n> >> 2.53.0\n> >>\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 99598C32BB\n\tfor ;\n\tMon, 13 Apr 2026 14:30:59 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id C497162E91;\n\tMon, 13 Apr 2026 16:30:58 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id C99B66271A\n\tfor ;\n\tMon, 13 Apr 2026 16:30:56 +0200 (CEST)","from ideasonboard.com (93-46-82-201.ip106.fastwebnet.it\n\t[93.46.82.201])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id BE56063D;\n\tMon, 13 Apr 2026 16:29:24 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"YdT7Pfyy\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1776090564;\n\tbh=aA1Y6IRuBiCDnmIMnBQ57eaSXRyRdgRmGTJTie/lzxw=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=YdT7PfyyAECc1y/AtP9BX6soFYMt0CjkOLqykgmLgIIvcYV2pnLsdlQ3Cd2q/o14t\n\to+NpwVIlV2RODc7AOChVBqGyNIrG1rps8cHGJx9ZLYom2mqHFwD8It9xqURLoDBdz7\n\ttzdiWjlc6PuKFS/J5m5DJYgHRZGTfKnH+XzlxyXc=","Date":"Mon, 13 Apr 2026 16:30:53 +0200","From":"Jacopo Mondi ","To":"Hans de Goede ","Cc":"Jacopo Mondi , \n\tlibcamera-devel@lists.libcamera.org,\n\tLoic Poulain ","Subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","Message-ID":"","References":"<20260408115630.12456-1-johannes.goede@oss.qualcomm.com>\n\t\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":38609,"web_url":"https://patchwork.libcamera.org/comment/38609/","msgid":"<537a8824-7b87-4863-84d8-cf83fd7c83e3@oss.qualcomm.com>","date":"2026-04-13T14:55:57","subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","submitter":{"id":242,"url":"https://patchwork.libcamera.org/api/people/242/","name":"Hans de Goede","email":"johannes.goede@oss.qualcomm.com"},"content":"Hi,\n\nOn 13-Apr-26 4:30 PM, Jacopo Mondi wrote:\n> Hi Hans\n> \n> On Mon, Apr 13, 2026 at 04:10:57PM +0200, Hans de Goede wrote:\n>> Hi,\n>>\n>> On 13-Apr-26 4:00 PM, Jacopo Mondi wrote:\n>>> Hi Hans\n>>> let me ask a few questions\n>>>\n>>> On Wed, Apr 08, 2026 at 01:56:27PM +0200, Hans de Goede wrote:\n>>>> Hi All,\n>>>>\n>>>> On Qualcomm chips any CSI-phy can be connected to any CSI-decoder and\n>>>> any CSI-decoder can be connected to any Video-Front-End (VFE, DMA write\n>>>> engine and co). Basically there are 2 big cross-switches between PHYs\n>>>> and decoders and between decoders and VFEs which can be controlled through\n>>>> media-controller links.\n>>>>\n>>>> As such the entite CAMSS block with CSI-phys, decoders and VFEs is\n>>>> represented to userspace as a single /dev/media# node.\n>>>>\n>>>> As long as active links from unrelated cameras are not touched when setting\n>>>> up a new camera 2 independent raw data-streams can be run and managed by 2\n>>>> different libcamera instances.\n>>>>\n>>>> But the standard locking of the /dev/media# node by the first libcamera\n>>>> instance to start streaming from one of the cameras blocks this.\n>>>>\n>>>> This patch series allows pipeline-handlers to opt-out of the base\n>>>> PipelineHandler MediaDevice locking and adds 2 helpers for pipeline\n>>>> handlers to implement finer grained locking.\n>>>>\n>>>\n>>> First one I have is: why 2 libcamera instances ? Doesn't libcamera\n>>> register one camera for each connected CSI-2 input ?\n>>\n>> Yes it does.\n>>\n>>> I guess, however, limiting to a single libcamera instance where there\n>>> actually is no need to, might be too restrictive ?\n>>\n>> Right, e.g. users may want to use gst-launch twice to launch 2 gst-pipelines\n>> each accessing a single camera.\n>>\n> \n> I would say this is fair requirement\n> \n>>\n>>>\n>>>> This is the second of 3 series which together introduce the camss pipeline\n>>>> handler. Here is a branch with all 3 series:\n>>>> https://github.com/jwrdegoede/libcamera/commits/camss_pipeline_v1/\n>>>>\n>>>> I hope to get this prep series merged while work continues on the camss\n>>>> pipeline handler itself.\n>>>>\n>>>> For an example of how to use this, see this commmit implementing finer\n>>>> grained locking for the camss pipeline handler:\n>>>>\n>>>> https://github.com/jwrdegoede/libcamera/commit/4ffd7b47119978940b543ad0914bf46c767573ad\n>>>>\n>>>> For the first patch an alternative approach would be add a lockingRequired\n>>>> flag to the MediaDevice class, allowing opting out of the locking on a per\n>>>> media device base.\n>>>\n>>> To me this indeed sounds like we need a finer grained control over the\n>>> locking of the media devices.\n>>>\n>>> Could 'bool PipelineHandler::acquire(Camera *camera);' become a virtual\n>>> function to delegate the finer-grained locking to pipeline handlers ?\n>>\n>> That would also be an option yes. But currently the locking is something\n>> \"owned\" by the core which must not be touched by pipeline handlers I tried\n>> to preserve that for pipeline handlers not opting out.\n> \n> I'm suggesting a virtual not a pure virtual, so pipelines that are\n> fine with the currently implemented mechanism won't need any change.\n\nRight, I get that. But the current wording in MediaDevice::lock()'s\ndocumentation suggests that currently it is not virtual at all\non purpose.\n\nI agree we can change that I just wanted to point out that I believe\nit currently *deliberately* is not virtual at all.\n\n>> E.g. MediaDevice::lock()'s doxygen comment says:\n> \n> Did you mean to paste:\n> \n> * \\brief Lock the device to prevent it from being used by other instances of\n> * libcamera\n> *\n> * Multiple instances of libcamera might be running on the same system, at the\n> * same time. To allow the different instances to coexist, system resources in\n> * the form of media devices must be accessible for enumerating the cameras\n> * they provide at all times, while still allowing an instance to lock a\n> * resource while it prepares to actively use a camera from the resource.\n> *\n> * This function shall not be called from a pipeline handler implementation\n> * directly, as the base PipelineHandler implementation handles this on the\n> * behalf of the specified implementation.\n> *\n\nYes I did mean to do that.\n\n> This however prevents designs like yours to work. It might be ideal for\n> inline pipelines or m2m ones where each CSI-2 input lives in its own\n> media graph, but it won't work if all CSI-2 inputs are part of the\n> same media graph; and I don't have argument against such designs at\n> the kernel level even if I might be missing them right now.\n> > Going forward we actually want (ideally) a single system-wide media\n> graph. I don't think the locking granularity we have implemented today\n> would work there.\n> \n>>\n>> With that said I've no objection against making PipelineHandler::acquire()\n>> virtual and updating the doc text here a bit to say, e.g. :\n>>\n>> * The base PipelineHandler implementation handles MediaDevice locking\n>> * on behalf of the specified implementation, so this function should not be\n>> * called from a pipeline handler implementation directly.\n>> * Optionally a pipeline handler may opt out of the base PipelineHandler\n>> * locking by overriding PipelineHandler::acquire().\n>>\n> \n> Providing a method override for PipelineHandler::lock() would be\n> functionally an opt-out :)\n\nI think you mean PipelineHandler::acquire() here? With that correction,\nyes I agree and I think that would be cleaner then what I'm currently\nproposing.\n\n> Let's see what others think\n\nAck.\n\nRegards,\n\nHans\n\n\n>>>> Hans de Goede (3):\n>>>> libcamera: pipeline: Allow pipeline-handlers to opt out of locking the\n>>>> media devices\n>>>> libcamera: media_object: Add MediaEntity::disableLinks()\n>>>> libcamera: v4l2_device: add lock() and unlock() methods\n>>>>\n>>>> include/libcamera/internal/media_object.h | 1 +\n>>>> include/libcamera/internal/pipeline_handler.h | 2 +\n>>>> include/libcamera/internal/v4l2_device.h | 3 ++\n>>>> src/libcamera/media_device.cpp | 16 ++------\n>>>> src/libcamera/media_object.cpp | 27 ++++++++++++++\n>>>> src/libcamera/pipeline_handler.cpp | 8 ++--\n>>>> src/libcamera/v4l2_device.cpp | 37 +++++++++++++++++++\n>>>> 7 files changed, 77 insertions(+), 17 deletions(-)\n>>>>\n>>>> --\n>>>> 2.53.0\n>>>>\n>>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 59B69BDCBD\n\tfor ;\n\tMon, 13 Apr 2026 14:56:04 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 2B0CB62E93;\n\tMon, 13 Apr 2026 16:56:03 +0200 (CEST)","from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com\n\t[205.220.180.131])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 22B4A6271A\n\tfor ;\n\tMon, 13 Apr 2026 16:56:02 +0200 (CEST)","from pps.filterd (m0279870.ppops.net [127.0.0.1])\n\tby mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n\t63DB17OV542922 for ;\n\tMon, 13 Apr 2026 14:56:01 GMT","from mail-qt1-f197.google.com (mail-qt1-f197.google.com\n\t[209.85.160.197])\n\tby mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4dfexfwv4d-1\n\t(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)\n\tfor ;\n\tMon, 13 Apr 2026 14:56:00 +0000 (GMT)","by mail-qt1-f197.google.com with SMTP id\n\td75a77b69052e-50d58bed44aso131673201cf.3\n\tfor ;\n\tMon, 13 Apr 2026 07:56:00 -0700 (PDT)","from [10.40.99.10] ([78.108.130.194])\n\tby smtp.gmail.com with ESMTPSA id\n\ta640c23a62f3a-b9d6e7c8a13sm318897566b.53.2026.04.13.07.55.57\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 13 Apr 2026 07:55:57 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=qualcomm.com header.i=@qualcomm.com\n\theader.b=\"WUdlyyrA\"; dkim=pass (2048-bit key;\n\tunprotected) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com\n\theader.b=\"YDrCzZ3b\"; dkim-atps=neutral","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=\n\tcc:content-transfer-encoding:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to; s=qcppdkim1; bh=\n\tpeCNaMv2jP7Jk06lEVWD1YasAWWk26PRMUvWUcXTjpg=; b=WUdlyyrASi6R/Hif\n\tEo4zEW2hbzWal1r0mYqlM+bVBvwSCunx/Po46xdS3mVbMvYSyv5+RUuL5i8mo3rk\n\tt4aGycEMZglZN8VnJwx515oWOF/pdmTcRqEIeT/p+ryfsOwRdEja6qHe1685R/Yd\n\ttRwBvnUToraWwwwtQu2Up5ytQJOnmAFfo8ez/+FpQsmUiBYqJ6T1wiRUsTskDXZz\n\t9hOob84JkI1D6y4q2BHVbmSx24k4oY2Bh+yfHDzi43qjukLGPh4BIGJTRPFKuDrS\n\t+O4KxG/i3eXNGVeSem3ATHCLeAnbxNEfhnh96E7a83d9vqIP4bZsakuNrdm3YzWU\n\tmMClng==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=oss.qualcomm.com; s=google; t=1776092160; x=1776696960;\n\tdarn=lists.libcamera.org; \n\th=content-transfer-encoding:in-reply-to:content-language:references\n\t:cc:to:subject:from:user-agent:mime-version:date:message-id:from:to\n\t:cc:subject:date:message-id:reply-to;\n\tbh=peCNaMv2jP7Jk06lEVWD1YasAWWk26PRMUvWUcXTjpg=;\n\tb=YDrCzZ3b8hm6D+XZBmYMYkZUjEhetK4vjYshnFiK4ZdjIfUrlZoE7Qy2P03e9/GVi5\n\tcoiZyWLFO6nyrVxzgIl8HfjgtNQCad12YNEdDrDLaQLFcS+reBkzZLgYiLWipgMbMZZK\n\tVe2KOD91IjzZFrtgSyltTu0b/VoCcY5ns0NxCEUIoTLJeLqiB8ztfXlYN+S+ovtrO5gO\n\tlhECINj/M1LaPaUTF5oTF6Jr4JNkTS4J2qKA8Va2mQ4He272tXVFA2ogXrOEe2vEMbFR\n\tJ0zpXsRAVhD+NgjD944wASdxBE2pWIr7JY5Egf8GnH0Clu+kyqTUaqXzY4EA3ndFmJ7e\n\tNHWQ=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20251104; t=1776092160; x=1776696960;\n\th=content-transfer-encoding:in-reply-to:content-language:references\n\t:cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg\n\t:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n\tbh=peCNaMv2jP7Jk06lEVWD1YasAWWk26PRMUvWUcXTjpg=;\n\tb=c2DnxL6hXBoviauH4gmzJU5cBZR7lF5YtP3edZWSDS9HO0VL0CoGX9HIffbgm4k20b\n\t70Rz1Dzehsu5K4zPxuQosdRSjqdzFPPI4GKeGBuwmlm7I0GB9QRIgjRDp1dmgwG5vJso\n\tG8Tihvhm+cLJ4F4VjlWvt4omRsqKu7Yf+2Exj3tPa5Oos65VHobjP//g5FlY6PPXN7LW\n\tDH+sUZcLwT19sWgwx+K5zTuvowyZSq57ZQhZmHdRnrFnnKVgT56Ti/t8VSGG8pEdofPB\n\tnEI42WycTK/BOdvaprE8Cp9FqQFzHuR++pg3OIMy/r5S/odzfB9yOIxoe6RFPLaPYCDF\n\tzdAw==","X-Gm-Message-State":"AOJu0YyowayXqLVDU4XdkZbD9YvypQPiW2F9vZQ8xVujKovcEU8IO+Zu\n\tL2GYKFnYPyR06y5zIocrPlZi7bpb+r5qL7wWwNPiDz//uqhiUwmgqJucv7t8d6jM8x3LnNiCWGA\n\t7kDu8acTQ0qnpD2Bf0Ax2WeNv9sxVGbOUBhseC/sTCWF6z49pungzMVezsCe/igyu0XuvgBlq0K\n\tIGWALctDQk","X-Gm-Gg":"AeBDievZZ2axGZKnu5iV53Nd74DWAUQ7V02iunjQ7jUTLRRK/XdgZwYURW/NybXwGhq\n\tuSsAEdKgE5cy0GBhOIRiTjcOIKTBz3RKfZQh7X8s1uTIXaQ/4Qbs+c+MNkoVfnrZjm7sNBsE1To\n\t+t81TsfEyU7b4LH+8ZwroCLjkszmmms2R20fSyiuANQ+b44cOKbKSwwhBccq4T5o0RpxPCN1T1b\n\tEm2t2HXSHIxdk6sKIICz2ZqlCmFU1FZQa66nnFvYOszorNIDGjl8oIkRaWOED8MkhjgLF7N9Gpd\n\t9ThMJCXIF3k31ytBPGDrWrbWv4tINSz/8X4uVjDosdaX994h4KPPYx3NSOzpdbnn3xqavARUhd/\n\tt1oAKJ1+7/Xpq0stXBl5aQn01vHlVaieQAlBfphkW","X-Received":["by 2002:a05:622a:2295:b0:50d:86cb:db75 with SMTP id\n\td75a77b69052e-50dd5b96031mr196790071cf.7.1776092159475; \n\tMon, 13 Apr 2026 07:55:59 -0700 (PDT)","by 2002:a05:622a:2295:b0:50d:86cb:db75 with SMTP id\n\td75a77b69052e-50dd5b96031mr196789521cf.7.1776092158928; \n\tMon, 13 Apr 2026 07:55:58 -0700 (PDT)"],"Message-ID":"<537a8824-7b87-4863-84d8-cf83fd7c83e3@oss.qualcomm.com>","Date":"Mon, 13 Apr 2026 16:55:57 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","From":"Hans de Goede ","Subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","To":"Jacopo Mondi ","Cc":"libcamera-devel@lists.libcamera.org,\n\tLoic Poulain ","References":"<20260408115630.12456-1-johannes.goede@oss.qualcomm.com>\n\t\n\t\n\t","Content-Language":"en-US, nl","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-Proofpoint-GUID":"mLsLBSGG-k8bGa__d5n2HaVUM0_qp-Sq","X-Authority-Analysis":"v=2.4 cv=OpZ/DS/t c=1 sm=1 tr=0 ts=69dd0400 cx=c_pps\n\ta=EVbN6Ke/fEF3bsl7X48z0g==:117 a=rrvG0T/C2D967D07Ol03YQ==:17\n\ta=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=s4-Qcg_JpJYA:10\n\ta=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22\n\ta=gowsoOTTUOVcmtlkKump:22\n\ta=NEAV23lmAAAA:8 a=l8VVSg6HG07k7NMdiP0A:9 a=QEXdDO2ut3YA:10\n\ta=a_PwQJl-kcHnX1M80qC6:22","X-Proofpoint-ORIG-GUID":"mLsLBSGG-k8bGa__d5n2HaVUM0_qp-Sq","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDEzMDE0NyBTYWx0ZWRfX61LMIgWsByF7\n\tvBNTaKCbQl/NQBXtekeIYQRUY4+lnxkAiZCUV/ZlCNdew34SqY4IvfZGTCQLfp0q8rIEv5TBICA\n\tqbERcp2R/BFcWCF1bH1YIlkILjVwsQvzWvAM2jsJ5R8M1jxDr/vaQha3cjU3aUvskVlPGc/13pU\n\tWQTWZ5ZyNmbDWlPJHOSbRQz+L5l8MFtKMz3ECnDP8rHm0hD8jAsBPvStDCt/zh/K/9XplWl+HD5\n\tEdkgdRBk9wTTumut8xaBxU15BMPKn7G6Z2Goriuc8x9ohFiJkMnRuDuciginzTX5LBoETHE3CEr\n\tytKUMKlplJaPZGg8z+mlrqtaP9MkqHm4uq0mR8I6kJAgzIyPSbuylZw9rJGafOqmsAI6Rtjzc51\n\t5BzuP4ot4SQUn6YXFNqN/H44Hm6Q2C0hGjj3vzstfEsC3pJtFzEl1ORzJB5/mrHEpJqaHkfzZGq\n\tnMIiaYGCJMWPaIiKv8Q==","X-Proofpoint-Virus-Version":"vendor=baseguard\n\tengine=ICAP:2.0.293, Aquarius:18.0.1143, Hydra:6.1.51,\n\tFMLib:17.12.100.49\n\tdefinitions=2026-04-13_03,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\timpostorscore=0 malwarescore=0 spamscore=0 bulkscore=0\n\tpriorityscore=1501\n\tadultscore=0 lowpriorityscore=0 phishscore=0 clxscore=1015\n\tsuspectscore=0\n\tclassifier=typeunknown authscore=0 authtc= authcc= route=outbound\n\tadjust=0\n\treason=mlx scancount=1 engine=8.22.0-2604010000\n\tdefinitions=main-2604130147","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":38610,"web_url":"https://patchwork.libcamera.org/comment/38610/","msgid":"","date":"2026-04-13T15:03:03","subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","submitter":{"id":143,"url":"https://patchwork.libcamera.org/api/people/143/","name":"Jacopo Mondi","email":"jacopo.mondi@ideasonboard.com"},"content":"Hi Hans\n\nOn Mon, Apr 13, 2026 at 04:55:57PM +0200, Hans de Goede wrote:\n> Hi,\n>\n> On 13-Apr-26 4:30 PM, Jacopo Mondi wrote:\n> > Hi Hans\n> >\n> > On Mon, Apr 13, 2026 at 04:10:57PM +0200, Hans de Goede wrote:\n> >> Hi,\n> >>\n> >> On 13-Apr-26 4:00 PM, Jacopo Mondi wrote:\n> >>> Hi Hans\n> >>> let me ask a few questions\n> >>>\n> >>> On Wed, Apr 08, 2026 at 01:56:27PM +0200, Hans de Goede wrote:\n> >>>> Hi All,\n> >>>>\n> >>>> On Qualcomm chips any CSI-phy can be connected to any CSI-decoder and\n> >>>> any CSI-decoder can be connected to any Video-Front-End (VFE, DMA write\n> >>>> engine and co). Basically there are 2 big cross-switches between PHYs\n> >>>> and decoders and between decoders and VFEs which can be controlled through\n> >>>> media-controller links.\n> >>>>\n> >>>> As such the entite CAMSS block with CSI-phys, decoders and VFEs is\n> >>>> represented to userspace as a single /dev/media# node.\n> >>>>\n> >>>> As long as active links from unrelated cameras are not touched when setting\n> >>>> up a new camera 2 independent raw data-streams can be run and managed by 2\n> >>>> different libcamera instances.\n> >>>>\n> >>>> But the standard locking of the /dev/media# node by the first libcamera\n> >>>> instance to start streaming from one of the cameras blocks this.\n> >>>>\n> >>>> This patch series allows pipeline-handlers to opt-out of the base\n> >>>> PipelineHandler MediaDevice locking and adds 2 helpers for pipeline\n> >>>> handlers to implement finer grained locking.\n> >>>>\n> >>>\n> >>> First one I have is: why 2 libcamera instances ? Doesn't libcamera\n> >>> register one camera for each connected CSI-2 input ?\n> >>\n> >> Yes it does.\n> >>\n> >>> I guess, however, limiting to a single libcamera instance where there\n> >>> actually is no need to, might be too restrictive ?\n> >>\n> >> Right, e.g. users may want to use gst-launch twice to launch 2 gst-pipelines\n> >> each accessing a single camera.\n> >>\n> >\n> > I would say this is fair requirement\n> >\n> >>\n> >>>\n> >>>> This is the second of 3 series which together introduce the camss pipeline\n> >>>> handler. Here is a branch with all 3 series:\n> >>>> https://github.com/jwrdegoede/libcamera/commits/camss_pipeline_v1/\n> >>>>\n> >>>> I hope to get this prep series merged while work continues on the camss\n> >>>> pipeline handler itself.\n> >>>>\n> >>>> For an example of how to use this, see this commmit implementing finer\n> >>>> grained locking for the camss pipeline handler:\n> >>>>\n> >>>> https://github.com/jwrdegoede/libcamera/commit/4ffd7b47119978940b543ad0914bf46c767573ad\n> >>>>\n> >>>> For the first patch an alternative approach would be add a lockingRequired\n> >>>> flag to the MediaDevice class, allowing opting out of the locking on a per\n> >>>> media device base.\n> >>>\n> >>> To me this indeed sounds like we need a finer grained control over the\n> >>> locking of the media devices.\n> >>>\n> >>> Could 'bool PipelineHandler::acquire(Camera *camera);' become a virtual\n> >>> function to delegate the finer-grained locking to pipeline handlers ?\n> >>\n> >> That would also be an option yes. But currently the locking is something\n> >> \"owned\" by the core which must not be touched by pipeline handlers I tried\n> >> to preserve that for pipeline handlers not opting out.\n> >\n> > I'm suggesting a virtual not a pure virtual, so pipelines that are\n> > fine with the currently implemented mechanism won't need any change.\n>\n> Right, I get that. But the current wording in MediaDevice::lock()'s\n> documentation suggests that currently it is not virtual at all\n> on purpose.\n>\n> I agree we can change that I just wanted to point out that I believe\n> it currently *deliberately* is not virtual at all.\n>\n> >> E.g. MediaDevice::lock()'s doxygen comment says:\n> >\n> > Did you mean to paste:\n> >\n> > * \\brief Lock the device to prevent it from being used by other instances of\n> > * libcamera\n> > *\n> > * Multiple instances of libcamera might be running on the same system, at the\n> > * same time. To allow the different instances to coexist, system resources in\n> > * the form of media devices must be accessible for enumerating the cameras\n> > * they provide at all times, while still allowing an instance to lock a\n> > * resource while it prepares to actively use a camera from the resource.\n> > *\n> > * This function shall not be called from a pipeline handler implementation\n> > * directly, as the base PipelineHandler implementation handles this on the\n> > * behalf of the specified implementation.\n> > *\n>\n> Yes I did mean to do that.\n>\n> > This however prevents designs like yours to work. It might be ideal for\n> > inline pipelines or m2m ones where each CSI-2 input lives in its own\n> > media graph, but it won't work if all CSI-2 inputs are part of the\n> > same media graph; and I don't have argument against such designs at\n> > the kernel level even if I might be missing them right now.\n> > > Going forward we actually want (ideally) a single system-wide media\n> > graph. I don't think the locking granularity we have implemented today\n> > would work there.\n> >\n> >>\n> >> With that said I've no objection against making PipelineHandler::acquire()\n> >> virtual and updating the doc text here a bit to say, e.g. :\n> >>\n> >> * The base PipelineHandler implementation handles MediaDevice locking\n> >> * on behalf of the specified implementation, so this function should not be\n> >> * called from a pipeline handler implementation directly.\n> >> * Optionally a pipeline handler may opt out of the base PipelineHandler\n> >> * locking by overriding PipelineHandler::acquire().\n> >>\n> >\n> > Providing a method override for PipelineHandler::lock() would be\n> > functionally an opt-out :)\n>\n> I think you mean PipelineHandler::acquire() here? With that correction,\n\nOf course, thanks!\n\n> yes I agree and I think that would be cleaner then what I'm currently\n> proposing.\n>\n> > Let's see what others think\n>\n> Ack.\n>\n> Regards,\n>\n> Hans\n>\n>\n> >>>> Hans de Goede (3):\n> >>>> libcamera: pipeline: Allow pipeline-handlers to opt out of locking the\n> >>>> media devices\n> >>>> libcamera: media_object: Add MediaEntity::disableLinks()\n> >>>> libcamera: v4l2_device: add lock() and unlock() methods\n> >>>>\n> >>>> include/libcamera/internal/media_object.h | 1 +\n> >>>> include/libcamera/internal/pipeline_handler.h | 2 +\n> >>>> include/libcamera/internal/v4l2_device.h | 3 ++\n> >>>> src/libcamera/media_device.cpp | 16 ++------\n> >>>> src/libcamera/media_object.cpp | 27 ++++++++++++++\n> >>>> src/libcamera/pipeline_handler.cpp | 8 ++--\n> >>>> src/libcamera/v4l2_device.cpp | 37 +++++++++++++++++++\n> >>>> 7 files changed, 77 insertions(+), 17 deletions(-)\n> >>>>\n> >>>> --\n> >>>> 2.53.0\n> >>>>\n> >>\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id A37D3C32BB\n\tfor ;\n\tMon, 13 Apr 2026 15:03:08 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8BDE862E93;\n\tMon, 13 Apr 2026 17:03:07 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 72BAC6271A\n\tfor ;\n\tMon, 13 Apr 2026 17:03:06 +0200 (CEST)","from ideasonboard.com (93-46-82-201.ip106.fastwebnet.it\n\t[93.46.82.201])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 6311A4F1;\n\tMon, 13 Apr 2026 17:01:34 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"TFyNX+YC\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1776092494;\n\tbh=6AlyesyYfJChLZZrWJhNNJttGDUUQ8UCF3fWJP7vsMQ=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=TFyNX+YCs2BUMozyWQhgqUpTIuTN1J2PJjAOcxYzCwwybK5u/NkHqowAg0R9PK0bD\n\tpkrLH9EI927vsm/qI63V3GVsSgw3uOIxvVLXHGFUJ75DORXI5tBtab91DiVD+ur1AS\n\tSCYGTpmYVSb5ePvgqdYl8II0oB1s4ZNbfj6BqoMo=","Date":"Mon, 13 Apr 2026 17:03:03 +0200","From":"Jacopo Mondi ","To":"Hans de Goede ","Cc":"Jacopo Mondi , \n\tlibcamera-devel@lists.libcamera.org,\n\tLoic Poulain ","Subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","Message-ID":"","References":"<20260408115630.12456-1-johannes.goede@oss.qualcomm.com>\n\t\n\t\n\t\n\t<537a8824-7b87-4863-84d8-cf83fd7c83e3@oss.qualcomm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<537a8824-7b87-4863-84d8-cf83fd7c83e3@oss.qualcomm.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":38618,"web_url":"https://patchwork.libcamera.org/comment/38618/","msgid":"<4666b546-ff25-438e-8c33-cfc518785b19@oss.qualcomm.com>","date":"2026-04-15T10:33:56","subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","submitter":{"id":242,"url":"https://patchwork.libcamera.org/api/people/242/","name":"Hans de Goede","email":"johannes.goede@oss.qualcomm.com"},"content":"Hi All,\n\nOn 8-Apr-26 13:56, Hans de Goede wrote:\n> Hi All,\n> \n> On Qualcomm chips any CSI-phy can be connected to any CSI-decoder and\n> any CSI-decoder can be connected to any Video-Front-End (VFE, DMA write\n> engine and co). Basically there are 2 big cross-switches between PHYs\n> and decoders and between decoders and VFEs which can be controlled through\n> media-controller links.\n> \n> As such the entite CAMSS block with CSI-phys, decoders and VFEs is\n> represented to userspace as a single /dev/media# node.\n> \n> As long as active links from unrelated cameras are not touched when setting\n> up a new camera 2 independent raw data-streams can be run and managed by 2\n> different libcamera instances.\n> \n> But the standard locking of the /dev/media# node by the first libcamera\n> instance to start streaming from one of the cameras blocks this.\n> \n> This patch series allows pipeline-handlers to opt-out of the base\n> PipelineHandler MediaDevice locking and adds 2 helpers for pipeline\n> handlers to implement finer grained locking.\n> \n> This is the second of 3 series which together introduce the camss pipeline\n> handler. Here is a branch with all 3 series:\n> https://github.com/jwrdegoede/libcamera/commits/camss_pipeline_v1/\n> \n> I hope to get this prep series merged while work continues on the camss\n> pipeline handler itself.\n> \n> For an example of how to use this, see this commmit implementing finer\n> grained locking for the camss pipeline handler:\n> \n> https://github.com/jwrdegoede/libcamera/commit/4ffd7b47119978940b543ad0914bf46c767573ad\n> \n> For the first patch an alternative approach would be add a lockingRequired\n> flag to the MediaDevice class, allowing opting out of the locking on a per\n> media device base.\n\nAs discussed during the meeting here are 2 example media-graphs\nof camss CSI media-controller nodes:\n\nAgetti (the SoC found on the Uno Q):\nhttps://fedorapeople.org/~jwrdegoede/agatti.dot\nhttps://fedorapeople.org/~jwrdegoede/agatti.dot.svg\n\nHamoa (X1 Elite Soc on T14s):\nhttps://fedorapeople.org/~jwrdegoede/hamoa.dot\nhttps://fedorapeople.org/~jwrdegoede/hamoa.dot.svg\n\nNote with Hamoa the devicetree bindings have changed\nand the PHYs are now described as separate devicetree\nnodes with the DT for the T14s only enabling the phy\nconnected to the standard (color) user facing sensor,\nso the media-graph only shows 1 phy.\n\nRegards,\n \nHans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 59BEBBDCBD\n\tfor ;\n\tWed, 15 Apr 2026 10:34:06 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 71FC462EA9;\n\tWed, 15 Apr 2026 12:34:05 +0200 (CEST)","from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com\n\t[205.220.168.131])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 96FF462E6A\n\tfor ;\n\tWed, 15 Apr 2026 12:34:02 +0200 (CEST)","from pps.filterd (m0279862.ppops.net [127.0.0.1])\n\tby mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n\t63F7tc1t764425 for ;\n\tWed, 15 Apr 2026 10:34:00 GMT","from mail-qt1-f199.google.com (mail-qt1-f199.google.com\n\t[209.85.160.199])\n\tby mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4dj6q7rm63-1\n\t(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)\n\tfor ;\n\tWed, 15 Apr 2026 10:34:00 +0000 (GMT)","by mail-qt1-f199.google.com with SMTP id\n\td75a77b69052e-50d8ed08aa4so132814021cf.3\n\tfor ;\n\tWed, 15 Apr 2026 03:34:00 -0700 (PDT)","from ?IPV6:2001:1c00:c32:7800:5bfa:a036:83f0:f9ec?\n\t(2001-1c00-0c32-7800-5bfa-a036-83f0-f9ec.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c32:7800:5bfa:a036:83f0:f9ec])\n\tby smtp.gmail.com with ESMTPSA id\n\ta640c23a62f3a-ba1780b9c2dsm43047466b.59.2026.04.15.03.33.57\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tWed, 15 Apr 2026 03:33:57 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=qualcomm.com header.i=@qualcomm.com\n\theader.b=\"C49Hb/q7\"; dkim=pass (2048-bit key;\n\tunprotected) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com\n\theader.b=\"Yx3isgP5\"; dkim-atps=neutral","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=\n\tcc:content-transfer-encoding:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to; s=qcppdkim1; bh=\n\tOK/A0qHfgthAoTxSdowukNm91bn61nApeemtBXqf2Ho=; b=C49Hb/q7CHZmO++O\n\t1sRU+9xozvYZQk2+s5pW9sYd2Zf1CEPYrBHHfs5fJdBkQI8DVYannAwPY8Eyd05D\n\t8ZZ3n7AN59b+FJkdmnVdmmmWLDV6R0svRPLcAoYit/6AYPPH+5RlM4tHvaOiC9Q2\n\t31YL7xGCSpcLzxFYUUQeivwaBCnRtyxp7MaDLZeRttQZ6ndcj5qWkS9elQPNac7w\n\tNIp/I5YaYvmODhg9acgAvBmGy3brIh4G46PrT0+Ya9T8OdRYnpg3M5+gvSr/oyRk\n\tTJRiC/4Q57RAvAm9bDQ90ScKcGiPcMuNfl/8H3JWDjRfjkmuEGXzBFYBbvSWG74f\n\tkylNUg==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=oss.qualcomm.com; s=google; t=1776249239; x=1776854039;\n\tdarn=lists.libcamera.org; \n\th=content-transfer-encoding:in-reply-to:content-language:references\n\t:cc:to:subject:from:user-agent:mime-version:date:message-id:from:to\n\t:cc:subject:date:message-id:reply-to;\n\tbh=OK/A0qHfgthAoTxSdowukNm91bn61nApeemtBXqf2Ho=;\n\tb=Yx3isgP5Kaz00BTU70U8141z7+H20newzGaMvmb9GkhhpYnkABG7xApjaJIM6eqy9J\n\txyoT/O2/6ETtBtf2X6NCx8RzLIdwmD1yvz5ORKMOdntd6pr9M+HVpbwnYw+jFwFATzpw\n\tzBaqAdK1anzTVkDlEXOPsJUhlXU9OD+S18dC+gz7flVMVObuXpJnDFOcwjGmZZU0a8rA\n\tNMzGktN8PXmUd69JOa2nzaHp1j4QvP6Xsgw2tUrCYQwYHcUPsOJ6bo/iBz3n6q1hJ3iI\n\tWsZ0Z/Caw5D+zsuNh1gFFSWqAf/YV5dxwcaOftoeLnbvBcX3E5oWKtuyxA2izPEPTgGp\n\tIJFA=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20251104; t=1776249239; x=1776854039;\n\th=content-transfer-encoding:in-reply-to:content-language:references\n\t:cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg\n\t:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n\tbh=OK/A0qHfgthAoTxSdowukNm91bn61nApeemtBXqf2Ho=;\n\tb=Pw5+Cag6xyAtkKPrlwUnEPEg7QMoWXwYKOdYaiO+kgSdxFEgW76Y7KSEw6CiLA9tNO\n\tV9pn9vrtWuzEmE3qa0mxt+epLEHvm19cYgYrSwIy5LQOiJb/+eQ0c9bYy40FCmrCt6Ne\n\tlZIpHgGJ1IIZHlknhuN7S088Kd12WXSa+XKO6+rBuuq9fMeQCDPb8HM/uMS0T9aRxmBl\n\twmpEwsZSY5+ssiQVbxNhP+lrosmNrP+N7mvxdbZHEv2gLUKbcEm3DDx9A06G2pmiIeS/\n\tzSrBwvYyPHiIr6c+drQksLRZr7kM4g0ZVZ3VNPp/U/iV5Jf1JjP4D5X9vyZfxXj0cBIZ\n\tX+LQ==","X-Gm-Message-State":"AOJu0YzOeD04LcI/+8Kadkqsj0V3+v76su0ooTs7PwReWa0gZ5Kt2yU6\n\tkeH1rVdt2UO82H2O7s2Gb0sTNoMIw1eM56zIbA7g3ZUm1Jruccc+Ny6vF8YzPYsGTvNdmpQb/c6\n\t2Xn2yWtaiBrxeqf5Z3Q8ntdjtpbK0P3zS+kC/CsdOT9olZtPcdU4/QxVKMe8dknR2fo0AF63kSG\n\tKzmz2G7GP+","X-Gm-Gg":"AeBDiet+yra900bOreiXl19xapUmTHpsXHoa+pZlgFYCLAvjeCGLmIQ1XnhnCryjlgx\n\tW1nF6xhXwmkh54gxBAbXCyf3STFdEK0wyX1kLr6vltgDZ9pcrMJ/e0oB8XS9Mp78r6nl2nqjyof\n\t8wLdvy1MRX/T582h3QcOoaTNBNSvy0ghC5P8yqvm68RzhzyUchi61fnNha/ek+7uErvCdSfXph+\n\t7NqgPNQI2pjvD0Nl60MXcPvbkHcvZqg6QDIW2p0CzWB/XsgDSxb3B8z3kW5+8AudpEwuzkcu3W7\n\tOGGcyXUi59dA8X+5N4aEmH89QfvGl1FE24zNJknlLWiWmSLetTLhxrZDUICYH4jJmKhkC6TJK3Y\n\tMQtogYTQ/OiGF0CfiJYoEmUWgMn0dQ/EtGsT3SlFUmcy9ai54eNGsUZATKIo2HczriGNLyxvZ5O\n\t/tPOSkIjc6gCGDyjfnjAkz9jtjNLOHrjxP3VC0rGbRjHvwQXUD2PAjzMK/buDNmnf0H7lY34Lb5\n\tthMSpw9gZPau93W4zC/KK5DiQU=","X-Received":["by 2002:a05:622a:1b01:b0:50b:2d93:97bd with SMTP id\n\td75a77b69052e-50dd5b7b1e0mr317379051cf.24.1776249239201; \n\tWed, 15 Apr 2026 03:33:59 -0700 (PDT)","by 2002:a05:622a:1b01:b0:50b:2d93:97bd with SMTP id\n\td75a77b69052e-50dd5b7b1e0mr317378701cf.24.1776249238752; \n\tWed, 15 Apr 2026 03:33:58 -0700 (PDT)"],"Message-ID":"<4666b546-ff25-438e-8c33-cfc518785b19@oss.qualcomm.com>","Date":"Wed, 15 Apr 2026 12:33:56 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","From":"Hans de Goede ","Subject":"Re: [PATCH 0/3] libcamera: Finer grained MediaDevice locking","To":"libcamera-devel@lists.libcamera.org","Cc":"Loic Poulain ","References":"<20260408115630.12456-1-johannes.goede@oss.qualcomm.com>","Content-Language":"en-US, nl","In-Reply-To":"<20260408115630.12456-1-johannes.goede@oss.qualcomm.com>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-Authority-Analysis":"v=2.4 cv=AvHeGu9P c=1 sm=1 tr=0 ts=69df6998 cx=c_pps\n\ta=WeENfcodrlLV9YRTxbY/uA==:117 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10\n\ta=A5OVakUREuEA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22\n\ta=u7WPNUs3qKkmUXheDGA7:22 a=_K5XuSEh1TEqbUxoQ0s3:22 a=NEAV23lmAAAA:8\n\ta=6ABPrATuAAAA:8 a=hxB6Eh12a6Cb4V-UIuMA:9 a=QEXdDO2ut3YA:10\n\ta=kacYvNCVWA4VmyqE58fU:22 a=FCRCnXBEA80fiJtl_cq2:22","X-Proofpoint-GUID":"Dvbp-s5Pt_xT6bSlU3HalZB0zv8DnTdS","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDE1MDA5NiBTYWx0ZWRfX2Pao2CyMfIuO\n\tFTDHqpAbJvaJi9JyyIX7i7bEwBPxPZ3mnSw3nZquVo4Lf5vBA4OqAxtnzP2EF+twZdcdGB79KC7\n\tQ7iKgw5GwQzNgRbE/rU530G00UbJpUdn//lwcHetFVw/eltX7dFk/6vgAI0K8Us5uRaDVZRItf9\n\tWhmVDlqCqTzmynYYIEifqa6G8jrcIoz/t2iDIm04JBBiWLVwavuVO07RpLiA+MjPBCagTqHSJoi\n\tLhvq9/IS0xpPI9C/dx+Ak+i7jAEppZGK3t+wCp9g31f9RPI/jCuD6UECjBA2c37Jut+JZU2fa/g\n\t5nHlz0D34Qy3U7SiTYMxjJURZ52+38eX1wmDGM4+bl8bZpVHntY6AbEesvLx8yI9dYWj1ibOBiQ\n\tptD+e57cXTLhhdO/2Jze9wFC/LgjqquQAYLited3H5d9s7Foh6z2XY5ooTCTsxdk4KWht3Cv05A\n\tmBFceeEOlFdYbrmPGYg==","X-Proofpoint-ORIG-GUID":"Dvbp-s5Pt_xT6bSlU3HalZB0zv8DnTdS","X-Proofpoint-Virus-Version":"vendor=baseguard\n\tengine=ICAP:2.0.293, Aquarius:18.0.1143, Hydra:6.1.51,\n\tFMLib:17.12.100.49\n\tdefinitions=2026-04-14_04,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tmalwarescore=0 spamscore=0 clxscore=1015 adultscore=0 phishscore=0\n\tbulkscore=0 suspectscore=0 priorityscore=1501 impostorscore=0\n\tlowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc=\n\troute=outbound adjust=0 reason=mlx scancount=1\n\tengine=8.22.0-2604070000\n\tdefinitions=main-2604150096","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]