[{"id":2699,"web_url":"https://patchwork.libcamera.org/comment/2699/","msgid":"","date":"2019-09-26T15:18:45","subject":"Re: [libcamera-devel] [PATCH 0/5] libcamera: Control framework\n\tbackend rework","submitter":{"id":4,"url":"https://patchwork.libcamera.org/api/people/4/","name":"Kieran Bingham","email":"kieran.bingham@ideasonboard.com"},"content":"Hi Jacopo,\n\nOn 18/09/2019 11:34, Jacopo Mondi wrote:\n> Hello,\n> this series is the first half of the currently in progress serialization\n> support work.\n> \n> The basic idea is that to be able to serialize Controls and V4L2Controls\n> using the same API, their back-end storage should be unified to use the same\n> polymorphic data storage class. This was the initial plan to be honest, but it\n> didn't match the urgent need to get controls support in at the time, but it's\n> now required for serialization, so it's now a good time to fix this long\n> standing issue.\n> \n> The series addresses the issue taking the following steps.\n> 1) Break out the DataValue class from the ControlValue class and associate it\n> with a DataInfo class, that is meant to support constant validation\n> information associated with a value.\n> \n> The mapping will be\n> V4L2Control = Control = DataValue\n> V4L2ControlInfo = ControlInfo = DataInfo\n> \n> With V4L2ControlList being a list of V4L2Controls\n> and ControlList being a map of Controls associated to a map of\n> ControlInfo both indexed by ControlId\n> \n> [ later considerations: when writing below about the API of ControlList and\n> V4L2ControlList I realized they're effectively maps of ids to values, and\n> naming them \"Map\" would make the syntax \"ControlMap[id] = value\" more\n> natural. What do you think? ]\n\n\nYes, they are a map - but the map represents a list of controls ... I\nkinda like ControlList (/V4L2ControlList) as that better describes what\nthe content of the object is.\n\nThe fact that it's internally represented as a map, is implementation.\nThe 'high-level' requirement is to provide a list of controls to set (or\nread?)\n\n\nIn fact, 'ControlList' is our API. I don't think we should list the type\nin the API, i.e. if it were a vector it shouldn't be ControlVector.\n\nIt's a list. - the storage is up to the implementation.\nOf course that affects how users interact with it ....\n\n\n> All of this in patches 1, 2, 3\n> \n> 2) Serialization implies de-serialization, and to construct a ControlList we\n> need a camera. Break this dependency in patch 4/5 to be able to reconstruct\n> a ControlList from serialized data later\n> \n> 3) Bikeshedders heaven: rewording of comments and rename of data types in\n> Control framework. As explained in the commit message of 5/5, the rewording\n> tries to enforce the following concepts: control metadata, control info,\n> and control values.\n> \n> On top of this I have patches and tests for Serialization, but not yet for\n> de-serialization. I hope not, but it might be that implementing it\n> require changes in this series, so be prepared.\n> \n> All of this for the back-end storage.\n> \n> The user APIs: there is work there too, as both V4L2Controls and Controls might\n> need re-thinking of their user API. The fundamental difference between the two\n> (and it took me a while to realize the implication of this in the API\n> definition) it's where validation information are kept.\n> \n> ControlList is created with a reference to a ControlInfoMap used for validation\n> and produced by pipeline handlers at camera registration time. This allows to\n> validate a control at the moment it is added to the list, as doing so when\n> queuing requests is indeed too late for a safe recovery.\n\nHrm ... so we have a ControlInfoMap ... Well that kind of goes a bit\nagainst what I said earlier. But in that case, it's not really an\narbitrary list of ControlInfo is it ? I wonder if that makes the term\n'map' more applicable?\n\nOr maybe it's just because in my head, a Control is always an\nassociation of an ID and a value.\n\n(I think in my original implementations I aimed to have an object called\nControl which stored both the ID and the value in a single class).\n\n\n> V4L2Control list only contains values. The validation informations are kept in\n> the device the list is applied on. I think this still makes sense, as V4L2\n> controls are meant to be validate at the time they are immediately applied to\n> the device by the driver exposing them, and they will not be exposed to\n> applications. Anyway, creating a V4L2ControlList from a device might make\n> serialization easier because both values and information would then be kept\n> in the same class, as it happens now for Controls.\n> \n> The other difference in the API is a matter of tastes mostly. Controls use the\n> overloaded operator[] to set/get controls, V4L2Controls have explicit get/set.\n> Having implemented them, it's clear that my preference goes toward explicit\n> get/set, as operator overloading makes me always a bit unconfortable and I\n> prefer to type in 3 letters more for set/get but have an explicit indication of\n> what's happening. Anyway, the use of [] made in ControlList is pretty natural\n> and does what you would expect it to do (maybe if it was a ControlMap it would\n> feel more natural to do controls[x] = y ? Now that I wrote it here, I'll suggest\n> it in the above comment too) and seems to be also in line with\n\nI find the [] operator quite natural, and allows short clean code ?\n\n ControlList snapshot;\n\n snapshot[Exposure] = 5;\n\n\nAha - That was it - Now I remember why we had the ControlInfo comparator\noverloads. It was to allow indexing the ControlList maps with either an\nenum of the control ID, or by indexing with a ControlInfo.\n\nBut if we don't use it with the ControlInfo then I guess they aren't needed.\n\n\n> https://google.github.io/styleguide/cppguide.html \"Operator Overloading\"\n> section. So I'll go with popular preference, but in any case I think the two\n> should be unified.\n> \n> As said, serialization will come on top of this work, so please comment to avoid\n> me too many re-bases :)\n> \n> Thanks\n> j\n> \n> Jacopo Mondi (5):\n> libcamera: Create DataValue and DataInfo\n> libcamera: controls: Use DataType and DataValue\n> libcamera: v4l2_controls: Use DataValue and DataInfo\n> libcamera: controls: De-couple Controls from Camera\n> libcamera: controls: Control framework refresh\n> \n> include/libcamera/controls.h | 94 +----\n> include/libcamera/data_value.h | 84 ++++\n> include/libcamera/meson.build | 1 +\n> src/libcamera/controls.cpp | 398 +++++-------------\n> src/libcamera/data_value.cpp | 317 ++++++++++++++\n> src/libcamera/gen-controls.awk | 4 +-\n> src/libcamera/include/v4l2_controls.h | 22 +-\n> src/libcamera/include/v4l2_device.h | 1 -\n> src/libcamera/meson.build | 7 +-\n> src/libcamera/pipeline/uvcvideo.cpp | 2 +-\n> src/libcamera/pipeline/vimc.cpp | 2 +-\n> src/libcamera/request.cpp | 4 +-\n> src/libcamera/v4l2_controls.cpp | 49 +--\n> src/libcamera/v4l2_device.cpp | 25 +-\n> test/controls/control_info.cpp | 4 +-\n> test/controls/control_list.cpp | 6 +-\n> test/controls/meson.build | 1 -\n> .../data_value.cpp} | 24 +-\n> test/data_value/meson.build | 12 +\n> test/meson.build | 1 +\n> 20 files changed, 593 insertions(+), 465 deletions(-)\n> create mode 100644 include/libcamera/data_value.h\n> create mode 100644 src/libcamera/data_value.cpp\n> rename test/{controls/control_value.cpp => data_value/data_value.cpp} (68%)\n> create mode 100644 test/data_value/meson.build\n> \n> --\n> 2.23.0\n> \n> _______________________________________________\n> libcamera-devel mailing list\n> libcamera-devel@lists.libcamera.org\n> https://lists.libcamera.org/listinfo/libcamera-devel\n>","headers":{"Return-Path":"","Received":["from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 489BA60BB6\n\tfor ;\n\tThu, 26 Sep 2019 17:18:48 +0200 (CEST)","from [192.168.0.20]\n\t(cpc89242-aztw30-2-0-cust488.18-1.cable.virginm.net [86.31.129.233])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id BB3AB9BF;\n\tThu, 26 Sep 2019 17:18:47 +0200 (CEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1569511128;\n\tbh=GJkU/mELgau8ZOjeeaPi6i+uUfGU8SMjyBGWf1Q6+JE=;\n\th=Reply-To:Subject:To:References:From:Date:In-Reply-To:From;\n\tb=XofCX38SVagCWTzZYxmYrYR5mwUVtnjGabnoKi6bHWPoMI+W/Nivgc0dHLaDDCsVN\n\tDxJZTtuUXXPRUK7i9/APR0hrYb4vGY9YqPCdGlZiyXRHb5s4sZSd+p8JKWR4xp9Nj3\n\ttLRNzJjoPgUmY9wWrCM/ges8348M6OEw9Egpo5v4=","Reply-To":"kieran.bingham@ideasonboard.com","To":"Jacopo Mondi , libcamera-devel@lists.libcamera.org","References":"<20190918103424.14536-1-jacopo@jmondi.org>","From":"Kieran Bingham ","Openpgp":"preference=signencrypt","Autocrypt":"addr=kieran.bingham@ideasonboard.com; keydata=\n\tmQINBFYE/WYBEACs1PwjMD9rgCu1hlIiUA1AXR4rv2v+BCLUq//vrX5S5bjzxKAryRf0uHat\n\tV/zwz6hiDrZuHUACDB7X8OaQcwhLaVlq6byfoBr25+hbZG7G3+5EUl9cQ7dQEdvNj6V6y/SC\n\trRanWfelwQThCHckbobWiQJfK9n7rYNcPMq9B8e9F020LFH7Kj6YmO95ewJGgLm+idg1Kb3C\n\tpotzWkXc1xmPzcQ1fvQMOfMwdS+4SNw4rY9f07Xb2K99rjMwZVDgESKIzhsDB5GY465sCsiQ\n\tcSAZRxqE49RTBq2+EQsbrQpIc8XiffAB8qexh5/QPzCmR4kJgCGeHIXBtgRj+nIkCJPZvZtf\n\tKr2EAbc6tgg6DkAEHJb+1okosV09+0+TXywYvtEop/WUOWQ+zo+Y/OBd+8Ptgt1pDRyOBzL8\n\tRXa8ZqRf0Mwg75D+dKntZeJHzPRJyrlfQokngAAs4PaFt6UfS+ypMAF37T6CeDArQC41V3ko\n\tlPn1yMsVD0p+6i3DPvA/GPIksDC4owjnzVX9kM8Zc5Cx+XoAN0w5Eqo4t6qEVbuettxx55gq\n\t8K8FieAjgjMSxngo/HST8TpFeqI5nVeq0/lqtBRQKumuIqDg+Bkr4L1V/PSB6XgQcOdhtd36\n\tOe9X9dXB8YSNt7VjOcO7BTmFn/Z8r92mSAfHXpb07YJWJosQOQARAQABtDBLaWVyYW4gQmlu\n\tZ2hhbSA8a2llcmFuLmJpbmdoYW1AaWRlYXNvbmJvYXJkLmNvbT6JAlcEEwEKAEECGwMFCwkI\n\tBwIGFQgJCgsCBBYCAwECHgECF4ACGQEWIQSQLdeYP70o/eNy1HqhHkZyEKRh/QUCXWTtygUJ\n\tCyJXZAAKCRChHkZyEKRh/f8dEACTDsbLN2nioNZMwyLuQRUAFcXNolDX48xcUXsWS2QjxaPm\n\tVsJx8Uy8aYkS85mdPBh0C83OovQR/OVbr8AxhGvYqBs3nQvbWuTl/+4od7DfK2VZOoKBAu5S\n\tQK2FYuUcikDqYcFWJ8DQnubxfE8dvzojHEkXw0sA4igINHDDFX3HJGZtLio+WpEFQtCbfTAG\n\tYZslasz1YZRbwEdSsmO3/kqy5eMnczlm8a21A3fKUo3g8oAZEFM+f4DUNzqIltg31OAB/kZS\n\tenKZQ/SWC8PmLg/ZXBrReYakxXtkP6w3FwMlzOlhGxqhIRNiAJfXJBaRhuUWzPOpEDE9q5YJ\n\tBmqQL2WJm1VSNNVxbXJHpaWMH1sA2R00vmvRrPXGwyIO0IPYeUYQa3gsy6k+En/aMQJd27dp\n\taScf9am9PFICPY5T4ppneeJLif2lyLojo0mcHOV+uyrds9XkLpp14GfTkeKPdPMrLLTsHRfH\n\tfA4I4OBpRrEPiGIZB/0im98MkGY/Mu6qxeZmYLCcgD6qz4idOvfgVOrNh+aA8HzIVR+RMW8H\n\tQGBN9f0E3kfwxuhl3omo6V7lDw8XOdmuWZNC9zPq1UfryVHANYbLGz9KJ4Aw6M+OgBC2JpkD\n\thXMdHUkC+d20dwXrwHTlrJi1YNp6rBc+xald3wsUPOZ5z8moTHUX/uPA/qhGsbkCDQRWBP1m\n\tARAAzijkb+Sau4hAncr1JjOY+KyFEdUNxRy+hqTJdJfaYihxyaj0Ee0P0zEi35CbE6lgU0Uz\n\ttih9fiUbSV3wfsWqg1Ut3/5rTKu7kLFp15kF7eqvV4uezXRD3Qu4yjv/rMmEJbbD4cTvGCYI\n\td6MDC417f7vK3hCbCVIZSp3GXxyC1LU+UQr3fFcOyCwmP9vDUR9JV0BSqHHxRDdpUXE26Dk6\n\tmhf0V1YkspE5St814ETXpEus2urZE5yJIUROlWPIL+hm3NEWfAP06vsQUyLvr/GtbOT79vXl\n\tEn1aulcYyu20dRRxhkQ6iILaURcxIAVJJKPi8dsoMnS8pB0QW12AHWuirPF0g6DiuUfPmrA5\n\tPKe56IGlpkjc8cO51lIxHkWTpCMWigRdPDexKX+Sb+W9QWK/0JjIc4t3KBaiG8O4yRX8ml2R\n\t+rxfAVKM6V769P/hWoRGdgUMgYHFpHGSgEt80OKK5HeUPy2cngDUXzwrqiM5Sz6Od0qw5pCk\n\tNlXqI0W/who0iSVM+8+RmyY0OEkxEcci7rRLsGnM15B5PjLJjh1f2ULYkv8s4SnDwMZ/kE04\n\t/UqCMK/KnX8pwXEMCjz0h6qWNpGwJ0/tYIgQJZh6bqkvBrDogAvuhf60Sogw+mH8b+PBlx1L\n\toeTK396wc+4c3BfiC6pNtUS5GpsPMMjYMk7kVvEAEQEAAYkCJQQYAQoADwIbDAUCWcOUawUJ\n\tB4D+AgAKCRChHkZyEKRh/XJhEACr5iidt/0MZ0rWRMCbZFMWD7D2g6nZeOp+F2zY8CEUW+sd\n\tCDVd9BH9QX9KN5SZo6YtJzMzSzpcx45VwTvtQW0n/6Eujg9EUqblfU9xqvqDmbjEapr5d/OL\n\t21GTALb0owKhA5qDUGEcKGCphpQffKhTNo/BP99jvmJUj7IPSKH97qPypi8/ym8bAxB+uY31\n\tgHTMHf1jMJJ1pRo2tYYPeIIHGDqXBI4sp5GHHF+JcIhgR/e/A6w/dgzHYmQPl2ix5eZYEZbV\n\tTRP+gkX4NV8oHqa/lR+xPOlWElGB57viOSOoWriqxQbFy8XbG1GR8cWlkNtGBGVWaJaSoORP\n\tiowD7irXL91bCyFIqL+7BVk3Jy4uzP744PzE80KwxOp5SQAp9sPzFbgsJrLev90PZySjFHG0\n\twP144DK7nBjOj/J0g9OHVASP1JjK+nw7SDoKnETDIdRC0XmiHXk7TXzPdkvO0UkpHdEPjZUp\n\tWyuc0MqehjR/hTTPt4m/Y14XzEcy6JREIjOrFfUZVho2QpOdv9CNryGdieRTNjUtz463CIaZ\n\tdPBiw9mOMBoNffkn9FIoCjLnAaj9gUAnEHWBZOEviQ5NuyqpeP0YtzI4iaRbSUkYZHej99X3\n\tVmHrdLlMqd/ZgYYbPGSL4AN3FVACb5CxuxEHwo029VcE5U3CSjzqtCoX12tm7A==","Organization":"Ideas on Board","Message-ID":"","Date":"Thu, 26 Sep 2019 16:18:45 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101\n\tThunderbird/60.8.0","MIME-Version":"1.0","In-Reply-To":"<20190918103424.14536-1-jacopo@jmondi.org>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"8bit","Subject":"Re: [libcamera-devel] [PATCH 0/5] libcamera: Control framework\n\tbackend rework","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","X-List-Received-Date":"Thu, 26 Sep 2019 15:18:48 -0000"}},{"id":2702,"web_url":"https://patchwork.libcamera.org/comment/2702/","msgid":"<20190926213636.GB4864@pendragon.ideasonboard.com>","date":"2019-09-26T21:36:36","subject":"Re: [libcamera-devel] [PATCH 0/5] libcamera: Control framework\n\tbackend rework","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hello,\n\nOn Thu, Sep 26, 2019 at 04:18:45PM +0100, Kieran Bingham wrote:\n> On 18/09/2019 11:34, Jacopo Mondi wrote:\n> > Hello,\n> > this series is the first half of the currently in progress serialization\n> > support work.\n> > \n> > The basic idea is that to be able to serialize Controls and V4L2Controls\n> > using the same API, their back-end storage should be unified to use the same\n> > polymorphic data storage class. This was the initial plan to be honest, but it\n> > didn't match the urgent need to get controls support in at the time, but it's\n> > now required for serialization, so it's now a good time to fix this long\n> > standing issue.\n> > \n> > The series addresses the issue taking the following steps.\n> > 1) Break out the DataValue class from the ControlValue class and associate it\n> > with a DataInfo class, that is meant to support constant validation\n> > information associated with a value.\n> > \n> > The mapping will be\n> > V4L2Control = Control = DataValue\n> > V4L2ControlInfo = ControlInfo = DataInfo\n> > \n> > With V4L2ControlList being a list of V4L2Controls\n> > and ControlList being a map of Controls associated to a map of\n> > ControlInfo both indexed by ControlId\n> > \n> > [ later considerations: when writing below about the API of ControlList and\n> > V4L2ControlList I realized they're effectively maps of ids to values, and\n> > naming them \"Map\" would make the syntax \"ControlMap[id] = value\" more\n> > natural. What do you think? ]\n> \n> Yes, they are a map - but the map represents a list of controls ... I\n> kinda like ControlList (/V4L2ControlList) as that better describes what\n> the content of the object is.\n> \n> The fact that it's internally represented as a map, is implementation.\n> The 'high-level' requirement is to provide a list of controls to set (or\n> read?)\n> \n> \n> In fact, 'ControlList' is our API. I don't think we should list the type\n> in the API, i.e. if it were a vector it shouldn't be ControlVector.\n> \n> It's a list. - the storage is up to the implementation.\n> Of course that affects how users interact with it ....\n\nGood names are difficult to create. I agree with Kieran here, list is\nmore descriptive of the purpose of the class than map in this case. We\ncould also call it ControlSet if we wanted to emphasise that the order\ndoesn't matter, but that name would generate confusion with the\noperation of setting controls in my opinion.\n\n> > All of this in patches 1, 2, 3\n> > \n> > 2) Serialization implies de-serialization, and to construct a ControlList we\n> > need a camera. Break this dependency in patch 4/5 to be able to reconstruct\n> > a ControlList from serialized data later\n> > \n> > 3) Bikeshedders heaven: rewording of comments and rename of data types in\n> > Control framework. As explained in the commit message of 5/5, the rewording\n> > tries to enforce the following concepts: control metadata, control info,\n> > and control values.\n> > \n> > On top of this I have patches and tests for Serialization, but not yet for\n> > de-serialization. I hope not, but it might be that implementing it\n> > require changes in this series, so be prepared.\n> > \n> > All of this for the back-end storage.\n> > \n> > The user APIs: there is work there too, as both V4L2Controls and Controls might\n> > need re-thinking of their user API. The fundamental difference between the two\n> > (and it took me a while to realize the implication of this in the API\n> > definition) it's where validation information are kept.\n> > \n> > ControlList is created with a reference to a ControlInfoMap used for validation\n> > and produced by pipeline handlers at camera registration time. This allows to\n> > validate a control at the moment it is added to the list, as doing so when\n> > queuing requests is indeed too late for a safe recovery.\n> \n> Hrm ... so we have a ControlInfoMap ... Well that kind of goes a bit\n> against what I said earlier. But in that case, it's not really an\n> arbitrary list of ControlInfo is it ? I wonder if that makes the term\n> 'map' more applicable?\n> \n> Or maybe it's just because in my head, a Control is always an\n> association of an ID and a value.\n> \n> (I think in my original implementations I aimed to have an object called\n> Control which stored both the ID and the value in a single class).\n> \n> > V4L2Control list only contains values. The validation informations are kept in\n> > the device the list is applied on. I think this still makes sense, as V4L2\n> > controls are meant to be validate at the time they are immediately applied to\n> > the device by the driver exposing them, and they will not be exposed to\n> > applications. Anyway, creating a V4L2ControlList from a device might make\n> > serialization easier because both values and information would then be kept\n> > in the same class, as it happens now for Controls.\n> > \n> > The other difference in the API is a matter of tastes mostly. Controls use the\n> > overloaded operator[] to set/get controls, V4L2Controls have explicit get/set.\n> > Having implemented them, it's clear that my preference goes toward explicit\n> > get/set, as operator overloading makes me always a bit unconfortable and I\n> > prefer to type in 3 letters more for set/get but have an explicit indication of\n> > what's happening. Anyway, the use of [] made in ControlList is pretty natural\n> > and does what you would expect it to do (maybe if it was a ControlMap it would\n> > feel more natural to do controls[x] = y ? Now that I wrote it here, I'll suggest\n> > it in the above comment too) and seems to be also in line with\n> \n> I find the [] operator quite natural, and allows short clean code ?\n> \n> ControlList snapshot;\n> \n> snapshot[Exposure] = 5;\n\nWhile I have a tendency to like operators, I would side a bit with\nJacopo on this, snapshot.set(Exposure, 5) or snapshot.add(Exposure, 5)\nmay be more readable. I know what operator[] does as I'm familiar with\nthe code, but for someone without knowledge of the implementation, the\noperator may not be that intuitive. Among other things, operator[] needs\nto define what happens when the element doesn't exist in the container.\nOne may suspect that it would get added, but .set() or .add() would make\nthat more explicit. Similarly, it is clear that .get() will do something\nwhen the element doesn't exist (even though the function name doesn't\nreally tell what will happen), while operator[] may leave the user\nwondering whether it could crash or lead to other unexpected behaviour.\n\nLet's remember the core rule: in a good API, methods operate as you\nwould expect from their name, and are named as you would expect from\ntheir purpose.\n\n> Aha - That was it - Now I remember why we had the ControlInfo comparator\n> overloads. It was to allow indexing the ControlList maps with either an\n> enum of the control ID, or by indexing with a ControlInfo.\n> \n> But if we don't use it with the ControlInfo then I guess they aren't needed.\n>\n> > https://google.github.io/styleguide/cppguide.html \"Operator Overloading\"\n> > section. So I'll go with popular preference, but in any case I think the two\n> > should be unified.\n> > \n> > As said, serialization will come on top of this work, so please comment to avoid\n> > me too many re-bases :)\n> > \n> > Thanks\n> > j\n> > \n> > Jacopo Mondi (5):\n> > libcamera: Create DataValue and DataInfo\n> > libcamera: controls: Use DataType and DataValue\n> > libcamera: v4l2_controls: Use DataValue and DataInfo\n> > libcamera: controls: De-couple Controls from Camera\n> > libcamera: controls: Control framework refresh\n> > \n> > include/libcamera/controls.h | 94 +----\n> > include/libcamera/data_value.h | 84 ++++\n> > include/libcamera/meson.build | 1 +\n> > src/libcamera/controls.cpp | 398 +++++-------------\n> > src/libcamera/data_value.cpp | 317 ++++++++++++++\n> > src/libcamera/gen-controls.awk | 4 +-\n> > src/libcamera/include/v4l2_controls.h | 22 +-\n> > src/libcamera/include/v4l2_device.h | 1 -\n> > src/libcamera/meson.build | 7 +-\n> > src/libcamera/pipeline/uvcvideo.cpp | 2 +-\n> > src/libcamera/pipeline/vimc.cpp | 2 +-\n> > src/libcamera/request.cpp | 4 +-\n> > src/libcamera/v4l2_controls.cpp | 49 +--\n> > src/libcamera/v4l2_device.cpp | 25 +-\n> > test/controls/control_info.cpp | 4 +-\n> > test/controls/control_list.cpp | 6 +-\n> > test/controls/meson.build | 1 -\n> > .../data_value.cpp} | 24 +-\n> > test/data_value/meson.build | 12 +\n> > test/meson.build | 1 +\n> > 20 files changed, 593 insertions(+), 465 deletions(-)\n> > create mode 100644 include/libcamera/data_value.h\n> > create mode 100644 src/libcamera/data_value.cpp\n> > rename test/{controls/control_value.cpp => data_value/data_value.cpp} (68%)\n> > create mode 100644 test/data_value/meson.build","headers":{"Return-Path":"","Received":["from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 36C7460BB6\n\tfor ;\n\tThu, 26 Sep 2019 23:36:48 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-216-236.bb.dnainternet.fi\n\t[81.175.216.236])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 958F59BF;\n\tThu, 26 Sep 2019 23:36:47 +0200 (CEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1569533807;\n\tbh=kqJYhwA41m3Zfg0VbhHx0WP7Ro2pepyJSuqAqTf0oU4=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=Kjw8xRvfRRvzyAaotTutOQwFAlJf8B/gz8TKOb4bf2Hm3P7C6GhIwcnI+vmOTF3tp\n\tdjhf9l7OcRv3pSnr1YmN95LBLZ5QjANjzjixDmG08XVrIXj2Rjrr1XJJE3UBGS1co1\n\tdKLYzSDRnCcq7aRmCDsXpjVlP/Qq582SsP2e8A5Q=","Date":"Fri, 27 Sep 2019 00:36:36 +0300","From":"Laurent Pinchart ","To":"Kieran Bingham ","Cc":"Jacopo Mondi , libcamera-devel@lists.libcamera.org","Message-ID":"<20190926213636.GB4864@pendragon.ideasonboard.com>","References":"<20190918103424.14536-1-jacopo@jmondi.org>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.10.1 (2018-07-13)","Subject":"Re: [libcamera-devel] [PATCH 0/5] libcamera: Control framework\n\tbackend rework","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","X-List-Received-Date":"Thu, 26 Sep 2019 21:36:48 -0000"}}]