| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| tfiga | mripard: hey, do you know whether it could be possible to fix the linux-sunxi mailing list so it stops bouncing? | [04:14] |
| .................... (idle for 1h39mn) | ||
| wens | AFAIK it bounces if you aren't subscribed | [05:53] |
| ......... (idle for 41mn) | ||
| tfiga | wens: looks like so, but it's being added on CC to threads with relatively wide distributions, with people who aren't interested in subscribing | [06:34] |
| *** | herrnst has quit IRC (Ping timeout: 252 seconds) | [06:39] |
| ....................... (idle for 1h52mn) | ||
| mripard | tfiga: I'm not sure who's the admin on that list | [08:31] |
| tfiga | mripard: okay
I wonder if there is any point in CCing it, if it drops replies well, there is some for the patches alone | [08:32] |
| mripard: contacted the owner via a form in the web interface | [08:39] | |
| mripard | great, sorry for that | [08:45] |
| ........... (idle for 51mn) | ||
| wens | IIRC it's not the only one. linux-stm also does this lol | [09:36] |
| ......... (idle for 41mn) | ||
| bbrezillon | hverkuil, pinchartl, tfiga: the vb2 migration to vb2_ext_buffer is really painful, not sure passing v4l2_buffer and v4l2_ext_buffer user-space strucs to core funcs is a good thing
that forces us to duplicate most of the logic to handle both the ext and non-ext version of the struct | [10:17] |
| hverkuil | Huh? vb2 should only have to deal with v4l2_ext_buffer.
Almost all drivers that use vb2 use the vb2 helper functions as well. | [10:18] |
| bbrezillon | hverkuil: you need to convert all drivers first
before you can get rid of the old non-ext path | [10:18] |
| hverkuil | struct v4l2_buffer is rarely used by drivers that also use vb2.
Those few that do should be converted. vb2 should be entirely based on v4l2_ext_buffer. | [10:21] |
| bbrezillon | so you want a "convert everything in a single patch" approach? | [10:22] |
| hverkuil | Yes. Not for the initial RFC series, but it is likely that for the final patch it will have to be one big bang.
At least for all the vb2-based drivers. I'm not sure we should even try to convert non-vb2 drivers. You certainly shouldn't spend time on that right now. | [10:23] |
| bbrezillon | oh, I'm definitely not trying to do that
but even just converting VB2 is painful | [10:24] |
| hverkuil | There is a reason this work hasn't been done yet :-) | [10:25] |
| bbrezillon | also, vb2_buf_ops hooks take void pointers | [10:25] |
| hverkuil | But why is it painful? Just because it is a lot of work? | [10:26] |
| bbrezillon | so it's hard to catch when you pass a wrong type
hverkuil: yes, because you have to change a lot of things, and it can't be done in small steps and it's error prone too | [10:26] |
| hverkuil | ??? vb2_buf_ops has nothing to do with v4l2_buffer.
It's passing struct vb2_v4l2_buffer. (for v4l2 drivers) | [10:27] |
| jmondi | sorry, bbl
ups, sorry, wrong window :) | [10:29] |
| hverkuil | v4l2_buffer is only used in videobuf2-v4l2.c, so that's the only place where v4l2_buffer will be replaced by v4l2_ext_buffer. | [10:29] |
| bbrezillon | hverkuil: hm, right, I guess I misread the code | [10:29] |
| hverkuil | So instead of a vb2_querybuf function you'll make a vb2_ext_querybuf. | [10:30] |
| bbrezillon | that's what I did
expect I was trying to keep vb2_querybuf in parallel and ->fill_user_buffer() is really passed a v4l2_buffer as a void pointer same for verify_planes_array | [10:31] |
| hverkuil | ah, yes.
Yeah, a big-bang conversion is best. | [10:32] |
| bbrezillon | and copy_timestamp as well | [10:33] |
| hverkuil | Just replace v4l2_buffer by v4l2_ext_buffer throughout videobuf2-v4l2.c. | [10:34] |
| bbrezillon | should we use an intermediate struct to avoid this kind of problems next time we rework the userspace API? | [10:34] |
| bingbu | tfiga: do you have time to comment for the patch of 'imgu buffer refactoring' again? I am working on the patch V2 and want to get all the comments addressed before I send that. | [10:34] |
| bbrezillon | hverkuil: also, there's one thing I'd like to check before going further | [10:35] |
| hverkuil | bbrezillon: no, bad idea. You'll be stuck with that forever and it isn't as if we do something like this every year :-) | [10:35] |
| bbrezillon | hverkuil: right now I re-use the VIDEO_CAP and VIDEO_OUT types for the new ext_pix_format
that means that userspace libs/apps have to know that, when using the EXT_FMT ioctls, VIDEO_CAP_MPLANE and VIDEO_OUT_MPLANE are invalid and should be replaced by VIDEO_CAP and VIDEO_OUT types should I instead add a new type to the v4l2_buf_type enum? | [10:37] |
| hverkuil | bbrezillon: leave it as is for now. Once we see the code we can discuss this.
I think we will want a capability indicating support for the new ioctls (CAP_V4L3? :-) ) and just always use VIDEO_CAP/OUT types when using the new ioctls. | [10:42] |
| bbrezillon | yep, we definitely want a flag for EXT_FMT and EXT_BUF support
and we're also running out of _CAP_ flags :) so maybe an QUERY_EXT_CAPS ioctl to address that ;) | [10:43] |
| hverkuil | just take one of the reserved fields. There are more than enough. | [10:44] |
| bbrezillon | where?
v4l2_capability ? | [10:44] |
| hverkuil | y | [10:45] |
| ....... (idle for 34mn) | ||
| bbrezillon | hverkuil: you removed the request_fd field from v4l2_ext_buffer
does that mean ->uses_requests is deprecated? | [11:19] |
| hverkuil | bbrezillon: no, that means that my original patch predates the request API :-)
That field needs to be kept. | [11:22] |
| bbrezillon | ok | [11:23] |
| ......... (idle for 43mn) | ||
| *** | snawrocki has quit IRC (Ping timeout: 258 seconds) | [12:06] |
| .... (idle for 16mn) | ||
| bbrezillon | does anyone know how we should close an FD returned by dma_buf_fd() in kernel space? Use case is: a valid dmabuf FD is returned by a function, but an error happens after that in the caller
right now I have a dma_buf_get()+dma_buf_put()+dma_buf_put() sequence, but 1/ I'm not sure what happens if someone else still holds a reference to the dmabuf (the FD probably stays valid until everyone has released the underlying file obj) 2/ I'm not sure it's safe to put the reference if a valid FD is attached to struct file | [12:22] |
| ...... (idle for 27mn) | ||
| hverkuil: should I provide a wrapper doing the !ext -> ext conversion for vb2_ioctl_prepare_buf() & co?
looks like a lot of drivers use those vb2 helpers | [12:51] | |
| hverkuil | in meeting, will get back to you soon. | [12:52] |
| bbrezillon | oh, and the same goes for vb2_querybuf() which is directly called by a few drivers | [12:58] |
| hverkuil | bbrezillon: I wouldn't make a wrapper at all. Just rename e.g. vb2_(ioctl_)querybuf to vb2_(ioctl_)ext_querybuf.
Pick one or two drivers that you convert (disable all others in the kernel config). We're doing an RFC patch series only at this stage, so there is no need to convert all drivers using these vb2 function. most drivers use the vb2_ioctl helpers, but some drivers predate those helpers and some actually need to do something driver specific. | [13:06] |
| bbrezillon | hverkuil: maybe I can just send the RFC with the new ioctls and structs and not convert any drivers (including vb2)
I already have the ext -> !ext and !ext -> ext wrappers at the v4l2-ioctl.c level | [13:22] |
| hverkuil | bbrezillon: It's OK to send what you have now, but keep working on vb2: we will need that no matter what. | [13:24] |
| bbrezillon | sure
the idea is to avoid refactoring everything before we agree on what we want the new ioctls to look like | [13:25] |
| ................................................ (idle for 3h57mn) | ||
| *** | benjiG has left | [17:24] |
| .................. (idle for 1h28mn) | ||
| bparrot | is there a "library" of raw video samples i could use as sources to do de-interlacing validation?
i am looking for YUYV or NV12 source files in all variation of interlace mode (interlace T/B, alternate T/B and sequential TB/BT) | [18:52] |
| ...... (idle for 27mn) | ||
| bbrezillon | ndufresne: I have at least one example where modifiers can differ on each plane => https://elixir.bootlin.com/linux/v5.1-rc1/source/include/uapi/drm/drm_fourcc.h#L525 | [19:21] |
| CarlFK | bparrot: this may help https://github.com/timvideos/test-patterns | [19:21] |
| bbrezillon | at least in theory | [19:21] |
| CarlFK | bparrot: and if you need more, let me know, I may be able to get it added quickly
"create a test system" is a task I am 1/2 doing right now | [19:21] |
| bparrot | CarlFK, thanks I'll take a look | [19:26] |
| ...... (idle for 26mn) | ||
| bbrezillon | ndufresne: OTH, the DRM doc says all modifiers should match https://elixir.bootlin.com/linux/v5.1-rc1/source/include/uapi/drm/drm_mode.h#L504
so I guess we can go move the modifier field to v4l2_ext_buffer | [19:52] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |