[Mesa-dev] [PATCH v2] intel: Move the DRM uapi headers to a non-Intel location.
Lionel Landwerlin
lionel.g.landwerlin at intel.com
Fri Jun 30 16:40:24 UTC 2017
On 30/06/17 17:14, Alex Deucher wrote:
> On Fri, Jun 30, 2017 at 12:02 PM, Eric Anholt <eric at anholt.net> wrote:
>> Alex Deucher <alexdeucher at gmail.com> writes:
>>
>>> On Thu, Jun 29, 2017 at 11:42 AM, Eric Anholt <eric at anholt.net> wrote:
>>>> I want to remove vc4's dependency on headers from libdrm as well, but
>>>> storing multiple copies of drm_fourcc.h in our tree would be silly.
>>>>
>>>> v2: Update Android.mk as well, move distcheck drm*.h references to
>>>> top-level noinst_HEADERS.
>>>>
>>>> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
>>>> Reviewed-by: Daniel Stone <daniels at collabora.com>
>>>> ---
>>>> Makefile.am | 4 ++++
>>>> {src/intel/drm => include/drm-uapi}/README | 0
>>>> {src/intel/drm => include/drm-uapi}/drm.h | 0
>>>> {src/intel/drm => include/drm-uapi}/drm_fourcc.h | 0
>>>> {src/intel/drm => include/drm-uapi}/drm_mode.h | 0
>>>> {src/intel/drm => include/drm-uapi}/i915_drm.h | 0
>>>> src/intel/Android.vulkan.mk | 2 +-
>>>> src/intel/Makefile.am | 1 -
>>>> src/intel/Makefile.drm.am | 22 ----------------------
>>>> src/intel/Makefile.sources | 6 ------
>>>> src/intel/Makefile.vulkan.am | 2 +-
>>>> src/mesa/drivers/dri/i965/Android.mk | 4 ++--
>>>> src/mesa/drivers/dri/i965/Makefile.am | 2 +-
>>>> 13 files changed, 9 insertions(+), 34 deletions(-)
>>>> rename {src/intel/drm => include/drm-uapi}/README (100%)
>>>> rename {src/intel/drm => include/drm-uapi}/drm.h (100%)
>>>> rename {src/intel/drm => include/drm-uapi}/drm_fourcc.h (100%)
>>>> rename {src/intel/drm => include/drm-uapi}/drm_mode.h (100%)
>>>> rename {src/intel/drm => include/drm-uapi}/i915_drm.h (100%)
>>>> delete mode 100644 src/intel/Makefile.drm.am
>>>
>>> I don't mean to pick on this patch specifically, but maybe it would
>>> still make sense to depend on libdrm for the drm headers? If not do
>>> we want similar restrictions on updating these as we have for libdrm?
>> Yes, we certainly have the same restrictions on updating headers (pull
>> only things that have landed in airlied's drm-next, or possibly
>> drm-misc-next if acked by airlied) as libdrm does. That's
>> "participating in kernel DRM development" rules, not libdrm rules.
> I'm not arguing about the fact that stuff has to land in drm-next,
> etc. first, but there are pretty strict additional requirements as to
> how they are updated:
> https://cgit.freedesktop.org/mesa/drm/tree/include/drm/README
> Do we want to enforce similar requirements in mesa?
I think that's the idea, and what's in the README file of this commit.
Maybe we need to update to to actually put the url of airlied's tree?
>
>> I don't think it makes sense to depend on libdrm if all you're using
>> From libdrm is the header that you can just put in the tree.
> I though we agreed that libdrm was supposed to be the canonical source
> for these headers in userspace. It just seems like we are going to
> end up with a proliferation of these headers as various projects
> decide to include them directly.
I guess most driver developers didn't have an opinion at the time or
didn't pay attention to the patch introducing
https://cgit.freedesktop.org/mesa/drm/tree/include/drm/README
Here is a pointer to the discussion with a different set of people, with
Eric's answer which makes the best argument for this (in my opinion) :
https://lists.freedesktop.org/archives/mesa-dev/2017-May/154491.html
>
> Alex
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list