[00:48] *** mchehab has quit IRC (Ping timeout: 265 seconds)
[15:35] *** benjiG has left 
[22:45] <sailus> jmondi: Ping?
[22:45] <pinchartl> sailus: (with a fake jmondi voice) pong
[22:46] <sailus> pinchartl: Buena notte!
[22:49] <sailus> pinchartl: About ro subdevs --- wouldn't you use them with MC-enabled setups as well?
[22:49] <sailus> The basic problem is the same, isn't it?
[22:50] <sailus> jmondi's patchset only mentions devnode centric bridge drivers...
[22:50] <pinchartl> what would be the use case for MC-centric devices ?
[22:51] <pinchartl> they should use RW subdevs
[22:51] <sailus> For drivers where the register list is selected based on the format set on the source pad?
[22:52] <sailus> Most drivers are such.
[22:52] <jmondi> sailus: pong
[22:52] <jmondi> pinchartl: ...
[22:52] <sailus> jmondi: EHLO
[22:52] <jmondi> you should work on your italian accent
[22:52] <jmondi> pinchartl: ^
[22:52] <pinchartl> sailus: and ? :-) you set the format with the RW subdev API in that case
[22:53] <pinchartl> and you benefit from the whole subdev API
[22:53] <sailus> pinchartl: The driver implementation is such that it uses SUBDEV_S_FMT, and that's all the information the user gets.
[22:53] <jmondi> sailus: with an MC centric driver you want userspace to be able to set a format on a subdev, don't you ?
[22:53] <sailus> No binning, cropping, skipping or scaling info.
[22:53] <pinchartl> sailus: no, you'd have to extend the sensor driver to support selection rectangles
[22:54] <pinchartl> so you'd get crop and output subdev, and would get rudimentary scaling information
[22:54] <pinchartl> if you want to differentiate between binning, skipping and scaling, then you'd need to split it in multiple subdevs
[22:54] <pinchartl> it doesn't change what exists today
[22:54] <jmondi> isn't this an orthogonal issue to ro/rw subdevs ?
[22:54] <pinchartl> the problem is well-known, and RO subdevs allows accessing the information through the API we have
[22:55] <pinchartl> if sensor drivers don't implement that API, they need to be fixed
[22:55] <sailus> Do you happen to have a sensor driver using ro sub-device API?
[22:56] <jmondi> not in mainline at the moment...
[22:56] <sailus> jmondi: Something that could be an RFC perhaps?
[22:56] <pinchartl> we're warking with different sensors
[22:56] <sailus> It'd be quite useful to understand how this could be used in practice.
[22:56] <pinchartl> one of them being ov5647
[22:58] <pinchartl> ov5647 will be extended to support the selection API
[22:58] <pinchartl> and so for each mode it will be able to report the corresponding crop rectangle
[22:59] <jmondi> but again, what information the sensor provides does not change with ro/rw subdev nodes, doesn't it ?
[23:00] <jmondi> if you have those information exposed by the driver, you can access them with a ro subdevice the same way you could with an rw subdevice
[23:01] <sailus> jmondi: What kind of information do you intend to put there?
[23:02] <sailus> And how many ro subdevs per sensor would there be?
[23:02] <pinchartl> any number you want
[23:02] <pinchartl> *exactly* the same way as with RW subdevs
[23:02] <pinchartl> it changes nothing there
[23:03] <pinchartl> the sensor driver is exactly the same, and doesn't know if the userspace API is RO or RW
[23:03] <pinchartl> (or doesn't exist at all)
[23:03] <jmondi> sailus: whatever the driver could expose with a rw subdev could be exposed with an rw subdev
[23:04] <sailus> How do you find those device nodes without MC?
[23:04] <sailus> Or would you register a media device for the bridge?
[23:05] <jmondi> sailus: good point, I've seen driver registering a media device to support enumeration, but handling subdevice configuration internally through direct calls to the subdev operations
[23:05] <jmondi> can't say I like it, but...
[23:05] <pinchartl> sailus: you'll need to register a MC device for the bridge
[23:05] <pinchartl> but without link setup support or any other configuration
[23:06] <pinchartl> just for the purpose of enumeration
[23:06] <pinchartl> (uvcvideo does that for instance, without subdevs)
[23:06] <pinchartl> and that should be made automatic for all drivers in the long term I think
[23:06] <sailus> Makes sense.
[23:06] <pinchartl> but that's another story
[23:06] <jmondi> a long story :)
[23:07] <sailus> What kind of information would you like to expose from a sensor driver?
[23:08] <sailus> Just the sensor's output format, or more?
[23:08] <sailus> I'm asking since the V4L2 sub-device interface is currently ill suited for providing the details on the configuration of the sensor using a single sub-device.
[23:08] <jmondi> more indeed, but that applies to both rw and ro subdevices
[23:08] <jmondi> indeed
[23:09] <pinchartl> sailus: in this case, it's the crop rectangle that we want as the first target
[23:09] <pinchartl> but we'll need more
[23:09] <pinchartl> there are two options
[23:09] <jmondi> we'll soon stumble on that part, as Laurent said it's currently awkward to report scaling and binning with a single subdev
[23:09] <sailus> Analogue crop or digital crop?
[23:09] <pinchartl> one way will be to split the sensor in multiple subdevs
[23:09] <jmondi> if not possible at all
[23:09] <pinchartl> another way would be to develop a new API
[23:10] <sailus> Indeed.
[23:10] <pinchartl> the second option would conflict with the smiapp driver
[23:10] <pinchartl> which is split in multiple subdevs
[23:10] <sailus> There can be multiple ways to do it, I don't think that's really a problem.
[23:10] <pinchartl> having two different APIs for the same purpose isn't a good idea
[23:10] <pinchartl> we know the subdev API is not very nice for sensors, that's nothing new
[23:11] <jmondi> https://lists.libcamera.org/pipermail/libcamera-devel/2020-March/007816.html
[23:11] <pinchartl> the RO API allows exposing what we have *today*
[23:11] <pinchartl> we can possibly, tomorrow, create a replacement for the 3 subdevs solution that smiapp uses
[23:11] <pinchartl> and then it would be automatically available in RO mode too
[23:11] <pinchartl> but it's a separate issue
[23:11] <pinchartl> one issue is to offer a RO way to query the subdev configuration
[23:12] <sailus> pinchartl: Don't forget CSI-2 VCs and DTs if you're thinking of changing the model.
[23:12] <pinchartl> another is a good API to configure sensors
[23:12] <jmondi> for my education, smiapp describes the whole sensor processing pipeline split as three subdevs ?
[23:12] <pinchartl> I don't want to change the model honestly
[23:12] <pinchartl> too much work, not worth it
[23:12] <sailus> I doubt alternatives are feasible, all those needs taken into account.
[23:12] <pinchartl> but if someone wants to do it, I won't stop them :-)
[23:13] <sailus> Without introducing new concepts on a quite well established uAPI...
[23:13] <sailus> jmondi: Correct.
[23:13] <sailus> It omits some less needed configuration; if that was there, there would be more subdevs.
[23:13] <pinchartl> what does it omit ?
[23:14] <sailus> (I'm not talking about embedded data here, which also requires more subdevs.)
[23:14] <sailus> Skipping, for instance.
[23:14] <sailus> I thought skipping would be out of fashion by 2012 but it turns out that's not the case.
[23:14] <jmondi> the subdev that controls skipping is different than the one that performs, say, binning ?
[23:15] <jmondi> it's not a single "subsampler" subdvice ?
[23:15] <sailus> jmondi: No skipping is done at all, currently.
[23:15] <sailus> No, the process is different.
[23:15] <sailus> But I guess the two could be combined, on the expense of control over the selection between the two.
[23:17] <jmondi> I see.. anyway, I linked you here the libcamera patch that tries to define the information we would like to be able to collect from a subdevice node
[23:17] <jmondi> or at least, a first attempt
[23:17] <jmondi> if you have comment there, they're very welcome
[23:18] <sailus> jmondi: Why try formats only?
[23:18] <jmondi> in the ro subdev ?
[23:18] <sailus> Yes.
[23:18] <jmondi> as it doesn't get applied to the HW
[23:18] <pinchartl> because setting the active format would be a write operation :-)
[23:19] <pinchartl> we can get(ACTIVE) and get/set(TRY)
[23:19] <sailus> The commit message discusses the *current* configuration.
[23:19] <sailus> Ah, right.
[23:19] <pinchartl> I'm not sure we'd need TRY, maybe get(ACTIVE) would be enough, but as get/set(TRY) doesn't modify the active state, we thought it could be useful
[23:19] <pinchartl> and it doesn't cose anything
[23:19] <pinchartl> cost
[23:20] <jmondi> I'm actually not sure what a use case for set(TRY) would be for a ro subdev, now that I think about that again
[23:21] <jmondi> formats can be enumerated, and testing a format just to see how the subdev would react I'm not sure bring much value
[23:21] <jmondi> pinchartl: or is there another use case for that in your opinion ?
[23:21] <sailus> jmondi: You can do that without changing device configuration?
[23:22] <jmondi> sailus: isn't that the whole point of TRY_FORMAT ?
[23:23] <sailus> Yes.
[23:23] <pinchartl> I don't agree
[23:23] <jmondi> pinchartl: shoot
[23:24] <pinchartl> should I point you to the V4L2 doc ? :-)
[23:24] <pinchartl> the *whole* TRY model on subdevs requires get and set
[23:24] <pinchartl> there are dependencies between formats on different pads
[23:29] * jmondi goes to read SUBDEV_S_FMT again
[23:29] <jmondi> got it, we need set(TRY) :)
[23:30] <pinchartl> :-)
[23:30] <pinchartl> the doc clearly does a better job at explaining this than I do :-)
[23:31] <pinchartl> sorry for not having been clear when we discussed the TRY operation for the V4L2Subdevice class :-(
[23:32] <jmondi> ?
[23:32] <jmondi> I was just wondring that in the context of the ro subdev
[23:33] <pinchartl> we had a previous discussion about the API for V4L2Sudbevice in libcamera, where I failed to explain why we needed get/set functions for both ACTIVE and TRY instead of a try function for TRY
[23:35] <jmondi> I don't even recall that :)
[23:35] <jmondi> ah, when I wanted a tryFormat() operation
[23:36] <jmondi> sorry for not having read the documentation, I would say :)
[23:36] <jmondi> sailus: do we have your blessing then ? :)
[23:39] <sailus> jmondi: I've acked the set.
[23:40] <jmondi> sailus: great, thanks a lot