[PATCH v2] drm: Compare only lower 32 bits of framebuffer map offsets

[Tormod Volden]

From: Tormod Volden 

Drivers using multiple framebuffers got broken by commit
41c2e75e60200a860a74b7c84a6375c105e7437f which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real offsets could not always be handed over for comparison.

Instead of ignoring the offset we will compare the lower 32 bit. Drivers
using multiple framebuffers should just make sure that the lower 32 bit
are different. The existing drivers in question are practically limited
to 32-bit systems so that should be fine for them.

It is assumed that current drivers always specify a correct framebuffer
map offset, even if this offset was ignored since above commit. So this
patch should not change anything for drivers using only one framebuffer.

Drivers needing multiple framebuffers with 64-bit map offsets will need
to cook up something, for instance keeping an ID in the lower bit which
is to be aligned away when it comes to using the offset.

All of above applies to _DRM_REGISTERS as well.

Signed-off-by: Tormod Volden 
---


On Mon, May 30, 2011 at 1:29 AM, Dave Airlie wrote:
>
> If you test it and it works I like it best. Simple and clear, and pretty
> close to what I was thinking was a good idea.
>
> As you say if someone needs this functionality in a new driver they can
> fix it, but really new drivers shouldn't be doing anything in this area.
>
> Dave.


Whoops, there was a less obvious fallthrough from the _DRM_SHM case above,
where we do not want to compare offsets at all if it contains a lock(*).

This patch has been tested on savage, and for verification also on radeon
with DRI1 and DRI2.

Tormod

(*) It actually checks if _DRM_CONTAINS_LOCK is the /only/ flag set. I
suppose this is intentional. My v2 patch does not change anything in the
case of _DRM_SHM: If it contains a lock, it returns a match without
comparing offsets. If no lock, it compares the full offsets. Is this
because the only _DRM_SHM used by userspace is the one with a lock, so
there is never a need to check a userspace-provided offset, or are those
always within 32 bit so a full check is ok?


 drivers/gpu/drm/drm_bufs.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 3e257a5..40ccfbc 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -46,10 +46,11 @@ static struct drm_map_list *drm_find_matching_map(struct 
drm_device *dev,
list_for_each_entry(entry, >maplist, head) {
/*
 * Because the kernel-userspace ABI is fixed at a 32-bit offset
-* while PCI resources may live above that, we ignore the map
-* offset for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS.
-* It is assumed that each driver will have only one resource of
-* each type.
+* while PCI resources may live above that, we only compare the
+* lower 32 bits of the map offset for maps of type
+* _DRM_FRAMEBUFFER or _DRM_REGISTERS.
+* It is assumed that if a driver have more than one resource
+* of each type, the lower 32 bits are different.
 */
if (!entry->map ||
map->type != entry->map->type ||
@@ -59,9 +60,12 @@ static struct drm_map_list *drm_find_matching_map(struct 
drm_device *dev,
case _DRM_SHM:
if (map->flags != _DRM_CONTAINS_LOCK)
break;
+   return entry;
case _DRM_REGISTERS:
case _DRM_FRAME_BUFFER:
-   return entry;
+   if ((entry->map->offset & 0x) ==
+   (map->offset & 0x))
+   return entry;
default: /* Make gcc happy */
;
}
-- 
1.7.1

[Bug 21582] Build failure if NOUVEAU && !HWMON

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=21582


Guenter Roeck  changed:

   What|Removed |Added

 CC||linux at roeck-us.net




--- Comment #1 from Guenter Roeck   2011-05-30 20:27:23 
---
Fixed with commit b54262f3c828ee17e27632d0d60255281c02e1a5.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 37193] Crash while switching between OpenGL window and other window

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37193

--- Comment #7 from Mathias Brodala  2011-05-30 14:51:23 
PDT ---
Created an attachment (id=47339)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47339)
kern.log 

Here?s at least some output I was able to find in my kern.log. Missing memory
space sure sounds odd but maybe this is finally something to get started on.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[3.0-rc1 regression] (was: Re: [2.6.39 regression] i915/kms: garbled screen because of 49183b281)

[Melchior FRANZ]

* Melchior FRANZ -- Thursday 12 May 2011:
> > Chris Wilson (4):
> >   drm/i915: Only enable the plane after setting the fb base (pre-ILK)
> 
> This patch introduces a bug on my infamous "Acer Travelmate
> 5735Z-452G32Mnss": when KMS takes over, the frame buffer contents
> get completely garbled up on screen, with colored stripes and
> unreadable text (photo on request). Only when X11 is started, the
> screen gets restored again. Closing and re-opening the lid partly
> cures the mess, too: it makes the font readable, though horizontally
> stretched.
> 
> Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the
> bug.

This got fixed after my bug report, but now it's back with exactly
the same description. Bisection result to come ...

m.

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37724

Marek Ol??k  changed:

   What|Removed |Added

Summary|occlusion queries are   |r300g with HyperZ/Z
   |messed up in ut2004 |compression: occlusion
   |(regression, bisected)  |queries are messed up in
   ||ut2004 (regression,
   ||bisected)

--- Comment #5 from Marek Ol??k  2011-05-30 13:59:23 PDT 
---
Ah ok.

I don't consider Hyper-Z ready yet but thanks for testing it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=35998

--- Comment #22 from Milan Plzik  2011-05-30 13:58:30 PDT 
---
(In reply to comment #21)
>   I tested gnome-shell with it; when using alignment table patches (Xorg's
> ColorTiling was always false), there was no change. However, when I reverted 
> to
> original r300_texture_desc.c, things seem to work more-or-less correctly --
> 8bpp textures seem to render fine (there's one case when I'm not sure),
> however, small 32bpp textures still render incorrectly.

UPDATE: looks like some fonts are not rendered properly either, but I can't
justify whether they are rendered into 8bpp or 32bpp textures.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Fw: [PATCH] drm: i915: correct return status in intel_hdmi_mode_valid()

[Nicolas Kaiser]

Forwarding to Keith Packard.
Sorry, initially sent to the previous maintainer instead.

Start weitergeleitete Nachricht:
Datum: Fri, 20 May 2011 18:58:53 +0200
Von: Nicolas Kaiser 
An: Chris Wilson 
Cc: David Airlie , dri-devel at lists.freedesktop.org, 
linux-kernel at vger.kernel.org
Betreff: [PATCH] drm: i915: correct return status in intel_hdmi_mode_valid()


Signed-off-by: Nicolas Kaiser 
---
Untested: just looks to me like the intention might be
to return MODE_CLOCK_LOW here, is that correct?

 drivers/gpu/drm/i915/intel_hdmi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index f289b86..655bbd9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -194,7 +194,7 @@ static int intel_hdmi_mode_valid(struct drm_connector 
*connector,
if (mode->clock > 165000)
return MODE_CLOCK_HIGH;
if (mode->clock < 2)
-   return MODE_CLOCK_HIGH;
+   return MODE_CLOCK_LOW;

if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
-- 
1.7.5.rc3

[Bug 30052] Fails to start X with intel+Ati video, whith modeset=1

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=30052





--- Comment #15 from Antonov Nikolay   2011-05-30 
12:31:57 ---
Yes, I can reproduce #15851:
steps:
Crtl+Alt+F1, "OFF" - everything is OK
Stop gdm daemon - OK
Start gdm or X - Freez.

with "ON" - X restarts successfully.

backtraces are very similar... so, I think it is one bug.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 37724] occlusion queries are messed up in ut2004 (regression, bisected)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37724

--- Comment #4 from almos  2011-05-30 11:31:28 PDT ---
(In reply to comment #3)
> Created an attachment (id=47307)
 View: https://bugs.freedesktop.org/attachment.cgi?id=47307
 Review: https://bugs.freedesktop.org/review?bug=37724=47307

> possible fix 2
> 
> Can you try this patch instead?
No apparent change compared to the first fix.

Now I see that I haven't mentioned that I use RADEON_HYPERZ=1. Without it there
are no rendering errors.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm: Compare only lower 32 bits of framebuffer map offsets

[Dave Airlie]

On Mon, 2011-05-30 at 01:12 +0200, Tormod Volden wrote:
> From: Tormod Volden 
> 
> Drivers using multiple framebuffers got broken by commit
> 41c2e75e60200a860a74b7c84a6375c105e7437f which ignored the framebuffer
> (or register) map offset when looking for existing maps. The rationale
> was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
> real offsets could not always be handed over for comparison.
> 
> Instead of ignoring the offset we will compare the lower 32 bit. Drivers
> using multiple framebuffers should just make sure that the lower 32 bit
> are different. The existing drivers in question are practically limited
> to 32-bit systems so that should be fine for them.
> 
> It is assumed that current drivers always specify a correct framebuffer
> map offset, even if this offset was ignored since above commit. So this
> patch should not change anything for drivers using only one framebuffer.
> 
> Drivers needing multiple framebuffers with 64-bit map offsets will need
> to cook up something, for instance keeping an ID in the lower bits,
> which is to be aligned away when it comes to using the offset.
> 
> Signed-off-by: Tormod Volden 
> ---
> 
> What about this idea? (Untested patch)

If you test it and it works I like it best. Simple and clear, and pretty
close to what I was thinking was a good idea.

As you say if someone needs this functionality in a new driver they can
fix it, but really new drivers shouldn't be doing anything in this area.

Dave.

[Bug 35935] since 2.6.38.1, screen become garbled after some times (RV770)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=35935

Mjules  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #6 from Mjules  2011-05-30 08:34:19 PDT ---
Hi,

I can't reproduce reliably (sometimes it occurs 2 times in 5 minutes, sometimes
nothing during weeks) and I suspect a hardware bug.

I think it's better to close it, no need to pollute buglist.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 34155] [drm:radeon_crtc_page_flip] *ERROR* failed to reserve new rbo buffer before flip

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34155

Alexandre Demers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 19484] corruption in Dolphin when moving the mouse

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=19484

--- Comment #21 from Michel D?nzer  2011-05-30 08:03:57 
PDT ---
Actually, the Git master log file shows the Composite extension being enabled,
so this might be bug 22566.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32402] Oops associated with radeon_unpin_work_func

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=32402





