On 2009.08.25 21:20:18 -0700, Linus Torvalds wrote:
And how about MacBook 2.1, which apparently also goes black?
Linus, sorry for reply this old thread.
I just handed on one MacBook with 945GM, and tried to find out
the reason of black screen. It is TV detection that caused it.
MacBook
http://bugs.freedesktop.org/show_bug.cgi?id=23785
--- Comment #5 from Nicolai Hähnle nhaeh...@gmail.com 2009-09-10 00:15:22
PST ---
That log must be incomplete. The only way to enter rc_mesa_to_program is
through code paths which first print out the Mesa program if debugging is
enabled. You
http://bugs.freedesktop.org/show_bug.cgi?id=23785
--- Comment #6 from Krzysztof A. Sobiecki sob...@gmail.com 2009-09-10
02:34:06 PST ---
NWN rendered correctly before 800f48258623f8caf25d013f44784edb7caa3f93(I have
tested several versions while bisecting) it also renders correctly on 7.5.1.
Hello Sirs:
The following patch is based on 2.6.31 mainline kernel for the system hang
issue caused by 3D scaling + ACPI. The modified header files includes
1. via_3d_reg.h
2. via_drv.h
3. via_verifier.h
4. via_drm.h
Signed-off-by: Bruce Changbrucech...@via.com.tw
diff -ruN
Hello Sirs:
The following patch is based on 2.6.31 mainline kernel for the system hang
issue caused by 3D scaling + ACPI. The modified c files includes
1. via_dmablit.c
2. via_dma.c
3. via_drv.c
4. via_irq.c
5. via_map.c
6. via_mm.c
7. via_verifier.c
Signed-off-by: Bruce
Hello Sirs:
The following patch is based on 2.6.31 mainline kernel for the system hang
issue caused by 3D scaling + ACPI. Please kindly help to integrate into
mainline kernel.
Thanks and Best Regards
=
Bruce C. Chang(張祖明)
VIA Technologies,
R3XX/R4XX AGP asic use the old PCI GART block, not the new PCIE GART.
Make sure we pick the right GART when disabling AGP.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/r300.c |6 ++
drivers/gpu/drm/radeon/r420.c |9 +++--
http://bugs.freedesktop.org/show_bug.cgi?id=23785
--- Comment #7 from Roland Scheidegger srol...@tungstengraphics.com
2009-09-10 04:54:06 PST ---
(In reply to comment #5)
That log must be incomplete.
IIRC, you can't get a log like that from nwn, since it redirects all stderr
output.
--
On Thu, Sep 10, 2009 at 06:19:52PM +0800, brucech...@via.com.tw wrote:
Hello Sirs:
The following patch is based on 2.6.31 mainline kernel for the
system hang issue caused by 3D scaling + ACPI. Please kindly help to
integrate into mainline kernel.
Thanks and Best Regards
http://bugs.freedesktop.org/show_bug.cgi?id=23785
--- Comment #8 from Krzysztof A. Sobiecki sob...@gmail.com 2009-09-10
07:08:59 PST ---
Created an attachment (id=29383)
-- (http://bugs.freedesktop.org/attachment.cgi?id=29383)
Vertex log for compiler.Base.Debug=1;
IIRC, you can't get a
http://bugs.freedesktop.org/show_bug.cgi?id=23785
--- Comment #9 from Krzysztof A. Sobiecki sob...@gmail.com 2009-09-10
08:08:37 PST ---
Created an attachment (id=29384)
-- (http://bugs.freedesktop.org/attachment.cgi?id=29384)
Output of RADEON_DEBUG=all last 3000 lines
RADEON_DEBUG=vert
http://bugs.freedesktop.org/show_bug.cgi?id=23785
Krzysztof A. Sobiecki sob...@gmail.com changed:
What|Removed |Added
Attachment #29357|0 |1
is
On Thu, Sep 10, 2009 at 7:47 AM, Jerome Glissejgli...@redhat.com wrote:
R3XX/R4XX AGP asic use the old PCI GART block, not the new PCIE GART.
Make sure we pick the right GART when disabling AGP.
Signed-off-by: Jerome Glisse jgli...@redhat.com
Acked-by: Alex Deucher alexdeuc...@gmail.com
Add getting clocks values
drivers/gpu/drm/radeon/radeon.h | 13 +
drivers/gpu/drm/radeon/radeon_atombios.c | 15 +++
2 files changed, 28 insertions(+), 0 deletions(-)
--
Rafał
0001-drm-radeon-kms-add-getting-clocks-values.patch
Description: Binary data
Add power management states storage and fill that when getting firmware info.
drivers/gpu/drm/radeon/radeon.h | 13 +
drivers/gpu/drm/radeon/radeon_atombios.c | 15 +++
2 files changed, 28 insertions(+), 0 deletions(-)
--
Rafał
W dniu 10 września 2009 18:02 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
Add power management states storage and fill that when getting firmware info.
drivers/gpu/drm/radeon/radeon.h | 13 +
drivers/gpu/drm/radeon/radeon_atombios.c | 15 +++
2
http://bugs.freedesktop.org/show_bug.cgi?id=23785
--- Comment #11 from Nicolai Hähnle nhaeh...@gmail.com 2009-09-10 09:43:50
PST ---
Wow, I totally forgot about NV_vertex_program, and I had no test cases for
that. The fact that those programs use the ENV register file is very probably
http://bugs.freedesktop.org/show_bug.cgi?id=23852
Summary: Artefacts displayed in console with multihead KMS
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
http://bugs.freedesktop.org/show_bug.cgi?id=23852
--- Comment #1 from Bob Ham r...@bash.sh 2009-09-10 14:25:57 PST ---
Created an attachment (id=29394)
-- (http://bugs.freedesktop.org/attachment.cgi?id=29394)
Photo of console display on larger monitor (artefacts on right)
--
Configure
Move mtrr range and memory information printing to radeon_object_init,
this are memory information and initialization common to all GPU and
they better fit in this function. Will also prevent code duplication
with upcoming init path changes.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
We are splitting GPU modeset init so that it's easier
to abord only remaining GPU init when somethings fails.
We want to always provide enough funcionalities to get
fbcon and a shadowfb X working. Only acceptable error
during initialization are memory allocation failure or
io mapping failure.
http://bugzilla.kernel.org/show_bug.cgi?id=13294
--- Comment #11 from Maxim Levitsky maximlevit...@gmail.com 2009-09-10
01:47:04 ---
I think this is fixed.
I don't see any leaks now
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this
http://bugzilla.kernel.org/show_bug.cgi?id=14139
Rafael J. Wysocki r...@sisk.pl changed:
What|Removed |Added
Status|NEW |RESOLVED
http://bugzilla.kernel.org/show_bug.cgi?id=14139
Carlos R. Mafra crma...@gmail.com changed:
What|Removed |Added
CC||crma...@gmail.com
http://bugzilla.kernel.org/show_bug.cgi?id=14139
zhen...@linux.intel.com changed:
What|Removed |Added
CC||zhen...@linux.intel.com
---
http://bugzilla.kernel.org/show_bug.cgi?id=14139
--- Comment #8 from Carlos R. Mafra crma...@gmail.com 2009-09-08 09:42:59 ---
Created an attachment (id=23037)
-- (http://bugzilla.kernel.org/attachment.cgi?id=23037)
dmesg from failing 2.6.31-rc9 with drm.debug=15
--
Configure bugmail:
http://bugzilla.kernel.org/show_bug.cgi?id=14139
--- Comment #9 from Carlos R. Mafra crma...@gmail.com 2009-09-08 09:54:10 ---
I've just tested the patch proposed by Zhenyu Wang here
http://marc.info/?l=linux-kernelm=125239311508274w=2
and it fixed it!
--
Configure bugmail:
From 2f5d46d24198e5e1c3ca4e0d2e0f464b84fbec39 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 10 Sep 2009 15:54:35 -0400
Subject: [PATCH] drm/radeon/kms/r600: use blit for BO moves
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
From b9fe1e51eed298bde4cb1a0c3b680b5da6063d8a Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 10 Sep 2009 16:31:13 -0400
Subject: [PATCH] drm/radeon/kms: pull in latest quirks and fixes from ddx
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
From 6825bfd3187cc0e668d1838c6259bedff7e27ad3 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 10 Sep 2009 17:53:39 -0400
Subject: [PATCH] drm/radeon/kms: add common scaled modes for TV and LVDS
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
http://bugzilla.kernel.org/show_bug.cgi?id=14139
--- Comment #11 from Carlos R. Mafra crma...@gmail.com 2009-09-09 14:57:39
---
Fixed by 7c8460db30dfd085ef3837c8fb02ecf2e718b983 in Linus' tree.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are
http://bugzilla.kernel.org/show_bug.cgi?id=14139
--- Comment #3 from Carlos R. Mafra crma...@gmail.com 2009-09-07 09:41:19 ---
Created an attachment (id=23029)
-- (http://bugzilla.kernel.org/attachment.cgi?id=23029)
dmesg from failing boot (with KMS and drm.debug=0x7)
--
Configure
http://bugzilla.kernel.org/show_bug.cgi?id=14139
--- Comment #5 from Carlos R. Mafra crma...@gmail.com 2009-09-07 09:56:12 ---
Created an attachment (id=23031)
-- (http://bugzilla.kernel.org/attachment.cgi?id=23031)
Xorg.log without KMS, with ModeDebug
--
Configure bugmail:
http://bugzilla.kernel.org/show_bug.cgi?id=14139
Rafael J. Wysocki r...@sisk.pl changed:
What|Removed |Added
Kernel Version||2.6.31-rc9
--
http://bugzilla.kernel.org/show_bug.cgi?id=14139
--- Comment #2 from ykzhao yakui.z...@intel.com 2009-09-07 01:23:20 ---
Sorry that I give the incorrect boot option. It should be drm.debug=0x07.
thanks.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You
http://bugzilla.kernel.org/show_bug.cgi?id=14139
ykzhao yakui.z...@intel.com changed:
What|Removed |Added
CC||yakui.z...@intel.com
---
http://bugzilla.kernel.org/show_bug.cgi?id=14139
--- Comment #4 from Carlos R. Mafra crma...@gmail.com 2009-09-07 09:44:26 ---
Created an attachment (id=23030)
-- (http://bugzilla.kernel.org/attachment.cgi?id=23030)
dmesg from working 2.6.31-rc8-gX boot (with KMS and drm.debug=0x7)
--
http://bugzilla.kernel.org/show_bug.cgi?id=14139
Summary: Output to external monitor is broken
Product: Drivers
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
http://bugzilla.kernel.org/show_bug.cgi?id=13819
Reinette Chatre reinette.cha...@intel.com changed:
What|Removed |Added
Status|NEW |RESOLVED
These patches break both free drivers out there. They not only break the
API, they also require some of these ioctls to be used correctly for
correct initialisation. There seems to be no attempt at working with
these two drivers to fix this specific issue.
I'm looking for the API break but
2009/9/9 Alex Deucher alexdeuc...@gmail.com:
On Tue, Sep 8, 2009 at 8:20 PM, Mike Lothianm...@fireburn.co.uk wrote:
2009/9/9 Alex Deucher alexdeuc...@gmail.com:
On Tue, Sep 8, 2009 at 7:17 PM, Mike Lothianm...@fireburn.co.uk wrote:
2009/9/8 Mike Lothian m...@fireburn.co.uk:
2009/9/8 Alex
2009/9/9 Alex Deucher alexdeuc...@gmail.com:
On Tue, Sep 8, 2009 at 8:20 PM, Mike Lothianm...@fireburn.co.uk wrote:
2009/9/9 Alex Deucher alexdeuc...@gmail.com:
On Tue, Sep 8, 2009 at 7:17 PM, Mike Lothianm...@fireburn.co.uk wrote:
2009/9/8 Mike Lothian m...@fireburn.co.uk:
2009/9/8 Alex
On Fri, Sep 11, 2009 at 11:58:01AM +1000, Dave Airlie wrote:
These patches break both free drivers out there. They not only break the
API, they also require some of these ioctls to be used correctly for
correct initialisation. There seems to be no attempt at working with
these two
As a first answer, without going in depth, as i just returned from my
thursday constitutional.
Do you have an explanation as to why this commit never made it to the
kernel?
Because it probably wasn't noticed, feel free to resend it.
I'm not sure why you need a version inside the
On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
On Fri, Sep 11, 2009 at 11:58:01AM +1000, Dave Airlie wrote:
Granted if these ioctls are to be used by *chrome to workaround this
bug as well, then
it would be good if patches to those driver were made available so as
to get
On Fri, Sep 11, 2009 at 04:26:55AM +0100, Dave Airlie wrote:
As a first answer, without going in depth, as i just returned from my
thursday constitutional.
Do you have an explanation as to why this commit never made it to the
kernel?
Because it probably wasn't noticed, feel
On Fri, Sep 11, 2009 at 01:29:21PM +1000, Daniel Stone wrote:
On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
And why did you suddenly start to care, while you pretty much ignored
this dead before? Would that be for technical reasons?
Luc,
When was the last productive
Because it probably wasn't noticed, feel free to resend it.
I'm not sure why you need a version inside the via_drm.h but I'm
willing to accept that the via driver development process is messed up
enough to require it. No other driver has needed it.
How do graphics drivers tell
On Fri, Sep 11, 2009 at 05:02:47AM +0100, Dave Airlie wrote:
They shouldn't have to. At build time they just require a certain version,
you shouldn't be building half the features into the driver because it
has an old _drm.h file. In an ideal world we would have all this stuff
hidden at the
What should the canonical source of such versioning information be?
* This header file defines the interface, and this versioning included
in the same headerfile should then niquely identify this interface.
* driver builds against this header and should then require this version
of the
On Fri, Sep 11, 2009 at 05:48:18AM +0200, Luc Verhaegen wrote:
On Fri, Sep 11, 2009 at 01:29:21PM +1000, Daniel Stone wrote:
On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
And why did you suddenly start to care, while you pretty much ignored
this dead before? Would
/*
+ * Printing helpers
+ */
+#define PINF(s, arg...) printk(KERN_INFO radeon s, ##arg)
+#define PWRN(s, arg...) \
+ printk(KERN_WARNING radeon (WR:%s:%d) s, __FILE__, __LINE__, ##arg)
+#define PERR(s, arg...) \
+ printk(KERN_ERR radeon (ER:%s:%d) s, __FILE__, __LINE__,
52 matches
Mail list logo
