[{"id":25729,"web_url":"https://patchwork.libcamera.org/comment/25729/","msgid":"<20221103115009.3azovuuzeouc3fjs@uno.localdomain>","date":"2022-11-03T11:50:09","subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/people/3/","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"content":"Hi David\n\nOn Thu, Nov 03, 2022 at 10:40:25AM +0000, David Plowman via libcamera-devel wrote:\n> Hi everyone\n>\n> (Warning: may affect all pipeline handlers!)\n>\n> I wanted to start the ball rolling on this. The problem is that when\n> we enumerate the cameras in the system, we try to set some of the\n> controls (specifically the HFLIP and VFLIP ones, and also later\n> HBLANK). But this will fail if we don't \"own\" the camera, for example,\n> it is already in use elsewhere.\n\nFeels like I'm missing one point here..\n\nHow do you get to CameraSensor::init() if your pipeline handler\nacquires the unicam media device at the very beginning of match() ?\n\nI understand we allow multiple application acquire the same PH as the\nph might register multiple cameras, but why is this a problem at\nmatch() time ?\n\n>\n> These patches address just the flip bits and not the HBLANK, though I\n> think the latter is a more straightforward problem. The flip bits are\n> troublesome because they affect the reported Bayer orders.\n>\n> So here the idea is to store the formats in the sensor's native Bayer\n> order, as we were doing before. Only we can't reset the flip bits now,\n> we have to query them and transform any Bayer formats the sensor gives\n> us back into the native order. Two patches implement this:\n>\n> 1. The first patch adds a function to turn BayerFormats back into mbus\n> codes. I couldn't see that we had functions to do this already, but\n> please correct me if I missed something!\n>\n> 2. The second patch queries the flip bits and transforms any\n> BayerFormats back into the native order to be stored.\n>\n> As I said, this potentially affects all pipeline handlers, which is\n> why I left it \"RFC\" for the moment. I did take a look through them all\n> to see what we might need to do:\n>\n> raspberrypi.cpp\n>\n> I think this PH is OK. We assume we're given the native Bayer order\n> and transform it according to the final sensor transform, setting the\n> flip bits every time. We update the format in any raw stream to match.\n>\n> uvcvideo.cpp, simple.cpp\n>\n> These appear to hardcode the transform to the Identity. I think mostly\n> they should be OK because the formats here won't be raw and you can't\n> have raw streams (?). Probably they should clear the flip bits to zero\n> where these controls exist, perhaps someone who knows more about them\n> could comment.\n>\n> rkisp1.cpp:\n>\n> Seems to force the transform to the Identity as well. So I think this\n> is like the above ones, it should be OK though it probably needs to\n> clear the sensor flip bits as well.\n>\n> ipu3.cpp:\n>\n> This one does handle transforms and appears to set the flip bits, so\n> that's good. I couldn't see it transforming the Bayer order for raw\n> streams correctly, so that probably wants checking. (To be fair, this\n> looks suspect already and is not made worse by these changes!)\n>\n> Thoughts and opinions gratefully received, as always.\n>\n> Thanks!\n> David\n>\n> David Plowman (2):\n> libcamera: bayer_format: Add toMbusCode method\n> libcamera: camera_sensor: Do not clear camera flips when listing\n> formats\n>\n> include/libcamera/internal/bayer_format.h | 1 +\n> src/libcamera/bayer_format.cpp | 12 ++++++\n> src/libcamera/camera_sensor.cpp | 51 +++++++++++++++++++----\n> 3 files changed, 56 insertions(+), 8 deletions(-)\n>\n> --\n> 2.30.2\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 B2220BDB16\n\tfor ;\n\tThu, 3 Nov 2022 11:50:13 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id F27D16307D;\n\tThu, 3 Nov 2022 12:50:12 +0100 (CET)","from relay11.mail.gandi.net (relay11.mail.gandi.net\n\t[217.70.178.231])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id C771C61F42\n\tfor ;\n\tThu, 3 Nov 2022 12:50:11 +0100 (CET)","(Authenticated sender: jacopo@jmondi.org)\n\tby mail.gandi.net (Postfix) with ESMTPSA id 2FEEA10000A;\n\tThu, 3 Nov 2022 11:50:10 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1667476213;\n\tbh=Vo2ZNPVRZjwAgdjZkIZf4R20HTW1GG2ShoSP5Pcd34Q=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=vQ6GvBBCD6ssPrLNdbXhiM4cvnSWHZPmUgFu77zx+wNYtbg2TUqt4ToPCaK7fZsyl\n\tfUGcFZmINvgAnOIrstJEl9241BxHMpoX/PpoyM9ep7fXVM2EQNuW96Bhc6iMa5/Stk\n\tuZ6hkavvjUCR+gal0ue4eH+jPeM0MrEzNikO6B+AQN6zxgf7VqytrvEhLjPArrbqn9\n\tFos/JVs9GCDqtjvdAdtIkhm9e1fFEN8tkq9LhWlzQRt1vg230c9hFWGI6Zovui8UaY\n\tHIdgH5CGqA4Hbezus6g9WiVWphpcbrbcxs09xoAasO/MaFFwQtq1hES9Z2cIt6l9Pm\n\tFmLjhOJ0NfEJg==","Date":"Thu, 3 Nov 2022 12:50:09 +0100","To":"David Plowman ","Message-ID":"<20221103115009.3azovuuzeouc3fjs@uno.localdomain>","References":"<20221103104027.4197-1-david.plowman@raspberrypi.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20221103104027.4197-1-david.plowman@raspberrypi.com>","Subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","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","From":"Jacopo Mondi via libcamera-devel ","Reply-To":"Jacopo Mondi ","Cc":"libcamera-devel@lists.libcamera.org","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":25731,"web_url":"https://patchwork.libcamera.org/comment/25731/","msgid":"","date":"2022-11-03T12:05:31","subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","submitter":{"id":34,"url":"https://patchwork.libcamera.org/api/people/34/","name":"Naushir Patuck","email":"naush@raspberrypi.com"},"content":"Hi Jacopo,\n\n\nOn Thu, 3 Nov 2022 at 11:50, Jacopo Mondi via libcamera-devel <\nlibcamera-devel@lists.libcamera.org> wrote:\n\n> Hi David\n>\n> On Thu, Nov 03, 2022 at 10:40:25AM +0000, David Plowman via\n> libcamera-devel wrote:\n> > Hi everyone\n> >\n> > (Warning: may affect all pipeline handlers!)\n> >\n> > I wanted to start the ball rolling on this. The problem is that when\n> > we enumerate the cameras in the system, we try to set some of the\n> > controls (specifically the HFLIP and VFLIP ones, and also later\n> > HBLANK). But this will fail if we don't \"own\" the camera, for example,\n> > it is already in use elsewhere.\n>\n> Feels like I'm missing one point here..\n>\n> How do you get to CameraSensor::init() if your pipeline handler\n> acquires the unicam media device at the very beginning of match() ?\n>\n> I understand we allow multiple application acquire the same PH as the\n> ph might register multiple cameras, but why is this a problem at\n> match() time ?\n>\n\nIn match(), the rpi, rkisp and ipu3 pipeline handlers call\nCameraSensor::init() as part of the Camera object registration. This call\nis unconditional assuming we can enumerate and register the sensor.\n\nNot sure if that answers your question though?\n\nNaush\n\n\n\n>\n> >\n> > These patches address just the flip bits and not the HBLANK, though I\n> > think the latter is a more straightforward problem. The flip bits are\n> > troublesome because they affect the reported Bayer orders.\n> >\n> > So here the idea is to store the formats in the sensor's native Bayer\n> > order, as we were doing before. Only we can't reset the flip bits now,\n> > we have to query them and transform any Bayer formats the sensor gives\n> > us back into the native order. Two patches implement this:\n> >\n> > 1. The first patch adds a function to turn BayerFormats back into mbus\n> > codes. I couldn't see that we had functions to do this already, but\n> > please correct me if I missed something!\n> >\n> > 2. The second patch queries the flip bits and transforms any\n> > BayerFormats back into the native order to be stored.\n> >\n> > As I said, this potentially affects all pipeline handlers, which is\n> > why I left it \"RFC\" for the moment. I did take a look through them all\n> > to see what we might need to do:\n> >\n> > raspberrypi.cpp\n> >\n> > I think this PH is OK. We assume we're given the native Bayer order\n> > and transform it according to the final sensor transform, setting the\n> > flip bits every time. We update the format in any raw stream to match.\n> >\n> > uvcvideo.cpp, simple.cpp\n> >\n> > These appear to hardcode the transform to the Identity. I think mostly\n> > they should be OK because the formats here won't be raw and you can't\n> > have raw streams (?). Probably they should clear the flip bits to zero\n> > where these controls exist, perhaps someone who knows more about them\n> > could comment.\n> >\n> > rkisp1.cpp:\n> >\n> > Seems to force the transform to the Identity as well. So I think this\n> > is like the above ones, it should be OK though it probably needs to\n> > clear the sensor flip bits as well.\n> >\n> > ipu3.cpp:\n> >\n> > This one does handle transforms and appears to set the flip bits, so\n> > that's good. I couldn't see it transforming the Bayer order for raw\n> > streams correctly, so that probably wants checking. (To be fair, this\n> > looks suspect already and is not made worse by these changes!)\n> >\n> > Thoughts and opinions gratefully received, as always.\n> >\n> > Thanks!\n> > David\n> >\n> > David Plowman (2):\n> > libcamera: bayer_format: Add toMbusCode method\n> > libcamera: camera_sensor: Do not clear camera flips when listing\n> > formats\n> >\n> > include/libcamera/internal/bayer_format.h | 1 +\n> > src/libcamera/bayer_format.cpp | 12 ++++++\n> > src/libcamera/camera_sensor.cpp | 51 +++++++++++++++++++----\n> > 3 files changed, 56 insertions(+), 8 deletions(-)\n> >\n> > --\n> > 2.30.2\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 C4E42BD16B\n\tfor ;\n\tThu, 3 Nov 2022 12:05:50 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 3F4806307D;\n\tThu, 3 Nov 2022 13:05:50 +0100 (CET)","from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com\n\t[IPv6:2607:f8b0:4864:20::f33])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id D634061F42\n\tfor ;\n\tThu, 3 Nov 2022 13:05:48 +0100 (CET)","by mail-qv1-xf33.google.com with SMTP id u7so911483qvn.13\n\tfor ;\n\tThu, 03 Nov 2022 05:05:48 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1667477150;\n\tbh=8zHAr5i/9p9j/GEf74wO98dVpI+EMO+RZ0Z9KpoyOJU=;\n\th=References:In-Reply-To:Date:To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=LwngDJD4N/2zgTa9ueKCc8sLwMHYYp6TiP3kFJK3grtmsDqYv0Y6QLcFgyYtr+Yra\n\tkLDbr/2YlrndWb2mIJDwzU2FetZ/Rte0H6GSZlIc0fQvfF2Vdx1NRHGV5SRvjMwM0u\n\tKYvV8PA/ihvuUcuoT4XHjyz2eRMX4OkJlLsmYdDFBB8hMpVD2uTw85P2JUHAfR7Z25\n\toWSocbrVii3Mg22ZrFE7VEWUiVJDSVuVzLiBSFQ7Zqb+Z1AVfQ26gb9tooYJplIuiU\n\totyxTUKWKsaQX3eX+MBBH0f8CNlQX2Q/wgjyKmQjFw72D1fSAQjARwFQc0+M8bZJLs\n\tH6aGYYl6OQ40Q==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google;\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=8k2IbSnEj3akNuzdHLKBwh5WwXHrA01A1OEBMLsj7A8=;\n\tb=r8xSrW5MgZhHIRRY1E8lGS4wtrCekAsqz1fqgoxdRXjdOLnHcTR5SDN64gIWB3QXT1\n\tR/bP65reKWPKOv+x3kBmu2m+YnAqhuiVaKMImrQURmQqezE3DnAL47LRbAezG16fjsJx\n\t8udkVWErCfNpwOnublJE8dYquSUnAM1xEXQoAXpLkU3ygumzG6yZQniudGlANRZjFwo8\n\tPNA67DBNY3iw8L7oL2h3MUOnio6Rz6Zk8mOirWef6P5QKTTjAfRQbwj5gTti5loF5t03\n\t7IJQtMROEVhpIF0L1izcAnHVjNb2Z9ZvCNS4e+03A+B3cocM+CoT1OrwQ6lRtQyvgXPf\n\tJx2w=="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key; \n\tunprotected) header.d=raspberrypi.com\n\theader.i=@raspberrypi.com\n\theader.b=\"r8xSrW5M\"; dkim-atps=neutral","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=cc:to:subject:message-id:date:from:in-reply-to:references\n\t:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id\n\t:reply-to;\n\tbh=8k2IbSnEj3akNuzdHLKBwh5WwXHrA01A1OEBMLsj7A8=;\n\tb=LeB4b5+tEKSwhk3ejfPr0D0ySW1K3aiyfQb/Lt3QkPz9mENYPNd7n610u8QrcmrpCg\n\tIGDy4Y659Nhkv0YniyLaB6G/YktqSyIXHSK2kiiZDmqd3XzIMRHfP1gWAsj7RRJIq1uS\n\tcGpKQjXIjm0AdyjqeJ+8MK1IAu8AXiaTMw1LY5TA5yumuQY2bVbo4+uhwo7wiS8eZQQx\n\tQrBaQr1aQJj6D1XOBCmJ2dgUDICvyYReFBrAoS1+udHyDcFxM9d2VFOfh/7AJTbtN5iT\n\tsyhWk40m+FOnI6VReEgzlkfkWyNVuieMI9ycdU2/njnd6lLD+EqJOQmIkmNuRje+94QX\n\tQ4ww==","X-Gm-Message-State":"ACrzQf3AxJNjTrOd0Do7KtFkfPL71DI2Ju3602t+sKhyST8o2Y2a9M41\n\tpmC5JopZW2eGC1IAY5cCAVMY6JGxB8gLMkpfUpgNRA8W2SM=","X-Google-Smtp-Source":"AMsMyM5teL3wuUfqHgUXmC+hrPacWuhWSyeSiCv+swTVloTlkjDn7oC+DgsgO9cMK84Odcq653AjuQU1wxZIlTDIX9o=","X-Received":"by 2002:a05:6214:d87:b0:4bb:942b:f5f9 with SMTP id\n\te7-20020a0562140d8700b004bb942bf5f9mr25844217qve.126.1667477147644;\n\tThu, 03 Nov 2022 05:05:47 -0700 (PDT)","MIME-Version":"1.0","References":"<20221103104027.4197-1-david.plowman@raspberrypi.com>\n\t<20221103115009.3azovuuzeouc3fjs@uno.localdomain>","In-Reply-To":"<20221103115009.3azovuuzeouc3fjs@uno.localdomain>","Date":"Thu, 3 Nov 2022 12:05:31 +0000","Message-ID":"","To":"Jacopo Mondi ","Content-Type":"multipart/alternative; boundary=\"0000000000000e910a05ec8fc70f\"","Subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","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","From":"Naushir Patuck via libcamera-devel\n\t","Reply-To":"Naushir Patuck ","Cc":"libcamera-devel@lists.libcamera.org","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":25733,"web_url":"https://patchwork.libcamera.org/comment/25733/","msgid":"<20221103125924.i4rh2molnttfzvfb@uno.localdomain>","date":"2022-11-03T12:59:24","subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/people/3/","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"content":"Hi Naush\n\nOn Thu, Nov 03, 2022 at 12:05:31PM +0000, Naushir Patuck wrote:\n> Hi Jacopo,\n>\n>\n> On Thu, 3 Nov 2022 at 11:50, Jacopo Mondi via libcamera-devel <\n> libcamera-devel@lists.libcamera.org> wrote:\n>\n> > Hi David\n> >\n> > On Thu, Nov 03, 2022 at 10:40:25AM +0000, David Plowman via\n> > libcamera-devel wrote:\n> > > Hi everyone\n> > >\n> > > (Warning: may affect all pipeline handlers!)\n> > >\n> > > I wanted to start the ball rolling on this. The problem is that when\n> > > we enumerate the cameras in the system, we try to set some of the\n> > > controls (specifically the HFLIP and VFLIP ones, and also later\n> > > HBLANK). But this will fail if we don't \"own\" the camera, for example,\n> > > it is already in use elsewhere.\n> >\n> > Feels like I'm missing one point here..\n> >\n> > How do you get to CameraSensor::init() if your pipeline handler\n> > acquires the unicam media device at the very beginning of match() ?\n> >\n> > I understand we allow multiple application acquire the same PH as the\n> > ph might register multiple cameras, but why is this a problem at\n> > match() time ?\n> >\n>\n> In match(), the rpi, rkisp and ipu3 pipeline handlers call\n> CameraSensor::init() as part of the Camera object registration. This call\n> is unconditional assuming we can enumerate and register the sensor.\n>\n\nExactly, so CameraSensor::init() is called once, regardless of which\napplication will later \"own\" the camera. Sensor's controls are\nreset indeed, is this the problem, that application do not expect to\nhave the controls reset ?\n\n> Not sure if that answers your question though?\n>\n> Naush\n>\n>\n>\n> >\n> > >\n> > > These patches address just the flip bits and not the HBLANK, though I\n> > > think the latter is a more straightforward problem. The flip bits are\n> > > troublesome because they affect the reported Bayer orders.\n> > >\n> > > So here the idea is to store the formats in the sensor's native Bayer\n> > > order, as we were doing before. Only we can't reset the flip bits now,\n> > > we have to query them and transform any Bayer formats the sensor gives\n> > > us back into the native order. Two patches implement this:\n> > >\n> > > 1. The first patch adds a function to turn BayerFormats back into mbus\n> > > codes. I couldn't see that we had functions to do this already, but\n> > > please correct me if I missed something!\n> > >\n> > > 2. The second patch queries the flip bits and transforms any\n> > > BayerFormats back into the native order to be stored.\n> > >\n> > > As I said, this potentially affects all pipeline handlers, which is\n> > > why I left it \"RFC\" for the moment. I did take a look through them all\n> > > to see what we might need to do:\n> > >\n> > > raspberrypi.cpp\n> > >\n> > > I think this PH is OK. We assume we're given the native Bayer order\n> > > and transform it according to the final sensor transform, setting the\n> > > flip bits every time. We update the format in any raw stream to match.\n> > >\n> > > uvcvideo.cpp, simple.cpp\n> > >\n> > > These appear to hardcode the transform to the Identity. I think mostly\n> > > they should be OK because the formats here won't be raw and you can't\n> > > have raw streams (?). Probably they should clear the flip bits to zero\n> > > where these controls exist, perhaps someone who knows more about them\n> > > could comment.\n> > >\n> > > rkisp1.cpp:\n> > >\n> > > Seems to force the transform to the Identity as well. So I think this\n> > > is like the above ones, it should be OK though it probably needs to\n> > > clear the sensor flip bits as well.\n> > >\n> > > ipu3.cpp:\n> > >\n> > > This one does handle transforms and appears to set the flip bits, so\n> > > that's good. I couldn't see it transforming the Bayer order for raw\n> > > streams correctly, so that probably wants checking. (To be fair, this\n> > > looks suspect already and is not made worse by these changes!)\n> > >\n> > > Thoughts and opinions gratefully received, as always.\n> > >\n> > > Thanks!\n> > > David\n> > >\n> > > David Plowman (2):\n> > > libcamera: bayer_format: Add toMbusCode method\n> > > libcamera: camera_sensor: Do not clear camera flips when listing\n> > > formats\n> > >\n> > > include/libcamera/internal/bayer_format.h | 1 +\n> > > src/libcamera/bayer_format.cpp | 12 ++++++\n> > > src/libcamera/camera_sensor.cpp | 51 +++++++++++++++++++----\n> > > 3 files changed, 56 insertions(+), 8 deletions(-)\n> > >\n> > > --\n> > > 2.30.2\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 A5D79BD16B\n\tfor ;\n\tThu, 3 Nov 2022 12:59:28 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 1852263036;\n\tThu, 3 Nov 2022 13:59:28 +0100 (CET)","from relay10.mail.gandi.net (relay10.mail.gandi.net\n\t[217.70.178.230])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 7B67461F42\n\tfor ;\n\tThu, 3 Nov 2022 13:59:26 +0100 (CET)","(Authenticated sender: jacopo@jmondi.org)\n\tby mail.gandi.net (Postfix) with ESMTPSA id A9EF3240002;\n\tThu, 3 Nov 2022 12:59:25 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1667480368;\n\tbh=WVdpzJNE5YYSi5oPCfPDNsNI8HU5AyCGBPAs+JT1T54=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=i0An21pHXNo7pPoNOr6WVitmjeoY+TFV9LTBuPaKCWFOAeKs4o49GTVH7TNmrlLUw\n\taWH5nYQ95pYsr5lO9SOsUnIU75EmPQyOE6WIl8xU8Y34gapiI+CCzGWSauPsTLoKRJ\n\tXMA5qczyO1bzIJrSKoKMkg4DTdcGReeJ8/B2YaJ7OTwlR7WZlqaBJ/JmK+23HwuMa4\n\tqdyvq+KrwAPZK6Xwsb03DbwOFHcrNumqrVR0g/xSbbbVETb3usSGwy71dyeTcrHxbL\n\tVyPUdA+GVRu9xcFzCVIEdrvYd0IqfJKFaGABe5zRhtwQi9kjAm3Md48lnd3qV2DJQX\n\teoXgG86nwxlbg==","Date":"Thu, 3 Nov 2022 13:59:24 +0100","To":"Naushir Patuck ","Message-ID":"<20221103125924.i4rh2molnttfzvfb@uno.localdomain>","References":"<20221103104027.4197-1-david.plowman@raspberrypi.com>\n\t<20221103115009.3azovuuzeouc3fjs@uno.localdomain>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","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","From":"Jacopo Mondi via libcamera-devel ","Reply-To":"Jacopo Mondi ","Cc":"libcamera-devel@lists.libcamera.org","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":25734,"web_url":"https://patchwork.libcamera.org/comment/25734/","msgid":"","date":"2022-11-03T13:26:42","subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","submitter":{"id":34,"url":"https://patchwork.libcamera.org/api/people/34/","name":"Naushir Patuck","email":"naush@raspberrypi.com"},"content":"Hi Jacopo,\n\nOn Thu, 3 Nov 2022 at 12:59, Jacopo Mondi wrote:\n\n> Hi Naush\n>\n> On Thu, Nov 03, 2022 at 12:05:31PM +0000, Naushir Patuck wrote:\n> > Hi Jacopo,\n> >\n> >\n> > On Thu, 3 Nov 2022 at 11:50, Jacopo Mondi via libcamera-devel <\n> > libcamera-devel@lists.libcamera.org> wrote:\n> >\n> > > Hi David\n> > >\n> > > On Thu, Nov 03, 2022 at 10:40:25AM +0000, David Plowman via\n> > > libcamera-devel wrote:\n> > > > Hi everyone\n> > > >\n> > > > (Warning: may affect all pipeline handlers!)\n> > > >\n> > > > I wanted to start the ball rolling on this. The problem is that when\n> > > > we enumerate the cameras in the system, we try to set some of the\n> > > > controls (specifically the HFLIP and VFLIP ones, and also later\n> > > > HBLANK). But this will fail if we don't \"own\" the camera, for\n> example,\n> > > > it is already in use elsewhere.\n> > >\n> > > Feels like I'm missing one point here..\n> > >\n> > > How do you get to CameraSensor::init() if your pipeline handler\n> > > acquires the unicam media device at the very beginning of match() ?\n> > >\n> > > I understand we allow multiple application acquire the same PH as the\n> > > ph might register multiple cameras, but why is this a problem at\n> > > match() time ?\n> > >\n> >\n> > In match(), the rpi, rkisp and ipu3 pipeline handlers call\n> > CameraSensor::init() as part of the Camera object registration. This\n> call\n> > is unconditional assuming we can enumerate and register the sensor.\n> >\n>\n> Exactly, so CameraSensor::init() is called once, regardless of which\n> application will later \"own\" the camera. Sensor's controls are\n> reset indeed, is this the problem, that application do not expect to\n> have the controls reset ?\n>\n\nAh, this is where our understanding may differ. The enumeration code -\nmatch(), registerCamera() and CameraSensor::init() will be called for every\n(concurrent or single) libcamera process.\nThis happens even when one of these processes has acquired and is actively\nrunning the camera, and in this case the other processes doing the\nenumeration will try to write to the sensor when they shouldn't from\nCameraSensor::init().\n\nAgain, if this does not make sense or actually answer your question, please\nshout :-)\n\nNaush\n\n\n>\n> > Not sure if that answers your question though?\n> >\n> > Naush\n> >\n> >\n> >\n> > >\n> > > >\n> > > > These patches address just the flip bits and not the HBLANK, though I\n> > > > think the latter is a more straightforward problem. The flip bits are\n> > > > troublesome because they affect the reported Bayer orders.\n> > > >\n> > > > So here the idea is to store the formats in the sensor's native Bayer\n> > > > order, as we were doing before. Only we can't reset the flip bits\n> now,\n> > > > we have to query them and transform any Bayer formats the sensor\n> gives\n> > > > us back into the native order. Two patches implement this:\n> > > >\n> > > > 1. The first patch adds a function to turn BayerFormats back into\n> mbus\n> > > > codes. I couldn't see that we had functions to do this already, but\n> > > > please correct me if I missed something!\n> > > >\n> > > > 2. The second patch queries the flip bits and transforms any\n> > > > BayerFormats back into the native order to be stored.\n> > > >\n> > > > As I said, this potentially affects all pipeline handlers, which is\n> > > > why I left it \"RFC\" for the moment. I did take a look through them\n> all\n> > > > to see what we might need to do:\n> > > >\n> > > > raspberrypi.cpp\n> > > >\n> > > > I think this PH is OK. We assume we're given the native Bayer order\n> > > > and transform it according to the final sensor transform, setting the\n> > > > flip bits every time. We update the format in any raw stream to\n> match.\n> > > >\n> > > > uvcvideo.cpp, simple.cpp\n> > > >\n> > > > These appear to hardcode the transform to the Identity. I think\n> mostly\n> > > > they should be OK because the formats here won't be raw and you can't\n> > > > have raw streams (?). Probably they should clear the flip bits to\n> zero\n> > > > where these controls exist, perhaps someone who knows more about them\n> > > > could comment.\n> > > >\n> > > > rkisp1.cpp:\n> > > >\n> > > > Seems to force the transform to the Identity as well. So I think this\n> > > > is like the above ones, it should be OK though it probably needs to\n> > > > clear the sensor flip bits as well.\n> > > >\n> > > > ipu3.cpp:\n> > > >\n> > > > This one does handle transforms and appears to set the flip bits, so\n> > > > that's good. I couldn't see it transforming the Bayer order for raw\n> > > > streams correctly, so that probably wants checking. (To be fair, this\n> > > > looks suspect already and is not made worse by these changes!)\n> > > >\n> > > > Thoughts and opinions gratefully received, as always.\n> > > >\n> > > > Thanks!\n> > > > David\n> > > >\n> > > > David Plowman (2):\n> > > > libcamera: bayer_format: Add toMbusCode method\n> > > > libcamera: camera_sensor: Do not clear camera flips when listing\n> > > > formats\n> > > >\n> > > > include/libcamera/internal/bayer_format.h | 1 +\n> > > > src/libcamera/bayer_format.cpp | 12 ++++++\n> > > > src/libcamera/camera_sensor.cpp | 51\n> +++++++++++++++++++----\n> > > > 3 files changed, 56 insertions(+), 8 deletions(-)\n> > > >\n> > > > --\n> > > > 2.30.2\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 A1968BD16B\n\tfor ;\n\tThu, 3 Nov 2022 13:27:01 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 223046307D;\n\tThu, 3 Nov 2022 14:27:01 +0100 (CET)","from mail-qt1-x831.google.com (mail-qt1-x831.google.com\n\t[IPv6:2607:f8b0:4864:20::831])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 87B6861F42\n\tfor ;\n\tThu, 3 Nov 2022 14:26:59 +0100 (CET)","by mail-qt1-x831.google.com with SMTP id z6so1173310qtv.5\n\tfor ;\n\tThu, 03 Nov 2022 06:26:59 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1667482021;\n\tbh=P8yohfEMcMI4yP2WkZTp6nHBP0n0/Q9ZTQZpThxfmzc=;\n\th=References:In-Reply-To:Date:To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=nuCBQ/JP/BXPandKiKnZ66AkJm89dT5B5hs44SHw0q+S+B0I8wdvCAcHVKKz/5XQM\n\tLjFbTTzwo+tzSvTns4l2dLoiiEZhsVsy4Uxoi5WlFDtbC9btfGmfQlj54o72E/NVsr\n\tcQADYz3AfKgwe4gVLUz6jc40LGp7WVxqH1XBmDrlUtAQwq+PNcWExYkhII5hTvKAo2\n\tGwGNzRoqKZ7kBZU7kBrQXDy7Zn+pJ9MRhHpno2FJsadMlY35U6EElKwtlN/VrgT9Aq\n\teQME7LB7/6nBfE9qjFYk6pHBO1ykCOjl4KLsmXVnAMibtoiHrrdJK35AyD5YHJEPLQ\n\tROEiFaXo7qzEg==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google;\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=/7ldch+6A/ZOAMBk5k7rQgfG06JGR8hJbhr/qtxTCck=;\n\tb=JsKXsTg/av9tAcT+zFLmXM/NdMe+jhXR1AjVaJDupbV1llR84KNmFZdjoVPtZHkPVq\n\t4YoVnQnLMWwnnxQ2eW8FXcOxIl9LgNt5ZYoR81qZLyAqRP8NdHgpKOdjNcNyyszcJokm\n\tRE9XN5sgU8p9N0eYL0CVbAkq+AMh3iKX7O5yeG1D1bFvSGQ+RXgximsvqZ8LSkzgWOFs\n\tNJ6jRvWjPFx/dhi+lQejibjGYjb0/okcD7K5o3+oCmLlRA7XByasYvN42Iu+IPmn4o54\n\tQVlTVLoc4khNCX0L8RFmEAMFlHbHF6UUPym6wOXiRuFgi5LisM4oInCwIPVkPZ/TDPxj\n\tR5SA=="],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key; \n\tunprotected) header.d=raspberrypi.com\n\theader.i=@raspberrypi.com\n\theader.b=\"JsKXsTg/\"; dkim-atps=neutral","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=cc:to:subject:message-id:date:from:in-reply-to:references\n\t:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id\n\t:reply-to;\n\tbh=/7ldch+6A/ZOAMBk5k7rQgfG06JGR8hJbhr/qtxTCck=;\n\tb=L5xUeBIACFfWuHwBNp4JViwYcrDjSLciMny59ESjcl/kBl9y0t0P6yN5uf4+P8NScg\n\t/ToOW5mYdojSdu5D9mkoaXF92g0BidxxBuupTVtye2aFq9jGxDogjydgXNk6LUorHON0\n\tD+AZX6tP77a57c5gSFvpHtipVgerv93FU8leqaIN0qrYMum/UyChm73o8X/ff5Swga/E\n\tA59Zh5QWDvU5LVDK2IO6FeJbpz7hoDWe3OSbJTum4OS1tGXRyTtY0/+uHX7bxwkqwqhF\n\tXHNttMvkWdGzuURJYQQCx5aRARXi8ZaKZwkWLjU9jkV8d9ceC08rOD8bNxRbd4xcJafU\n\t5RLg==","X-Gm-Message-State":"ACrzQf35xDREKgxuKVd0EeXommlXIEnkQwHwZPQS7TSg1Y9Oa8cYMM5w\n\tK1/mq3vginy69MufuAg/ucU4ORrK8YQdpOBHnFIq1WPbdIA=","X-Google-Smtp-Source":"AMsMyM7FgHILTiQlT1DWNG9FLOVwBUhWyk+6+LHMpiUQTIDuaH+DiClMDsU9wA4SLc+Yb5gqGlFWaoCiXsak1dJB7fI=","X-Received":"by 2002:a05:622a:1820:b0:3a4:f758:fc0c with SMTP id\n\tt32-20020a05622a182000b003a4f758fc0cmr24505745qtc.110.1667482018438;\n\tThu, 03 Nov 2022 06:26:58 -0700 (PDT)","MIME-Version":"1.0","References":"<20221103104027.4197-1-david.plowman@raspberrypi.com>\n\t<20221103115009.3azovuuzeouc3fjs@uno.localdomain>\n\t\n\t<20221103125924.i4rh2molnttfzvfb@uno.localdomain>","In-Reply-To":"<20221103125924.i4rh2molnttfzvfb@uno.localdomain>","Date":"Thu, 3 Nov 2022 13:26:42 +0000","Message-ID":"","To":"Jacopo Mondi ","Content-Type":"multipart/alternative; boundary=\"00000000000060f4a505ec90e948\"","Subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","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","From":"Naushir Patuck via libcamera-devel\n\t","Reply-To":"Naushir Patuck ","Cc":"libcamera-devel@lists.libcamera.org","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":25735,"web_url":"https://patchwork.libcamera.org/comment/25735/","msgid":"<20221103135635.gyn6y7phwgbyaq35@uno.localdomain>","date":"2022-11-03T13:56:35","subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/people/3/","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"content":"Hi Naush\n\nOn Thu, Nov 03, 2022 at 01:26:42PM +0000, Naushir Patuck wrote:\n> Hi Jacopo,\n>\n> On Thu, 3 Nov 2022 at 12:59, Jacopo Mondi wrote:\n>\n> > Hi Naush\n> >\n> > On Thu, Nov 03, 2022 at 12:05:31PM +0000, Naushir Patuck wrote:\n> > > Hi Jacopo,\n> > >\n> > >\n> > > On Thu, 3 Nov 2022 at 11:50, Jacopo Mondi via libcamera-devel <\n> > > libcamera-devel@lists.libcamera.org> wrote:\n> > >\n> > > > Hi David\n> > > >\n> > > > On Thu, Nov 03, 2022 at 10:40:25AM +0000, David Plowman via\n> > > > libcamera-devel wrote:\n> > > > > Hi everyone\n> > > > >\n> > > > > (Warning: may affect all pipeline handlers!)\n> > > > >\n> > > > > I wanted to start the ball rolling on this. The problem is that when\n> > > > > we enumerate the cameras in the system, we try to set some of the\n> > > > > controls (specifically the HFLIP and VFLIP ones, and also later\n> > > > > HBLANK). But this will fail if we don't \"own\" the camera, for\n> > example,\n> > > > > it is already in use elsewhere.\n> > > >\n> > > > Feels like I'm missing one point here..\n> > > >\n> > > > How do you get to CameraSensor::init() if your pipeline handler\n> > > > acquires the unicam media device at the very beginning of match() ?\n> > > >\n> > > > I understand we allow multiple application acquire the same PH as the\n> > > > ph might register multiple cameras, but why is this a problem at\n> > > > match() time ?\n> > > >\n> > >\n> > > In match(), the rpi, rkisp and ipu3 pipeline handlers call\n> > > CameraSensor::init() as part of the Camera object registration. This\n> > call\n> > > is unconditional assuming we can enumerate and register the sensor.\n> > >\n> >\n> > Exactly, so CameraSensor::init() is called once, regardless of which\n> > application will later \"own\" the camera. Sensor's controls are\n> > reset indeed, is this the problem, that application do not expect to\n> > have the controls reset ?\n> >\n>\n> Ah, this is where our understanding may differ. The enumeration code -\n> match(), registerCamera() and CameraSensor::init() will be called for every\n> (concurrent or single) libcamera process.\n> This happens even when one of these processes has acquired and is actively\n> running the camera, and in this case the other processes doing the\n> enumeration will try to write to the sensor when they shouldn't from\n> CameraSensor::init().\n>\n> Again, if this does not make sense or actually answer your question, please\n> shout :-)\n>\n\nNo it does, I was assuming a single libcamera instance running\nand an upper layer arbitrator that mediates the camera access. But\nthat would be pipewire...\n\nSorry, it was trivial and this indeed is a valid use case.\n\nMore below\n\n\n> Naush\n>\n>\n> >\n> > > Not sure if that answers your question though?\n> > >\n> > > Naush\n> > >\n> > >\n> > >\n> > > >\n> > > > >\n> > > > > These patches address just the flip bits and not the HBLANK, though I\n> > > > > think the latter is a more straightforward problem. The flip bits are\n> > > > > troublesome because they affect the reported Bayer orders.\n> > > > >\n> > > > > So here the idea is to store the formats in the sensor's native Bayer\n> > > > > order, as we were doing before. Only we can't reset the flip bits\n> > now,\n> > > > > we have to query them and transform any Bayer formats the sensor\n> > gives\n> > > > > us back into the native order. Two patches implement this:\n> > > > >\n> > > > > 1. The first patch adds a function to turn BayerFormats back into\n> > mbus\n> > > > > codes. I couldn't see that we had functions to do this already, but\n> > > > > please correct me if I missed something!\n> > > > >\n\nI don't see any helper for that, so the change is welcome\n\n> > > > > 2. The second patch queries the flip bits and transforms any\n> > > > > BayerFormats back into the native order to be stored.\n> > > > >\n> > > > > As I said, this potentially affects all pipeline handlers, which is\n> > > > > why I left it \"RFC\" for the moment. I did take a look through them\n> > all\n> > > > > to see what we might need to do:\n> > > > >\n> > > > > raspberrypi.cpp\n> > > > >\n> > > > > I think this PH is OK. We assume we're given the native Bayer order\n> > > > > and transform it according to the final sensor transform, setting the\n> > > > > flip bits every time. We update the format in any raw stream to\n> > match.\n> > > > >\n> > > > > uvcvideo.cpp, simple.cpp\n> > > > >\n> > > > > These appear to hardcode the transform to the Identity. I think\n> > mostly\n> > > > > they should be OK because the formats here won't be raw and you can't\n> > > > > have raw streams (?). Probably they should clear the flip bits to\n\nIt is possible to have RAW streams with the simple pipeline\ntheoretically. Even more so considering the plan of plumbing a\nsofware ISP/debayer to it\n\n> > zero\n> > > > > where these controls exist, perhaps someone who knows more about them\n> > > > > could comment.\n> > > > >\n> > > > > rkisp1.cpp:\n> > > > >\n> > > > > Seems to force the transform to the Identity as well. So I think this\n> > > > > is like the above ones, it should be OK though it probably needs to\n> > > > > clear the sensor flip bits as well.\n> > > > >\n> > > > > ipu3.cpp:\n> > > > >\n> > > > > This one does handle transforms and appears to set the flip bits, so\n> > > > > that's good. I couldn't see it transforming the Bayer order for raw\n> > > > > streams correctly, so that probably wants checking. (To be fair, this\n> > > > > looks suspect already and is not made worse by these changes!)\n> > > > >\n> > > > > Thoughts and opinions gratefully received, as always.\n\nI'll reply to the patch\n\n> > > > >\n> > > > > Thanks!\n> > > > > David\n> > > > >\n> > > > > David Plowman (2):\n> > > > > libcamera: bayer_format: Add toMbusCode method\n> > > > > libcamera: camera_sensor: Do not clear camera flips when listing\n> > > > > formats\n> > > > >\n> > > > > include/libcamera/internal/bayer_format.h | 1 +\n> > > > > src/libcamera/bayer_format.cpp | 12 ++++++\n> > > > > src/libcamera/camera_sensor.cpp | 51\n> > +++++++++++++++++++----\n> > > > > 3 files changed, 56 insertions(+), 8 deletions(-)\n> > > > >\n> > > > > --\n> > > > > 2.30.2\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 6A236BDB16\n\tfor ;\n\tThu, 3 Nov 2022 13:56:40 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id B72786307D;\n\tThu, 3 Nov 2022 14:56:39 +0100 (CET)","from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net\n\t[IPv6:2001:4b98:dc4:8::225])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 0A68961F42\n\tfor ;\n\tThu, 3 Nov 2022 14:56:38 +0100 (CET)","(Authenticated sender: jacopo@jmondi.org)\n\tby mail.gandi.net (Postfix) with ESMTPSA id 45BB11C0003;\n\tThu, 3 Nov 2022 13:56:36 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org;\n\ts=mail; t=1667483799;\n\tbh=ucurEYMtSWQOx2Lnj+66BwySagyJmbkFur2ZRTTeERI=;\n\th=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:\n\tList-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:\n\tFrom;\n\tb=rhcvT+2/6Zu79Q/0AVK0uaXDXDSDe0uXRE43IaqRKEUaS4RNdVkJxUcJ+nxc2S78t\n\tWR1/gasWHLjiIrmfjryXS8M1vvMYuEf4xz3tIXmf0oWuCgYzrilCrtGoUP50oztaSr\n\tlbT2U2fPk2iWdonKD6Zj3s3KaaSa4ab3iTgNMWHlfBAtLc7hcJQlLbc5h0WxNLRqIV\n\tXaaQRwy+qREF2mcf4W1MY8L+Sb6erIB1vMfG0O/cwXuXLsgWeNe22MjhAUyLgdjCMO\n\tg0TqFFfSyYx5P21+PNIFc/XJHhr/MzGpkvdkBrbEkqvLkWN7DPwYzc36WBGiEf2wMZ\n\tYw1FkbRaPH/RA==","Date":"Thu, 3 Nov 2022 14:56:35 +0100","To":"Naushir Patuck ","Message-ID":"<20221103135635.gyn6y7phwgbyaq35@uno.localdomain>","References":"<20221103104027.4197-1-david.plowman@raspberrypi.com>\n\t<20221103115009.3azovuuzeouc3fjs@uno.localdomain>\n\t\n\t<20221103125924.i4rh2molnttfzvfb@uno.localdomain>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [RFC PATCH 0/2] Resolve invalid attempts to\n\tset sensor flip controls","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","From":"Jacopo Mondi via libcamera-devel ","Reply-To":"Jacopo Mondi ","Cc":"libcamera-devel@lists.libcamera.org","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]