On 03/12/2011 04:59 PM, Rob Clark wrote:
On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter wrote:
On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
This doesn't seem that different from the graphics chips we support
with kms. I don't think it would require much work to use K
https://bugzilla.kernel.org/show_bug.cgi?id=30472
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 f
https://bugzilla.kernel.org/show_bug.cgi?id=30472
--- Comment #2 from Alex Deucher 2011-03-14 17:50:32
---
Dave has sent Linus the pull request for that patch set.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
From: Matthew Garrett
The Integrated Graphics Device opregion specification defines a mechanism
for the OS and system firmware to collaborate on various graphics-related
functionality. This is currently implemented in the i915 driver but isn't
strictly limited to these devices. Move it to a more
https://bugzilla.kernel.org/show_bug.cgi?id=30472
--- Comment #3 from Martin Steigerwald 2011-03-14
18:12:34 ---
Thanks a lot. I will try with a recent git pull from Linus mainline tree once
its in there.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Yo
https://bugs.freedesktop.org/show_bug.cgi?id=35312
Summary: r600g: Automatic mipmap generation doesn't work
properly
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
On Mon, Mar 14, 2011 at 9:03 AM, Marcus Lorentzon
wrote:
> On 03/12/2011 04:59 PM, Rob Clark wrote:
>>
>> On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter wrote:
>>
>>>
>>> On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
>>>
This doesn't seem that different from the graphics
On 03/13/11 18:15, Arthur Titeica wrote:
> On Sun, 13 Mar 2011 15:08:03 +0100, Anders Eriksson wrote:
>>
>> I've uploaded a video of a 38-rc8 boot:
>> http://www.easy-share.com/1914220540/2.6.38-rc8_bad_x.mp4
>>
> Here's a link to a speedier server:
> http://www.psw.ro/tmp/radeon/2.6.38-rc8_bad_x.
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #5 from Ian Romanick 2011-03-14 14:08:08 PDT
---
(In reply to comment #4)
> Like Marek said, this isn't a bug it is a hardware limitation. The only way
> this could work is with changes to Gnome Shell, so you should contact the
> G
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #6 from Ionut Biru 2011-03-14 14:14:05 PDT
---
@Ian (In reply to comment #5)
> (In reply to comment #4)
> > Like Marek said, this isn't a bug it is a hardware limitation. The only way
> > this could work is with changes to Gnome She
On Mon, Mar 14, 2011 at 6:20 PM, Alex Deucher wrote:
> On Sun, Mar 13, 2011 at 10:08 AM, Anders Eriksson
> wrote:
>> Hi,
>>
>> I've found what I guess is a radeon (or drm/kms) regression post 2.6.35.
>> I've got my TV conneced to my RS690G over HDMI, and the display has
>> always been jittery a
On Sun, Mar 13, 2011 at 10:08 AM, Anders Eriksson wrote:
> Hi,
>
> I've found what I guess is a radeon (or drm/kms) regression post 2.6.35.
> I've got my TV conneced to my RS690G over HDMI, and the display has
> always been jittery after POST and at the GRUB screen. Pre-KMS, the X
> server (or dr
https://bugzilla.kernel.org/show_bug.cgi?id=30472
Dave Airlie changed:
What|Removed |Added
CC||airl...@linux.ie
--- Comment #4 from Da
https://bugzilla.kernel.org/show_bug.cgi?id=30472
Martin Steigerwald changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #7 from Tom Stellard 2011-03-14 17:28:24 PDT
---
(In reply to comment #5)
> (In reply to comment #4)
> > Like Marek said, this isn't a bug it is a hardware limitation. The only way
> > this could work is with changes to Gnome Shell,
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #8 from Tom Stellard 2011-03-14 17:29:19 PDT
---
Created an attachment (id=44454)
--> (https://bugs.freedesktop.org/attachment.cgi?id=44454)
The shader in question before and after our suggestions
--
Configure bugmail: https://bug
Hello,
Some nitpicks below.
On Mon, March 14, 2011 18:59, Chris Wilson wrote:
> From: Matthew Garrett
>
> The Integrated Graphics Device opregion specification defines a mechanism
> for the OS and system firmware to collaborate on various graphics-related
> functionality. This is currently imple
On Tue, Mar 15, 2011 at 02:18:02AM +0100, Indan Zupancic wrote:
> > +
> > + if (dev->set_backlight)
> > + dev->set_backlight(dev->drm_dev, bclp * max / 255);
>
> I would hide the max backlight from the opregion code and move this
> calculation into set_brightness. Then change the inter
Typo in the aspect scale setup.
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 1d89259.
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #9 from Matt Turner 2011-03-14 21:26:25 PDT ---
(In reply to comment #7)
> We were able to give some suggestions to the gnome shell developers to get the
> shader to fit. The optimization that is missing is pre-computing of
> equiva
-glut
--disable-glw --enable-glx-tls --enable-debug
I am here on linux-next (next-20110314) and xserver-1.10-rc3.
- Sedat -
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> This can spuriously limit the BO to active_vram_size in GTT again.
>
> On second thought, I don't understand why this would be necessary /
> helpful at all. If active_vram_size is the maximum amount of VRAM that
> should ever be used anywhere (as opposed to the maximum amount visible
> to the CP
From: Dave Airlie
So we used to use lpfn directly to restrict VRAM when we couldn't
access the unmappable area, however this was removed in
93225b0d7bc030f4a93165347a65893685822d70 as it also restricted
the gtt placements. However it was only later noticed that this
broke on some hw.
This remove
From: Dave Airlie
So we used to use lpfn directly to restrict VRAM when we couldn't
access the unmappable area, however this was removed in
93225b0d7bc030f4a93165347a65893685822d70 as it also restricted
the gtt placements. However it was only later noticed that this
broke on some hw.
This remove
Okay another radeon regression showed up in the late stages, and I've
pushed a fix for a 3rd problem, again reported on fusion systems which
currently none of the devs have access to.
This is on top of the last req, which contains the other fusion fix and
the complete system hang fixes.
Dave.
On 03/12/2011 04:59 PM, Rob Clark wrote:
> On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter wrote:
>
>> On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
>>
>>> This doesn't seem that different from the graphics chips we support
>>> with kms. I don't think it would require much
https://bugzilla.kernel.org/show_bug.cgi?id=30472
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
https://bugzilla.kernel.org/show_bug.cgi?id=30472
--- Comment #2 from Alex Deucher 2011-03-14
17:50:32 ---
Dave has sent Linus the pull request for that patch set.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
From: Matthew Garrett
The Integrated Graphics Device opregion specification defines a mechanism
for the OS and system firmware to collaborate on various graphics-related
functionality. This is currently implemented in the i915 driver but isn't
strictly limited to these devices. Move it to a more
https://bugzilla.kernel.org/show_bug.cgi?id=30472
--- Comment #3 from Martin Steigerwald 2011-03-14
18:12:34 ---
Thanks a lot. I will try with a recent git pull from Linus mainline tree once
its in there.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Yo
n x86_64
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: dmesg.txt
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110314/6002ad18/attachment-0001.txt>
-- next part --
A non-text attachment was scrubbed..
https://bugs.freedesktop.org/show_bug.cgi?id=35312
Summary: r600g: Automatic mipmap generation doesn't work
properly
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
On Mon, Mar 14, 2011 at 9:03 AM, Marcus Lorentzon
wrote:
> On 03/12/2011 04:59 PM, Rob Clark wrote:
>>
>> On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter ?wrote:
>>
>>>
>>> On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
>>>
This doesn't seem that different from the graphics
On 03/13/11 18:15, Arthur Titeica wrote:
> On Sun, 13 Mar 2011 15:08:03 +0100, Anders Eriksson wrote:
>>
>> I've uploaded a video of a 38-rc8 boot:
>> http://www.easy-share.com/1914220540/2.6.38-rc8_bad_x.mp4
>>
> Here's a link to a speedier server:
> http://www.psw.ro/tmp/radeon/2.6.38-rc8_bad_x.
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #5 from Ian Romanick 2011-03-14 14:08:08
PDT ---
(In reply to comment #4)
> Like Marek said, this isn't a bug it is a hardware limitation. The only way
> this could work is with changes to Gnome Shell, so you should contact the
> G
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #6 from Ionut Biru 2011-03-14 14:14:05
PDT ---
@Ian (In reply to comment #5)
> (In reply to comment #4)
> > Like Marek said, this isn't a bug it is a hardware limitation. The only way
> > this could work is with changes to Gnome She
On Mon, Mar 14, 2011 at 6:20 PM, Alex Deucher wrote:
> On Sun, Mar 13, 2011 at 10:08 AM, Anders Eriksson
> wrote:
>> ?Hi,
>>
>> I've found what I guess is a radeon (or drm/kms) regression post 2.6.35.
>> I've got my TV conneced to my RS690G over HDMI, and the display has
>> always been jittery a
On Sun, Mar 13, 2011 at 10:08 AM, Anders Eriksson
wrote:
> ?Hi,
>
> I've found what I guess is a radeon (or drm/kms) regression post 2.6.35.
> I've got my TV conneced to my RS690G over HDMI, and the display has
> always been jittery after POST and at the GRUB screen. Pre-KMS, the X
> server (or d
https://bugzilla.kernel.org/show_bug.cgi?id=30472
Dave Airlie changed:
What|Removed |Added
CC||airlied at linux.ie
--- Comment #4 from
https://bugzilla.kernel.org/show_bug.cgi?id=30472
Martin Steigerwald changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #7 from Tom Stellard 2011-03-14 17:28:24
PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > Like Marek said, this isn't a bug it is a hardware limitation. The only way
> > this could work is with changes to Gnome Shell,
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #8 from Tom Stellard 2011-03-14 17:29:19
PDT ---
Created an attachment (id=44454)
--> (https://bugs.freedesktop.org/attachment.cgi?id=44454)
The shader in question before and after our suggestions
--
Configure bugmail: https://bug
Typo in the aspect scale setup.
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 1d892
https://bugs.freedesktop.org/show_bug.cgi?id=35257
--- Comment #9 from Matt Turner 2011-03-14 21:26:25 PDT
---
(In reply to comment #7)
> We were able to give some suggestions to the gnome shell developers to get the
> shader to fit. The optimization that is missing is pre-computing of
> equiv
44 matches
Mail list logo
