[Bug 29852] Changing external monitors requires X restart

2010-08-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=29852 tim.h...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED

[Bug 29852] Changing external monitors requires X restart

2010-08-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=29852 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|REOPENED|RESOLVED

[Bug 29852] Changing external monitors requires X restart

2010-08-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=29852 --- Comment #18 from tim.h...@gmail.com 2010-08-31 01:59:57 PDT --- Thanks again. Now that I am better-informed, I will re-test using the Maverick live CD where KMS works; if problems persist I will submit bug reports to the targets you

Re: [PATCH 1/6] DownloadFromScreenCS: download via a scratch BO if pixmap domain is unknown

2010-08-31 Thread Michel Dänzer
On Mon, 2010-08-23 at 18:27 +1200, Karl Tomlinson wrote: radeon_bo_is_busy() may return without setting the domain out-parameter. If this happens, then download via a scratch GTT BO to avoid CPU VRAM read. I'm on the fence about this one. I can see how it could help *if* radeon_bo_is_busy()

Re: [PATCH 6/6] RADEONPrepareAccess_CS: fallback to DFS when pixmap is in VRAM

2010-08-31 Thread Michel Dänzer
First of all, thanks a lot for splitting up the patch from the bug report, this was very helpful for review. Unfortunately though, the split isn't quite perfect: * Patch 4 introduces a big endian build break (typo, pSrc instead of pDst in RADEONUploadToScreenCS) which is silently

Re: [PATCH 3/6] RADEONDownloadFromScreenCS: flush CS writes before mapping BO for read

2010-08-31 Thread Michel Dänzer
On Mon, 2010-08-23 at 19:41 +1200, Karl Tomlinson wrote: If unflushed CS operations write to the pixmap BO, then these need to be flushed before mapping the BO for read. This currently only affects big endian systems and only when the operation writes to the GTT domain. [...] @@ -593,6

Bug#595033: xserver-xorg-video-ati: Only one display works at a time with RV620 [FirePro 2260] with two DisplayPort output

2010-08-31 Thread Julien Cristau
On Tue, Aug 31, 2010 at 16:59:47 +0200, Thomas PIERSON wrote: Package: xserver-xorg-video-ati Version: 1:6.13.1-2 Severity: normal Hi, I have an issue with 2 monitors connected on two DislpayPort output. The card is an ATI FirePro 2260. And only one display can works at a time. $

Bug#595033: xserver-xorg-video-ati: Only one display works at a time with RV620 [FirePro 2260] with two DisplayPort output

2010-08-31 Thread Alex Deucher
On Tue, Aug 31, 2010 at 10:59 AM, Thomas PIERSON web.pier...@gmail.com wrote: Package: xserver-xorg-video-ati Version: 1:6.13.1-2 Severity: normal Hi, I have an issue with 2 monitors connected on two DislpayPort output. The card is an ATI FirePro 2260. And only one display can works at a

[Bug 29808] EXA Acceleration on Evergreen results in lockup of X

2010-08-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=29808 --- Comment #4 from Matthew Cox m...@mattcox.ca 2010-08-31 14:49:27 PDT --- I've determined how to prevent and induce this bug. If I run X with fglrx (catalyst 10.8) and then remove it from my system (the module, the DDX, everything), then

Bug#595033: xserver-xorg-video-ati: Only one display works at a time with RV620 [FirePro 2260] with two DisplayPort output

2010-08-31 Thread Julien Cristau
reassign 595033 linux-2.6 tag 595033 fixed-upstream patch kthxbye On Tue, Aug 31, 2010 at 11:51:33 -0400, Alex Deucher wrote: On Tue, Aug 31, 2010 at 10:59 AM, Thomas PIERSON web.pier...@gmail.com wrote: I have an issue with 2 monitors connected on two DislpayPort output. The card is

Re: [PATCH 3/6] RADEONDownloadFromScreenCS: flush CS writes before mapping BO for read

2010-08-31 Thread Karl Tomlinson
Michel Dänzer writes: @@ -593,6 +596,10 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y, int w, if ((src_domain (RADEON_GEM_DOMAIN_GTT | RADEON_GEM_DOMAIN_VRAM)) == (RADEON_GEM_DOMAIN_GTT | RADEON_GEM_DOMAIN_VRAM)) src_domain = 0; +#if X_BYTE_ORDER ==

Re: [PATCH 6/6] RADEONPrepareAccess_CS: fallback to DFS when pixmap is in VRAM

2010-08-31 Thread Karl Tomlinson
Thank you for taking the time to look at this, Michel. Michel Dänzer writes: First of all, thanks a lot for splitting up the patch from the bug report, this was very helpful for review. Unfortunately though, the split isn't quite perfect: * Patch 4 introduces a big endian build break

Re: [PATCH 1/6] DownloadFromScreenCS: download via a scratch BO if pixmap domain is unknown

2010-08-31 Thread Karl Tomlinson
Michel Dänzer writes: On Mon, 2010-08-23 at 18:27 +1200, Karl Tomlinson wrote: radeon_bo_is_busy() may return without setting the domain out-parameter. If this happens, then download via a scratch GTT BO to avoid CPU VRAM read. I'm on the fence about this one. I can see how it could help