Bug 76376

Do you have some funny patches to your libdrm? nouveau_drm.h should be installed irrespective of whether nouveau is built or not. From include/drm/Makefile.am:

klibdrmincludedir = ${includedir}/libdrm
klibdrminclude_HEADERS = \
        drm.h \
        drm_mode.h \
        drm_fourcc.h \
        drm_sarea.h \
        i915_drm.h \
        mga_drm.h \
        nouveau_drm.h \
        r128_drm.h \
        radeon_drm.h \
        savage_drm.h \
        sis_drm.h \
        via_drm.h \
        mach64_drm.h \
        qxl_drm.h

All of those should be getting installed, unless my automake-foo sucks (an entirely plausible theory).

In OpenBSD we have a single set of shared kernel/userland drm headers.  Only the headers for the supported drm drivers (i915 and radeon) are installed.  We also use a seperate set of Makefiles for libdrm instead of autoconf.

I can propose adding the nouveau_drm.h to our kernel but I'd rather not do this for the rest of the drm drivers we don't support.  The exynos code in libdrm and exynos_drm.h for example is GPL licensed and we can't include any GPL licensed code in the kernel.

Sounds like you have custom patches to libdrm... you could just as well have custom patches for mesa ripping out nouveau support from loader. The thing is that this is the dispatch code, I believe the idea is that it shouldn't depend on a particular driver being built. At least none of the other ones are conditioned that way.

Pardon for cutting in:

Jonathan, apart from exynos is there any compelling reason why *BSD uses such an "old libdrm", and syncs "random files" rather than the whole repo ?

IMHO one could ping the exynos people to correct the license, similarly to what Rob did recently with freedreno[1], and then just use the upstream libdrm.


Ilia, I have the same impression as well. AFAICS the headers *_drm.h (provided by libdrm) are meant to be independent from on the device specific libraries/ packages libdrm_*.

[1] http://cgit.freedesktop.org/mesa/drm/commit/?id=128e74cf6492025e63e035566bd6e2203e8da5e1

It isn't 'old libdrm' or 'random files' it is a specific subset for the drivers the kernel supports.  The history here seems to be that five years ago Owain removed the autoconf portions for reasons I'm not entirely clear on.  Normally this is because of something like a requirement on gnu make and python in a build system.

The diff we have to libdrm is quite minimal, and includes changes for our privilege separated server and a drmCheckModesettingSupported() case for OpenBSD.

If the answer here is all the _drm.h files must be installed fine, I'll work something out.  Maybe we'll go back to having multiple copies of the headers instead of sharing them between userland and the kernel.

(In reply to comment #5)
> It isn't 'old libdrm' or 'random files' it is a specific subset for the
"old drm" refers to the structure, "random files" refers that you're pulling only changes to the core drm files.
 
> drivers the kernel supports.  The history here seems to be that five years
> ago Owain removed the autoconf portions for reasons I'm not entirely clear
Indeed, I've skimmed through the history and did not see any reason why it was nuked. Was hoping that you may have an idea on the topic.

> on.  Normally this is because of something like a requirement on gnu make
> and python in a build system.
> 
AFAICS the build is very simple and does not require anything fancy apart from autoconf/automake. Not sure how keen are you guys on the auto* pair though.

> The diff we have to libdrm is quite minimal, and includes changes for our
> privilege separated server and a drmCheckModesettingSupported() case for
> OpenBSD.
> 
drmCheckModesettingSupported recently gained support for FreeBSD, and I suspect that no one will object if you guys are interested in merging your OpenBSD implementation.

> If the answer here is all the _drm.h files must be installed fine, I'll work
> something out.  Maybe we'll go back to having multiple copies of the headers
> instead of sharing them between userland and the kernel.
This is how we handle it currently - headers do not change with every drm release, things do not sound that bad.

My main goal here is "drm has evolved over the last 5 years". It has a nice selection of programs/apps/documentation that people working on drm on any platform may be interested in. If you guys want less headache/patching, consider using the upstream drm and sent us patches on how we can make it better :-)

Thanks