Re: [PATCH] MAINTAINERS: Mark UVC gadget driver as orphan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux