Nouveau - Mar 2014 - [Bug 76376] New: mesa does not build after nouveau loader changes

https://bugs.freedesktop.org/show_bug.cgi?id=76376

          Priority: medium
            Bug ID: 76376
          Assignee: nouveau at lists.freedesktop.org
           Summary: mesa does not build after nouveau loader changes
          Severity: normal
    Classification: Unclassified
                OS: OpenBSD
          Reporter: jsg at openbsd.org
          Hardware: Other
            Status: NEW
           Version: git
         Component: Drivers/DRI/nouveau
           Product: Mesa

After commit 51989817e6767d8ef469708c69d7ce38b87e9b6e mesa does not build here
when configured with

--with-gallium-drivers=r300,r600,swrast \
--with-dri-drivers=i915,i965,r200,radeon,swrast \

libtool: compile:  gcc -DPACKAGE_NAME=\"Mesa\"
-DPACKAGE_TARNAME=\"mesa\"
-DPACKAGE_VERSION=\"10.2.0-devel\" "-DPACKAGE_STRING=\"Mesa
10.2.0-devel\""
"-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\""
-DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\"
-DVERSION=\"10.2.0-devel\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\"
-DYYTEXT_POINTER=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
-DHAVE_PTHREAD=1 -I. -DDEBUG -DUSE_X86_64_ASM -DHAVE_DLOPEN
-DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS
-DHAVE_MINCORE -I../../include -fvisibility=hidden -I/usr/X11R6/include
-I/usr/include/dev/pci/drm -I/usr/local/include -I/usr/local/include/libelf -g
-O2 -Wall -std=c99 -Werror=implicit-function-declaration
-Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O0 -MT
libloader_la-pci_id_driver_map.lo -MD -MP -MF
.deps/libloader_la-pci_id_driver_map.Tpo -c pci_id_driver_map.c  -fPIC -DPIC -o
.libs/libloader_la-pci_id_driver_map.o
pci_id_driver_map.c:29:25: error: nouveau_drm.h: No such file or directory
pci_id_driver_map.c: In function 'nouveau_chipset':
pci_id_driver_map.c:34: error: variable 'gp' has initializer but
incomplete
type
pci_id_driver_map.c:34: error: 'NOUVEAU_GETPARAM_CHIPSET_ID' undeclared
(first
use in this function)
pci_id_driver_map.c:34: error: (Each undeclared identifier is reported only
once
pci_id_driver_map.c:34: error: for each function it appears in.)
pci_id_driver_map.c:34: warning: excess elements in struct initializer
pci_id_driver_map.c:34: warning: (near initialization for 'gp')
pci_id_driver_map.c:34: warning: excess elements in struct initializer
pci_id_driver_map.c:34: warning: (near initialization for 'gp')
pci_id_driver_map.c:34: error: storage size of 'gp' isn't known
pci_id_driver_map.c:37: error: 'DRM_NOUVEAU_GETPARAM' undeclared (first
use in
this function)
pci_id_driver_map.c:34: warning: unused variable 'gp'
pci_id_driver_map.c:42: warning: control reaches end of non-void function
Makefile:512: recipe for target 'libloader_la-pci_id_driver_map.lo'
failed

nouveau headers should not be included unless nouveau is being built.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140320/994cd5e4/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=76376

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140320/a205a519/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=76376

--- Comment #2 from Jonathan Gray <jsg at openbsd.org> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140320/5ef1229d/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=76376

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140320/52ce8bab/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=76376

--- Comment #4 from Emil Velikov <emil.l.velikov at gmail.com> ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140321/5cb58594/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=76376

--- Comment #5 from Jonathan Gray <jsg at openbsd.org> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140321/f4542c3e/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=76376

Emil Velikov <emil.l.velikov at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |NOTOURBUG

--- Comment #6 from Emil Velikov <emil.l.velikov at gmail.com> ---
(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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140321/017d12f4/attachment.html>