<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
sailus: Heippa!
hverkuil: <u>mchehab</u>: ping
mchehab: sorry, I~m a bit late today
<br> hi all
hverkuil: Not that there is much to say. Just note the pending v5.6 PR. And I'll prepare another v5.6 PR today/tomorrow.
mchehab: yeah, I noticed. I'm planning to send those after -rc1
hverkuil: OK.
<br> I also posted this series: "[PATCH 00/11] Rename VFL_TYPE_GRABBER to _VIDEO"
<br> I want to make a PR for that as well and hope that it can be merged early in the cycle.
mchehab: I guess we commented about thi rename already
<br> while I agree that GRABBER is not the best name choice, a rename like that will just introduce another backward-compatible symbol
hverkuil: It's kAPI, not uAPI.
mchehab: ak,OK!
hverkuil: include/media/v4l2-dev.h
mchehab: for kAPI, let's do it!!!
syoung: hi all
mchehab: if all that it has there is rename, I don't have any objections for you to make a PR
hverkuil: Very nice to see nvidia finally posting a driver. To bad that v2 no longer works on my Jetson TX1, but at least they are making an effort!
mchehab: yeah, that's a good thing
<br> <u>hverkuil</u>: did a really quick look at the patch series... looks ok to be merged - I mean, the GRABBER one
hverkuil: Hopefully this will also mean that we (Cisco) can finally upstream our tc358840 HDMI-to-CSI driver. It's been block from upstreaming since I had no way of testing this on a mainline kernel, only on a way too old 4.4 kernel.
sailus: On the fourcc helper macro patches.
<br> It'd be nice to get them merged.
hverkuil: And when that driver is merged, then I can post the V4L2 HDCP API that we created.
sailus: But they're marked as rejected in Patchwork. :-(
<br> Such as this one: https://patchwork.linuxtv.org/patch/58781/
hverkuil: <u>sailus</u>: mchehab preferred a printk format for that.
sailus: These are also for the user space.
<br> Adding a printk formats is not really an option in that case.
mchehab: userspace can do whatever it wants
sailus: Besides, printing 64-bit numbers works that way as well in the user space.
<br> There's a macro that translates to the appropriate format specifiers.
mchehab: but for kernelspace, having a %fourcc would be better
<br> (of course "%fourcc" is a bad name, as %f has already a meaning)
<br> but having a "%" code is really the way to go here
sailus: My preference is to use a macro in kernel as well.
<br> So should the existing macros be put behind #ifdef __kernel__?
<br> A lot of user space programs need this, so it'd be quite helpful to have it here.
<br> We don't really have a user space only header that would be generally required in the user space and it might not be worth creating one just for this purpose.
hverkuil: We could have a printk formatter that uses the macro to print the fourcc. Not sure if that's a brilliant idea or a horrible one :-)
sailus: X-)
<br> That'd require including a V4L2 header file in lib/vsprintf.c.
hverkuil: I do think that is it nice if we can have that macro in a publicly available header to allow userspace to use the same code to format a fourcc.
mchehab: yeah, printk using a v4l2 header is a bad idea
hverkuil: It doesn't have to be a v4l2 header, the same macro is AFAIK also valid for drm fourccs.
<br> linux/fourcc.h
<br> But I am also OK to have it in videodev2.h under an #ifndef __KERNEL__
mchehab: does drm also use bit 31 for BE?
sailus: This is so specific to V4L2 that I'd keep it in a macro and not involve lib/vsprintf.c; there are some network related formats but no subsystem specific ones apart from those.
hverkuil: I have a faint memory that it does that (and that we in fact copied it from drm), but I would have to check.
sailus: Note that we can always use it in the kernel, and later define a format specifier if needed, and leave the macro for uAPI only.
hverkuil: Yes, see: include/uapi/drm/drm_fourcc.h
<br> #define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian instead of little endian */
<br>
mchehab: <u>sailus</u>: to be frank, I'm not in favor of adding userspace-only macros at uAPI
sailus: Well, then the solution is obvious: have the macro available in both user and kernel spaces, isn't it? :-)
mchehab: that should, instead, be at v4l-utils or at libcamera
hverkuil: Since both drm and v4l use fourccs in the same way, it does make sense to add it as a printk format.
mchehab: at uAPI level, the less the merrier
sailus: <u>mchehab</u>: Every user space project would end up copying the definition.
<br> If they would even use it.
mchehab: or include libcamera.h (or lib/include/libv4l2.h)
<br> if the userspace app doesn't use either... well, that's nothing we can do...
sailus: The header should be independent of libv4l2, as not every program dealing with video nodes uses it.
mchehab: the goal of libv4l2 is to be used everywhere...
<br> we're now switching to libcamera
<br> so, the next right place is at libcamera headers
<br> <u>see</u>: at Kernel level, we don't need the macros - as the right place for such conversion is at printk() function
sailus: <u>mchehab</u>: Other subsystems don't appear to do that either.
mchehab: so we would be just flooding the uAPI with things that we'll need to carry endlessly just because a developer is not using the right userspace infra
<br> <u>sailus</u>: there are a lot of printk macros specific for some subsystems, like networking
sailus: Networking is somewhat more generic than V4L2. These are usually things that are defined by some networking standard.
mchehab: MAC/FDDI addresses
<br> ------------------
<br> ::
<br> %pM 00:01:02:03:04:05
<br> %pMR 05:04:03:02:01:00
<br> IPv4 addresses
<br> --------------
<br> ::
<br> %pI4 1.2.3.4
<br> Filesystem specific ones:
<br> UUID/GUID addresses
<br> -------------------
<br> ::
<br> %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
<br> dentry names
<br> block_device names
<br> ------------------
<br> ::
<br> %pg sda, sda1 or loop0p1
sailus: Adding one for V4L2 is still stretching that practice somewhat.
mchehab: even network-device ones
<br> Network device features
<br> -----------------------
<br> ::
<br> %pNF 0x000000000000c000
sailus: If you insist, I can write a patch, and put your Suggested-by: tag there. :^)
mchehab: yeah, please do so
<br> the best is to also c/c drm ML
sailus: Oh, yes, I will!
mchehab: as the macro would also help them
<br> if it ends by not being accepted at all, I may consider adding it for kAPI, but I don't see why adding it to uAPI
<br> (at the Kernel headers)
hverkuil: <u>mchehab</u>: sailus: mailed a proposal for a patch for v4l-utils (and I guess it can be added to libcamera as well)
mchehab: it does make a lot of sense for libcamera and for v4l-utils
sailus: We will have three copies (minimum) instead of one... whatever.
mchehab: <u>hverkuil</u>: sounds OK to me
<br> <u>sailus</u>: as you said, there is now one copy per app... reducing to 3 is a good thing
<br> you should remind that v4l-utils is actually something that we're deprecating in favor of libcamera approach
hverkuil: libv4l2, not v4l-utils :-)
mchehab: yes, that's what I meant. thanks for noticing it
<br> so, at the end of the day, we should basically have the in-kernel handling - inside printk - and an userspace one at libcamera
<br> sounds quite reasonable to me
hverkuil: Basically the choice is between a suboptimal solution in the kernel using macros (but those can be used by userspace as well!), or an optimal solution in the kernel, but at the cost of not being able to use that in userspace.
<br> I'm leaning towards the latter. Ideally we would have an optimal kernel solution that would also work in userspace, but that is unfortunately not possible AFAICS.
mchehab: ok, anything else?
sailus: That's all from me.
hverkuil: from me as well.