| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | arnd has quit IRC (Ping timeout: 246 seconds)
broonie has quit IRC (Read error: Connection reset by peer) ldts has quit IRC (Read error: Connection reset by peer) lvrp16 has quit IRC (Ping timeout: 240 seconds) | [01:49] |
| ........................................................... (idle for 4h52mn) | ||
| svarbanov has quit IRC (Ping timeout: 258 seconds) | [06:42] | |
| ......... (idle for 40mn) | ||
| serg-z has quit IRC (Quit: ZNC 1.7.5 - https://znc.in) | [07:22] | |
| ................ (idle for 1h16mn) | ||
| dikshita1 has quit IRC (Excess Flood) | [08:38] | |
| ................... (idle for 1h31mn) | ||
| hverkuil | gnurou: ping | [10:09] |
| gnurou | hverkuil: pongidy | [10:11] |
| hverkuil | gnurou: I'm looking at "[PATCH v4 0/2] media: mtk-vcodec: fix builds when remoteproc is disabled"
This is for 5.10, right? But if so, then I need a Fixes: tag as well. | [10:11] |
| gnurou | correct - should I send a v5 of can you just add the line when picking it up?
s/of/or | [10:13] |
| hverkuil | If you just reply to both patches with the correct Fixes: line, then I'll pick that up. | [10:13] |
| gnurou | ack, let me fetch the proper hashes and come back to this | [10:15] |
| hverkuil | great.
dafna2: ping | [10:15] |
| gnurou | hverkuil: there you go - thanks for the ping! | [10:18] |
| hverkuil | thanks! | [10:19] |
| ............... (idle for 1h13mn) | ||
| ezequielg: ping | [11:32] | |
| ......... (idle for 43mn) | ||
| ezequielg: what is the status of https://patchwork.linuxtv.org/project/linux-media/patch/20201007103544.22807-6-ezequiel@collabora.com/ ?
Benjamin Bara reported that it still doesn't completely fix his problem (as I understand it). I'm adding patches 1-4 to my PR, those look good. | [12:15] | |
| ....... (idle for 30mn) | ||
| dafna2 | hverkuil: pong | [12:47] |
| hverkuil | dafna2: unping :-) | [12:49] |
| ......... (idle for 40mn) | ||
| ezequielg | hverkuil: Thanks for picking up patche 1-4. I failed to reply to patch 5/6, as I was sure it needed clarification.
I personally believe 5/6 should be picked, which has pH5 R-b. The fix is legitimate and correct. It seems it's not enough so we might have some more conditions to chase and fix. But I'd say 5/6 is a step forward. Sorry for not being clear! :) | [13:29] |
| I'll see if I can resend/respin patches 5/6 and 6/6, along with mpeg2 uapi cleanup.
And I think it's time to get H.264 public as well. Along with VP8. | [13:39] | |
| *** | dikshita1 has left | [13:48] |
| ......... (idle for 41mn) | ||
| hverkuil | ezequielg: thank you for the feedback. I'll wait for the v3 of those two coda patches.
I've made good progress today in going through the rkisp1 and the smaller 'random' patches. | [14:29] |
| ......... (idle for 41mn) | ||
| jernej | hverkuil: can this be re-delegated to 5.10-rc fixes? https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=for-v5.11c&id=6676a37f009460de90561ef2282e60ec4126fa6e | [15:11] |
| hverkuil | jernej: a bit of a pain to do, but I think you are right that this is something for v5.10. | [15:12] |
| jernej: done | [15:20] | |
| jernej | hverkuil: great, thanks!
what about this patch? https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-5-jernej.skrabec@siol.net/ all others in this series were queued for 5.10, but I guess is too late? | [15:21] |
| hverkuil | Note: a PR with 5.10 patches will be posted some time next week.
Yeah, that's too late. I plan to go through such series next week. Today I mainly looked at the 'random patches', i.e. anything not adding new drivers or bigger pieces of functionality. | [15:21] |
| ......... (idle for 40mn) | ||
| Kmpol | hi
i saw some source of drivers related to v4l, many companies uses the same internal chips, however some companies price the device at high price and some at low price even when the driver is pretty much the same, why sould I pay high price when I can get the same result at low price? Maybe the pricing is related to the quality of the Windows driver? Is there is something i am missing that can effect the quality of the device and because of that charge higher price? | [16:02] |
| affect;) | [16:20] | |
| .............. (idle for 1h9mn) | ||
| *** | headless has left "Konversation terminated!" | [17:29] |
| ................... (idle for 1h33mn) | ||
| koike | sailus: Hi, I just saw your comment regarding MEDIA_BUS_FMT_METADATA_FIXED, this is a silly question, but I was doing a comparison with MEDIA_BUS_FMT_FIXED and I just realized I don't understand what it mean. Does it mean that the bus format can't be changed and we don't care which type it is?
sailus: (thanksk for reviewing btw) | [19:02] |
| ........... (idle for 51mn) | ||
| hverkuil | MEDIA_BUS_FMT_FIXED is primarily used for drivers where the media bus format wasn't known, or where nobody took the trouble to find out what the media bus format was. It's mainly used by older drivers.
In most cases it can probably be replaced by a real media bus code. But it's not really worth the effort. koike: sailus: ^^^ | [19:54] |
| *** | GrayShade has quit IRC (Remote host closed the connection) | [20:03] |
| sailus | koike: hverkuil: The FIXED mbus code has also been used on links inside devices, where you can't configure it anyway, and often the "bus" is actually some shared device internal buffer.
I'd think most of the time dimensions don't matter in that case (such as statistics), but are there cases (sensor embedded data) where dimensions do matter. Although... if it's sensor embedded data, then its inter-device link, and you'll have to have a specific mbus code there. I'm still saying that if we specify dimensions are zero now, we can't change that later. | [20:10] |
| ........... (idle for 52mn) | ||
| *** | fritzfritz__ has quit IRC (Ping timeout: 260 seconds)
dagmcr has quit IRC (Ping timeout: 260 seconds) | [21:04] |
| ...................... (idle for 1h47mn) | ||
| koike | hverkuil: sailus: thanks. My question is: what would be the difference between MEDIA_BUS_FMT_FIXED and MEDIA_BUS_FMT_METADATA_FIXED ? Should we expose the the information if it is metadata or not in the mbus code? I wonder if this is useful for userspace or not. And to the pourpose of the patch, we could have a MEDIA_BUS_FMT_METADATA_INTERNAL to indicate width/height doesn't make sense
or just MEDIA_BUS_FMT_INTERNAL for this. My point is that I don't see value of having MEDIA_BUS_FMT_METADATA_FIXED to be the same as MEDIA_BUS_FMT_FIXED, but for metadata. (but I can be wrong) | [22:52] |
| sailus | I don't think the FIXED mbus code tells much to the user space in either case.
There are links that are metadata only, or image data only, but in some cases the same link can carry either, or both (well, we need API extensions to this anyway). | [22:55] |
| ..... (idle for 23mn) | ||
| koike | sailus: right. In a practical sense, our current issue is that in the link, width/height doesn't make sense, and v4l2-compliance complains if this value is 0, so we were trying to think a way to indicate userspace that these values doesn't make sense and can be ignored
so now I wonder what would be the best way to do this then sailus: if we can just add a mbus code, or if we need some more complete extention (as you mentioned) for this too, and how it would look like | [23:18] |
| sailus | Ah, I remember now this discussion. :-)
I wonder if this check could be just be removed. | [23:22] |
| koike | hverkuil: ^ what do you think? | [23:23] |
| sailus | For FIXED mbus code, that is.
That said, I don't really mind adding FIXED_METADATA code either. | [23:23] |
| koike | right, tbh I prefer avoid adding FIXED_METADATA, seems another point of confusion unconsistent and redundant apis (unless we define it well when one of the other should be used) | [23:25] |
| sailus | I suppose v4l2-compliance reports pretty much all ISP drivers that have statistics or parameter interfaces on video nodes. | [23:30] |
| The documentation (Documentation/userspace-api/media/v4l/subdev-formats.rst) doesn't seem to require width and height would have to be non-zero.
But it could be nice to document this is possibly the case for metadata formats. | [23:40] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |