similar to: [PATCH] Revert "nouveau: enable use of new kernel interfaces"

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c | 2 -- src/mesa/drivers/dri/nouveau/nouveau_screen.c | 2 -- 2 files changed, 4 deletions(-) diff --git a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c index

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4016871..c02ee61 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ LIBDRM_RADEON_REQUIRED=2.4.56 LIBDRM_AMDGPU_REQUIRED=2.4.63 LIBDRM_INTEL_REQUIRED=2.4.61

From: Ben Skeggs <bskeggs at redhat.com> The winsys layer would attempt to cleanup the nouveau_device if screen init failed, however, in most paths the pipe driver would have already destroyed it, resulting in accesses to freed memory etc. This commit fixes the problem by allowing the winsys to detect whether the pipe driver's destroy function needs to be called or not. Signed-off-by:

On 12/07/2015 01:40 PM, Ilia Mirkin wrote: > This all seems very roundabout... Can't we do this in a somewhat > consistent way with the device being cleaned up in one place or > another but not both? That would be lovely, but not possible. It has to be cleaned up by the pipe screen destroy() function, as that's the normal exit path. If the pipe driver creation path fails before

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4016871..c02ee61 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ LIBDRM_RADEON_REQUIRED=2.4.56 LIBDRM_AMDGPU_REQUIRED=2.4.63 LIBDRM_INTEL_REQUIRED=2.4.61

On Sun, Dec 6, 2015 at 10:48 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 12/07/2015 01:40 PM, Ilia Mirkin wrote: >> This all seems very roundabout... Can't we do this in a somewhat >> consistent way with the device being cleaned up in one place or >> another but not both? > That would be lovely, but not possible. It has to be cleaned up by the > pipe

From: Ben Skeggs <bskeggs at redhat.com> v2. forgot bump for non-gallium driver Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b6680d0..965c6f7 100644 --- a/configure.ac +++ b/configure.ac @@ -72,8 +72,8 @@ LIBDRM_REQUIRED=2.4.60

This all seems very roundabout... Can't we do this in a somewhat consistent way with the device being cleaned up in one place or another but not both? On Thu, Nov 26, 2015 at 8:04 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > From: Ben Skeggs <bskeggs at redhat.com> > > The winsys layer would attempt to cleanup the nouveau_device if screen > init failed, however, in

https://bugs.freedesktop.org/show_bug.cgi?id=112201 Bug ID: 112201 Summary: Syscall param ioctl(generic) points to uninitialised byte(s) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: not set Priority: not set

nouveau screens are reused for the same device node. However in the scenario where we create screen 1, screen 2, and then delete screen 1, the surrounding code might also close the original device node. To protect against this, dup the fd and use the dup'd fd in the nouveau_device. Also tell the nouveau_device that it is the owner of the fd so that it will be closed on destruction. Also make

https://bugs.freedesktop.org/show_bug.cgi?id=97900 Bug ID: 97900 Summary: [regression] nouveau_screen.c:230:2: error: implicit declaration of function ‘nouveau_drm_del’ Product: Mesa Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority:

https://bugs.freedesktop.org/show_bug.cgi?id=101335 Bug ID: 101335 Summary: build failure: nouveau_screen.c:105:8: error: implicit declaration of function ‘nouveau_drm_new’; Product: Mesa Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority:

https://bugs.freedesktop.org/show_bug.cgi?id=93547 Bug ID: 93547 Summary: Built failed for "Mesa (master): nouveau: remove use of deprecated nouveau_device:: drm_version" Product: Mesa Version: git Hardware: x86 (IA32) OS: All Status: NEW Severity: normal Priority:

--- .../winsys/drm/nouveau/common/nouveau_context.c | 6 ++++-- .../winsys/drm/nouveau/common/nouveau_winsys.c | 7 ++++++- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/src/gallium/winsys/drm/nouveau/common/nouveau_context.c b/src/gallium/winsys/drm/nouveau/common/nouveau_context.c index 25c9845..d9321ea 100644 ---

I made some changes to the Nouveau drm winsys so it could be shared between Mesa and VL. Mostly this involved moving all the common stuff into common/ and adding dri/. Compiles and runs the stuff in progs/ like before as far as I know, but if anyone actually uses the Mesa driver for anything non-trivial I'd appreciate knowing if this broke anything for you. :) * The code in common/ compiles

https://bugs.freedesktop.org/show_bug.cgi?id=101199 Bug ID: 101199 Summary: nouveau_screen.c: undefined reference to `nouveau_drm_del' Product: Mesa Version: 17.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component:

For a long time the gallium pipe drivers for nvidia fixed function cards (nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and godforsaken -- especially nv0x and nv1x had seen almost no progress since their creation. They've recently grown a classic mesa driver which implements many new features: texturing, hardware-accelerated tnl. However the killer feature is "it

SUBMISSION DEADLINE 14th International Conference on Wireless Networks and Mobile Systems Submission Deadline: April 18, 2017 http://www.winsys.icete.org/ July 24 - 26, 2017 Madrid, Spain. WINSYS is organized in 3 major tracks: - Sensor Networks and Ad Hoc Communications - Wireless and Mobile Technologies - Mobile Software and Services In Cooperation with ITG. Technically

SUBMISSION DEADLINE 15th International Conference on Wireless Networks and Mobile Systems Submission Deadline: March 13, 2018 http://www.winsys.icete.org/ July 26 - 28, 2018 Porto, Portugal. WINSYS is organized in 3 major tracks: - Sensor Networks and Ad Hoc Communications - Wireless and Mobile Technologies - Mobile Software and Services A short list of presented papers will be

SUBMISSION DEADLINE 15th International Conference on Wireless Networks and Mobile Systems Submission Deadline: March 13, 2018 http://www.winsys.icete.org/ July 26 - 28, 2018 Porto, Portugal. WINSYS is organized in 3 major tracks: - Sensor Networks and Ad Hoc Communications - Wireless and Mobile Technologies - Mobile Software and Services A short list of presented papers will be