--- Comment #18 from Stuart Foster   2011-05-30 
08:00:45 ---
(In reply to comment #16)
> Created an attachment (id=59942)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=59942) [details]
> proposed fix 2. against 2.6.39
> 
> try again + fix error paths.

Ran the patch on 2.6.39 overnight (~9 hours) and there have been no problems
the problem looks fixed for me.

thanks

Stuart

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 34102] radeon drm/kms: please use suspend/hibernate notifiers for allocating memory in suspend routines

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34102


Florian Mickler  changed:

   What|Removed |Added

 CC||florian at mickler.org




--- Comment #13 from Florian Mickler   2011-05-30 
07:56:27 ---
A patch referencing this bug report has been merged in v3.0-rc1:

commit ddeb648708108091a641adad0a438ec4fd8bf190
Author: Rafael J. Wysocki 
Date:   Sun May 15 11:38:48 2011 +0200

PM / Hibernate: Add sysfs knob to control size of memory for drivers

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 36812] GPU lockup in Team Fortress 2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36812

--- Comment #6 from Enrico_m at gmx.de 2011-05-30 06:47:14 PDT ---
Here it also got worse With MESA_GLSL=nopt -> The game does not show the menu
anymore and the GPU does not reset (systems frozen).

If there is anything I could do to help debug this issue (test patches or add
more traces), please let me know.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 37724] occlusion queries are messed up in ut2004 (regression, bisected)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37724

Marek Ol??k  changed:

   What|Removed |Added

  Attachment #47288|0   |1
is obsolete||

--- Comment #3 from Marek Ol??k  2011-05-30 04:03:13 PDT 
---
Created an attachment (id=47307)
 View: https://bugs.freedesktop.org/attachment.cgi?id=47307
 Review: https://bugs.freedesktop.org/review?bug=37724=47307

possible fix 2

Can you try this patch instead?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm: Compare only lower 32 bits of framebuffer map offsets

[Tormod Volden]

From: Tormod Volden 

Drivers using multiple framebuffers got broken by commit
41c2e75e60200a860a74b7c84a6375c105e7437f which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real offsets could not always be handed over for comparison.

Instead of ignoring the offset we will compare the lower 32 bit. Drivers
using multiple framebuffers should just make sure that the lower 32 bit
are different. The existing drivers in question are practically limited
to 32-bit systems so that should be fine for them.

It is assumed that current drivers always specify a correct framebuffer
map offset, even if this offset was ignored since above commit. So this
patch should not change anything for drivers using only one framebuffer.

Drivers needing multiple framebuffers with 64-bit map offsets will need
to cook up something, for instance keeping an ID in the lower bits,
which is to be aligned away when it comes to using the offset.

Signed-off-by: Tormod Volden 
---

What about this idea? (Untested patch)

Regards,
Tormod

 drivers/gpu/drm/drm_bufs.c |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 3e257a5..b4224eb 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -46,10 +46,11 @@ static struct drm_map_list *drm_find_matching_map(struct 
drm_device *dev,
list_for_each_entry(entry, >maplist, head) {
/*
 * Because the kernel-userspace ABI is fixed at a 32-bit offset
-* while PCI resources may live above that, we ignore the map
-* offset for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS.
-* It is assumed that each driver will have only one resource of
-* each type.
+* while PCI resources may live above that, we only compare the
+* lower 32 bits of the map offset for maps of type
+* _DRM_FRAMEBUFFER or _DRM_REGISTERS.
+* It is assumed that if a driver have more than one resource
+* of each type, the lower 32 bits are different.
 */
if (!entry->map ||
map->type != entry->map->type ||
@@ -61,7 +62,9 @@ static struct drm_map_list *drm_find_matching_map(struct 
drm_device *dev,
break;
case _DRM_REGISTERS:
case _DRM_FRAME_BUFFER:
-   return entry;
+   if ((entry->map->offset & 0x) ==
+   (map->offset & 0x))
+   return entry;
default: /* Make gcc happy */
;
}
-- 
1.7.0.4

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=35998

--- Comment #21 from Milan Plzik  2011-05-29 23:40:31 PDT 
---
(In reply to comment #20)
> Setting this environment variable disables tiling in r300g:
> 
> RADEON_DEBUG=notiling
> 
> It must be set such that the Gnome Shell can see it, of course.

  I tested gnome-shell with it; when using alignment table patches (Xorg's
ColorTiling was always false), there was no change. However, when I reverted to
original r300_texture_desc.c, things seem to work more-or-less correctly --
8bpp textures seem to render fine (there's one case when I'm not sure),
however, small 32bpp textures still render incorrectly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=35998

--- Comment #21 from Milan Plzik eme...@gmail.com 2011-05-29 23:40:31 PDT ---
(In reply to comment #20)
 Setting this environment variable disables tiling in r300g:
 
 RADEON_DEBUG=notiling
 
 It must be set such that the Gnome Shell can see it, of course.

  I tested gnome-shell with it; when using alignment table patches (Xorg's
ColorTiling was always false), there was no change. However, when I reverted to
original r300_texture_desc.c, things seem to work more-or-less correctly --
8bpp textures seem to render fine (there's one case when I'm not sure),
however, small 32bpp textures still render incorrectly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32402] Oops associated with radeon_unpin_work_func

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=32402





--- Comment #18 from Stuart Foster smf.li...@ntlworld.com  2011-05-30 
08:00:45 ---
(In reply to comment #16)
 Created an attachment (id=59942)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=59942) [details]
 proposed fix 2. against 2.6.39
 
 try again + fix error paths.

Ran the patch on 2.6.39 overnight (~9 hours) and there have been no problems
the problem looks fixed for me.

thanks

Stuart

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Fw: [PATCH] drm: i915: correct return status in intel_hdmi_mode_valid()

[Nicolas Kaiser]

Forwarding to Keith Packard.
Sorry, initially sent to the previous maintainer instead.

Start weitergeleitete Nachricht:
Datum: Fri, 20 May 2011 18:58:53 +0200
Von: Nicolas Kaiser ni...@nikai.net
An: Chris Wilson ch...@chris-wilson.co.uk
Cc: David Airlie airl...@linux.ie, dri-devel@lists.freedesktop.org, 
linux-ker...@vger.kernel.org
Betreff: [PATCH] drm: i915: correct return status in intel_hdmi_mode_valid()


Signed-off-by: Nicolas Kaiser ni...@nikai.net
---
Untested: just looks to me like the intention might be
to return MODE_CLOCK_LOW here, is that correct?

 drivers/gpu/drm/i915/intel_hdmi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index f289b86..655bbd9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -194,7 +194,7 @@ static int intel_hdmi_mode_valid(struct drm_connector 
*connector,
if (mode-clock  165000)
return MODE_CLOCK_HIGH;
if (mode-clock  2)
-   return MODE_CLOCK_HIGH;
+   return MODE_CLOCK_LOW;
 
if (mode-flags  DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
-- 
1.7.5.rc3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37724] occlusion queries are messed up in ut2004 (regression, bisected)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37724

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

  Attachment #47288|0   |1
is obsolete||

--- Comment #3 from Marek Olšák mar...@gmail.com 2011-05-30 04:03:13 PDT ---
Created an attachment (id=47307)
 View: https://bugs.freedesktop.org/attachment.cgi?id=47307
 Review: https://bugs.freedesktop.org/review?bug=37724attachment=47307

possible fix 2

Can you try this patch instead?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[3.0-rc1 regression] (was: Re: [2.6.39 regression] i915/kms: garbled screen because of 49183b281)

[Melchior FRANZ]

* Melchior FRANZ -- Thursday 12 May 2011:
  Chris Wilson (4):
drm/i915: Only enable the plane after setting the fb base (pre-ILK)
 
 This patch introduces a bug on my infamous Acer Travelmate
 5735Z-452G32Mnss: when KMS takes over, the frame buffer contents
 get completely garbled up on screen, with colored stripes and
 unreadable text (photo on request). Only when X11 is started, the
 screen gets restored again. Closing and re-opening the lid partly
 cures the mess, too: it makes the font readable, though horizontally
 stretched.
 
 Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the
 bug.

This got fixed after my bug report, but now it's back with exactly
the same description. Bisection result to come ...

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30052] Fails to start X with intel+Ati video, whith modeset=1

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=30052





--- Comment #15 from Antonov Nikolay osti...@gmail.com  2011-05-30 12:31:57 
---
Yes, I can reproduce #15851:
steps:
Crtl+Alt+F1, OFF - everything is OK
Stop gdm daemon - OK
Start gdm or X - Freez.

with ON - X restarts successfully.

backtraces are very similar... so, I think it is one bug.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36812] GPU lockup in Team Fortress 2

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36812

--- Comment #6 from enric...@gmx.de 2011-05-30 06:47:14 PDT ---
Here it also got worse With MESA_GLSL=nopt - The game does not show the menu
anymore and the GPU does not reset (systems frozen).

If there is anything I could do to help debug this issue (test patches or add
more traces), please let me know.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 19484] corruption in Dolphin when moving the mouse

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=19484

--- Comment #21 from Michel Dänzer mic...@daenzer.net 2011-05-30 08:03:57 PDT 
---
Actually, the Git master log file shows the Composite extension being enabled,
so this might be bug 22566.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 34155] [drm:radeon_crtc_page_flip] *ERROR* failed to reserve new rbo buffer before flip

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=34155

Alexandre Demers alexandre.f.dem...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 35935] since 2.6.38.1, screen become garbled after some times (RV770)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=35935

