Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place

[Mauro Carvalho Chehab <mchehab@kernel.org>]

Em Mon, 13 May 2019 16:57:19 +0200
Daniel Vetter <daniel@ffwll.ch> escreveu:

> > > I think small boutique trees are a problem themselves, not a solution.
> > > So if you're creating a new small boutique tree to fix a problem, you
> > > then have 2. Yes, assuming sufficient expenditure of energy it can be
> > > made to work, but I'd prefer to make my own life as easy and lazy as
> > > possible :-) And I think I've been fairly successful at that within
> > > drivers/gpu at least.
> > > 
> > > Imo the proper fix is to merge v4l and drm, at a process/maintainer
> > > level. That would solve both the original issue and the 2ndary one of
> > > the permanent topic branch.  
> > 
> > Proposals are welcome ;-)  
> 
> I'm already somewhat unpopular at LPC/lkml/kernel-at-large, I don't want
> to make this worse.  That's why I don't want to officially push for
> anything here myself, nor be in any other way involved in an effort to
> figure out v4l governance and maintainership rules.
> 
> What I think is required for efficient collaboration with drm (no matter
> how we implement that in the details once we're ready for that step) is
> some kind of group maintainership model. Doesn't need to be as extreme as
> drm-misc, but I think at least something like the soc tree (while it was
> still a bit more limited as arm-soc). Otherwise the impendence mismatch
> between how drm rolls and how v4l rolls is probably way too much. From my
> understanding v4l is working differently.
> 
> Also, through sheer inertia of size, I don't think it'll be easier to
> align drm with the v4l model. So that option is not realistic.

I don't think it is realistic trying to align V4L2 model to every single 
other subsystems we use. We have a lot of alignment with alsa, with even
increased during this merge window due to some drivers on media sharing 
media controller resources with usb-audio. We also have lots of alignment
with i2c, as we use a lot of stuff there, and from time to time they
need to add new features due to our needs. The same is true also for
input and for other subsystems and arch/sub-arch trees.

That doesn't mean at all that everybody should use the same maintainership
model. Each subsystem should use whatever suits best.

That's said, after following this thread for a while, I'm starting to
convince that it wouldn't even be realistic to have a common fourcc 
API for both subsystems. The internal requirements from each subsystem
are different, and, as it was already pointed in this thread, that's
basically why DRM ended by having their own way of doing that.

Yet, it would make sense to have at least a single nomenclature for
both systems to use, but it could be a simple as what we already do
with other common resources, like:

	Documentation/ioctl/ioctl-number.txt

If we keep the fourcc codes there sorted, if one subsystem would
add a conflicting code, it would be easy to notice at linux-next.

Thanks,
Mauro