On Fri, Jul 26, 2024 at 10:04:48AM +0200, Ricardo Ribalda Delgado wrote: > On Thu, Jul 25, 2024 at 10:07 PM Laurent Pinchart wrote: > > On Thu, Jul 25, 2024 at 04:43:14PM -0300, Jason Gunthorpe wrote: > > > On Thu, Jul 25, 2024 at 10:31:25PM +0300, Laurent Pinchart wrote: > > > > > > > I don't think those are necessarily relevant examples, as far as device > > > > pass-through goes. Vendors have many times reverted to proprietary ways, > > > > and they still do, at least in the areas of the kernel I'm most active > > > > in. I've seen first hand a large SoC vendor very close to opening a > > > > significant part of their camera stack and changing their mind at the > > > > last minute when they heard they could possibly merge their code through > > > > a different subsystem with a pass-through blank cheque. > > > > > > If someone came with a fully open source framework for (say) some > > > camera, > > > > We have such a framework, it's called libcamera :-) Multiple vendors are > > already collaborating. > > > > > with a passthrough kernel driver design, would you reject it > > > soley because it is passthrough based and you are scared that > > > something else will use it to do something not open source? > > > > It depends what "passthrough kernel driver design" means. If it means > > accessing the PCI registers directly from userspace, yes. That's what X > > used to do before KMS, and I'm glad it's now a distant past. > > Nobody has suggested giving PCI register access to userspace. I know you didn't, but as I didn't expect Jason to be familiar with the camera ISP discussions, I didn't want to make any specific assumption regarding what he meant by passthrough kernel driver design. > > If it means a kernel driver that takes the majority of its runtime > > parameters from a buffer blob assembled by userspace, while controlling > > clocks, power domains and performing basic validation in kernelspace, > > then I've already acked multiple drivers with such a design, exactly > > because they have open-source userspace that doesn't try to keep many > > device features proprietary and usable by closed-source userspace only. > > If that was an option we would not be having this discussion. > > Vendors cannot have vendor access in v4l2. > """ > It is not an option to upstream a driver that has support for > undocumented closed features. Basically maintainers can't put their > name on something that contains unverifiable (for them) and unusable > (by all except the vendor) features. > """ > https://linuxtv.org/news.php?entry=2022-11-14-1.hverkuil What is not an option exactly in my description above ? We have multiple V4L2 drivers for ISPs. They receive ISP parameters from userspace through a data buffer. It's not allowed to be opaque, but it doesn't prevent vendor closed-source userspace implementations with additional *camera* features, as long as the *hardware* features are available to everybody. > > > I wouldn't agree with that position, I think denying users useful open > > > source solutions out of fear is not what Linux should be doing. -- Regards, Laurent Pinchart
