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

[Laurent Pinchart]

Hi Paul,

On Tue, Apr 23, 2019 at 06:54:49PM +0200, Paul Kocialkowski wrote:
> Le dimanche 21 avril 2019 à 01:40 +0300, Laurent Pinchart a écrit :
> > On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote:
> >> On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote:
> >>> On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> >>>> And a lot of people pushed for the "fourcc is a standard", when
> >>>> really it's totally not.
> >>> 
> >>> Even if it's not a standard, having consistency would be a good thing.
> >>> 
> >>> And you said yourself that DRM fourcc is now pretty much an authority
> >>> for the fourcc, so it definitely looks like a standard to me.
> >> 
> >> I think trying to make the V4L2 and DRM fourccs converge is a lost
> >> cause, as it has already significantly diverged. Even if we coordinate
> >> an effort to introduce new formats with the same fourcc on both sides,
> >> I don't see what good that would be since the formats we have now are
> >> still plagued by the inconsistency.
> >> 
> >> I think we always need an explicit translation step from either v4l2 or
> >> drm to the internal representation and back, without ever assuming that
> >> formats might be compatible because they share the same fourcc.
> > 
> > I don't agree. APIs evolve, and while we can't switch from one set of
> > 4CCs to another in existing APIs, we could in new APIs. Boris is working
> > on new ioctls to handle formats in V4L2, and while 4CC unification could
> > be impopular from a userspace developers point of view there, I don't
> > think we have ruled it out completely. The move to the request API is
> > also an area where a common set of 4CCs could be used, as it will depart
> > from the existing V4L2 ioctls. To summarize my opinion, we're not there
> > yet, but I wouldn't rule it out completely for the future.
> 
> Well, I don't see how we could maintain backward compatibility with
> some DRM and V4L2 fourccs that are compatible and some that aren't.
> Since both descriptions have diverged already, one would need explicit
> checking of whether the format at hand is a compatible one or not
> before passing-it along as-is to the other subsystem or going through a
> format conversion step (in userspace, duplicating the information).
> So it feels like it kind of defeats the purpose.

Yes and no. If a V4L2-only application needs to deal with two sets of
4CCs for old and new APIs, it's a burden. However, if an application
that shares buffers between V4L2 and DRM/KMS can use a single set of
4CCs, that's a win, as those applications already need to convert. In
the end this shifts the problem from one set of applications to another,
but as soon as the new APIs get old enough to mandate their usage (which
would roughly be when the corresponding kernel ships in all supported
versions of all major distros), then applications will be able to drop
the conversion code, and everybody will be happier. Short term pain for
long term gain.

> If we're going to use a unified 4CC representation in the future, I
> think we should do it by using the new formats that this proposal is
> introducing instead of subsystem-specific formats. At which point I
> believe we will need an internal conversion step between that format
> and what the subsystem uses internally. Or do it the other way round
> and use the unified format all around the subsystem, with a legacy
> layer for the previous subsystem-specific format.

I agree with you. I would like new APIs to use unified 4CCs (probably
coming from DRM), and have an internal conversion from and to
subsystem-specific 4CCs where needed. That's quite a lot of work of
course, and won't happen overnight.

-- 
Regards,

Laurent Pinchart