mchehab: Bom dia!
sailus_: moikka!
How do you do?
fine. and you?
Fine, too. thanks!
Tiffany submitted a vb2 cache sync fix, which apparently should go to stable as well.
In some cases vb2 fails to perform the cache sync correctly.
Do you think we could have this in v4.3 through the fixes branch?
There's a minor conflict with patches in the master branch, but this is automatically handled by git.
Subject: [PATCH v2] media: vb2: Fix vb2_dc_prepare do not correct sync data to device ?
Correct.
I suspect that his patch doesn't even compile ;)
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -1,4 +1,3 @@
-/*
I've split it into two, since the dma-contig and dma-sg changes need to go to different stable versions.
Yes, that, too.
But the rest is good.
I'll resubmit and send a pull request those.
i'm a little reticent on sending core patches during -rc, as those are risky...
and deserve more testing
So to master instead, and then to v4.3 through stable?
that is, IMHO, the best...
I'm ok with that, but v4.3 will be broken as well.
except, if the patch is critical and has been widely tested
Albeit this does not seem to have been a problem, dma-contig has been broken since v3.8, i.e. since the cache sync support was added.
I assume that you can't test it this week, as you're at ELCE...
and other developers that could also test it are there too
Well, proper cache synchronisation is difficult to test to begin with.
well, it it has been broken since 3.8, this is not critical
s/it it/if it/
It requires a DMA mapping implementation will return different number of entries from dma_map_sg() than the scatterlist originally had.
yes, I know that this is the kind of thing that it is not easy to test
that's why I think it is safer to merge at master and let people to test it better
Fair enough. Let's target v4.4 then.
ok
mchehab, hi, have you seen this? https://patchwork.linuxtv.org/patch/31561/
yes, I saw it
i should be merging more patches by the end of this week
OK, I just wanted to be sure :) Thanks
on a second tought... wouldn't be better to fix it at v4l2-core?
maybe not... as the default frame rate are driver specific
s/are/is
that's what I thought thought, the docs say a zero frameinterval means "reset" and I interpreted that as setting the default framerate
ok
the patch looks ok on my eyes
hi
i am trying to capture a video/image with my webcam. i tried streamer -q -c /dev/video0 -f rgb24 -r 3 -t 00:30:00 -o ~/outfile.avi
which gave me an avi
but stuff was pretty dark
i found: ffmpeg -f video4linux2 -i /dev/video0 -vframes 2 test%3d.jpeg
which gave me a much better looking image
i wondered whats the reason for this
i have to admit many of the switches i dont know their meaning
man streamer doesnt seem to exist