http://bugs.freedesktop.org/show_bug.cgi?id=25741
--- Comment #23 from Luca Tettamanti kronos...@gmail.com 2010-03-09 01:50:32
PST ---
(In reply to comment #22)
Created an attachment (id=33870)
-- (http://bugs.freedesktop.org/attachment.cgi?id=33870) [details]
fix spread spectrum
This
On Tuesday 09 March 2010, Luca Tettamanti wrote:
On Sat, Mar 6, 2010 at 10:36 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Hi,
For at least two reasons it would be beneficial for some code outisde the
graphics driver(s) to know if the KMS are used.
First, in the non-KMS (ie. UMS) case we
http://bugs.freedesktop.org/show_bug.cgi?id=24973
--- Comment #8 from Marius Groeger marius.groe...@web.de 2010-03-09 07:19:18
PST ---
Is this still an issue with 2.6.33 or drm-next?
Nope. For me the TV-out/xrandr issue seems to be fixed. By now I am using
2.6-master, mesa-master,
2010/3/8 Rafał Miłecki zaj...@gmail.com:
We almost always used first HDMI block for first encoder and second for
sencod.
Exception was KLDSCP_LVTMA. Analyzing code picking DIG encoder shows the same
behaviour. It shows HDMI block are related to DIGs, which relation we now use.
On Sat, Mar 6, 2010 at 10:36 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Hi,
For at least two reasons it would be beneficial for some code outisde the
graphics driver(s) to know if the KMS are used.
First, in the non-KMS (ie. UMS) case we probably wouldn't want to call
acpi_video_resume(),
--
On Mon, 8 Mar 2010, Alex Deucher wrote:
On Mon, Mar 8, 2010 at 12:42 PM, Piotr Gluszenia Slawinski
curi...@bwv190.internetdsl.tpnet.pl wrote:
i have dual head sa(l)vage(d) MX card.
it works only in vesa mode, or with dri disabled.
i am trying latest Xorg and mesa avail from gentoo
From ae937bceef62997a63140abb5208d33f3b6ac13c Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Mon, 8 Mar 2010 17:10:41 -0500
Subject: [PATCH] drm/radeon/kms: further spread spectrum fixes
Adjust modeset ordering to fix spread spectrum.
The spread spectrum command table
From eff99b0788d4a2fd6cd4adaa7b10ccb9b201b2d3 Mon Sep 17 00:00:00 2001
From: David Heidelberger d.ok...@gmail.com
Date: Tue, 9 Mar 2010 13:50:27 +0100
Subject: [PATCH] nv30: fix typo
Signed-off-by: David Heidelberger d.ok...@gmail.com
---
src/gallium/drivers/nv30/nv30_miptree.c |2 +-
1
http://bugs.freedesktop.org/show_bug.cgi?id=25741
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://bugs.freedesktop.org/show_bug.cgi?id=26496
--- Comment #12 from Michel Dänzer mic...@daenzer.net 2010-03-09 07:01:40
PST ---
(In reply to comment #11)
Failed to free bo[(address)] at 8000
ret = Operation not permitted
I'm not sure if it's related, but I figured it was worth
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #14 from Alex Deucher ag...@yahoo.com 2010-03-09 07:11:22 PST ---
(In reply to comment #13)
A funny (maybe significant?) detail:
ut2003 works in 1024x768 mode - my guess is that it's not using xrandr to
switch the res but the
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback, allowing to do asic specific test for
lockup detection. In
This simplify and improve GPU reset for R1XX-R6XX hw, it's
not 100% reliable here are result:
- R1XX/R2XX works bunch of time in a row, sometimes it
seems it can work indifinitly
- R3XX/R3XX the most unreliable one, sometimes you will be
able to reset few times, sometimes not even once
- R5XX
Patch rename gpu_reset to asic_reset in prevision of having
gpu_reset doing more stuff than just basic asic reset.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/r100.c |6 ++--
This serie of patch fix the shortcoming of the previous one, their
shouldn't be any more false positive and resume should lead to
infinite look or other reinitialization issue on r6xx/r7xx.
Cheers,
Jerome
--
Download
http://bugs.freedesktop.org/show_bug.cgi?id=24973
--- Comment #9 from Daniel di...@betriebsdirektor.de 2010-03-09 07:48:38 PST
---
(In reply to comment #8)
Daniel, your reply is confusing, since it seems to still /be/ an issue with
2.6.33. Have you tried that kernel before switching to
http://bugs.freedesktop.org/show_bug.cgi?id=26496
--- Comment #10 from Michel Dänzer mic...@daenzer.net 2010-03-09 03:37:06
PST ---
(In reply to comment #9)
If you'd still like my Xorg log, please let me know.
Yes please.
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=26496
--- Comment #11 from Joseph Jezak jos...@gentoo.org 2010-03-09 04:40:18 PST
---
Created an attachment (id=33889)
-- (http://bugs.freedesktop.org/attachment.cgi?id=33889)
X log, after startup and some usage including sleep/wake
I'm also
2010/3/9 Rafael J. Wysocki r...@sisk.pl:
On Tuesday 09 March 2010, Luca Tettamanti wrote:
I'm note sure how to check that a device is graphic card though :|
Well, that's the outside of the graphics driver part of my question. :-)
Can we use the same way userspace (DDX) uses to check for KMS?
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #13 from Tobias Jakobi liquid.a...@gmx.net 2010-03-09 07:04:34
PST ---
A funny (maybe significant?) detail:
ut2003 works in 1024x768 mode - my guess is that it's not using xrandr to
switch the res but the old method, I think it
http://bugs.freedesktop.org/show_bug.cgi?id=24973
--- Comment #7 from Daniel di...@betriebsdirektor.de 2010-03-09 06:49:10 PST
---
(In reply to comment #4)
Is this still an issue with 2.6.33 or drm-next?
Nope. For me the TV-out/xrandr issue seems to be fixed. By now I am using
2.6-master,
i've tried to run this old X server with new (2.6.32) kernel
here is log from startup :
http://83.18.229.190/Xorg/Xorg.0.log.old_X_new_kernel
what is stunning - DRI works , and i get stunning 360fps
with gears turning _smoothly_ in glxgears.
downsides - switching to VT doesn't work.
Second, in the KMS case, we'd be able to skip the kernel VT switch,
because
the KMS driver uses its own framebuffer anyway.
So, is there any reasonable way to check that from the outside of the
graphics
driver? It should be general enough to cover the cases when there are
On Tue, 9 Mar 2010, James Simmons wrote:
i've tried to run this old X server with new (2.6.32) kernel
here is log from startup :
http://83.18.229.190/Xorg/Xorg.0.log.old_X_new_kernel
what is stunning - DRI works , and i get stunning 360fps
with gears turning _smoothly_ in glxgears.
http://bugs.freedesktop.org/show_bug.cgi?id=24973
--- Comment #10 from Marius Groeger marius.groe...@web.de 2010-03-09
09:12:41 PST ---
Thanks for clearing this up, Daniel. Seems I have to take it from here on my
own, as the issue is definitely present with 2.6.33 on my r300 (Thinkpad T43).
On Tue, 9 Mar 2010, Piotr Gluszenia Slawinski wrote:
On Tue, 9 Mar 2010, James Simmons wrote:
i've tried to run this old X server with new (2.6.32) kernel
here is log from startup :
http://83.18.229.190/Xorg/Xorg.0.log.old_X_new_kernel
what is stunning - DRI works , and i get stunning
http://bugs.freedesktop.org/show_bug.cgi?id=26816
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://bugs.freedesktop.org/show_bug.cgi?id=26641
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
CC|
On Tuesday 09 March 2010, James Simmons wrote:
Second, in the KMS case, we'd be able to skip the kernel VT switch,
because
the KMS driver uses its own framebuffer anyway.
So, is there any reasonable way to check that from the outside of the
graphics
driver? It
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #15 from Tobias Jakobi liquid.a...@gmx.net 2010-03-09 14:35:28
PST ---
Yeah, you're right - it picks the 60Hz. Looks like I have to manually edit the
INI to let it choose the 85Hz mode.
--
Configure bugmail:
http://bugzilla.kernel.org/show_bug.cgi?id=15181
Matteo rootki...@yahoo.it changed:
What|Removed |Added
Kernel Version|2.6.33-rc6 |2.6.34-rc1
--
Configure
http://bugzilla.kernel.org/show_bug.cgi?id=15181
Alex Deucher alexdeuc...@gmail.com changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_acpi.c |5 ++---
drivers/gpu/drm/nouveau/nouveau_bios.c | 28 +---
drivers/gpu/drm/nouveau/nouveau_gem.c |2 +-
drivers/gpu/drm/nouveau/nouveau_grctx.h | 10 +-
drivers/gpu/drm/nouveau/nouveau_hw.h|2 +-
On Tue, Mar 09, 2010 at 10:08:28PM +0100, Rafael J. Wysocki wrote:
On Tuesday 09 March 2010, James Simmons wrote:
Second, in the KMS case, we'd be able to skip the kernel VT switch,
because
the KMS driver uses its own framebuffer anyway.
So, is there any reasonable
34 matches
Mail list logo
