| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | nst has quit IRC (Ping timeout: 256 seconds) | [01:55] |
| .................................................................. (idle for 5h27mn) | ||
| mchehab has quit IRC (Remote host closed the connection) | [07:22] | |
| ............ (idle for 55mn) | ||
| hverkuil | koike: that's undefined at the moment. The Request API framework does not support streaming from multiple queues, it's lacking infrastructure for that. The API supports it (although it needs more documentation to describe how it should behave), but it's never been used.
koike: what's the use-case? The Request API has really been tested with stateless decoders only, and going beyond that use-case will require quite a lot of work. | [08:17] |
| ............... (idle for 1h11mn) | ||
| tfiga | hverkuil: I suppose it's for all the ISP drivers, the two in staging and MediaTek ones on the list | [09:30] |
| .... (idle for 15mn) | ||
| *** | kwizart has quit IRC (Remote host closed the connection) | [09:45] |
| ............................... (idle for 2h32mn) | ||
| hverkuil | jmondi: ping | [12:17] |
| jmondi | hverkuil: pong
Hi Hans | [12:18] |
| hverkuil | regarding the 'Register read-only sub-dev devnode' series: I see a v6 is needed. Do you need additional input from me? Probably regarding whether or not reserved field should be added for the SUBDEV_QUERYCAP, it looks like that's the only open question, right? | [12:19] |
| jmondi | hverkuil: yes, I wanted to get a consensus there
from what sakari said, between v4l2 and media-controller the way of versioning ioctls differ | [12:20] |
| hverkuil | OK, I'll look at that a bit more today and will reply.
jmondi: was there a dependency on the IO_MC series? I thought there was, but I may be wrong. | [12:20] |
| jmondi | hverkuil: not that I'm aware of :) | [12:21] |
| hverkuil | Ah, I think I got confused with the ENUM_FMT patch, which was originally independent of the IO_MC series, but was incorporated into that series later on. | [12:23] |
| jmondi | I think that's the one, yes | [12:25] |
| .... (idle for 19mn) | ||
| mchehab | with regards to ENUM_FMT patches, I guess I'll just push it, now that we got sailus ack
with the test from hverkuil's v3 I'll also merge together the quick fix for ipu3.rst solving a Sphinx warning with 2.4.4 (detected when testing such patches) hmm... sailus ack was just for the IPU3 driver | [12:44] |
| .......... (idle for 48mn) | ||
| hverkuil | tfiga: koike: using the request API with ISPs is a much bigger project. I believe pinchartl has looked into it, but I don't know if any progress was made (haven't heard anything). Most of the work will be with the internal plumbing, and I expect that to be quite complex. | [13:34] |
| pinchartl | hverkuil: I gave up on that one | [13:40] |
| hverkuil | I suspected that was the case. | [13:41] |
| ........... (idle for 53mn) | ||
| pinchartl: is your omap dss patch series now merged? | [14:34] | |
| pinchartl | hverkuil: yes it is | [14:35] |
| hverkuil | Congrats! So I can now work on CEC for omap5 without interfering with your work in that driver? | [14:35] |
| pinchartl | yes :-)
sorry for delaying you there | [14:37] |
| hverkuil | No problem, I'll try and find some time soon to work on that. It would be nice to finalize that.
pinchartl: BTW, was your series merged for 5.7, or did it already appear in 5.6? | [14:38] |
| pinchartl | v5.7-rc1 | [14:40] |
| hverkuil | Thank you, good to know. | [14:40] |
| koike | hverkuil: tfiga: yes, so mediatek isp has two frame capture nodes and a couple of capture nodes for metadata, and an output node for parameters, and (if I understand correctly) they are using Request API to sync buffers, to queue buffers for multiple video nodes in one request (which I think it make sense) | [14:45] |
| hverkuil | koike: I wonder how they do that, I don't think the infrastructure fully supports this. Although it might work if you make specific assumptions on how it is used by userspace.
I.e.: what happens if the request has no buffers, or a buffer for the capture node but not for the metadata capture node (or vice versa), or a buffer for a device node that is not streaming, etc. etc. | [14:51] |
| .... (idle for 15mn) | ||
| pinchartl | the concept of streaming on a video node doesn't make much sense anymore for m2m devices using the request API
but reworking that is a ton of work | [15:10] |
| koike | hverkuil: I was guessing that driver would dictate what is valid in req_validate() callback | [15:13] |
| hverkuil | koike: that might be how they did it. I haven't seen the code, so I'm just not sure. | [15:14] |
| *** | benjiG has left | [15:14] |
| koike | hverkuil: they didn't, but I had this question too and I suggested to use req_validate() to enforce those, but I'm still unsure about other side effects of using Request API for ISPs
the other option would be to not use the request api, and internally, the driver would wait for a buffer in each video node to be queued, before doing anything with it | [15:15] |
| hverkuil | There is nothing wrong with using the Req API, that's really what it is there for. It's just that this has never been tested and reviewed since the initial implementations were for the simpler decoder use-case. | [15:20] |
| koike | right | [15:22] |
| hverkuil | Once you start to allow buffers for different video nodes to be added to a request, then you have to start to think about the requirements and behavior, in particular all the corner cases. We need an RFC, I think. | [15:23] |
| .... (idle for 15mn) | ||
| *** | lexano has quit IRC (Ping timeout: 272 seconds) | [15:38] |
| hverkuil | Hmm, vimc is broken after the CAP_IO_MC is enabled in that driver, but only for 32-bit. Native 64-bit is fine. Easy enough to test: v4l2-ctl -v pixelformat=BA81 is OK, but v4l2-ctl-32 -v pixelformat=BA81 says "The pixelformat 'BA81' is invalid".
I'll dig deeper tomorrow. To compile v4l2-ctl-32 use 'configure --enable-v4l2-ctl-32' when configuring v4l-utils. There is no compat32 code needed for ENUM_FMT, so I don't quite understand why this fails on 32 bit. Found it. v4l2-ctl bug with a v4l2_fmtdesc that was never properly zeroed. | [15:40] |
| ..... (idle for 22mn) | ||
| ndufresne | paulk-leonov: with some intermediate userspace implementation, cedrus driver seems to oops, https://paste.centos.org/view/fd782fc4
(e.g. the slice params are still incomplete / bogus) that's 5.6.0-rc1, a bit aging, but I don't know if there was any other activity paulk-leonov: first thing I notice with cedrus (I mean appart that is to not use the new mplane structures) is that it will default the bitstream buffer size to 1kb so I had to add userspace code to pick a proper bitstream buffer size, that haven't been needed so far with rkvdec and hantro | [16:09] |
| ...................... (idle for 1h45mn) | ||
| *** | syoung has quit IRC (Quit: leaving) | [17:57] |
| ........................ (idle for 1h58mn) | ||
| mripard has quit IRC (Ping timeout: 265 seconds) | [19:55] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |