| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| jmondi | hverkuil: ping | [09:22] |
| hverkuil | jmondi: pong | [09:23] |
| jmondi | hverkuil: good morning | [09:23] |
| hverkuil | Good morning to you as well! | [09:23] |
| jmondi | hverkuil: I was wondering if " [PATCH 4/4] media: i2c: imx219: Selection compliance fixes" fell into the cracks | [09:23] |
| hverkuil | sailus: ^^^^ (Sakari deals with sensor patches :-) ) | [09:24] |
| jmondi | hverkuil: ack... the patch was from you, that's why I pinged you :D
sailus: same question then, do you think you can collect the patch ? | [09:24] |
| sailus | jmondi: Let me see. A moment.
jmondi: Yes. It was unread in my inbox. It looked like it was related to libcamera somehow. ;) I'll take it. | [09:29] |
| jmondi | sailus: thanks! it will align with ov5647 I have on the list
sailus: libcamera side will need to be updated accordingly, but I'll take care of it | [09:32] |
| sailus | jmondi: Thanks! | [09:32] |
| jmondi | sailus: speaking ov ov56747....
5647 sailus: do you think it is good enough to go, leaving the last patch out ? (the one that removes the 8-bit mode) | [09:32] |
| sailus | I was hoping for someone else to comment on that patch.
I presume this has been used elsewhere, too. I guess we could merge the last one as well, and see whether someone will complain. | [09:34] |
| jmondi | sailus: I agree! history will be in git anyway | [09:35] |
| sailus | Just the last patch of the other set was not merged yet, right? | [09:35] |
| jmondi | was the rest of the set merged ? | [09:35] |
| sailus | I don't know. You only asked about the last patch. :-)
Hmm. There's also no ack from the DT folks on the DT binding patch. It's just a rename, but still. | [09:36] |
| jmondi | I was suggesting to leave the last patch out if it was controversial :) | [09:36] |
| sailus | No, the other set, with the imx219 patch. | [09:36] |
| jmondi | sailus: no, none of the other patches from the set that contains the imx219 patch I pinged Hans on is merged | [09:39] |
| sailus | jmondi: Ack. | [09:40] |
| jmondi | I think more dicussion is required, but the imx219 one fixes a bug, so I think it can be collected in isolation | [09:40] |
| sailus | More discussion on what?
The last ov5647 patch? | [09:40] |
| jmondi | nope :) the other three patches in the set that contains the imx219 patch I pinged Hans on
[PATCH 1/4] media: docs: Describe pixel array properties (the series doesn't have a subject because of a fault between the chair and the keyboard) [PATCH 1/4] media: docs: Describe pixel array properties ups https://patchwork.kernel.org/project/linux-media/list/?series=329273 | [09:41] |
| sailus | Ah. Yes. Indeed. | [09:44] |
| ..... (idle for 23mn) | ||
| dafna2 | hi, the documentation of "VIDIOC_SUBDEV_ENUM_FRAME_SIZE" says "Available frame sizes may depend on the current ‘try’ formats at other pads of the sub-device, as well as on the current active links and the current values of V4L2 controls."
does that means that if the 'which' filed of v4l2_subdev_frame_size_enum is "V4L2_SUBDEV_FORMAT_TRY" then the sizes enumerated on the src pad depends on the 'try' format of the sink pad? | [10:07] |
| sailus | dafna2: That's an interesting question. | [10:10] |
| dafna2 | I see a similar scentence in the doc of VIDIOC_SUBDEV_ENUM_MBUS_CODE "Available media bus formats may depend on the current ‘try’ formats at other pads of the sub-device," | [10:10] |
| sailus | I'd say "yes".
But there are no try controls in that context, so it'll have to be active control values. See e1c47e732cbb4 . | [10:10] |
| dafna2 | the rkisp1 does not look at the try format for the mbus codes enumeration | [10:11] |
| sailus | The which fields were added but I wonder if the documentation was touched at the same time. | [10:11] |
| dafna2 | so if the which field is 'active' then all mbus codes should be enumrated and when it is 'try' then only the ones that can be prodeuced by that 'try' on the other pads should be enumerated? | [10:12] |
| sailus | dafna2: I'd think so.
Although if there are selections that affect it, too, then the selections are what matter in the end (but they are in turn affected by the format on the sink pads). | [10:13] |
| dafna2 | ok, but also only the selections associated with the 'try' | [10:16] |
| sailus | dafna2: Yes.
hverkuil: Which e-mail address do you prefer for the imx219 patch? It's different in From: and Sob:. | [10:23] |
| hverkuil | hverkuil-cisco@xs4all.nl
I always forget to change my email to that account when I manually post a patch, and if I merge my own patches for a PR, then I have a script that automatically fixes it. | [10:27] |
| sailus | hverkuil: Thanks. I'll change it for the imx219 patch before sending a pull request. | [10:33] |
| ezequielg | hverkuil: do you think cedrus vp8 could be merged on this release? | [10:37] |
| hverkuil | ezequielg: "[PATCH v3] media: cedrus: Add support for VP8 decoding"? | [10:50] |
| ezequielg | yes.
I've reviewed-by-it, and jernej confirms he did plenty testing on it. btw, I'm trying to add vp8 test vectors to fluster conformance test, which would be a nice complement of the vp8 destaging. | [10:52] |
| hverkuil | ezequielg: I will try to, but no guarantees. | [10:59] |
| ezequielg | no problem.
we are quite late, after all. I might respin MPEG-2 cleanup, now that Kwiboo tested it. But of course, no hurries there. | [10:59] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |