| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | camus has joined #linux-media
camus1 has quit IRC (Ping timeout: 480 seconds) | [00:17] |
| ....... (idle for 32mn) | ||
| jarthur has quit IRC (Ping timeout: 480 seconds) | [00:51] | |
| .......... (idle for 47mn) | ||
| lexano has quit IRC (Remote host closed the connection) | [01:38] | |
| camus has quit IRC (Remote host closed the connection)
camus has joined #linux-media | [01:45] | |
| ...... (idle for 25mn) | ||
| lexano has joined #linux-media | [02:12] | |
| eelstrebor has quit IRC (Quit: Ex-Chat) | [02:18] | |
| ......... (idle for 43mn) | ||
| bingbu has joined #linux-media | [03:01] | |
| ........ (idle for 35mn) | ||
| camus1 has joined #linux-media | [03:36] | |
| camus has quit IRC (Ping timeout: 480 seconds) | [03:41] | |
| ......... (idle for 43mn) | ||
| camus has joined #linux-media
camus1 has quit IRC (Read error: Connection reset by peer) | [04:24] | |
| ......... (idle for 41mn) | ||
| camus has quit IRC (Read error: Connection reset by peer)
camus has joined #linux-media | [05:06] | |
| .... (idle for 16mn) | ||
| jm_h has joined #linux-media | [05:22] | |
| .... (idle for 15mn) | ||
| dikshita has joined #linux-media | [05:37] | |
| bingbu has quit IRC (Ping timeout: 480 seconds) | [05:51] | |
| bingbu has joined #linux-media | [06:00] | |
| djrscally has joined #linux-media
camus1 has joined #linux-media camus has quit IRC (Ping timeout: 480 seconds) | [06:09] | |
| ..... (idle for 21mn) | ||
| mripard has quit IRC (Ping timeout: 480 seconds)
GBenji has joined #linux-media camus has joined #linux-media camus1 has quit IRC (Read error: Connection reset by peer) | [06:38] | |
| ...... (idle for 29mn) | ||
| ao2 has joined #linux-media | [07:12] | |
| tonitch has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)
KitsuWhooa has quit IRC (Quit: Unable to handle kernel NULL pointer dereference at null) KitsuWhooa has joined #linux-media | [07:24] | |
| javierm has quit IRC (Quit: leaving)
javierm has joined #linux-media javierm has quit IRC () svarbanov has joined #linux-media javierm has joined #linux-media | [07:31] | |
| jmondi | hverkuil_: ping | [07:44] |
| hverkuil_ | jmondi: pong
tomba: finished my review of the v9 series | [07:49] |
| jmondi | hverkuil_: Hi Hans
a very quick question, as I got this contested during a review https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/vidioc-subdev-g-fmt.html?highlight=subdev_s_fmt#c.V4L.VIDIOC_SUBDEV_S_FMT I read the -EBUSY as 'it's forbidden to change format while the sensor is streaming' | [07:51] |
| tomba | hverkuil_: thanks! lots of good comments. | [07:53] |
| jmondi | to me it has always been like that: it's an awful idea to change format while streaming, but I've been told that the specs only say "it could" not "it must" | [07:53] |
| *** | camus1 has joined #linux-media
camus has quit IRC (Ping timeout: 480 seconds) | [07:55] |
| hverkuil_ | jmondi: sorry, I'm not sure what the question is. | [07:57] |
| jmondi | hverkuil_: there's a diver in review that allows to change format while streaming
I pointed the author to the specs I got told "the specs says the driver could return -EBUSY, not that it should" do you concur changing format while streaming is forbidden, it' a very bad idea, EBUSY should be returned (sorry to ask, but I get every single comment I made contested in that review and I'm looking for support to make sure it's not me getting specs wrong) | [07:58] |
| hverkuil_ | It is allowed to change the format on the fly without returning -EBUSY, but *only* if the driver can do that safely. | [08:02] |
| jmondi | the current implementation stops the streaming | [08:02] |
| tomba | doesn't that skip the pipeline validation which happens when the streaming is started? | [08:02] |
| jmondi | tomba: and also it could be done one the subdev node whitout informing the receiver
to me it's an awful idea in general | [08:02] |
| hverkuil_ | An example of that is S_FMT where only the colorspace is changed. It could also be possible (no drivers allow this at the moment) if the new format has a sizeimage that is less than the currently allocated buffers and there is some mechanism to tell the actual resolution by userspace (nothing in the current API allows this, for the record). | [08:03] |
| jmondi | s/one the subdev/on the subdev/
hverkuil_: thanks | [08:03] |
| hverkuil_ | Note that what I said applies to VIDIOC_S_FMT, I don't think anyone ever thought about VIDIOC_SUBDEV_S_FMT w.r.t. this. | [08:04] |
| jmondi | it's for a subdev, so it SUBDEV_S_FMT | [08:05] |
| hverkuil_ | It is a very bad idea in general, and you need really good reasons for doing this. | [08:08] |
| jmondi | hverkuil_: thanks, I'll report that | [08:10] |
| *** | tonitch has joined #linux-media | [08:22] |
| pinchartl | hverkuil_: thanks a lot for the review of the series
jmondi: agreed, it's awful in general for sensors. we would need to atomically apply a configuration across the whole pipeline to make this safe. it may be possible, but only with API extensions and lots of work on the kernel side, so for now I think all sensor drivers should disallow changing format during streaming | [08:24] |
| *** | mripard has joined #linux-media | [08:27] |
| jmondi | pinchartl: I agree, the driver author also pointed out 'other' drivers allow that... but I haven't found any | [08:29] |
| pinchartl | we have lots of bugs in lots of drivers | [08:31] |
| jmondi | that's fine, as long as their presence is not used as an argument to introduce new bugs :) | [08:33] |
| mripard | pinchartl: I believe it's called unemployment insurance | [08:34] |
| pinchartl | I think that with a good set of helpers we could likely drop 50% of the code in drivers/media/i2c/
there's too much boilerplate and too many bugs cargo cult hurts | [08:34] |
| jmondi | mripard: so we just need to introduce new bugs while fixing the existing one to keep the wheel spinning ? | [08:36] |
| mripard | jmondi: exactly :) | [08:37] |
| *** | hverkuil has joined #linux-media
hverkuil_ has quit IRC (Quit: Page closed) | [08:44] |
| pinchartl | hverkuil: welcome back :-) | [08:51] |
| Eugen_H | Hi everyone
I see you are discussing about streaming... I hit a strange issue recently : vb2_is_streaming on the queue returning true before my actual top driver's streamon was called... is this fine ? or it's something bad ? so far my driver always assumed that if vb2_is_streaming(queue) returns true, streamon was previously called | [08:52] |
| pinchartl | do you mean before .vidioc_streamon() gets called, or before the .start_streaming() queue operation gets called ? | [08:56] |
| Eugen_H | before my vidioc_streamon() is called | [08:57] |
| pinchartl | I wouldn't expect that, it sounds weird | [08:59] |
| Eugen_H | my driver is receiving buffers , and so far it was checking : if the queue is streaming, then just add the buffers to the DMA engine queue. However, when I tested using libcamera, it looks like vidioc_streamon is called later, after the buffers are being queued
in consequence, my driver adds the buffers to a DMA queue that is not initialized (this happens in the streamon() call) to avoid problems, I just save the streaming state (on or off) in a local variable and check it when I receive buffers. if it's not streaming, just put them pending for when streaming starts later on my actual concern is whether I should do it like this, or maybe there is another problem in some other place | [08:59] |
| pinchartl | .buf_queue() can be called before .start_streaming(), but I wouldn't expect it to be called before .vidioc_streamon(). I'd recommend investigating why | [09:02] |
| Eugen_H | in other words, vb2.ops.buf_queue is called before vidioc_streamon, and moreover, in vb2.ops.buf_queue, vb2_is_streaming on the queue returns true
pinchartl: okay thanks, I will try to see maybe there is a locking problem somewhere | [09:03] |
| pinchartl | vb2_is_streaming() returns q->streaming
which is set to 1 in vb2_core_streamon() called from vb2_streamon(), itself called from vb2_ioctl_streamon() do you call vb2_streamon() or vb2_ioctl_streamon() manually before .vidioc_streamon() ? | [09:06] |
| Eugen_H | no, that should not happen
hmm, what is the difference between vidioc_streamon and vb2_ops.start_streaming it looks like my code hooks into vb2_ops.start_streaming it is possible that vb2_ops.start_streaming is called after vb2_ops.buf_queue ? | [09:09] |
| *** | camus has joined #linux-media | [09:14] |
| svarbanov | mchehab, hverkuil, on what tree I have to base my pull requests - media_tree.git or media_stage.git ? | [09:16] |
| *** | camus1 has quit IRC (Ping timeout: 480 seconds) | [09:16] |
| pinchartl | Eugen_H: correct. start_streaming will likely be called after an initial set of buffers have been queued to the driver
that's controlled by the min_buffers_needed field of vb2_queue I'd recommend initializing your DMA list earlier and not checking vb2_is_streaming() in .buf_queue() | [09:17] |
| Eugen_H | okay, that explains a lot, thank you very much ! | [09:18] |
| pinchartl | the framework guarantees if .buf_queue() gets called, .start_streaming() will be called very soon
s/guarantees/guarantees that/ | [09:18] |
| Eugen_H | in buf_queue , I have to restart my DMA engine if it's not started already
because my DMA engine restarts itself after each frame is done. if there are no more frames, DMA engine stops However, streaming may still be on (never stopped actually ). so when more buffers are queued, I have to restart my DMA engine | [09:19] |
| pinchartl | then you need to keep an internal streaming state | [09:19] |
| Eugen_H | exactly my conclusion !
so I am doing just that. thanks ! | [09:20] |
| pinchartl | you're welcome :-) | [09:20] |
| Eugen_H | I wondered if it's actually OK to keep an internal streaming state
(and to see why queue is streaming before the buffers are queued) so actually we have streamon -> buf_queue -> start_streaming | [09:20] |
| pinchartl | yes | [09:23] |
| ...... (idle for 28mn) | ||
| *** | macc24_ has joined #linux-media
hverkuil1 has joined #linux-media macc24 has quit IRC (Ping timeout: 480 seconds) | [09:51] |
| hverkuil1 has quit IRC (Quit: Leaving.) | [10:08] | |
| hverkuil | svarbanov: either works. I've started to use media_stage since that prevents problems if my PR would depend on a patch that is already merged on media_stage but not on media_tree. | [10:16] |
| pinchartl | hverkuil: if everything goes through media_stage, we need to advertise it as the base tree
pinchartl is still not convinced by the process, but it's a different issue | [10:19] |
| hverkuil | For driver developers media_tree is the best choice, but as a maintainer making PRs media_stage is the cleanest option. Esp. when merging all these random fixes it can easily happen that a similar patch from someone else was already merged in media_stage, but not yet in media_tree.
ezequielg: what is the status for the vp9 patches? I think there are still a few patches in the series that are waiting for your review? | [10:21] |
| pinchartl | I've run into such a case recently, I've sent a pull request and one patch had been picked up manually already | [10:22] |
| .... (idle for 17mn) | ||
| svarbanov | hverkuil, I've the same problems. thanks! | [10:39] |
| Eugen_H | can I open the question of v4l2-utils release? 1.20.0 is pretty old and lacks certain updates... Would be nice (at least for me) to have 1.21.0 tagged to update the root file system (buildroot) | [10:46] |
| pinchartl | would be nice to include meson support in 1.21.0 ;-) | [10:49] |
| andrzej_p | hverkuil: Thanks for asking ezequielg. I was going to ask you what were the prospects of the vp9 series given it's been soaking on the ML for two weeks. | [10:56] |
| hverkuil | andrzej_p: ezequielg: IF ezequielg can acked it this week, then I can make a PR (assuming I don't find anything) hopefully just in time for 5.16. Otherwise it will slip to 5.17. | [10:59] |
| pinchartl: re meson: I am still not convinced. What we have works fine, and I am a bit scared to switch over. If it was a new project, then I'd be more than fine with it. Or if we had major problems with the autotools, but that isn't the case either. | [11:06] | |
| pinchartl | to this day, I still can't figure out how to cross-compile v4l-utils with autotools. I have to hack the .am files to remove some applications that won't compile correctly, I haven't found a way to disable them through the configure script
cross-compilation with autotools is painful I think meson is a net improvement but I can equally let v4l-utils bitrot and not care about it :-) | [11:11] |
| hverkuil | Ah, cross-compilation, I have to admit that I never do that for v4l-utils, so that's something I won't notice. | [11:13] |
| pinchartl | lucky you :-) | [11:14] |
| ezequielg | hverkuil: re: vp9 I will reply on the ML. Our last agreement was that it needed a uAPI closer review by dwlsalmeida and ndufresne. | [11:15] |
| pinchartl | the only drawback I see with meson is that it's a change, so it takes some energy, but apart from that, I really think we'll be better off with it | [11:15] |
| hverkuil | pinchartl: if you can convince Mauro, then I won't block it. Although I would be very much opposed to supporting both, so either we use autotools or meson, but not keep both around. | [11:17] |
| pinchartl | I agree with that, supporting both would be painful
I'd like to get feedback from Gregor. he seemed supportive of meson overall I think, but we need an official answer, and a list of the issues that would need to be solved before it can be merged | [11:17] |
| hverkuil | If mchehab would agree to the switch, and Gregor is also happy, then I'll take another look to check that all the bits 'n pieces that I care about are also working with meson. | [11:20] |
| ..... (idle for 20mn) | ||
| tomba | +1 for meson. my local v4l-utils branch has the meson patches, as I just couldn't get it working with autotools. | [11:40] |
| ...... (idle for 25mn) | ||
| Eugen_H | one small thing related to (mainly) logic/best practice: the top v4l2 driver (video device) should propagate the set_fmt to the underlying subdevice ? or assume the subdevice will output the expected format already ? if there is no check, the subdev might send another format that might overflow the top video driver's buffer | [12:05] |
| *** | BrianG61UK has quit IRC (Remote host closed the connection)
BrianG61UK has joined #linux-media | [12:10] |
| ndufresne | Eugen_H: imx6 drivers have done some propagation in the past, but the negotiation capacity of the kernel is not so great, the way this was designed, negotiation and configuration is entirely meant to be done by userspace | [12:19] |
| ............ (idle for 56mn) | ||
| *** | eelstrebor has joined #linux-media | [13:15] |
| ........... (idle for 51mn) | ||
| pinchartl | Eugen_H: the video node shouldn't propagate the format to the connected subdev, it should assume that userspace configures the subdev correctly, and verify at streamon time that this is the case
(essentially calling get_fmt on the subdev then, and comparing at least width, height and media bus code with pixel format) | [14:06] |
| ............................... (idle for 2h30mn) | ||
| *** | gouchi has joined #linux-media | [16:36] |
| GBenji has left | [16:44] | |
| ........ (idle for 39mn) | ||
| ao2 has quit IRC (Remote host closed the connection) | [17:23] | |
| ............ (idle for 56mn) | ||
| macc24_ is now known as macc24 | [18:19] | |
| ....................... (idle for 1h52mn) | ||
| ao2 has joined #linux-media
gouchi has quit IRC (Remote host closed the connection) | [20:11] | |
| gouchi has joined #linux-media | [20:17] | |
| gouchi has quit IRC (Remote host closed the connection) | [20:26] | |
| jarthur has joined #linux-media
ao2 has quit IRC (Quit: Leaving) | [20:33] | |
| ........... (idle for 50mn) | ||
| jm_h has quit IRC (Remote host closed the connection) | [21:24] | |
| ....... (idle for 30mn) | ||
| svarbanov has quit IRC (Ping timeout: 480 seconds) | [21:54] | |
| .... (idle for 17mn) | ||
| djrscally has quit IRC (Quit: Konversation terminated!) | [22:11] | |
| djrscally has joined #linux-media | [22:20] | |
| ........ (idle for 38mn) | ||
| djrscally has quit IRC (Ping timeout: 480 seconds) | [22:58] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |