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:

quoted

On Thu, Jul 25, 2024 at 04:43:14PM -0300, Jason Gunthorpe wrote:

quoted

On Thu, Jul 25, 2024 at 10:31:25PM +0300, Laurent Pinchart wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

quoted

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