sailus: ping
mfelsch: Pong.
sailus: Do you remember the OnSemi ap1302 Intel atomisp sensor driver?
mchehab: series look like a nice compromise between what I had in mind and what you want :-)
mchehab: thanks.
mchehab: I'll review in detail and make some minor comments.
sailus: I have this ISP on my desk and a driver provided by the cam-module supplier. Now I'm try to merge both in a mainline way. Now I'm asking myself if the context switching can be supported by a standard subdev driver?
sailus: I would drop the multi-context support completely if this can't be handled yet else I would add the driver (still single context) with respect to future context support
sailus: This commit removed the support: d4870725b99a622e6d05ef62b6a648a3e28adfc3
The atomisp driver was merged, somewhat accidentally, and removed a few years afterwards.
No-one had the hardware to test it most of the time, so it's difficult to say how much of its time in the staging tree it was functional.
What do you mean by context switching btw.?
sailus: The ap1302-isp supports multiple contexts (different roi, formats, ...) which can be switched by a single context switch command, as far as I can see.
sailus: The current API does not cover this currently or did I miss something?
ezequielg: did some other additional changes. I guess it is now a lot better
sending a v2 with the aditional patches
it also addresses some issues I noticed while looking at the other media/*/Kconfig files
mchehab: since you mention it. I think we need to move mem2mem out of platform.
that doesn't seem right.
and i'd like to find a better name for MEDIA_EMBEDDED.
perhaps MEDIA_SOC or MEDIA_PLATFORM or so.
could make sense, but see the new version...
there are some new logic there, with depends on EMBEDDED
anyway, need to take small break.. bbiab
no worries.
btw, not sure if you saw, MythTV now uses V4L2 codecs :-)
https://www.mythtv.org/wiki/Release_Notes_-_31_Video_decoding_and_playback
(didn't test - just saw the news today on lwn)
ezequielg: back
I'll wait for people to review before changing MEDIA_EMBEDDED to something else or moving m2m
I have conflicting opinions about moving m2m devs
I mean, IPU3 is currently in staging, but, if it ever gets rid of it, where would it fit? I may be wrong, as I don't see its code for a while, but I guess part of the driver is m2m, and the other part is platform driver (non-embedded, as it can be shipped on laptops too)
placing it under a platform/ dir makes sense, but if we consider platform==SoC (or Embedded), it doesn't make much sense anymore
mchehab: the ImgU is a memory to memory devices but doesn't use the V4L2 mem2mem framework. the CIO2 is a regular CSI-2 capture device
and both are CPI devices
s/CPI/PCI/
OK!
so, it would fit under pci/
yes
back to the m2m case, in the past, we used to organize directories based on their core function (dvb, v4l, ...)
but if you're concerned about an end-user that has little to no technical knowledge (which I understand was the reason you didn't like Ezequiel's proposal), then it should be under a webcam category
and the two drivers should be selected together
we're now using a per-bus approach: i2c, pci, usb, platform
moving m2m out of that doesn't seem right, and may not stick for a long time
pinchartl: yeah, from Kconfig PoV, it makes sense to select both IPU3 CIO2 and ImgU drivers together for end-users
and auto-select any I2C driver it may need (sensor drivers)
auto-selection of sensors is a lost battle, I wouldn't even attempt it
pinchartl: for embedded, yes, agreed
you can't know what hardware exists out there, and it will give a false impression that things can work out of the box
for laptops, it should be taken care, as users won't be able to discover dependencies by themselves
if you want to do that, select them all, don't select them individually
(nor distro managers)
distros will have to package them all
pinchartl: yeah, select them all is indeed an option
it is a way better to have all of them selected (for PC/Laptop) than to not have a camera working out of the box because some distro forgot to select some driver
that's a distro decision, you can't control it
(we used to have this kind of problem in the past, before having the auto-select rules working fine)
pinchartl: it is usually not a distro decision
it is just that they forget to enable new stuff when added
the only think you can do is to offer a select all option for users that compile the kernel manually or use media-build. I'm not sure it's worth it, and it will increase compilation time, but I don't care much
(I know that by expecience: from the time I was maintaining Fedora and RHEL Kernels)
do you mean you forgot to enable new options ? ;-)
pinchartl: we do have the autoselect already
well, actually, past maintainers did that... Instead, I added CONFIG_MEDIA_SUBDRV_AUTOSELECT when I noticed how hard it was to keep it uptodated
:-D
ok this is weird, v4l2 and the camera driver seems to disagree on what format a camera device has?
https://github.com/varigit/DART-SD410-kernel/blob/release/kernel-18.01/drivers/media/platform/qcom/camss-8x16/camss-video.c#L323 - according to some print statements I added to that code, the sd_pix variable ends up being 640x352 (a resolution set by a media-ctl command), but v4l2-ctl (and VIDIOC_G_FMT) returns 1920x1080
the media-ctl commands in question are https://pastebin.com/raw/eUatxi5J; is that wrong?
(the media graph, from --print-dot, is https://cloud.mort.coffee/s/9e5qRSZGdQc62CQ/preview)
what exactly does media-ctl do from the perspective of video4linux? Is video4linux even supposed to reflect configuration done through media-ctl?
mort: it actually uses the media controller API, not V4L
v4l core and drivers know about media controller
hmm
and they are the ones that actually answer to the requests
isn't it kind of weird that you can have a camera driver which accepts setting a particular format no problem, but then just breaks when you start streaming?
like, when vidioc_g_fmt reports 640x480, you'd expect to be able to open a device with that resolution and do vidioc_streamon
yeah, that should work
well, in my case, after a media-ctl command to set the resolution to 640x352, vidioc_g_fmt still reports the format as 640x480, but qcom-camss' video_check_format function fails because pix->width != sd_pix->width
is that a bug in qcom-camss do you think?
you need to set both subdev and dev to the same format
(and everything at the pipeline need to use compatible formats)
yeah, it is painful to do it manually
is the subdev a v4l thing or a media controller thing?
I assume media controller?
it is a complex camera thing
it is there to support camera devices that require software to do the setup
(usb cameras usually have a controller with sets everything, so just vidioc_s_fmt is enough)
this is a weird embedded thing
yes
looking at https://cloud.mort.coffee/s/9e5qRSZGdQc62CQ/preview and my media-ctl command, the only relevant device not touched by the media-ctl command I'm running at boot is msm_vfe0_video3, aka /dev/video3 - I assume I should include that then in the media-ctl command