Hi Devin, On Tuesday, 20 February 2018 20:18:16 EET Devin Heitmueller wrote: > On Mon, Feb 19, 2018 at 11:19 AM, Laurent Pinchart wrote: > > I've tested VLC (2.2.8) and haven't noticed any issue. If a program is > > directed to the metadata video node and tries to capture video from it it > > will obviously fail. That being said, software that work today should > > continue working, otherwise it's a regression, and we'll have to handle > > that. > > Perhaps it shouldn't be a video node then (as we do with VBI devices). > Would something like /dev/videometadataX would be more appropriate?
We've thought about it, and the initial implementation created a metadata device node instead of a video device node. This has been rejected, see https://www.mail-archive.com/linux-media@vger.kernel.org/msg97454.html and https://www.mail-archive.com/linux-media@vger.kernel.org/msg97446.html. > People have for years operated under the expectation that /dev/videoX > nodes are video nodes. If we're going to be creating things with that > name which aren't video nodes then that is going to cause considerable > confusion as well as messing up all sorts of existing applications > which operate under that expectation. > > I know that some of the older PCI boards have always exposed a bunch > of video nodes for various things (i.e. raw video vs. mpeg, etc), but > because USB devices have traditionally been simpler they generally > expose only one node of each type (i.e. one /dev/videoX, /dev/vbiX > /dev/radioX). I've already gotten an email from a customer who has a > ton of scripts which depend on this behavior, so please seriously > consider the implications of this design decision. While I can't speak about other USB devices as I'm not too familiar with them, please note that the UVC driver already exposes multiple video nodes related to video capture (or video output) for some devices, and will posssibly do so increasingly in the future when we add support for UVC 1.5. We can reconsider the decision of exposing metadata through a video node, but adding new video nodes to expose additional compressed video streams for UVC 1.5 support is something that userspace has to live with the same way it already has to live with multiple video nodes for older PCI boards. > It's easy to brush this off as "all the existing applications will > eventually be updated", but you're talking about changing the basic > behavior of how these device nodes have been presented for over a > decade. That's not what I meant, I might have not expressed myself correctly. Updating applications is something we should strive for when we want to get rid of an undesired userspace behaviour, but that's in no way an excuse for breaking anything. Regarding the issue reported by Alexandre-Xavier, it looks to me like he might be suffering from another problem, possibly part of the same patch series, but not caused by the extra video device node. That's why I asked for more information before taking any decision. -- Regards, Laurent Pinchart
