Em Mon, 13 May 2019 16:57:19 +0200 Daniel Vetter <daniel@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
