Displaying 14 results from an estimated 14 matches for "nouveau_drm_winsi".
Did you mean:
nouveau_drm_winsys
2014 Jun 19
1
[PATCH] nouveau: dup fd before passing it to device
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
2015 Nov 27
13
[mesa v2 1/9] nouveau: bump required libdrm version to 2.4.66
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
2015 Nov 26
9
[mesa 1/9] nouveau: bump required libdrm version to 2.4.66
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
2015 Dec 16
11
[mesa v3 1/9] nouveau: bump required libdrm version to 2.4.66
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
2015 Nov 27
0
[mesa v2 9/9] 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
2015 Dec 28
0
[PATCH] Revert "nouveau: enable use of new kernel interfaces"
This reverts commit a8c474760268f2ebdddd655cea06dbef4500236a, and allows
the new kernel interfaces to be optionally enabled, but still off by
default. Some people are having issues while others aren't, need to
investigate.
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
Cc: Ben Skeggs <bskeggs at redhat.com>
---
src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c | 2 ++
2015 Dec 07
2
[mesa v2 5/9] nouveau: fix screen creation failure paths
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
2015 Dec 07
1
[mesa v2 5/9] nouveau: fix screen creation failure paths
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
2015 Nov 27
0
[mesa v2 5/9] nouveau: fix screen creation failure paths
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:
2015 Dec 07
0
[mesa v2 5/9] nouveau: fix screen creation failure paths
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
2019 Nov 03
4
[Bug 112201] New: Syscall param ioctl(generic) points to uninitialised byte(s)
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
2013 Mar 05
3
[Bug 61879] New: Python binding of gbm's gbm_create_device fail to create_device
https://bugs.freedesktop.org/show_bug.cgi?id=61879
Priority: medium
Bug ID: 61879
Assignee: nouveau at lists.freedesktop.org
Summary: Python binding of gbm's gbm_create_device fail to
create_device
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: amirouche.boubekki at
2019 Aug 14
1
Video Hardware Decoding: Jittery Rectangles on Nvidia GT218 NVA8 VP4.
Hi Ilia,
A fortnight ago, you wrote:
> > The video plays, CPU load is less (my aim), but there's ‘tearing’ of
> > the picture as if small rectangles that are updates are appearing in
> > the wrong location, off by a little. If I step through the frames
> > with mpv's ‘.’ and ‘,’ then I've found a pattern: one frame's
> > picture is good, followed by
2013 Oct 10
97
[Bug 70354] New: Failed to initialise context object: 2D_NVC0 (0) (for my GeForce GT 750M)
https://bugs.freedesktop.org/show_bug.cgi?id=70354
Priority: medium
Bug ID: 70354
Assignee: nouveau at lists.freedesktop.org
Summary: Failed to initialise context object: 2D_NVC0 (0) (for
my GeForce GT 750M)
QA Contact: xorg-team at lists.x.org
Severity: normal
Classification: Unclassified
OS: