| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | mchehab has quit IRC (Quit: ZNC 1.7.2+deb3 - https://znc.in) | [06:58] |
| nst has quit IRC (*.net *.split)
Kwiboo- has quit IRC (*.net *.split) larsc has quit IRC (*.net *.split) mmattice has quit IRC (*.net *.split) | [07:07] | |
| ...................... (idle for 1h46mn) | ||
| svarbanov | hverkuil, does v4l2 compound controls supports v4l2_events when the content of the control is changed? | [08:53] |
| hverkuil | svarbanov: it should support that, yes. | [09:00] |
| svarbanov | hverkuil, ok cool, can I trigger the event from the driver when I found (in the driver) that the content is changed?
I'm thinking about HDR10 static metadata for decoder case. I have a way to catch the new HDR10 Mastering display info and CLL and I'm searching a way to notify the client | [09:02] |
| hverkuil | svarbanov: this should happen automatically if you call __v4l2_ctrl_s_ctrl_compound with a new compound value.
The control framework checks if it differs from the old value and it transmits the event if it is indeed different. Um, it's worth verifying this :-) This isn't tested by v4l2-compliance for compound controls AFAIK. I need to improve that, at least for the compound controls supported by vivid. | [09:05] |
| paulk-leonov: ezequielg: can you review v2 of Samuel Holland's cedrus PM series? | [09:12] | |
| svarbanov | hverkuil, thanks for the hint :)
hverkuil, I'm not sure, do we concluded that hdr10 static metadata implementation will be through v4l2_ctrl ? Or it is not clear yet. I want to avoid doable work | [09:13] |
| hverkuil | svarbanov: I can't remember where that discussion ended up. Did it reach a conclusion?
Hmm, the last email is from me on Feb 19. | [09:17] |
| svarbanov | hverkuil, I remember you were strongly for v4l2 ctrls but there were some comments from pinchartl | [09:18] |
| hverkuil | In that last email I basically say that it makes sense to use a video device for extended infoframes. If the DMA engine supports it, then dumping all InfoFrames to a video device is also possible. But otherwise use controls.
I also want to note that many i2c HDMI receivers do not lend themselves for streaming infoframes to a metadata video device for the simple reason that infoframes are just stored in registers. Using controls are the obvious way of exposing the infoframes. So I stand by my conclusion in that email. | [09:21] |
| ..... (idle for 20mn) | ||
| neg: can you review https://patchwork.linuxtv.org/cover/63086/ ? | [09:43] | |
| neg | hverkuil: On my things to do this week, hoping I can create a setup where I can test it | [09:46] |
| hverkuil | ok, thanks! | [09:46] |
| ......... (idle for 40mn) | ||
| *** | taliho has quit IRC (Read error: Connection reset by peer)
varodek has quit IRC (Read error: Connection reset by peer) [LOGGER] has quit IRC (Ping timeout: 246 seconds) | [10:26] |
| ......... (idle for 40mn) | ||
| YuGiOhJCJ has quit IRC (Quit: YuGiOhJCJ) | [11:06] | |
| ...... (idle for 27mn) | ||
| ezequielg | hverkuil: on cedrus, hantro and rkvdec, i'm noticing we are fixing the same bugs and issues. we should really consider having a way to avoid this, either common code or helpers.
being different drivers, i'm not all that sure what's best. | [11:33] |
| hverkuil | I like helper functions, it's often a good approach. Common code can work as well, but you have to be certain it can really be the same for all drivers, i.e. it is harder to allow for driver-specific code.
This is just based on general experience, it has to be looked at case-by-case. | [11:35] |
| ezequielg | stateless decoder so far tend to be so similar, that they could even support a common driver! i know it's not the v4l2 way, but it shows how common they are. | [11:49] |
| hverkuil | One driver that supports several HW models can be tricky. It makes a lot of sense for a vendor that has several variants of what is basically the same HW. But you have to be cautious when it is from different vendors or if the HW variants are really different from one another. | [11:53] |
| ezequielg | hverkuil: also, i'm working on vp9, am i still in time? was delayed because i started testing and found a regression which btw, we have to fix on the other decoders as well :) | [11:54] |
| hverkuil | We have drivers where the 'common driver' theme was taken too far, making it hard to maintain. | [11:55] |
| ezequielg | indeed, that's true. | [11:56] |
| hverkuil | ezequielg: we're at rc4, so there is another three weeks for vp9 patches (well, two weeks, really, to give me and Mauro time to review/merge the patches) | [11:56] |
| ezequielg | you change one thing, but then you can only test on so much platforms. | [11:56] |
| hverkuil | it's a balance, and it takes experience to decide what is best. In this case my gut tells me that you are better of with helpers/frameworks rather than combining in a single driver. | [11:58] |
| .... (idle for 15mn) | ||
| *** | indy has quit IRC (Ping timeout: 260 seconds) | [12:13] |
| ezequielg | hverkuil: +1
hverkuil: i'm taking a look at samuel holland cedrus patches. | [12:19] |
| ....... (idle for 30mn) | ||
| *** | gouchi has quit IRC (Remote host closed the connection) | [12:49] |
| tfiga | hverkuil: ezequielg: from my experience, with good helpers you can often achieve a close level of unification to a common driver
after all, what stops you from creating helpers for everything that is common? :) and it leaves several ways of handling things that are not common | [13:03] |
| *** | ao2 has quit IRC (Quit: Leaving) | [13:06] |
| .... (idle for 18mn) | ||
| ezequielg | tfiga: +1 | [13:24] |
| *** | taliho has quit IRC (Quit: The Lounge - https://thelounge.chat)
RzR has quit IRC (Changing host) | [13:35] |
| ....... (idle for 31mn) | ||
| gnurou | one thing I have been wondering when looking at the kernel data structures: are the `v4l2_plane_pix_format::sizeimage` reported by S_FMT and `v4l2_plane::length` reported by QUERYBUF supposed to be the same? If not, what is the difference? If yes, is there a reason to have two ways to get this information? | [14:08] |
| ............ (idle for 56mn) | ||
| koike | hello o/ request api question: what should happen if: a user do a request with several VIDIOC_QBUF to different capture nodes, then do a VIDIOC_STREAMON to just one of the capture nodes. Should the request be ignored? (or is this implementation specific?). I guess I'm a bit confused, because there is no way to call STREAMON to multiple capture devices at once | [15:04] |
| *** | mtr has quit IRC (Quit: leaving) | [15:05] |
| ............ (idle for 59mn) | ||
| ezequielg | gnurou: good question. struct v4l2_plane is part of struct v4l2_buffer. so it contains buffer's plane information. it's not necessarily talking about a format. otoh, v4l2_plane_pix_format::sizeimage is a format's plane size.
so it's really format vs. buffer. | [16:04] |
| *** | _abbenormal has quit IRC (Read error: Connection reset by peer) | [16:05] |
| ezequielg | and a driver should expect (check?) buffer.plane.length > format.plane.sizeimage
well, >= of course. | [16:05] |
| gnurou | ezequielg: right, I also realized that there is also the fact that `v4l2_plane::length` needs to be specified when queueing USERPTR buffers
I have just been asked the question "should I rely on the size reported by S_FMT or QUERYBUF for my buffer size?" and found myself not being able to give a good answer :) | [16:06] |
| ezequielg | what do you mean "for my buffer size" ? | [16:08] |
| gnurou | like, when you submit non-MMAP buffers | [16:09] |
| ezequielg | OUTPUT type buffers? | [16:09] |
| gnurou | yes. sorry, should have been more precise
although I guess this should also apply to CAPTURE buffers, as long as they are not MMAP is the length reported by the format, or the length reported by QUERYBUF, the source of truth for how much memory is needed for a buffer (or should they just be equal all the time) my guess is that both are valid and should have the same value, but I thought I would ask nonetheless | [16:09] |
| ezequielg | right.... good question indeed.
I believe that S/TRY_FMT should match what you'll later get via QUERYBUF. but I am now wondering if this is something drivers need to take care of, and therefore how error prone is. | [16:14] |
| gnurou | that was my worry as well :) | [16:16] |
| ezequielg | i'm being summoned to take a break, but i'll add a TODO item here to look into this and think some more.
if you believe the docs are unclear in this regards, by all means throw a patch. | [16:16] |
| *** | KindOne has quit IRC (Quit: K-Lined) | [16:20] |
| gnurou | don't worry too much. I was just surprised to see what looked like the same information come from 2 different sources
in order to throw a patch we first need to find the answer to that question :) | [16:22] |
| .................... (idle for 1h39mn) | ||
| *** | mszyprow^home has quit IRC (Ping timeout: 240 seconds) | [18:01] |
| ..................... (idle for 1h43mn) | ||
| ndufresne | gnurou: sizeimage in there solves notably the issue of framing using read/write interface (not that this interface is used much anymore), but the rule that ezequielg gave you is correct, and it should be validate when you do USERPTR, or DMABUF buffer type (importation)
the buffer abstraction is a little more complex, as it's not bound to a fixed size image, hence the length vs bytesused, etc. | [19:44] |
| ...................... (idle for 1h48mn) | ||
| *** | Marex has quit IRC (Ping timeout: 260 seconds) | [21:32] |
| .... (idle for 17mn) | ||
| bparrot has quit IRC (Remote host closed the connection) | [21:49] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |