#v4l 2018-04-13,Fri

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***sarnex has quit IRC (Ping timeout: 256 seconds) [03:47]
............................................ (idle for 3h39mn)
prabhakarlad has quit IRC (Read error: Connection reset by peer) [07:26]
.......................... (idle for 2h9mn)
pinchartl has quit IRC (Read error: Connection reset by peer) [09:35]
................. (idle for 1h24mn)
Whoopiendufresne: can we work on the the colorimetry issue? but I don't know where to start. [10:59]
.......... (idle for 48mn)
sailusmripard: Ping? [11:47]
mripardsailus: pong [11:47]
sailusHow do you do? [11:47]
mripardfine, and you? [11:47]
sailusFine, too, thanks.
I briefly discussed the CSI-2 TX patches with pinchartl.
There are some unknowns related to them, indeed, for instance pipeline handling. There are bits missing from the whole picture.
I'm a bit hesitant to ack a driver in that state.
[11:47]
mripardwhich bits would need to be implemented? [11:52]
sailusWell, hardware. :-) [11:52]
mripardor what would you need to make you more comfortable
this is going to be in SoCs, so you'll have them eventually
[11:53]
sailusHow do you expect the pipeline to be handled? I suppose that if there is an MC pipeline, it will end to the PHY.
Or just the CSI-2 TX entity.
Was that the thinking?
Or would the entire pipeline be controlled from the same host?
And if that's the case, then do the DT bindings rather tell what hardware capabilities there are, and the actual configuration would be supplied by the user?
[11:55]
mripardyeah, I was thinking that it would stop either at the CSI2 TX
The common case would be that you're streaming to another device entirely, using a different OS
so that wouldn't really make much sense to model that in Linux I guess
[11:59]
sailusI agree.
There might be whatever use cases, perhaps setting the configuration through V4L2 controls could make sense.
[12:00]
mripardthe fact that the test setup I have at the moment is a single pipeline run under a single OS is definitely not the expected use case [12:02]
sailusI was thinking that, too. :-) [12:02]
It's a small driver and no-one can use it yet because the other pieces are missing. So there is no risk of committing to a particular uAPI I presume.
Or any other behaviour, e.g. regarding the virtual channels and data types.
[12:07]
Replied to the driver patch.
Oops, on v8 but there's also v9.
The MAINTAINERS entry is there, good. :-)
No, this is a different driver.
But the MAINTAINERS entry covers the other one.
[12:14]
...... (idle for 28mn)
mripardsailus: yeah, the MAINTAINERS entry in the CSI2-RX driver covers both
the v9 is for Rx, v8 for TX
I'll address your comments, thanks!
[12:46]
***hverkuil_ has quit IRC (Ping timeout: 245 seconds) [12:52]
........ (idle for 38mn)
ndufresneWhoopie, have you resync with upstream master/1.14 ? there is some fixes I landed, I'd love to know what's next [13:30]
................... (idle for 1h32mn)
***prabhakarlad has left [15:02]
..... (idle for 23mn)
snawrocki has quit IRC (Quit: Leaving) [15:25]
............. (idle for 1h3mn)
lucaceresoli has quit IRC (Quit: Leaving) [16:28]
.......... (idle for 49mn)
indy has quit IRC (Quit: ZNC - http://znc.sourceforge.net) [17:17]
Whoopiendufresne: I applied all v4l2object git commit, no change in behaviour, still "Device wants 2:4:7:1 colorimetry"
ndufresne: do you wanna have the whole debug output?
ndufresne: here you go :-) https://pastebin.com/G3EVFf19
[17:21]
...... (idle for 29mn)
ndufresneWhoopie, hmm, there is a renegotiation going on, first time, it didn't have colorimetry, so the driver chose
and second time, it went through try_fmt (because the device is busy, we can't do s_fmt)
hmm, and the driver does not set the colorspace on try
so gst select a default, and then it does not match
Whoopie, I think the solution would be to save the last accepted colorimetry, and if the driver return DEFAULT, pick that instead
Whoopie, which kernel version is this ?
[17:54]
Whoopiendufresne: 4.15 [17:58]
ndufresneok, so this bug is on all platforms then ... better work around it
Whoopie, uvc is tricky, if you do try_fmt while idle, you don't get the same thing is as if you do try_fmt while the driver is streaming/busy
thanks for the detail, I have a good understanding of the failure, just need to find a good way to workaround
[17:58]
Whoopievery welcome [18:00]
ndufresneI know it won't get fixed in the driver, because UVC protocol won't allow [18:00]
Whoopieif you say so ;-) [18:03]
ndufresne: strange enough, it works on Ubuntu 16.04. I'll post the logs in a sec. [18:09]
ndufresnethere was a massive change in the way we negotiate caps in 1.14, seems like a side effect
but we get a massive speed up in startup time
[18:10]
Whoopiehttps://pastebin.com/vEqvA1B1 [18:11]
................... (idle for 1h33mn)
gustavmbHi there [19:44]
***gustavmb has left [19:46]
............................................ (idle for 3h36mn)
koike has quit IRC (Quit: WeeChat 1.6) [23:22]
....... (idle for 33mn)
strfry has left "WeeChat 1.9" [23:55]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)