[Bug 24029] New: Compiz water effect causes black screen on r300

2009-09-18 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=24029

   Summary: Compiz water effect causes black screen on r300
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: ASSIGNED
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r300
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: ore...@gmail.com
 QAContact: nhaeh...@gmail.com
CC: nhaeh...@gmail.com


With latest mesa testing with rv350, compiz water causes the screen to go
completely black until the effect is finished. I did a bisect and found the
first bad commit which is:

0723cd1b0a8a76808844a2216d709f56fbad88e2 is first bad commit
commit 0723cd1b0a8a76808844a2216d709f56fbad88e2
Author: Nicolai Hähnle 
Date:   Wed Jul 29 20:59:56 2009 +0200

r300: Cleanup r300_fragment_program_code

Configuration register values are now stored directly in that structure.

Signed-off-by: Nicolai Hähnle 

:04 04 ec18babd110667a8c1ea82ac0226b9669641151d
e4e0402eebd0b6a1049533042a3d2fc2febb1ab6 M  src

After looking into the source, it seems the changes made in r300_fragprog.c are
not a problem but changes for the other three files in the commit cause the
problem. Hope to see it fixed soon, thanks.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm: Add async event synchronization for drmWaitVblank

2009-09-18 Thread Jesse Barnes
Just one comment so far now that I'm using this code.

On Fri, 11 Sep 2009 14:33:34 -0400
"Kristian Høgsberg"  wrote:
> + file_priv->event_space -= sizeof e->event;
> + seq = drm_vblank_count(dev, pipe);
> + if ((vblwait->request.type & _DRM_VBLANK_NEXTONMISS) &&
> + (seq - vblwait->request.sequence) <= (1 << 23)) {
> + vblwait->request.sequence = seq + 1;
> + }
> +
> + DRM_DEBUG("event on vblank count %d, current %d, crtc %d\n",
> +   vblwait->request.sequence, seq, pipe);

When we queue the event we should probably return the queued sequence
number to the client since in some cases they may be doing a relative
wait and will need to know the ultimate sequence number to look for in
their wake handler.

-- 
Jesse Barnes, Intel Open Source Technology Center

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 23992] Skybox corruption in Tremulous with KMS enabled.

2009-09-18 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=23992





--- Comment #3 from Lukasz Krotowski   2009-09-18 
11:19:53 PST ---
Created an attachment (id=29671)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=29671)
Radeon/DRM part of dmesg.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 23852] Artefacts displayed in console with multihead KMS

2009-09-18 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=23852





--- Comment #2 from Jerome Glisse   2009-09-18 08:34:20 
PST ---
Please attach full dmesg of a session with kms one


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] drm/radeon/r600/kms: rv670 is not DCE3

2009-09-18 Thread Alex Deucher
>From 3065eb65a36a0b49a7975274b8236fc01127c1db Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Fri, 18 Sep 2009 11:30:30 -0400
Subject: [PATCH] drm/radeon/r600/kms: rv670 is not DCE3

RV670 was using the wrong modesetting code.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d7c4efd..7f103ec 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -108,9 +108,9 @@ enum radeon_family {
CHIP_R600,
CHIP_RV610,
CHIP_RV630,
+   CHIP_RV670,
CHIP_RV620,
CHIP_RV635,
-   CHIP_RV670,
CHIP_RS780,
CHIP_RS880,
CHIP_RV770,
-- 
1.5.6.3
From 3065eb65a36a0b49a7975274b8236fc01127c1db Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Fri, 18 Sep 2009 11:30:30 -0400
Subject: [PATCH] drm/radeon/r600/kms: rv670 is not DCE3

RV670 was using the wrong modesetting code.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d7c4efd..7f103ec 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -108,9 +108,9 @@ enum radeon_family {
 	CHIP_R600,
 	CHIP_RV610,
 	CHIP_RV630,
+	CHIP_RV670,
 	CHIP_RV620,
 	CHIP_RV635,
-	CHIP_RV670,
 	CHIP_RS780,
 	CHIP_RS880,
 	CHIP_RV770,
-- 
1.5.6.3

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [IDEA] drm/radeon/kms: user defined power state

2009-09-18 Thread Alex Deucher
2009/9/17 Rafał Miłecki :
> W dniu 18 września 2009 00:55 użytkownik Rafał Miłecki
>  napisał:
>> My new proposition is rather create some "user_power_mode" and let
>> user specify all 3 params. For example:
>> $ echo 20 40 1050 > /sys/class/gpu/user_power_mode
>> $ cat /sys/class/gpu/user_power_mode
>> Engine clock: 20
>> Memory clock: 40
>> Voltage: 1050
>
> Or maybe
> $ echo user 20 40 1050 > /sys/class/gpu/power_modes
> $ echo minimum 10 20 900 > /sys/class/gpu/power_modes
> do you think we should allow user to overwrite all modes?

Certain combinations of clocks and voltages aren't possible or
advisable.  I think we need to keep it simple.  Just 3 modes:
- low/battery mode
- normal
- fast/performance
and keep everything else dynamic.

Once that's on place we can look at something for tweakers.

Alex

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 23234] radeon , kms , xrandr - mouse "disspaears" on secondary screen

2009-09-18 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=23234





--- Comment #13 from Kevin DeKorte   2009-09-18 05:57:13 
PST ---
Appears to be fixed using drm-next,drm and ddx (git) from Sep 18, 2009


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [IDEA] drm/radeon/kms: user defined power state

2009-09-18 Thread Pauli Nieminen
2009/9/17 Rafał Miłecki 

> W dniu 18 września 2009 00:55 użytkownik Rafał Miłecki
>  napisał:
> > My new proposition is rather create some "user_power_mode" and let
> > user specify all 3 params. For example:
> > $ echo 20 40 1050 > /sys/class/gpu/user_power_mode
> > $ cat /sys/class/gpu/user_power_mode
> > Engine clock: 20
> > Memory clock: 40
> > Voltage: 1050
>
> Or maybe
> $ echo user 20 40 1050 > /sys/class/gpu/power_modes
> $ echo minimum 10 20 900 > /sys/class/gpu/power_modes
> do you think we should allow user to overwrite all modes?
>
> --
> Rafał
>
>
What about multi-gpu systems? I think we want to expose this interface as
gpu specific location.

I agree that user-space interface should have atomic way of setting all
parameters at once. But I think that at first we want to only expose some
predefined states to user-space that are known to work well in some
workloads.  This will make it easier to track down bugs in power management
code when there is not so many variables in play.

Of course later it would be nice to give more control to user-space so user
can control voltages and clocks manually (for example overclockers would
like this kind of feature).

I also think that there should be logging for all power state changes so it
is easier to know what went wrong if just looking the dmesg that user
provided when reporting the bug.

So maybe it is best to develop complete idea of interface at first for
developer testing and only exposes simple interface to users at first and
later expose full control interface.

Pauli
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm/radeon/kms: Move radeon_get_clock_info() call out of radeon_clocks_init().

2009-09-18 Thread Michel Dänzer
On Fri, 2009-09-18 at 07:45 +0100, Dave Airlie wrote: 
> > From: Michel Dänzer 
> > 
> > Someone on IRC reported problems after commit
> > 95a8f1bf4f48b434c9f839ab5a0773f66b39d7c6 ('drm/radeon/kms: Move
> > radeon_clocks_init() call back after getting VRAM info.'). And indeed, at 
> > least
> > some ASIC vram_info hooks use the clock info obtained by
> > radeon_get_clock_info(). So, move that call out of radeon_clocks_init(), 
> > ahead
> > of the radeon_vram_info() call.
> > 
> 
> This broke r600/rv770,

Whoops, sorry I failed to notice those have separate init paths.

> fixed up and applied to drm-next.

Thanks!


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm/radeon/kms: Move radeon_get_clock_info() call out of

2009-09-18 Thread Thierry Vignaud
Dave Airlie  writes:

> > An rv350 specific issue then?
>
> I booted it on my desktop rv370 and I'm sure Michel has booted it on
> his rv350 macbook, so might be a bios issue or soemthing else.

Maybe but note that drm-next just complains that there's no modes:

"Connected connector with 0 modes"

whereas 2.6.31 kernel reports this too, but also says it's fallbacking
on standard modes:

i2c-adapter i2c-0: unable to read EDID block.
radeon :02:00.0: VGA-1: no EDID data
[drm:drm_helper_initial_config] *ERROR* connectors have no modes, using 
standard modes

IMHO, the culprit would be that chunk:
diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 6aaa2cb..ff447f1 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -940,16 +945,9 @@ bool drm_helper_initial_config(struct drm_device *dev)
 dev->mode_config.max_height);

/*
-* None of the available connectors had any modes, so add some
-* and try to light them up anyway
+* we shouldn't end up with no modes here.
 */
-   if (!count) {
-   DRM_ERROR("connectors have no modes, using standard modes\n");
-   list_for_each_entry(connector,
-   &dev->mode_config.connector_list,
-   head)
-   drm_helper_add_std_modes(dev, connector);
-   }
+   WARN(!count, "Connected connector with 0 modes\n");
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm/radeon/kms: Move radeon_get_clock_info() call out of

2009-09-18 Thread Dave Airlie
> 
> 
> An rv350 specific issue then?

I booted it on my desktop rv370 and I'm sure Michel has booted it on his 
rv350 macbook, so might be a bios issue or soemthing else.

Dave.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm/radeon/kms: Move radeon_get_clock_info() call out of

2009-09-18 Thread Thierry Vignaud
Thierry Vignaud  writes:

> For me, drm-next's still broken even with that patch whereas stock
> 2.6.31 is working fine (modulo hard freeze after a couple hours) on
> RV350 AP [Radeon 9600].

It works fine on RV530 though:
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
radeon :01:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
radeon :01:00.0: setting latency timer to 64
[drm] radeon: Initializing kernel modesetting.
[drm] register mmio base: 0xFDAF
[drm] register mmio size: 65536
ATOM BIOS: A67105
[drm] GPU reset succeed (RBBM_STATUS=0x1140)
[drm] Clocks initialized !
[drm] Generation 2 PCI interface, using max accessible memory
[drm] Detected VRAM RAM=256M, BAR=256M
[drm] RAM width 128bits DDR
[drm] radeon: 1 quad pipes, 2 z pipes initialized.
[drm] radeon: VRAM 256M
[drm] radeon: VRAM from 0x to 0x0FFF
[drm] radeon: GTT 512M
[drm] radeon: GTT from 0x2000 to 0x3FFF
[drm] radeon: irq initialized.
[TTM] Zone  kernel: Available graphics memory: 443534 kiB.
[TTM] Zone highmem: Available graphics memory: 1036914 kiB.
[drm] radeon: 256M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] PCIE GART of 512M enabled (table at 0x0004).
[drm] radeon: cp idle (0x1C03)
[drm] Loading R500 Microcode
platform radeon_cp.0: firmware: requesting radeon/R520_cp.bin
[drm] radeon: ring at 0x2000
[drm] ring test succeeded in 7 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP3: INTERNAL_LVTM1
[drm] Connector 1:
[drm]   S-video
[drm]   Encoders:
[drm] TV1: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] CRT2: INTERNAL_KLDSCP_DAC2
[drm] DFP1: INTERNAL_KLDSCP_TMDS1
[drm] fb mappable at 0xD00C
[drm] vram apper at 0xD000
[drm] size 7257600
[drm] fb depth is 24
[drm]pitch is 6912
executing set pll
executing set crtc timing
[drm] TV-6: set mode 1680x1050 1e
Console: switching to colour frame buffer device 210x65
fb0: radeondrmfb frame buffer device
registered panic notifier
[drm] radeon: kernel modesetting successfully initialized.
[drm] Initialized radeon 2.0.0 20080528 for :01:00.0 on minor 0


An rv350 specific issue then?

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel