similar to: Question about NV18 and GBM library.

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

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Bruno <bonbons67 at internet.lu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #3 from Bruno <bonbons67 at

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

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

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

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=73200 Priority: medium Bug ID: 73200 Assignee: nouveau at lists.freedesktop.org Summary: vdpau-GL interop fails due to different screen objects Severity: normal Classification: Unclassified OS: All Reporter: ystreet00 at gmail.com Hardware: Other

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Pierre Moreau <pierre.morrow at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Resolution|--- |FIXED --- Comment #2 from Pierre Moreau

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #4 from Pierre Moreau <pierre.morrow at free.fr> --- (In reply to Bruno from comment #3) > Are you testing on a system where the GeForce 8600 GTS is a secondary GPU > and not initialized by VBIOS? I wasn't, you're right. I'll plug my HD6870 along and see if I can debug this. Does it only go wrong when

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #21 from Pierre Moreau <pierre.morrow at free.fr> --- I tested with latest Nouveau and latest drm-next as of yesterday (4.6-rcX), with the G84 alongside a GM206; the GM206 was the one driving the screen. Launching weston or kmscon works, but starting X makes the whole computer freeze (no responce on key presses, power button

nouveau_drv_video.so - what should it be? https://koji.fedoraproject.org/koji/buildinfo?buildID=722316 ... 0.7.4-13 - Revert symlinks - should be handled by mesa rhbz#1271842 https://bugzilla.redhat.com/show_bug.cgi?id=1271842 ... 0.7.4-12 - Add symlinks for radeonsi,r600,nouveau - rhbz#1264499 https://bugzilla.redhat.com/show_bug.cgi?id=1264499 $ rpm -q

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

Are you using VA-API on X11? libva gets the driver name from Xserver, it is nouveau for you. so libva tries to load nouveau_drv_video.so.  You can create a symlink for nouveau pointing to a available driver or just ignore the message because you have gallium_drv_video.so now. Thanks Haihao > nouveau_drv_video.so - what should it be? > > >

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

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 ++

On 31/07/2013 11:03, Ilia Mirkin wrote: > On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres at free.fr> wrote: >> On 30/07/2013 18:43, Ilia Mirkin wrote: >>> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov at gmail.com> >>> wrote: >>>> On 30/07/13 21:39, Christ-Jan Wijtmans wrote: >>>>> Hi, my apologies if

On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres at free.fr> wrote: > On 30/07/2013 18:43, Ilia Mirkin wrote: >> >> On Tue, Jul 30, 2013 at 6:31 PM, Emil Velikov <emil.l.velikov at gmail.com> >> wrote: >>> >>> On 30/07/13 21:39, Christ-Jan Wijtmans wrote: >>>> >>>> Hi, my apologies if this is the wrong place to

so uhm, as far as i know in ATI drivers this is possible, why no nouveau? Live long and prosper, Christ-Jan Wijtmans https://github.com/cjwijtmans http://facebook.com/cj.wijtmans http://twitter.com/cjwijtmans On Thu, Aug 1, 2013 at 2:15 AM, Christ-Jan Wijtmans <cj.wijtmans at gmail.com>wrote: > Sorry but 1.7 and 6.3 MB are huge... > > > Live long and prosper, > >

Sorry but 1.7 and 6.3 MB are huge... Live long and prosper, Christ-Jan Wijtmans http://facebook.com/cj.wijtmans http://twitter.com/cjwijtmans On Wed, Jul 31, 2013 at 5:42 PM, Martin Peres <martin.peres at free.fr> wrote: > On 31/07/2013 11:03, Ilia Mirkin wrote: > >> On Wed, Jul 31, 2013 at 10:44 AM, Martin Peres <martin.peres at free.fr> >> wrote: >>