| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| prabhakarlad | sailus pinchartl: ping | [08:11] |
| ..... (idle for 21mn) | ||
| hverkuil | prabhakarlad: ping | [08:32] |
| prabhakarlad | hverkuil: pong | [08:32] |
| hverkuil | prabhakarlad: does the rcar-vin have a scaler? | [08:33] |
| prabhakarlad | Yes it does support scaling. | [08:34] |
| hverkuil | So it will scale from the crop rectangle to the compose rectangle?
(just checking) | [08:37] |
| sailus | prabhakarlad: Pong. | [08:42] |
| prabhakarlad | hverkuil: let me dig through it, im not completely sure.
sailus: with the current fwnode parsing if an invalid bus-type (say 9) is passed in DT v4l2_fwnode_endpoint_alloc_parse(.bus_type = V4L2_MBUS_PARALLEL) returns success with bus-type set to V4L2_MBUS_PARALLEL. is this the expected behavior ? | [08:43] |
| sailus | prabhakarlad: Does it? | [08:48] |
| prabhakarlad | Yes :) | [08:49] |
| sailus | -ENXIO should be returned.
Looking at the code, that's what it seems to do. But I haven't tested it for quite a while. :-) The problem seems to be in v4l2_fwnode_bus_type_to_mbus(). We should add an invalid MBUS type and v4l2_fwnode_bus_type_to_mbus() should return that if there's no valid bus type. Would you like to write a patch? :-) | [08:49] |
| prabhakarlad | Sure will do that :)
V4L2_MBUS_INVALID sounds good ? | [08:54] |
| sailus | Yeah. | [08:55] |
| prabhakarlad | hverkuil: Yes it does https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/rcar-vin/rcar-dma.c#n532 | [09:04] |
| hverkuil | prabhakarlad: ok, good to know. | [09:05] |
| arnd: I looked at your proposed patch, and I really don't like how the compat code now pollutes the main v4l2-ioctl.c source.
This should remain as much as possible in v4l2-compat-ioctl32.c. The 32 bit structs can be added in a v4l2-compat-ioctl32.h header so v4l2-ioctl.c can include it, and helper functions can be placed in v4l2-compat-ioctl32.c. So v4l2-ioctl.c can have the 'case's for the compat ioctls, but those should call helper functions from v4l2-compat-ioctl32.c instead of keeping it all in v4l2-ioctl.c. | [09:10] | |
| arnd | hverkuil: ok, I'll try that then | [09:15] |
| hverkuil | arnd: I so wish I could step in a time machine and go back in time to tell the V4L2 designers about future 64 bit architectures :-) | [09:17] |
| arnd | hverkuil: the one part I can't figure out how to do yet is the v4l2_format32 conversion for V4L2_BUF_TYPE_VIDEO_OVERLAY, is there a reason why this one doesn't already get copied using check_array_args() ?
(the v4l2_clip array) | [09:20] |
| hverkuil | Probably because v4l2_clip has a different size for 32 vs 64 bit architectures, so you can't just copy it as an array.
The sad thing is that the 'next' 'pointer' is just discarded and never actually used. | [09:23] |
| arnd | hverkuil: I don't think the reason is compat mode, as that would be the same for the arrays in v4l2_buffer and v4l2_ext_controls | [09:28] |
| hverkuil | arnd: ah yes. Then I think it is simply that this already worked and nobody bothered to switch it over to check_array_args(). The check_array_args() function was created much, much later than the overlay support.
I have no objection to switch over to check_array_args() for overlays. | [09:40] |
| arnd | ok, thanks for confirming, now I just need to figure out which drivers actually access the v4l2_clip array
I suppose anything that implements either vidioc_g_fmt_vid_out_overlay or vidioc_g_fmt_vid_overlay | [09:41] |
| hverkuil | Yup. I count 7 drivers.
arnd: actually 8 drivers: drivers/staging/vc04_services/bcm2835-camera uses it as well. | [09:48] |
| arnd | hverkuil: what about users of vidioc_create_bufs? I see that the compat code does the conversion for those as well, but they all end up in vb2_ioctl_create_bufs, which does not support the overlay version
is that a coincidence or by design? | [09:54] |
| hverkuil | by design: overlays do not use buffers. Capture overlays write directly into a framebuffer, output overlays can be used to mix in a framebuffer (containing an OSD) into the output video signal. | [09:56] |
| arnd | ok, good, then VIDIOC_CREATE_BUFS32 compat support can be much simpler than it is today | [09:58] |
| hverkuil | For modern drivers this is never used, it's for old hardware only. I wish we could drop it altogether, but some of this HW is still in use, I'm pretty certain of that. | [09:58] |
| ................................................ (idle for 3h56mn) | ||
| *** | kbingham has quit IRC (Ping timeout: 272 seconds) | [13:54] |
| ......................................................................................... (idle for 7h23mn) | ||
| arnd | hverkuil-: I've completed a first pass, with 9 files changed, 720 insertions(+), 1242 deletions(-)
have not tried compiling yet... | [21:17] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |