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
Alex
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
