3D support for Displaylink devices
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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110530/10bc0139/attachment.htm>
3D support for Displaylink devices
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
[PATCH v2] drm: Compare only lower 32 bits of framebuffer map offsets
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, &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
[Bug 21582] Build failure if NOUVEAU && !HWMON
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
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. ___ 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
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 -- 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)
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. ___ 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)
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
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. ___ 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
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.
[Bug 21582] Build failure if NOUVEAU && !HWMON
https://bugzilla.kernel.org/show_bug.cgi?id=21582 Guenter Roeck changed: What|Removed |Added CC||li...@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. ___ 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()
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
[PATCH v2] drm: Compare only lower 32 bits of framebuffer map offsets
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, &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 30052] Fails to start X with intel+Ati video, whith modeset=1
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)
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&attachment=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
[Bug 37724] occlusion queries are messed up in ut2004 (regression, bisected)
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&attachment=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
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)
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. ___ 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)
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
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. ___ 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
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
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. ___ 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
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
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
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
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 36812] GPU lockup in Team Fortress 2
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 30052] Fails to start X with intel+Ati video, whith modeset=1
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. ___ 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 -- 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 37724] occlusion queries are messed up in ut2004 (regression, bisected)
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&attachment=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
[Bug 37724] occlusion queries are messed up in ut2004 (regression, bisected)
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&attachment=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.
Fw: [PATCH] drm: i915: correct return status in intel_hdmi_mode_valid()
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@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 --- 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 34102] radeon drm/kms: please use suspend/hibernate notifiers for allocating memory in suspend routines
https://bugzilla.kernel.org/show_bug.cgi?id=34102 Florian Mickler changed: What|Removed |Added CC||flor...@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. ___ 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
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Compare only lower 32 bits of framebuffer map offsets
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, &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 || @@ -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