pinchartl: I know it's been asked before, but can't we drop VIDEO_V4L2_SUBDEV_API? I see very little advantage to that config option.
Regarding making MEDIA_CONTROLLER selectable: it makes sense for bridge drivers to select it. I'm not so sure if it makes sense for i2c drivers. I think that should remain 'depends on'.
Personally I'm in favor of always enabling MEDIA_CONTROLLER for v4l2 and possibly DVB. The overhead is minimal and it simplifies driver code.
tfiga: haven't had time yet to look at the latest codec spec updates. I hope to get to it early next week.
hverkuil: no worries, thanks for heads up
hverkuil: have you seen my email about some issues with formats/buffers?
it was in the thread called "[RFP] Which V4L2 ioctls could be replaced by better versions?"
basically there are scenarios when it's impossible to import DMA-bufs to V4L2 even though they should normally work with the drivers
I haven't read it yet.
hverkuil: I²C drivers generally don't depend on MC, but many depend on the V4L2 sub-device API, or can optionally use it.
Well, the MC dependency is implicit in these cases.
Changing the current menu system would end up compiling the V4L2 sub-device and MC frameworks if any such driver is enabled.
I don't think that's a problem though; I expect more and more drivers would use MC.
hi, I need some help. I am using v4l2 loopback to create a stream at /dev/video1, but I need this to appear as a UVC webcam. I've been working on this for 3 days and pulling my hair out. Any ideas?
imstig, Are you using https://github.com/umlaeute/v4l2loopback or such ?
kbingham: something like that, let me check
kbingham: that is the one!
kbingham: I want to get it to appear in apps that check for UVC, for example cheese
imstig, Well I'm afraid the default answer is that you are best to ask on that github project (perhaps by creating an issue), as it's not a #v4l component.
imstig, That module code will have to provide some sort of option to 'pretend' to be a UVC compliant device.
kbingham: are there any that you know of that do that?
imstig, I didn't know about v4l2-loopback until I just googled :)
ah lol, ok thank you
imstig, have you tried 'cheese -d /dev/videoN' <where N is your loopback device?>
let me try
I don't think a UVC video device is particular marked differently - but I guess the apps could be checking or filtering on some device specific capability.
that command doesnt work –– I dont think its asking for a device node
doesn't work for the real camera either
I'm betting on it filtering differently. What is weird is that I have a UVC usb video capture device also connected that it should work with. Somehow it only finds webcams
snawrocki: https://www.spinics.net/lists/arm-kernel/msg679409.html
snawrocki: where did arch/arm/plat-samsung/s5p-dev-mfc.c go? Or was it deleted?
hverkuil: thanks, this file was deleted during migration to DT, the codec devices are now instantiated from devicetree
OK, I'll remove it from MAINTAINERS.
OK, thanks