* Alexandre Demers wrote:
> On 11-04-15 10:27 AM, Joerg Roedel wrote:
> > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
> >> Ok, I'll test it today. Should I apply it on a clean rc3 without any of
> >> the other patches?
> > Yes, apply it just on -rc3 without any other
of the patch would be greatly appreciated.
Regards,
Cedric
-- next part --
A non-text attachment was scrubbed...
Name: rv730_gallium_be_support.patch
Type: text/x-patch
Size: 14868 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
> Ok, but how did the allocation changes start triggering this error in
> v2.6.39-rc1? There must still be some layout specific thing here, right?
> Do we understand the details of that as well?
Well, thinking again about this, the GPU
On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote:
> On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel wrote:
> > On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
> >> On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote:
> >> > And this makes a difference, with this change
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
> Ok, but how did the allocation changes start triggering this error in
> v2.6.39-rc1? There must still be some layout specific thing here, right?
> Do we understand the details of that as well?
No, I must admit that I lack enough
On Fri, Apr 15, 2011 at 04:04:45PM +0200, Andreas Herrmann wrote:
> What about tagging this patch for stable/longterm releases?
>
> Potentially there are other cases where certain combinations of
> hardware(GPUs)/drivers/whatsoever might trigger a GartTlbWlkErr. If
> the BIOS doesn't follow the
On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
> Ok, I'll test it today. Should I apply it on a clean rc3 without any of
> the other patches?
Yes, apply it just on -rc3 without any other patch.
>
> BTW, may I suggest adding the info under bug 33012 in kernel bugzilla?
> This
On Fri, Apr 15, 2011 at 03:11:52PM +0200, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
> > we definitely want to also understand the reason for things not
> > working, even if we do revert..
>
> Okay, here it is.
>
> After experimenting with different
On 4/15/11 3:19 PM, Jesse Barnes wrote:
> Or is there a CEA block extension that allows for more granularity?
CEA has bits for the two YCbCr formats too, which we should also parse
since there's plenty of 1.3+CEA blocks in the world thanks to HDMI. For
CEA blocks version 2 and up (version
* Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
> > we definitely want to also understand the reason for things not
> > working, even if we do revert..
>
> Okay, here it is.
>
> After experimenting with different configurations for the north-bridge
>
On 4/15/11 2:40 PM, Jesse Barnes wrote:
> @@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid,
> info->bpp = 0;
> break;
> }
> +
> + if (edid->features & DRM_EDID_FEATURE_RGB)
> + info->color_formats =
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
> we definitely want to also understand the reason for things not
> working, even if we do revert..
Okay, here it is.
After experimenting with different configurations for the north-bridge
it turned out that a GART related MCE
On 11-04-15 10:27 AM, Joerg Roedel wrote:
> On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
>> Ok, I'll test it today. Should I apply it on a clean rc3 without any of
>> the other patches?
> Yes, apply it just on -rc3 without any other patch.
>
>> BTW, may I suggest adding the
This patch disables GartTlbWlk errors on AMD Fam10h CPUs if
the BIOS forgets to do is (or is just too old). Letting
these errors enabled can cause a sync-flood on the CPU
causing a reboot.
This patch is the fix for
https://bugzilla.kernel.org/show_bug.cgi?id=33012
on my machine.
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c |6 ++
include/drm/drm_crtc.h |5
On Sat, 16 Apr 2011 06:42:44 +1000
Dave Airlie wrote:
> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes
> wrote:
> > On Sat, 16 Apr 2011 06:10:07 +1000
> > Dave Airlie wrote:
> >
> >> > -
> >> > +#define DRM_COLOR_FORMAT_RGB444 ? ? ? ? ? ? ? ?(1<<0)
> >> > +#define DRM_COLOR_FORMAT_YCRCB444 ? ?
On Sat, 16 Apr 2011 06:10:07 +1000
Dave Airlie wrote:
> > -
> > +#define DRM_COLOR_FORMAT_RGB444 ? ? ? ? ? ? ? ?(1<<0)
> > +#define DRM_COLOR_FORMAT_YCRCB444 ? ? ?(1<<1)
> > +#define DRM_COLOR_FORMAT_YCRCB422 ? ? ?(1<<2)
> > ?/*
> > ?* Describes a given display (e.g. CRT or flat panel) and its
https://bugs.freedesktop.org/show_bug.cgi?id=35367
--- Comment #2 from Marek Ol??k 2011-04-15 13:27:28 PDT
---
(In reply to comment #1)
> (In reply to comment #0)
> > rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box.
> > kernel d-r-t, git ddx with tiling enabled in
On 04/15/2011 12:18 PM, Yinghai Lu wrote:
> On 04/15/2011 12:06 PM, Ingo Molnar wrote:
>
>>
>> Joerg, mind submitting it with a changelog that includes everything we
>> learned
>> about this bug and all the Tested-by's in place?
>>
>> Is anyone of the opinion that we should try to revert the
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c |6 ++
include/drm/drm_crtc.h |5
On Fri, 15 Apr 2011 15:36:22 -0400
Adam Jackson wrote:
> On 4/15/11 3:19 PM, Jesse Barnes wrote:
>
> > Or is there a CEA block extension that allows for more granularity?
>
> CEA has bits for the two YCbCr formats too, which we should also parse
> since there's plenty of 1.3+CEA blocks in the
On Fri, 15 Apr 2011 12:19:31 -0700
Jesse Barnes wrote:
> On Fri, 15 Apr 2011 15:13:02 -0400
> Adam Jackson wrote:
> > info->color_formats = DRM_COLOR_FORMAT_RGB444;
> > if (edid->features & DRM_EDID_FEATURE_YCRCB444)
> > info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
> >
On Fri, 15 Apr 2011 14:29:50 -0400
Adam Jackson wrote:
> On 4/15/11 2:22 PM, Jesse Barnes wrote:
> > EDID 1.4 digital monitors report the bit depth supported in the input
> > field. Add support for parsing this out and storing the info in the
> > display_info structure for use by drivers.
> >
>
On Fri, 15 Apr 2011 15:13:02 -0400
Adam Jackson wrote:
> On 4/15/11 2:40 PM, Jesse Barnes wrote:
>
> > @@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid,
> > info->bpp = 0;
> > break;
> > }
> > +
> > + if (edid->features &
On 04/15/2011 12:06 PM, Ingo Molnar wrote:
>
> Joerg, mind submitting it with a changelog that includes everything we
> learned
> about this bug and all the Tested-by's in place?
>
> Is anyone of the opinion that we should try to revert the allocation
> order/alignment changes in addition to
On Fri, Apr 15, 2011 at 11:46 AM, Joerg Roedel wrote:
> On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
>> Ok, but how did the allocation changes start triggering this error in
>> v2.6.39-rc1? There must still be some layout specific thing here, right?
>> Do we understand the details
On Fri, Apr 15, 2011 at 10:33 AM, Joerg Roedel wrote:
> On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
>> Ok, but how did the allocation changes start triggering this error in
>> v2.6.39-rc1? There must still be some layout specific thing here, right?
>> Do we understand the details
https://bugs.freedesktop.org/show_bug.cgi?id=36270
Summary: [r300g] Light sources are checkered in Unigine
Sanctuary when HDR is used
Product: Mesa
Version: git
Platform: x86 (IA32)
URL:
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c | 10 ++
include/drm/drm_crtc.h |6
https://bugs.freedesktop.org/show_bug.cgi?id=36268
Summary: [r300g, bisected] minor flickering in Unigine
Sanctuary
Product: Mesa
Version: git
Platform: Other
URL: http://unigine.com/download/#sanctuary
Hi Alex,
On Thu, 14 Apr 2011 19:47:06 -0400, Alex Deucher wrote:
> Apparently some distros set i2c-algo-bit.bit_test to 1 by
> default. In some cases this causes i2c_bit_add_bus
> to fail and prevents the i2c bus from being added. In the
> radeon case, we fail to add the ddc i2c buses which
On Fri, Apr 15, 2011 at 10:26:34AM +0200, Michel D?nzer wrote:
> On Don, 2011-04-14 at 23:09 +0200, Joerg Roedel wrote:
> > On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
> > > On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote:
> > > > And this makes a difference, with this
On Don, 2011-04-14 at 23:09 +0200, Joerg Roedel wrote:
> On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
> > On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote:
> > > And this makes a difference, with this change on-top of -rc3 the box boots
> > > fine. So there seems to be some
https://bugzilla.kernel.org/show_bug.cgi?id=32982
Bart Van Assche changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Block Layer
On 11-04-15 09:11 AM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
>> we definitely want to also understand the reason for things not
>> working, even if we do revert..
> Okay, here it is.
>
> After experimenting with different configurations for the
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #14 from Christoph Bumiller
2011-04-15 09:34:15 PDT ---
Interesting, I have this with llvmpipe too, but it looks correct with nvc0, so
I'd look for a driver specific issue.
--
Configure bugmail:
On 04/14/2011 12:42 PM, Jesse Barnes wrote:
> We've already seen that apps want to monitor the display config, and
> some (like upowerd) poll for changes since we don't provide a
> notification for general mode config changes, just hotplug events. So
> add a new drm event, with CHANGE=1 set in
On Fri, 15 Apr 2011 09:23:38 -0500
Chris Bandy wrote:
> On 04/14/2011 12:42 PM, Jesse Barnes wrote:
> > /**
> > + * drm_sysfs_change_event - generate a DRM uevent indicating a display
> > config change
> > + * @dev: DRM device
> > + *
> > + * Send a uevent for the DRM device specified by @dev.
On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote:
> On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel wrote:
> > Actually, the nb gart is part of the cpu. It is part of the cpu north
> > bridge and can translate io and cpu accesses. In fact, it is a remapper
> > of physical memory
On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote:
> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote:
> > Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm"
> > to everyone, but then chose to CC Maciej instead: Would you be so kind and
> > add this
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #13 from Fryderyk Dziarmagowski
2011-04-15 07:06:58 PDT ---
I got exactly same problem on Intel G45/G43 (Mesa HEAD) like on the screenshot
from #7 (using beta version)
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #12 from Krzysztof A. Sobiecki 2011-04-15
06:35:39 PDT ---
Created an attachment (id=45667)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45667)
RADEON_DEBUG=vp,tex without mesa patch
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #11 from Krzysztof A. Sobiecki 2011-04-15
06:19:41 PDT ---
Created an attachment (id=45666)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45666)
RADEON_DEBUG=vp and patch on r300g
I will post also log without patched mesa.
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #10 from Sven Arvidsson 2011-04-15 05:57:58 PDT ---
Created an attachment (id=45665)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45665)
r300g with patch
I have added logs from my system, both from the debug build of Trine
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #9 from Sven Arvidsson 2011-04-15 05:56:05 PDT ---
Created an attachment (id=45664)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45664)
Trine debug log
--
Configure bugmail:
logout is being done with libICE. I know it is not being done with Hal,
Consolekit or the XKillClient Xlib function. I will update this bug report as
soon as I know which function causes this and have a testcase ready. If you
think it will lead to a fix I would be willing to use a pencil and paper
https://bugs.freedesktop.org/show_bug.cgi?id=35367
--- Comment #1 from Andy Furniss 2011-04-15
04:43:15 PDT ---
(In reply to comment #0)
> rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box.
> kernel d-r-t, git ddx with tiling enabled in xorg.conf.
> Does not affect my PCIE
https://bugs.freedesktop.org/show_bug.cgi?id=35312
--- Comment #3 from Andy Furniss 2011-04-15
04:30:30 PDT ---
(In reply to comment #1)
> Created an attachment (id=45598)
View: https://bugs.freedesktop.org/attachment.cgi?id=45598
Review: https://bugs.freedesktop.org/review?bug=35312=45598
>
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #8 from Turo Lamminen 2011-04-15
03:37:30 PDT ---
(In reply to comment #5)
> Created an attachment (id=45654)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45654)
> Log from beta game on r300g
Get the mesa log too so we can
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #7 from Krzysztof A. Sobiecki 2011-04-15
03:29:51 PDT ---
Created an attachment (id=45659)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45659)
Screenshot from beta game on r300g
Game looks very similar on llvmpipe and
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #6 from Krzysztof A. Sobiecki 2011-04-15
03:26:49 PDT ---
Created an attachment (id=45657)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45657)
Log from beta game on llvmpipe
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #5 from Krzysztof A. Sobiecki 2011-04-15
03:24:05 PDT ---
Created an attachment (id=45654)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45654)
Log from beta game on r300g
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=35312
--- Comment #2 from Gustaw Smolarczyk 2011-04-15
00:40:53 PDT ---
Indeed it helps. Piglit test fbo-generatemipmap-formats is still failing, but
may be unrelated problem. Basic functionality now works properly.
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=36256
Summary: Return to tty after leaving X problematic if using
multiple cards since 2.6.32
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
> On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote:
> > And this makes a difference, with this change on-top of -rc3 the box boots
> > fine. So there seems to be some dependency between the GART base and the GTT
> > base even when
On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote:
On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote:
Thought about CCing Linus to show him that 2.6.39-rcX isn't as calm
to everyone, but then chose to CC Maciej instead: Would you be so kind and
add this to your
On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel j...@8bytes.org wrote:
Actually, the nb gart is part of the cpu. It is part of the cpu north
bridge and can translate io and cpu accesses. In fact, it is a remapper
of physical
https://bugs.freedesktop.org/show_bug.cgi?id=36256
Summary: Return to tty after leaving X problematic if using
multiple cards since 2.6.32
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=35312
--- Comment #2 from Gustaw Smolarczyk wielkie...@gmail.com 2011-04-15
00:40:53 PDT ---
Indeed it helps. Piglit test fbo-generatemipmap-formats is still failing, but
may be unrelated problem. Basic functionality now works properly.
--
Configure
On Don, 2011-04-14 at 23:09 +0200, Joerg Roedel wrote:
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
And this makes a difference, with this change on-top of -rc3 the box boots
fine. So there seems to be
On Fri, Apr 15, 2011 at 10:26:34AM +0200, Michel Dänzer wrote:
On Don, 2011-04-14 at 23:09 +0200, Joerg Roedel wrote:
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
And this makes a difference, with this
Hi Alex,
On Thu, 14 Apr 2011 19:47:06 -0400, Alex Deucher wrote:
Apparently some distros set i2c-algo-bit.bit_test to 1 by
default. In some cases this causes i2c_bit_add_bus
to fail and prevents the i2c bus from being added. In the
radeon case, we fail to add the ddc i2c buses which
https://bugzilla.kernel.org/show_bug.cgi?id=32982
Bart Van Assche bart.vanass...@gmail.com changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Block Layer
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #5 from Krzysztof A. Sobiecki sob...@gmail.com 2011-04-15
03:24:05 PDT ---
Created an attachment (id=45654)
-- (https://bugs.freedesktop.org/attachment.cgi?id=45654)
Log from beta game on r300g
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #6 from Krzysztof A. Sobiecki sob...@gmail.com 2011-04-15
03:26:49 PDT ---
Created an attachment (id=45657)
-- (https://bugs.freedesktop.org/attachment.cgi?id=45657)
Log from beta game on llvmpipe
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #7 from Krzysztof A. Sobiecki sob...@gmail.com 2011-04-15
03:29:51 PDT ---
Created an attachment (id=45659)
-- (https://bugs.freedesktop.org/attachment.cgi?id=45659)
Screenshot from beta game on r300g
Game looks very similar on
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #8 from Turo Lamminen t...@alternativegames.net 2011-04-15
03:37:30 PDT ---
(In reply to comment #5)
Created an attachment (id=45654)
-- (https://bugs.freedesktop.org/attachment.cgi?id=45654)
Log from beta game on r300g
Get the
https://bugs.freedesktop.org/show_bug.cgi?id=35312
--- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com 2011-04-15
04:30:30 PDT ---
(In reply to comment #1)
Created an attachment (id=45598)
View: https://bugs.freedesktop.org/attachment.cgi?id=45598
Review:
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #9 from Sven Arvidsson s...@whiz.se 2011-04-15 05:56:05 PDT ---
Created an attachment (id=45664)
-- (https://bugs.freedesktop.org/attachment.cgi?id=45664)
Trine debug log
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #10 from Sven Arvidsson s...@whiz.se 2011-04-15 05:57:58 PDT ---
Created an attachment (id=45665)
-- (https://bugs.freedesktop.org/attachment.cgi?id=45665)
r300g with patch
I have added logs from my system, both from the debug build
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
we definitely want to also understand the reason for things not
working, even if we do revert..
Okay, here it is.
After experimenting with different configurations for the north-bridge
it turned out that a GART related MCE fires
* Joerg Roedel j...@8bytes.org wrote:
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
we definitely want to also understand the reason for things not
working, even if we do revert..
Okay, here it is.
After experimenting with different configurations for the
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #11 from Krzysztof A. Sobiecki sob...@gmail.com 2011-04-15
06:19:41 PDT ---
Created an attachment (id=45666)
-- (https://bugs.freedesktop.org/attachment.cgi?id=45666)
RADEON_DEBUG=vp and patch on r300g
I will post also log without
On Fri, Apr 15, 2011 at 04:04:45PM +0200, Andreas Herrmann wrote:
What about tagging this patch for stable/longterm releases?
Potentially there are other cases where certain combinations of
hardware(GPUs)/drivers/whatsoever might trigger a GartTlbWlkErr. If
the BIOS doesn't follow the BKDG
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
Ok, but how did the allocation changes start triggering this error in
v2.6.39-rc1? There must still be some layout specific thing here, right?
Do we understand the details of that as well?
Well, thinking again about this, the GPU
On Fri, Apr 15, 2011 at 10:33 AM, Joerg Roedel j...@8bytes.org wrote:
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
Ok, but how did the allocation changes start triggering this error in
v2.6.39-rc1? There must still be some layout specific thing here, right?
Do we understand the
On Fri, Apr 15, 2011 at 11:46 AM, Joerg Roedel j...@8bytes.org wrote:
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
Ok, but how did the allocation changes start triggering this error in
v2.6.39-rc1? There must still be some layout specific thing here, right?
Do we understand the
On Fri, Apr 15, 2011 at 03:11:52PM +0200, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
we definitely want to also understand the reason for things not
working, even if we do revert..
Okay, here it is.
After experimenting with different
On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel j...@8bytes.org wrote:
On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel j...@8bytes.org wrote:
And this makes a difference,
https://bugs.freedesktop.org/show_bug.cgi?id=36236
--- Comment #14 from Christoph Bumiller e0425...@student.tuwien.ac.at
2011-04-15 09:34:15 PDT ---
Interesting, I have this with llvmpipe too, but it looks correct with nvc0, so
I'd look for a driver specific issue.
--
Configure bugmail:
Hi
Here you are a patch that adds big endian support for rv730 in r600
gallium driver.
I used the mesa-demos to test the driver status on big endian platform.
Except with demos using accumulation buffer, the rendering is the same
as on Intel platform. Albeit there are still some artefacts
https://bugs.freedesktop.org/show_bug.cgi?id=36268
Summary: [r300g, bisected] minor flickering in Unigine
Sanctuary
Product: Mesa
Version: git
Platform: Other
URL: http://unigine.com/download/#sanctuary
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_edid.c | 54
On 4/15/11 2:22 PM, Jesse Barnes wrote:
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
Signed-off-by: Jesse Barnesjbar...@virtuousgeek.org
Very nice.
On 4/14/11 1:42 PM, Jesse Barnes wrote:
We've already seen that apps want to monitor the display config, and
some (like upowerd) poll for changes since we don't provide a
notification for general mode config changes, just hotplug events. So
add a new drm event, with CHANGE=1 set in the event,
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_edid.c | 10 ++
On 11-04-15 10:27 AM, Joerg Roedel wrote:
On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
Ok, I'll test it today. Should I apply it on a clean rc3 without any of
the other patches?
Yes, apply it just on -rc3 without any other patch.
BTW, may I suggest adding the info under
https://bugs.freedesktop.org/show_bug.cgi?id=36270
Summary: [r300g] Light sources are checkered in Unigine
Sanctuary when HDR is used
Product: Mesa
Version: git
Platform: x86 (IA32)
URL:
* Alexandre Demers alexandre.f.dem...@gmail.com wrote:
On 11-04-15 10:27 AM, Joerg Roedel wrote:
On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
Ok, I'll test it today. Should I apply it on a clean rc3 without any of
the other patches?
Yes, apply it just on -rc3
On 4/15/11 2:40 PM, Jesse Barnes wrote:
@@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid,
info-bpp = 0;
break;
}
+
+ if (edid-features DRM_EDID_FEATURE_RGB)
+ info-color_formats = DRM_COLOR_FORMAT_RGB444;
+
On Fri, 15 Apr 2011 15:13:02 -0400
Adam Jackson a...@redhat.com wrote:
On 4/15/11 2:40 PM, Jesse Barnes wrote:
@@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid,
info-bpp = 0;
break;
}
+
+ if (edid-features
On 04/15/2011 12:06 PM, Ingo Molnar wrote:
Joerg, mind submitting it with a changelog that includes everything we
learned
about this bug and all the Tested-by's in place?
Is anyone of the opinion that we should try to revert the allocation
order/alignment changes in addition to this
On Fri, 15 Apr 2011 14:29:50 -0400
Adam Jackson a...@redhat.com wrote:
On 4/15/11 2:22 PM, Jesse Barnes wrote:
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by
On Fri, 15 Apr 2011 12:19:31 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 15 Apr 2011 15:13:02 -0400
Adam Jackson a...@redhat.com wrote:
info-color_formats = DRM_COLOR_FORMAT_RGB444;
if (edid-features DRM_EDID_FEATURE_YCRCB444)
info-color_formats |=
On 4/15/11 3:19 PM, Jesse Barnes wrote:
Or is there a CEA block extension that allows for more granularity?
CEA has bits for the two YCbCr formats too, which we should also parse
since there's plenty of 1.3+CEA blocks in the world thanks to HDMI. For
CEA blocks version 2 and up (version
On Fri, 15 Apr 2011 15:36:22 -0400
Adam Jackson a...@redhat.com wrote:
On 4/15/11 3:19 PM, Jesse Barnes wrote:
Or is there a CEA block extension that allows for more granularity?
CEA has bits for the two YCbCr formats too, which we should also parse
since there's plenty of 1.3+CEA
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_edid.c | 55
-
+#define DRM_COLOR_FORMAT_RGB444 (10)
+#define DRM_COLOR_FORMAT_YCRCB444 (11)
+#define DRM_COLOR_FORMAT_YCRCB422 (12)
/*
* Describes a given display (e.g. CRT or flat panel) and its limitations.
*/
@@ -201,6 +203,7 @@ struct drm_display_info {
unsigned
https://bugs.freedesktop.org/show_bug.cgi?id=35367
--- Comment #2 from Marek Olšák mar...@gmail.com 2011-04-15 13:27:28 PDT ---
(In reply to comment #1)
(In reply to comment #0)
rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box.
kernel d-r-t, git ddx with tiling enabled
On Sat, 16 Apr 2011 06:10:07 +1000
Dave Airlie airl...@gmail.com wrote:
-
+#define DRM_COLOR_FORMAT_RGB444 (10)
+#define DRM_COLOR_FORMAT_YCRCB444 (11)
+#define DRM_COLOR_FORMAT_YCRCB422 (12)
/*
* Describes a given display (e.g. CRT or flat panel) and its
1 - 100 of 103 matches
Mail list logo
