Alex Deucher <alexdeuc...@gmail.com> writes:
> On Fri, Jun 30, 2017 at 12:40 PM, Lionel Landwerlin
> <lionel.g.landwer...@intel.com> wrote:
>> On 30/06/17 17:14, Alex Deucher wrote:
>>>
>>> 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 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
>
> I don't necessarily agree with the rules for updating the headers in
> libdrm. I agree with Eric's statement that they should always be
> compatible. I like to be able to update the UAPI headers along with
> the libdrm patch that uses them. That said, I get yelled at every
> time I try and do that, so I feel like we should apply that equally or
> get rid of it.Sorry, what do you get yelled at for? The only thing that would cause yelling, I believe, would be trying to merge (not just submit for review) libdrm/mesa/etc. patches updating the UAPI headers before the UAPI is in drm-next.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
