[{"id":38372,"web_url":"https://patchwork.libcamera.org/comment/38372/","msgid":"<177402493129.426081.2164867215872322382@localhost>","date":"2026-03-20T16:42:11","subject":"Re: [RFC PATCH v2 0/1] Add queueControls mechanism","submitter":{"id":184,"url":"https://patchwork.libcamera.org/api/people/184/","name":"Stefan Klug","email":"stefan.klug@ideasonboard.com"},"content":"Hi David,\n\nThank you for the patch.\n\nQuoting David Plowman (2026-03-12 16:10:37)\n> Hi everyone\n> \n> Here's a version of Barnabas's previous patch (hence \"v2\") that added\n> a separate applyControls function, to bypass the request queue. If you\n> recall, I was a fan of this one.\n> \n> I've re-worked it only slightly, replacing the single pending\n> ControlList with a queue, which is the functionality that was\n> important to us. To make that explicit, I've renamed \"applyControls\"\n> to \"queueControls\" everywhere.\n\nI'm a bit hesitant here. The thing that nags me is that this introduces\na second queuing mechanism. I see that it would help the RPi use case\n(we should get a name for that) and I feel bad that we're still not\nthere, yet.\n\napplyControls() was meant as a mechanism to apply controls as fast as\npossible (basically modifying the current state of the camera) without\ngoing through any queue. So multiple calls to this function would all be\ncollated into the next possible point where we can apply controls.\nReplacing that with a queing mechanism contradicts that target.\n\nI still believe that the use case you are targeting can well be\nfulfilled with the request based model but requires us to split requests\nfrom buffers (which is on several todo lists since far too long, but I'm\nsure it will happen).\n\nSo introducing another queuing mechanism would likely bring us in a\nsituation where the behavior is even harder to describe.\n\n> \n> I've also tried, in passing, to answer some of the hanging questions:\n> \n> * Like requests, I've not allowed controls to be queued before the\n> camera is running. Don't feel strongly either way, really.\n> \n> * I've allowed queueing empty ControlLists. Doing this allows you to\n> get \"another frame like the last one\".\n\nAs said above, that defeats the \"set the exposure value on every change\nevent of a slider UI control and the last one wins\" use case.\n\nBest regards,\nStefan\n\n> \n> * I clear out all pending controls when the camera stops. If an\n> application needs to be sure they have been applied, it should wait\n> (which kind of leads us on to PFC, but not a subject for this\n> patch!). Or if it doesn't want to wait, it should re-apply any\n> in-question values when it re-starts the camera.\n> \n> * I'm using the fallback only when the PH explicitly doesn't support\n> queueControlsDevice. Really, if it's supported it's got to work\n> every time, even if that only means putting it in a queue in the\n> PH. Having some ControlLists go into the PH here, and then to have\n> it fail and put others into the pending queue, just feels entirely\n> confusing!\n> \n> * In the fallback case I'm copying the ControlList so that we can\n> recover if the request fails to queue. Firstly, I don't think this\n> is too horrible, and anyway, it's a fallback. If anyone cares about\n> this they should implement queueControlsDevice.\n> \n> TBH, I'm a bit unconvinced by the whole fallback thing. We (RPi)\n> always queue up lots of requests as soon as we can, and to my\n> understanding they all go through to our PH pretty much straight away,\n> which kind of nullifies the whole point. But maybe other PHs behave\n> differently? Always happy to be corrected on any misconceptions!\n> \n> Thanks\n> David\n> \n> David Plowman (1):\n> libcamera: Add independent queue for ControlLists\n> \n> include/libcamera/camera.h | 1 +\n> include/libcamera/internal/camera.h | 1 +\n> include/libcamera/internal/pipeline_handler.h | 7 ++\n> src/libcamera/camera.cpp | 61 +++++++++++++++\n> src/libcamera/pipeline_handler.cpp | 76 +++++++++++++++++++\n> 5 files changed, 146 insertions(+)\n> \n> -- \n> 2.47.3\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 80CD2BE086\n\tfor ;\n\tFri, 20 Mar 2026 16:42:17 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 937356273C;\n\tFri, 20 Mar 2026 17:42:16 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id BC1E362655\n\tfor ;\n\tFri, 20 Mar 2026 17:42:14 +0100 (CET)","from ideasonboard.com (unknown\n\t[IPv6:2a00:6020:448c:6c00:183a:c254:d560:19e5])\n\tby perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id 41BE0BE1;\n\tFri, 20 Mar 2026 17:41:00 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"vmRi+3xp\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1774024860;\n\tbh=7QrA6QGQTTdi4+kqqhI7jn68XUODQmPT3yBUHud45H0=;\n\th=In-Reply-To:References:Subject:From:Cc:To:Date:From;\n\tb=vmRi+3xp+pcNUuHjbSM+GL0g2DDvOOhpj37HW7/ZXR0iwXRIKFK/EjyH5d5qfSCEJ\n\tHhw6aSOBkpWnEPcIQWLMOGKMPfJku5ZXbPBo+QvF4jfbsij+yH7qeJzOC9+Z8GX/nj\n\tbi5HMqlWgTmMSBAFMloRKE/M1T8aKAlRgeJSgNIE=","Content-Type":"text/plain; charset=\"utf-8\"","MIME-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","In-Reply-To":"<20260312160009.18654-1-david.plowman@raspberrypi.com>","References":"<20260312160009.18654-1-david.plowman@raspberrypi.com>","Subject":"Re: [RFC PATCH v2 0/1] Add queueControls mechanism","From":"Stefan Klug ","Cc":"David Plowman ","To":"David Plowman ,\n\tlibcamera-devel@lists.libcamera.org","Date":"Fri, 20 Mar 2026 17:42:11 +0100","Message-ID":"<177402493129.426081.2164867215872322382@localhost>","User-Agent":"alot/0.12.dev8+g2c003385c862.d20250602","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":38379,"web_url":"https://patchwork.libcamera.org/comment/38379/","msgid":"","date":"2026-03-23T13:59:06","subject":"Re: [RFC PATCH v2 0/1] Add queueControls mechanism","submitter":{"id":42,"url":"https://patchwork.libcamera.org/api/people/42/","name":"David Plowman","email":"david.plowman@raspberrypi.com"},"content":"Hi Stefan\n\nThanks for the comments. I'm always very happy when people want to\ndiscuss this!!\n\nOn Fri, 20 Mar 2026 at 16:42, Stefan Klug wrote:\n>\n> Hi David,\n>\n> Thank you for the patch.\n>\n> Quoting David Plowman (2026-03-12 16:10:37)\n> > Hi everyone\n> >\n> > Here's a version of Barnabas's previous patch (hence \"v2\") that added\n> > a separate applyControls function, to bypass the request queue. If you\n> > recall, I was a fan of this one.\n> >\n> > I've re-worked it only slightly, replacing the single pending\n> > ControlList with a queue, which is the functionality that was\n> > important to us. To make that explicit, I've renamed \"applyControls\"\n> > to \"queueControls\" everywhere.\n>\n> I'm a bit hesitant here. The thing that nags me is that this introduces\n> a second queuing mechanism. I see that it would help the RPi use case\n> (we should get a name for that) and I feel bad that we're still not\n> there, yet.\n>\n> applyControls() was meant as a mechanism to apply controls as fast as\n> possible (basically modifying the current state of the camera) without\n> going through any queue. So multiple calls to this function would all be\n> collated into the next possible point where we can apply controls.\n> Replacing that with a queing mechanism contradicts that target.\n\nYes, I can appreciate that there may be a use-case where you want to\napply controls immediately and aren't interested in getting sequences\nof controlled frames.\n\nRather than just trying to implement one or the other, I'd be fine\nwith making both alternatives available - so long as we all get to\nbypass the request queue!\n\n>\n> I still believe that the use case you are targeting can well be\n> fulfilled with the request based model but requires us to split requests\n> from buffers (which is on several todo lists since far too long, but I'm\n> sure it will happen).\n>\n> So introducing another queuing mechanism would likely bring us in a\n> situation where the behavior is even harder to describe.\n\nThe whole business of splitting buffers (or controls) from requests is\nof course important here. I always struggle with the terminology.\n\nIf you take buffers out of requests into their own queue, a request\nqueue is really just a control list queue. Or if you take the control\nlists out of the requests, then the request queue is basically a\nbuffer queue (which is what I had). So it's not terribly clear to me\nwhat a \"request\" ends up being, but I don't think I mind too much what\nthings are called so long as we have the functionality we want.\n\nBut whatever we do, I think we end up with more than one queue, so\ndefining how they interact is unavoidable. The Kamaros view was at\nleast interesting in that respect - it had a \"command\" (mostly like a\ncontrol list) queue (actually more than one!), and then separate\nbuffer queues. Not saying that's the thing to do, but it's one data\npoint.\n\nI think I nominated this as a topic for Nice, so really hopeful that\nfolks are up for a discussion and that we can plan some concrete first\nsteps in this area.\n\nThanks!\nDavid\n\n>\n> >\n> > I've also tried, in passing, to answer some of the hanging questions:\n> >\n> > * Like requests, I've not allowed controls to be queued before the\n> > camera is running. Don't feel strongly either way, really.\n> >\n> > * I've allowed queueing empty ControlLists. Doing this allows you to\n> > get \"another frame like the last one\".\n>\n> As said above, that defeats the \"set the exposure value on every change\n> event of a slider UI control and the last one wins\" use case.\n>\n> Best regards,\n> Stefan\n>\n> >\n> > * I clear out all pending controls when the camera stops. If an\n> > application needs to be sure they have been applied, it should wait\n> > (which kind of leads us on to PFC, but not a subject for this\n> > patch!). Or if it doesn't want to wait, it should re-apply any\n> > in-question values when it re-starts the camera.\n> >\n> > * I'm using the fallback only when the PH explicitly doesn't support\n> > queueControlsDevice. Really, if it's supported it's got to work\n> > every time, even if that only means putting it in a queue in the\n> > PH. Having some ControlLists go into the PH here, and then to have\n> > it fail and put others into the pending queue, just feels entirely\n> > confusing!\n> >\n> > * In the fallback case I'm copying the ControlList so that we can\n> > recover if the request fails to queue. Firstly, I don't think this\n> > is too horrible, and anyway, it's a fallback. If anyone cares about\n> > this they should implement queueControlsDevice.\n> >\n> > TBH, I'm a bit unconvinced by the whole fallback thing. We (RPi)\n> > always queue up lots of requests as soon as we can, and to my\n> > understanding they all go through to our PH pretty much straight away,\n> > which kind of nullifies the whole point. But maybe other PHs behave\n> > differently? Always happy to be corrected on any misconceptions!\n> >\n> > Thanks\n> > David\n> >\n> > David Plowman (1):\n> > libcamera: Add independent queue for ControlLists\n> >\n> > include/libcamera/camera.h | 1 +\n> > include/libcamera/internal/camera.h | 1 +\n> > include/libcamera/internal/pipeline_handler.h | 7 ++\n> > src/libcamera/camera.cpp | 61 +++++++++++++++\n> > src/libcamera/pipeline_handler.cpp | 76 +++++++++++++++++++\n> > 5 files changed, 146 insertions(+)\n> >\n> > --\n> > 2.47.3\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 75F62BE086\n\tfor ;\n\tMon, 23 Mar 2026 13:59:21 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 777FB62760;\n\tMon, 23 Mar 2026 14:59:20 +0100 (CET)","from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com\n\t[IPv6:2a00:1450:4864:20::52e])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 6138062647\n\tfor ;\n\tMon, 23 Mar 2026 14:59:18 +0100 (CET)","by mail-ed1-x52e.google.com with SMTP id\n\t4fb4d7f45d1cf-66971ccfcabso270315a12.3\n\tfor ;\n\tMon, 23 Mar 2026 06:59:18 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=raspberrypi.com header.i=@raspberrypi.com\n\theader.b=\"U/NXCkeE\"; dkim-atps=neutral","ARC-Seal":"i=1; a=rsa-sha256; t=1774274358; cv=none;\n\td=google.com; s=arc-20240605;\n\tb=BK+CxqKQi/OqbEsQbLCJqbdK3VjUvzlOgkP2BSG1UuJaerm6FC+sO8dDikHhp0fpU1\n\ttFRGgdOQMWninLsif5sWj1hjI4zi7TTpBW5BksW6gb5K/xIvuQAqKZimk/9UfxJbR/96\n\teKbf06FhiJkI09Ptvj8st/2Ym+aSh9ueN1GAYXmDyu/HwIwhneiLeu7toI09BkLGvF06\n\tpoawXjEL6Sp1tF33+h2fqHg9TFi3df3a7StAqu5rKBZY6EMopwkk+0tWyHQrIuAUNwga\n\tH6meTMsYJ+avTI2OhmuA0Zd8gO7N8oJD5AzqjMo9TSD+XMgbGmugEQJQ4S51Rkpt3s69\n\toR7g==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=arc-20240605; \n\th=cc:to:subject:message-id:date:from:in-reply-to:references\n\t:mime-version:dkim-signature;\n\tbh=BgD7XOmFdF7c9vE3hAN+ymQPYT1IqGE2kjCSOLDjm0k=;\n\tfh=t/KYLNRDbBmQ42QEGaOCZdvkJHzEXRVLaWxWkOJjIhk=;\n\tb=MmvvCGHTSUbh0td7ACx1axsBfh9cusisVtArz8GBY/Ul2t7eMS4scbi6tjaRMraSvF\n\tqa3F85l1DJnR6ieG60QevZj8RiCqHwDa/t+vr4YvMYu7ZBASZPpHs48ttFaXDTSOTPqz\n\tzyNlZpsz9VreoRzn5qJHoTBdWz6XOolNmJtd4I8ULwNrY2Yolrohsox6UOmLf6oCu6Up\n\tnwQNXC0OplV4v6QvK1xJH5UhF0LGEdbU4LrOhylrGoJQQ3JqowNjxVcqmiuio7oP4PDm\n\t+81DK3tdyTUiQB/eai7DPedaRFDETXBe3Y7mMBWUFWjxCYeUx9KmRS3LWjcgVjs2+168\n\t8DDw==; darn=lists.libcamera.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google; t=1774274358; x=1774879158;\n\tdarn=lists.libcamera.org; \n\th=cc:to:subject:message-id:date:from:in-reply-to:references\n\t:mime-version:from:to:cc:subject:date:message-id:reply-to;\n\tbh=BgD7XOmFdF7c9vE3hAN+ymQPYT1IqGE2kjCSOLDjm0k=;\n\tb=U/NXCkeEFzqZnYDShPsVCMgNWCVD1OkkEFuhuYHHmqqS7dCxTBdh85fUTRSCpclpCx\n\tc6iyVFXM2Mhv7BMxW4yjKZwu/0xuzmy5MEOeP3MIDslDiNJlTetbO05bK2nWEBKLgwH3\n\tSMCXF1fy3MTkxhY/9G0CgGfxQPBz5/YuIkWJD8a/QZTFpvAHjTOPF/MJqag3BrQTeXtZ\n\tJ5ueOP57Ga29LTzsFonrYn1/WJEBU8yaBPU3O+dC65zwi6D6DU7DisMcJKJ6hlI2u2W/\n\tNmqY+VXWIWZqQhJ1UvT3VBLYRYFsEO+KURljBXvBVAkl8+32TbfJr1rRCitnc6niGe0r\n\tQNFw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20251104; t=1774274358; x=1774879158;\n\th=cc:to:subject:message-id:date:from:in-reply-to:references\n\t:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n\t:message-id:reply-to;\n\tbh=BgD7XOmFdF7c9vE3hAN+ymQPYT1IqGE2kjCSOLDjm0k=;\n\tb=PIPplD6u0QOxEk2kN5xwZHTyL0CnmwwWU+bYOsK+irNuMA32LlcJ/AYsjhasVSNU2+\n\t9uizFjknMlhrhiWVKcbt5SuUyAadziRlneLEmy9m0ZNEDEtGv+wbwgD/8t/yoZQJ19qf\n\tvDw5HKE/yXfH0kHPbPAbXnzzO98d3AU1jF+Dvp3GxGQ4X5XGPv6o0QiddHXY5woK6Bjz\n\tsxWThTBa/3+Cr4P7M3JgVFLHklgoMxHY2gY/nT+K3x9r+GLJ4qwYpNG6mRv27k/U9W8X\n\tig9VFOsr50noVhUbkc6/v2LUPdwLIp716F+JhKtFwGPiuMGWP1iQ051sN7HUwMaJVWhw\n\tR+gA==","X-Gm-Message-State":"AOJu0YxBptcK6aIqBWzrvcYQOMSNqn78Lcpt6XzFk6m4BVd55tnfNN14\n\tHQBb4yLRwlRQYGn9ycRlDC7gz+vw9nKrFtkC8HvkhOd+GfRyYCxw0Uw09JuYsQXX+Acoq1atjmu\n\tbjVko9u/JOF91yE4NdIBAcUVpuiqAb5esSdgeIo8roA==","X-Gm-Gg":"ATEYQzyiDoso0LabxJHyCt5LaJn2Jpi0y5+6ZvUJvQRtlX0lphjOZKSCkGH12KTlGzc\n\twby9ovvxVRrNtFs6PLOEwlpPg2PlAFUdTRbT0ZjbIO33ld60mjdOt6T3RnquyVURhOK74k02q0i\n\t8lJgDxvBe0DWSQ2q/nrhXTYpm+HkQ69vOGDsfzhfg4t848QtuVhjDrnYmABK4wrwwLxT6/HEOKA\n\tLUVfy5k/evu1qDodNTNwvcdW4sNtqsNsfA2tHqgsst9NQ+sSmGV0kvOWu7URSBAuPhSKx8DcjXi\n\tW4Cfd1HwrjivlOBjKGW5Yde2nNHUuk09S0il4iWOSJXrt1hGgM65ZzreliB5reAQwAp9pKHnZsa\n\tegXVVX1OO82CA/Ba21R/SPthp","X-Received":"by 2002:a17:906:36d4:b0:b98:2b55:f7c6 with SMTP id\n\ta640c23a62f3a-b982f4dec8dmr644443766b.57.1774274357593;\n\tMon, 23 Mar 2026 06:59:17 -0700 (PDT)","MIME-Version":"1.0","References":"<20260312160009.18654-1-david.plowman@raspberrypi.com>\n\t<177402493129.426081.2164867215872322382@localhost>","In-Reply-To":"<177402493129.426081.2164867215872322382@localhost>","From":"David Plowman ","Date":"Mon, 23 Mar 2026 13:59:06 +0000","X-Gm-Features":"AQROBzC2yQWhV-I4uKrxZCAp922tz9H-R_NyyHRKzp5UUssSx0N4UMrp50hS094","Message-ID":"","Subject":"Re: [RFC PATCH v2 0/1] Add queueControls mechanism","To":"Stefan Klug ","Cc":"libcamera-devel@lists.libcamera.org","Content-Type":"text/plain; charset=\"UTF-8\"","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\" "}}]