On Tue, Aug 13, 2024 at 01:44:47PM +0300, Laurent Pinchart wrote:
I haven't had time to maintain the UVC gadget driver for a long while. Dan Scally confirmed he is also in a similar -ENOTIME situation with no short term hope of fixing that. Being listed as maintainers doesn't help progress, so mark the driver as orphan to reflect the current state. Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> --- Dan, could you please ack this patch ? Michael, feel free to take over if you want. You have been active on the code base recently, so that makes you the best candidate, even if I disagree with most of your technical decisions. I'm a bit sad to leave a driver I cared about without trust in its future, hopefully the future will prove I was wrong.
This is really sad to hear. For now I will not take over maintenance since I for myself am unsure about the time that will be available in the future for this project. I understand that the path that I took to get the uvc driver working is not to your liking. Although we did never had some proper discussion how to tackle the obstacles that are obviously in the way since you know the spec better. For now the users are stuck to the v4l2sink backend which highly depends on the v4l2 ioctls. But as long we can not properly tell the OS that this is an limited v4l2 device which mostly using the vb2 api to share buffer data, it seems legit to just implement these callbacks and use them. Your mentioned "doubtful" progress which is not as invasive IMHO. However regarding the uvc-gadget project I think it still is the way to go and should be used to implement the state and workflow of e.g. the uvcsink gstreamer element and other applications wanting to stream via the uvc gadget. I for now am happy that the code is working smooth enough to properly fill the video pipeline. While only implementing parts of the uvc spec for now. So the next steps from my POV would be to rework the uvcsink to use the libusbgadget instead of the v4l2sink defaults and implement all missing parts that are currently working in the libusbgadget so it will be an drop in replacement. Parallel to that it should be clear what parts of the v4l2 framework are really necessary and we could think of some kind of flag to tell the userspace that this device is limited so that e.g. v4l2-compliance would not even worry testing it. And with that the implemented callbacks that will then not be needed anymore can be safely removed. Thanks, Michael
--- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8766f3e5e87e..e6df197f1a58 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -23819,10 +23819,8 @@ F: drivers/media/usb/uvc/ F: include/uapi/linux/uvcvideo.h USB WEBCAM GADGET -M: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> -M: Daniel Scally <dan.scally@xxxxxxxxxxxxxxxx> L: linux-usb@xxxxxxxxxxxxxxx -S: Maintained +S: Orphan F: drivers/usb/gadget/function/*uvc* F: drivers/usb/gadget/legacy/webcam.c F: include/uapi/linux/usb/g_uvc.h -- Regards, Laurent Pinchart
-- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
