On Tue, Oct 15, 2019 at 04:16:00AM +1000, Dave Airlie wrote: > I've kicked this around in my head over the past few weeks but wanted > to get some feedback on whether it's a good idea or what impact it > might have that I haven't considered. > > We are getting requests via both amdgpu/amdkfd and i915 for new user > APIs for userspace drivers that throw code over the wall instead of > being open source developed projects, but we are also seeing it for > android drivers and kms properties, and we had that i915 crappy crtc > background thing that was for Chrome but Chrome didn't want it. The Chrome issue this past week was really a communication breakdown between everyone involved. The Chrome patch at first glance looks like it implements the feature, so this type of thing really just needs to be caught by the left hand talking to the right (which is what happened when Daniele and I talked at XDC). At least in our (Chrome's) case, we'll catch this type of thing much earlier next time and avoid the situation entirely. I think even under your new proposal we would have been in the same spot (since this patchset is still in review). > > Now this presents a couple of issues: > > a) these projects don't seem to that good at following our development > guidelines, avoid developing userspace features in parallel in the > open and having good development implementations before submitting > upstream. > > b) these projects don't have experienced userspace developers > reviewing their kernel uapis. One big advantage of adding uapis with > mesa developers is they have a lot of experience in the area as well. > > It's leading me to think I want to just stop all uapi submissions via > driver trees, and instead mandate that all driver uapi changes are > sent in separate git pull requests to dri-devel, I'd try (with some > help) to catch all uapi modifications in normal trees, and refuse > pulls that modified uapi. We did this a separate pull with the initial HDCP support and it went Ok. I think there was a bit of conflict pain between hdcp topic branch and drm-intel, but we mostly got along. That said, I do want to be sensitive to HW vendors trying to upstream their HW features. We shit on them for keeping everything downstream, but then we shit on them for missing the bar when they try to upstream. With Android moving to kms, we're going to have more vendors coming forward with boutique HW features they are looking to standardize (or maybe they'll just stay downstream -- I'll try to stay optimistic). Nothing in your proposal suggests that it will be more difficult for vendors to upstream the right way, just that we'll have more oversight and a more consistent voice for UAPI. So yeah, I think that's completely reasonable. Sean > > At least I'm considered writing the script and refusing and pulls that > have a uapi change that doesn't contain a link to the userspace > changes required for it in a public developed repo. > > Thoughts? > > Dave. > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
