{"id":1984,"url":"https://patchwork.libcamera.org/api/1.1/covers/1984/?format=json","web_url":"https://patchwork.libcamera.org/cover/1984/","project":{"id":1,"url":"https://patchwork.libcamera.org/api/1.1/projects/1/?format=json","name":"libcamera","link_name":"libcamera","list_id":"libcamera_core","list_email":"libcamera-devel@lists.libcamera.org","web_url":"","scm_url":"","webscm_url":""},"msgid":"<20190918103424.14536-1-jacopo@jmondi.org>","date":"2019-09-18T10:34:19","name":"[libcamera-devel,0/5] libcamera: Control framework backend rework","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/1.1/people/3/?format=json","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"mbox":"https://patchwork.libcamera.org/cover/1984/mbox/","series":[{"id":501,"url":"https://patchwork.libcamera.org/api/1.1/series/501/?format=json","web_url":"https://patchwork.libcamera.org/project/libcamera/list/?series=501","date":"2019-09-18T10:34:19","name":"libcamera: Control framework backend rework","version":1,"mbox":"https://patchwork.libcamera.org/series/501/mbox/"}],"comments":"https://patchwork.libcamera.org/api/covers/1984/comments/","headers":{"Return-Path":"","Received":["from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net\n\t[217.70.183.196])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id C41C160BB0\n\tfor ;\n\tWed, 18 Sep 2019 12:32:50 +0200 (CEST)","from uno.lan (2-224-242-101.ip172.fastwebnet.it [2.224.242.101])\n\t(Authenticated sender: jacopo@jmondi.org)\n\tby relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 70BE0E0009\n\tfor ;\n\tWed, 18 Sep 2019 10:32:50 +0000 (UTC)"],"X-Originating-IP":"2.224.242.101","From":"Jacopo Mondi ","To":"libcamera-devel@lists.libcamera.org","Date":"Wed, 18 Sep 2019 12:34:19 +0200","Message-Id":"<20190918103424.14536-1-jacopo@jmondi.org>","X-Mailer":"git-send-email 2.23.0","MIME-Version":"1.0","Content-Transfer-Encoding":"8bit","Subject":"[libcamera-devel] [PATCH 0/5] libcamera: Control framework backend\n\trework","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","X-List-Received-Date":"Wed, 18 Sep 2019 10:32:50 -0000"},"content":"Hello,\n this series is the first half of the currently in progress serialization\nsupport work.\n\nThe basic idea is that to be able to serialize Controls and V4L2Controls\nusing the same API, their back-end storage should be unified to use the same\npolymorphic data storage class. This was the initial plan to be honest, but it\ndidn't match the urgent need to get controls support in at the time, but it's\nnow required for serialization, so it's now a good time to fix this long\nstanding issue.\n\nThe series addresses the issue taking the following steps.\n1) 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 All of this in patches 1, 2, 3\n\n2) 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\n3) 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\nOn top of this I have patches and tests for Serialization, but not yet for\nde-serialization. I hope not, but it might be that implementing it\nrequire changes in this series, so be prepared.\n\nAll of this for the back-end storage.\n\nThe user APIs: there is work there too, as both V4L2Controls and Controls might\nneed 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\ndefinition) it's where validation information are kept.\n\nControlList is created with a reference to a ControlInfoMap used for validation\nand produced by pipeline handlers at camera registration time. This allows to\nvalidate a control at the moment it is added to the list, as doing so when\nqueuing requests is indeed too late for a safe recovery.\n\nV4L2Control list only contains values. The validation informations are kept in\nthe device the list is applied on. I think this still makes sense, as V4L2\ncontrols are meant to be validate at the time they are immediately applied to\nthe device by the driver exposing them, and they will not be exposed to\napplications. Anyway, creating a V4L2ControlList from a device might make\nserialization easier because both values and information would then be kept\nin the same class, as it happens now for Controls.\n\nThe other difference in the API is a matter of tastes mostly. Controls use the\noverloaded operator[] to set/get controls, V4L2Controls have explicit get/set.\nHaving implemented them, it's clear that my preference goes toward explicit\nget/set, as operator overloading makes me always a bit unconfortable and I\nprefer to type in 3 letters more for set/get but have an explicit indication of\nwhat's happening. Anyway, the use of [] made in ControlList is pretty natural\nand does what you would expect it to do (maybe if it was a ControlMap it would\nfeel more natural to do controls[x] = y ? Now that I wrote it here, I'll suggest\nit in the above comment too) and seems to be also in line with\nhttps://google.github.io/styleguide/cppguide.html \"Operator Overloading\"\nsection. So I'll go with popular preference, but in any case I think the two\nshould be unified.\n\nAs said, serialization will come on top of this work, so please comment to avoid\nme too many re-bases :)\n\nThanks\n j\n\nJacopo 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--\n2.23.0"}