---
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 +-
dr
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,
http://bugzilla.kernel.org/show_bug.cgi?id=15181
Alex Deucher changed:
What|Removed |Added
CC||[email protected]
--- Comment #1 fr
http://bugzilla.kernel.org/show_bug.cgi?id=15181
Matteo changed:
What|Removed |Added
Kernel Version|2.6.33-rc6 |2.6.34-rc1
--
Configure bugmail: http://bugz
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #15 from Tobias Jakobi 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://bugs.freedesktop.org/userprefs.
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
> > > > graph
http://bugs.freedesktop.org/show_bug.cgi?id=26641
Alex Deucher changed:
What|Removed |Added
CC||[email protected]
http://bugs.freedesktop.org/show_bug.cgi?id=26816
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 wo
http://bugs.freedesktop.org/show_bug.cgi?id=24973
--- Comment #10 from Marius Groeger 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).
--
Configure bugma
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_ i
> > > 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 c
> 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 does
http://bugs.freedesktop.org/show_bug.cgi?id=24973
--- Comment #7 from Daniel 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, mesa-master, radeon-maste
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #13 from Tobias Jakobi 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 was via XVidMode
--
http://bugs.freedesktop.org/show_bug.cgi?id=24973
--- Comment #9 from Daniel 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 2.6-master?
I did not try
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 Int
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
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/r100.c |6 ++--
drivers/gpu/drm/radeon/r300.c |6
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 m
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 th
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #14 from Alex Deucher 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 old method, I
http://bugs.freedesktop.org/show_bug.cgi?id=26496
--- Comment #12 from Michel Dänzer 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 mentioning sinc
http://bugs.freedesktop.org/show_bug.cgi?id=25741
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
>From eff99b0788d4a2fd6cd4adaa7b10ccb9b201b2d3 Mon Sep 17 00:00:00 2001
From: David Heidelberger
Date: Tue, 9 Mar 2010 13:50:27 +0100
Subject: [PATCH] nv30: fix typo
Signed-off-by: David Heidelberger
---
src/gallium/drivers/nv30/nv30_miptree.c |2 +-
1 files changed, 1 insertions(+), 1 del
http://bugs.freedesktop.org/show_bug.cgi?id=26496
--- Comment #11 from Joseph Jezak 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 seeing messages like
2010/3/9 Rafael J. Wysocki :
> 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? Some
I
http://bugs.freedesktop.org/show_bug.cgi?id=26496
--- Comment #10 from Michel Dänzer 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/userprefs.cgi?tab=email
---
>From ae937bceef62997a63140abb5208d33f3b6ac13c Mon Sep 17 00:00:00 2001
From: Alex Deucher
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 relies on the
crtc routi
On Sat, Mar 6, 2010 at 10:36 PM, Rafael J. Wysocki 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(), because
2010/3/8 Rafał Miłecki :
> 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.
>
> Signed-off-by: Rafał Mił
--
On Mon, 8 Mar 2010, Alex Deucher wrote:
> On Mon, Mar 8, 2010 at 12:42 PM, Piotr Gluszenia Slawinski
> 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 ebuilds.
>>
>> also Xv do
http://bugs.freedesktop.org/show_bug.cgi?id=24973
--- Comment #8 from Marius Groeger 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, radeon-master and libdr
http://bugs.freedesktop.org/show_bug.cgi?id=26954
--- Comment #1 from Fabio Pedretti 2010-03-09 03:18:36
PST ---
Created an attachment (id=33888)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33888)
sauerbraten backtrace
Note that shaders have to be enabled in the game to get the ass
On Tuesday 09 March 2010, Luca Tettamanti wrote:
> On Sat, Mar 6, 2010 at 10:36 PM, Rafael J. Wysocki 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=25741
--- Comment #23 from Luca Tettamanti 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 should do the
35 matches
Mail list logo
