Displaying 20 results from an estimated 200 matches similar to: "[Bug 30603] New: X crash in NVAccelDownloadM2MF with KDE desktop effects enabled."
2009 Sep 22
7
[Bug 24092] New: X with nouveau hangs in nouveau_bo_map_range when doing anything
http://bugs.freedesktop.org/show_bug.cgi?id=24092
Summary: X with nouveau hangs in nouveau_bo_map_range when doing
anything
Product: xorg
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Driver/nouveau
2009 Dec 11
2
[PATCH 1/2] exa: Pre-G80 tiling support.
For now pixmaps will only be tiled if driver pixmaps are being used
and we're told to with the NOUVEAU_CREATE_PIXMAP_TILED usage hint.
Signed-off-by: Francisco Jerez <currojerez at riseup.net>
---
src/nouveau_exa.c | 31 ++++++++++++++++++++-----------
src/nv50_exa.c | 6 +++---
src/nv50_xv.c | 2 +-
src/nv_proto.h | 2 +-
src/nv_type.h | 1 +
5 files
2009 Oct 22
1
[PATCH] nv04-nv40/exa: Reorder the commands in PrepareCopy to match the blob.
This fixes a somewhat indeterministic corruption problem on nv17 when
there is stuff going on the other fifos (e.g. gallium but I've also
reproduced it with an app just SIFM-ing memory around): in some cases
it made the blits the X server had scheduled use the wrong pitch.
Signed-off-by: Francisco Jerez <currojerez at riseup.net>
---
src/nv04_exa.c | 22 ++++++++++++----------
1
2015 Mar 14
1
[PATCH ddx] Add support for VRAM-less devices to the ddx
With this patch the DDX almost works with GK20A, the missing piece is adding COHERENT mappings to the right places. ;-)
If you specify NOUVEAU_BO_APER the kernel will truncate valid_domains to the domains specified at creation time.
This means that as long as we only specify the correct domain in nouveau_allocate_surface the effect is still the same.
Signed-off-by: Maarten Lankhorst <dev at
2011 Feb 10
2
[Bug 34139] New: Seemingly random GUI lock-ups
https://bugs.freedesktop.org/show_bug.cgi?id=34139
Summary: Seemingly random GUI lock-ups
Product: xorg
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
AssignedTo: nouveau at lists.freedesktop.org
2010 Apr 20
1
[PATCH] nv30/exa : cleanup from nv40 exa
This has two purposes :
- cleaner code
- reduce the diff between nv30 and nv40 exa for a possible nvfx_exa merge ?
The main differences seem to be that nv30 uses rect texture format (and does
not support repeat on that). Then there are some minor changes in TX_FORMAT
RT_FORMAT and TEX_FILTER usage. And NVAccelInitNVx0TCL look complete
different.
Tested with:
./rendercheck -t
2009 Nov 04
1
[PATCH] nv10/exa: Spring-cleaning
* Kill the A8+A8 hack. Recent enough X servers (>=1.7) fall back to
ARGB glyphs for drivers not supporting A8 render targets.
* Kill all the global state. It doesn't matter a lot yet but it might
if we get multicard working at some point.
* Other random clean-ups with no functional changes.
Some numbers from x11perf -aa10text -aa24text -comppixwin10 -comppixwin500:
* Before, with A
2009 Oct 31
0
[PATCH] nv/exa: fix 15/16 bits solid fill
From: Marcin Slusarz <marcin.slusarz at gmail.com>
after this change nouveau passes all fill and blend tests of rendercheck
(before: fill - 108/120, blend - 3323868/3569150)
tested on NV34
Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com>
---
src/nv04_exa.c | 19 +++++++++----------
src/nv_accel_common.c | 5 ++++-
2 files changed, 13 insertions(+), 11
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
2010 Dec 07
1
[ANNOUNCE] xorg-server 1.9.99.901
Ok, I think we've done enough damage for one release. Thanks everyone
for pulling a long weekend to get changes prepared and reviewed.
We're still missing the threaded input stuff, but that needs more review
and I think we wore Tiago out this time around. If someone wants to
propose merging it after the freeze, I think we should consider doing
it.
Note that this tarball depends on
2009 Sep 14
1
[Nouveau-cvs] xf86-video-nv: Branch 'master'
On Sun, 13 Sep 2009 20:06:59 -0700 (PDT)
darktama at kemper.freedesktop.org (Ben Skeggs) wrote:
> src/drmmode_display.c | 6 ++++++
> src/nv_driver.c | 2 ++
> 2 files changed, 8 insertions(+)
>
> New commits:
> commit 6c045fc44783454180d7b3d00b5f25436bd5544e
> Author: Ben Skeggs <bskeggs at redhat.com>
> Date: Mon Sep 14 13:04:12 2009 +1000
>
2009 Jun 10
1
Compilation error in nouveau_exa.c
Dear nouveau team,
compilation of the Nouveau driver is currently failing for me with the
following error:
> gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include/xorg -I/usr/local/include -I/usr/local/include/drm -I/usr/pkg/include/pixman-1 -I/usr/pkg/include -I/usr/pkg/include/X11/dri -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/nouveau -g -O2 -Wall
2009 Jul 10
1
Can't build xf86-video-nouveau
Hello folks.
I would like to ask You for help with the following problem.
Am I missing anything important?
Thanks.
make all-recursive
make[1]: Entering directory `/home/tavvva/Install/nouveau/xf86-video-nouveau'
Making all in src
make[2]: Entering directory `/home/tavvva/Install/nouveau/xf86-video-nouveau/src'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
2007 Mar 19
0
Problems running wine under an Xvnc server
I've been trying to run wine inside an Xvnc server, but no matter what
I do, wine, wineconsole, winecfg, I get the same error:
$ winecfg
Invoking /usr/lib/wine/wine.bin winecfg.exe ...
glxcmds.c:343: CreateContext: Assertion `mode != ((void *)0)' failed.
wine: Assertion failed at address 0xb7d47947 (thread 0009), starting
debugger...
err:seh:start_debugger Couldn't start debugger
2012 May 11
3
[Bug 49815] New: nouveau segfaults in p_atomic_dec_zero
https://bugs.freedesktop.org/show_bug.cgi?id=49815
Bug #: 49815
Summary: nouveau segfaults in p_atomic_dec_zero
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component:
2012 Mar 01
1
[Bug 46810] New: Mesa Failing To Build
https://bugs.freedesktop.org/show_bug.cgi?id=46810
Bug #: 46810
Summary: Mesa Failing To Build
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/nouveau
2015 May 19
2
[PATCH 1/2] Check before trying a solid fill
Pre-nv50 has all sorts of funny requirements for non-copy alu
operations, and will bail out of solid fills left and right. Account for
that case and fall back to the memset.
Reported-by: Andrew Randrianasulu <randrianasulu at gmail.com>
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
src/drmmode_display.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
2019 Apr 09
0
[PATCH 4/4] drm: add convert_lines_toio() variant, fix cirrus builds on powerpc.
The __io_virt() macro is not available on all architectures, so cirrus
can't simply pass a pointer to io memory down to the format conversion
helpers. The format conversion helpers must use memcpy_toio() instead.
Add a convert_lines_toio() variant which does just that. Switch the
drm_fb_*_dstclip() functions used by cirrus to accept a __iomem pointer
as destination and pass that down to
2012 Mar 20
0
[LLVMdev] Runtime linker issue wtih X11R6 on i386 with -O3 optimization
Hi everybody. I have an odd issue that I'd like to get some advice on.
It is a bit of a long story so please bear with me.
X11R6 has a notion of modules so it basically compiles everything into
shared libraries and at start-of-day it loads libraries (modules) as
needed. A side effect of that is that they require really lazy binding
because they do (can?) not enforce the load order.
The
2019 Apr 10
1
[PATCH v2 3/3] drm: switch drm_fb_xrgb8888_to_rgb888_dstclip to accept __iomem dst
Not all archs have the __io_virt() macro, so cirrus can't simply convert
pointers that way. The drm format helpers have to use memcpy_toio()
instead.
This patch makes drm_fb_xrgb8888_to_rgb888_dstclip() accept a __iomem
dst pointer and use memcpy_toio() instead of memcpy(). The helper
function (drm_fb_xrgb8888_to_rgb888_line) has been changed to process a
single scanline.
Signed-off-by: