On Fri, Jun 30, 2017 at 12:02 PM, Eric Anholt <e...@anholt.net> wrote:
> Alex Deucher <alexdeuc...@gmail.com> writes:
>
>> On Thu, Jun 29, 2017 at 11:42 AM, Eric Anholt <e...@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.landwer...@intel.com>
>>> Reviewed-by: Daniel Stone <dani...@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 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.
Alex
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