Mjules mjulie...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #6 from Mjules mjulie...@gmail.com 2011-05-30 08:34:19 PDT ---
Hi,

I can't reproduce reliably (sometimes it occurs 2 times in 5 minutes, sometimes
nothing during weeks) and I suspect a hardware bug.

I think it's better to close it, no need to pollute buglist.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37724] occlusion queries are messed up in ut2004 (regression, bisected)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37724

--- Comment #4 from almos aaalmo...@gmail.com 2011-05-30 11:31:28 PDT ---
(In reply to comment #3)
 Created an attachment (id=47307)
 View: https://bugs.freedesktop.org/attachment.cgi?id=47307
 Review: https://bugs.freedesktop.org/review?bug=37724attachment=47307

 possible fix 2
 
 Can you try this patch instead?
No apparent change compared to the first fix.

Now I see that I haven't mentioned that I use RADEON_HYPERZ=1. Without it there
are no rendering errors.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: Compare only lower 32 bits of framebuffer map offsets

[Tormod Volden]

From: Tormod Volden debian.tor...@gmail.com

Drivers using multiple framebuffers got broken by commit
41c2e75e60200a860a74b7c84a6375c105e7437f which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real offsets could not always be handed over for comparison.

Instead of ignoring the offset we will compare the lower 32 bit. Drivers
using multiple framebuffers should just make sure that the lower 32 bit
are different. The existing drivers in question are practically limited
to 32-bit systems so that should be fine for them.

It is assumed that current drivers always specify a correct framebuffer
map offset, even if this offset was ignored since above commit. So this
patch should not change anything for drivers using only one framebuffer.

Drivers needing multiple framebuffers with 64-bit map offsets will need
to cook up something, for instance keeping an ID in the lower bit which
is to be aligned away when it comes to using the offset.

All of above applies to _DRM_REGISTERS as well.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---


On Mon, May 30, 2011 at 1:29 AM, Dave Airlie wrote:

 If you test it and it works I like it best. Simple and clear, and pretty
 close to what I was thinking was a good idea.

 As you say if someone needs this functionality in a new driver they can
 fix it, but really new drivers shouldn't be doing anything in this area.

 Dave.


Whoops, there was a less obvious fallthrough from the _DRM_SHM case above,
where we do not want to compare offsets at all if it contains a lock(*).

This patch has been tested on savage, and for verification also on radeon
with DRI1 and DRI2.

Tormod

(*) It actually checks if _DRM_CONTAINS_LOCK is the /only/ flag set. I
suppose this is intentional. My v2 patch does not change anything in the
case of _DRM_SHM: If it contains a lock, it returns a match without
comparing offsets. If no lock, it compares the full offsets. Is this
because the only _DRM_SHM used by userspace is the one with a lock, so
there is never a need to check a userspace-provided offset, or are those
always within 32 bit so a full check is ok?


 drivers/gpu/drm/drm_bufs.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 3e257a5..40ccfbc 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -46,10 +46,11 @@ static struct drm_map_list *drm_find_matching_map(struct 
drm_device *dev,
list_for_each_entry(entry, dev-maplist, head) {
/*
 * Because the kernel-userspace ABI is fixed at a 32-bit offset
-* while PCI resources may live above that, we ignore the map
-* offset for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS.
-* It is assumed that each driver will have only one resource of
-* each type.
+* while PCI resources may live above that, we only compare the
+* lower 32 bits of the map offset for maps of type
+* _DRM_FRAMEBUFFER or _DRM_REGISTERS.
+* It is assumed that if a driver have more than one resource
+* of each type, the lower 32 bits are different.
 */
if (!entry-map ||
map-type != entry-map-type ||
@@ -59,9 +60,12 @@ static struct drm_map_list *drm_find_matching_map(struct 
drm_device *dev,
case _DRM_SHM:
if (map-flags != _DRM_CONTAINS_LOCK)
break;
+   return entry;
case _DRM_REGISTERS:
case _DRM_FRAME_BUFFER:
-   return entry;
+   if ((entry-map-offset  0x) ==
+   (map-offset  0x))
+   return entry;
default: /* Make gcc happy */
;
}
-- 
1.7.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 21582] Build failure if NOUVEAU !HWMON

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=21582


Guenter Roeck li...@roeck-us.net changed:

   What|Removed |Added

 CC||li...@roeck-us.net




--- Comment #1 from Guenter Roeck li...@roeck-us.net  2011-05-30 20:27:23 ---
Fixed with commit b54262f3c828ee17e27632d0d60255281c02e1a5.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=35998

--- Comment #22 from Milan Plzik eme...@gmail.com 2011-05-30 13:58:30 PDT ---
(In reply to comment #21)
   I tested gnome-shell with it; when using alignment table patches (Xorg's
 ColorTiling was always false), there was no change. However, when I reverted 
 to
 original r300_texture_desc.c, things seem to work more-or-less correctly --
 8bpp textures seem to render fine (there's one case when I'm not sure),
 however, small 32bpp textures still render incorrectly.

UPDATE: looks like some fonts are not rendered properly either, but I can't
justify whether they are rendered into 8bpp or 32bpp textures.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37724

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

Summary|occlusion queries are   |r300g with HyperZ/Z
   |messed up in ut2004 |compression: occlusion
   |(regression, bisected)  |queries are messed up in
   ||ut2004 (regression,
   ||bisected)

--- Comment #5 from Marek Olšák mar...@gmail.com 2011-05-30 13:59:23 PDT ---
Ah ok.

I don't consider Hyper-Z ready yet but thanks for testing it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37193] Crash while switching between OpenGL window and other window

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37193

--- Comment #7 from Mathias Brodala i...@noctus.net 2011-05-30 14:51:23 PDT 
---
Created an attachment (id=47339)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47339)
kern.log 

Here’s at least some output I was able to find in my kern.log. Missing memory
space sure sounds odd but maybe this is finally something to get started on.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

3D support for Displaylink devices

[PRASANNA KUMAR]

USB graphics devices from displaylink does not have 3D hardware. To get 3D 
effects (compiz, GNOME 3, KWin, OpenGL apps etc) with these device in Linux the 
native (primary) GPU can be used to provide hardware acceleration. All the 
graphics operation is done using the native (primary) GPU and the end result is 
taken and send to the displaylink device. Can this be achieved? If so is it 
possible to implement a generic framework so that any device (USB, thunderbolt 
or any new technology) can use this just by implementing device specific 
(compression and) data transport? I am not sure this is the correct mailing 
list.

Thanks,
Prasanna Kumar___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel