[Bug 28940] New: rv515 (Mobility x1400) Display corruption after some time
https://bugs.freedesktop.org/show_bug.cgi?id=28940 Summary: rv515 (Mobility x1400) Display corruption after some time Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: gt...@spearhead.de Created an attachment (id=36799) --> (https://bugs.freedesktop.org/attachment.cgi?id=36799) lspci output (graphics only) After some uptime (upwards of an hour so far), I get different kinds of display corruption on a laptop with a Radeon x1400. Currently, I'm looking at a somewhat grainy picture which looks like a badly dithered low-colour version of the screen content. There are noticeable vertical stripes, and the whole image is shimmering. The system is working fine otherwise. In an earlier instance, I had a pulsating green gradient covering the bottom of the screen. In addition, screen response was slow, like the proper content was only updating evers second or so. The effect does not show in screenshots. This is on a Debian-built 2.6.34 686 kernel, running X.org 1.7.7 and the "radeon" driver 6.13.0, libdrm2 2.4.21 from Debian packages. I'm attaching lspci output for the card, as well as dmesg and the Xorg.log from the currently "broken" running system. -- 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 28940] rv515 (Mobility x1400) Display corruption after some time
https://bugs.freedesktop.org/show_bug.cgi?id=28940 --- Comment #1 from Nicos Gollan 2010-07-07 02:55:01 PDT --- Created an attachment (id=36800) --> (https://bugs.freedesktop.org/attachment.cgi?id=36800) Xorg.log from a "broken" system -- 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 28940] rv515 (Mobility x1400) Display corruption after some time
https://bugs.freedesktop.org/show_bug.cgi?id=28940 --- Comment #2 from Nicos Gollan 2010-07-07 02:55:36 PDT --- Created an attachment (id=36801) --> (https://bugs.freedesktop.org/attachment.cgi?id=36801) dmesg output from a "broken" system -- 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
Re: Report for 2.6.35-rc3-00262-g984bc96
Andrew Morton [Tue, Jul 06, 2010 at 07:42:22PM -0700]: > On Thu, 1 Jul 2010 09:40:52 +0200 Nico Schottelius > wrote: > > > Good morning! > > > > A short report on what's broken in 2.6.35-rc3-00262-g984bc96 with > > the Lenovo X201: > > So you see two post-2.6.34 regressions? I'm not 100% sure whether the netdev issue was not already part of 2.6.34. Just changed to 2.6.35-rc4, but noticed another issue on 2.6.35-rc3-00262-g984bc96: After several (>=3) resumes, the system completly freezes. Used to happen with 2.6.33 very often (always?), vanished with 2.6.34-something Cheers, Nico -- New PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 Please resign, if you signed 9885188C or 8D0E27A4. Currently moving *.schottelius.org to http://www.nico.schottelius.org/ ... pgpUqmICuvH4B.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28943] New: Red=cyan? Why?
https://bugs.freedesktop.org/show_bug.cgi?id=28943 Summary: Red=cyan? Why? Product: Mesa Version: unspecified Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/MGA AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: eblanc...@users.sourceforge.net I'm having a strange color replacement in ubuntu 10.04. Hardware is matrox g550 agp dual head, 32 MB. Well, running silent hill 2 in wine, I have cyan blood when it should be red! Here you can read the (closed) bug: http://bugs.winehq.org/show_bug.cgi?id=17741 (there are a lot of details about the bug) I thought it was due to wine but it isn't, so it was closed as invalid. Please note, this `bug' appears since a couple of years ago and even now, with mesa 7.7.1. -- 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 24818] shadowtex demo doesn't work on rs780
https://bugs.freedesktop.org/show_bug.cgi?id=24818 --- Comment #7 from Andy Furniss 2010-07-07 04:37:38 PDT --- (In reply to comment #4) > I can confirm this using mesa master and RV620. > > I've noticed that corruption is random as I restart shadowtex demo until some > time. After starting it for example 10th time, corruption stops changing. So > it > indeed looks like using some random data from VRAM or something. After having > "stable" corruption I've to reboot to get random corruptions again (for a few > shadowtex restarts). Seems like there's been a further regression - probably in mesa master during the last few weeks. I now can't run this at all - shadowtex: r700_assembler.c:6355: Process_Export: Assertion `starting_register_number >= pAsm->starting_export_register_number' failed. Anyone else getting this? -- 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 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 Tom Stellard changed: What|Removed |Added Attachment #36773|0 |1 is obsolete|| -- 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 28932] KWin crash (KDE 4.4.90) during call to r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=28932 --- Comment #4 from Darin McBride 2010-07-07 11:34:09 PDT --- Ok, I've installed mesa from git, and, oddly, now the backtrace doesn't show function names in r600_dri.so... but obviously the fact I'm getting a backtrace again means I'm still hitting the problem. :-) -- 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 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 --- Comment #9 from Tom Stellard 2010-07-07 11:34:27 PDT --- Created an attachment (id=36839) View: https://bugs.freedesktop.org/attachment.cgi?id=36839 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36839 Possible Fix. Can you try again with this patch. -- 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 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 --- Comment #10 from Scott Moreau 2010-07-07 13:15:31 PDT --- Created an attachment (id=36845) --> (https://bugs.freedesktop.org/attachment.cgi?id=36845) compiz crash (In reply to comment #9) > Created an attachment (id=36839) View: https://bugs.freedesktop.org/attachment.cgi?id=36839 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36839 > Possible Fix. > > Can you try again with this patch. This patch works, but it only worked the first time I tried it. Since restarting compiz, it crashes after falling back to software routines for whatever reason. It doesn't matter if the effect is enabled at (compiz) runtime or if it's disabled at runtime then enabled after compiz has fully started. I have attached the bt. -- 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 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 --- Comment #11 from Scott Moreau 2010-07-07 13:30:54 PDT --- (In reply to comment #9) > Created an attachment (id=36839) View: https://bugs.freedesktop.org/attachment.cgi?id=36839 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36839 > Possible Fix. > > Can you try again with this patch. (In reply to comment #10) > Created an attachment (id=36845) --> (https://bugs.freedesktop.org/attachment.cgi?id=36845) > compiz crash > > (In reply to comment #9) > > Created an attachment (id=36839) View: https://bugs.freedesktop.org/attachment.cgi?id=36839 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36839 > > Possible Fix. > > > > Can you try again with this patch. > > This patch works, but it only worked the first time I tried it. Because I failed to use the gallium driver. This bt is from classic mesa and can be ignored. -- 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 01/18] drm: use noop_llseek
The drm device drivers currently allow seeking on the
character device but never care about the actual
file position.
When we change the default llseek operation to be
no_llseek, calling llseek on a drm device would
return an error condition, which is an API change.
Explicitly setting noop_llseek lets us keep the
current API.
Signed-off-by: Arnd Bergmann
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
Documentation/DocBook/drm.tmpl|1 +
drivers/gpu/drm/i810/i810_drv.c |1 +
drivers/gpu/drm/i830/i830_drv.c |1 +
drivers/gpu/drm/i915/i915_drv.c |1 +
drivers/gpu/drm/mga/mga_drv.c |1 +
drivers/gpu/drm/nouveau/nouveau_drv.c |1 +
drivers/gpu/drm/r128/r128_drv.c |1 +
drivers/gpu/drm/radeon/radeon_drv.c |1 +
drivers/gpu/drm/savage/savage_drv.c |1 +
drivers/gpu/drm/sis/sis_drv.c |1 +
drivers/gpu/drm/tdfx/tdfx_drv.c |1 +
drivers/gpu/drm/via/via_drv.c |1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 +
13 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 910c923..2861055 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -136,6 +136,7 @@
#ifdef CONFIG_COMPAT
.compat_ioctl = i915_compat_ioctl,
#endif
+ .llseek = noop_llseek,
},
.pci_driver = {
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
index c1e0275..199fdfa 100644
--- a/drivers/gpu/drm/i810/i810_drv.c
+++ b/drivers/gpu/drm/i810/i810_drv.c
@@ -63,6 +63,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/i830/i830_drv.c b/drivers/gpu/drm/i830/i830_drv.c
index 44f990b..3be1d7d 100644
--- a/drivers/gpu/drm/i830/i830_drv.c
+++ b/drivers/gpu/drm/i830/i830_drv.c
@@ -74,6 +74,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 423dc90..bd8c139 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -547,6 +547,7 @@ static struct drm_driver driver = {
#ifdef CONFIG_COMPAT
.compat_ioctl = i915_compat_ioctl,
#endif
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/mga/mga_drv.c b/drivers/gpu/drm/mga/mga_drv.c
index ddfe161..524185f 100644
--- a/drivers/gpu/drm/mga/mga_drv.c
+++ b/drivers/gpu/drm/mga/mga_drv.c
@@ -75,6 +75,7 @@ static struct drm_driver driver = {
#ifdef CONFIG_COMPAT
.compat_ioctl = mga_compat_ioctl,
#endif
+ .llseek = noop_llseek,
},
.pci_driver = {
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 2737704..9505fa6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -400,6 +400,7 @@ static struct drm_driver driver = {
#if defined(CONFIG_COMPAT)
.compat_ioctl = nouveau_compat_ioctl,
#endif
+ .llseek = noop_llseek,
},
.pci_driver = {
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
index b806fdc..dc22c6e 100644
--- a/drivers/gpu/drm/r128/r128_drv.c
+++ b/drivers/gpu/drm/r128/r128_drv.c
@@ -71,6 +71,7 @@ static struct drm_driver driver = {
#ifdef CONFIG_COMPAT
.compat_ioctl = r128_compat_ioctl,
#endif
+ .llseek = noop_llseek,
},
.pci_driver = {
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index e166fe4..e79dcf5 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -218,6 +218,7 @@ static struct drm_driver driver_old = {
#ifdef CONFIG_COMPAT
.compat_ioctl = radeon_compat_ioctl,
#endif
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/savage/savage_drv.c
b/drivers/gpu/drm/savage/savage_drv.c
index 021de44..2a2830f 100644
--- a/drivers/gpu/drm/savage/savage_drv.c
+++ b/drivers/gpu/drm/savage/savage_drv.c
@@ -54,6 +54,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/si
[Bug 28955] New: [r300g]: refresh/update/damage issues using compiz.
https://bugs.freedesktop.org/show_bug.cgi?id=28955 Summary: [r300g]: refresh/update/damage issues using compiz. Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ore...@gmail.com Created an attachment (id=36846) --> (https://bugs.freedesktop.org/attachment.cgi?id=36846) example Can reproduce reliably, running any compiz with r300g on rv350. While the screen is not being damaged (you can see with showrepaint plugin) any change in a window is not updated until some other window moves in front of it or animation happens in the area. It used to work a few months ago as far as I can remember, but I could not find a good commit to bisect with that would build and wouldn't crash compiz when trying to start it. Steps to reproduce: 1) Start compiz with r300g on rv350 2) Make sure the screen isn't already being damaged, then click on something in ccsm or go to a different webpage in a browser or use an irc client with text scrolling up (a terminal or any other window can also be affected) 3) Observe issue -- 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
Fair eviction for i915, based on Daniel's drm_mm scanner
On Tue, Jul 6, 2010 at 5:13 PM, Eric Anholt wrote: > On Fri, ?2 Jul 2010 15:02:10 +0100, Chris Wilson chris-wilson.co.uk> wrote: >> This is a resend of Daniel Vetter's drm mm work to provide a basis for >> performing fair eviction in i915. I've taken the liberty of attaching the >> acks and review comments from the previous round, so please look over and >> check that they still hold true. > > This is in Dave's hands now to review the core bits -- I like the i915 > bits. Okay I've pushed out a new drm-core-next branch, please pull or base the intel next branch on that, I've only pushed the drm_mm changes to that which I think is the first 6 patches of the series drm: implement helper functions for scanning lru list drm_mm: extract check_free_mm_node drm: sane naming for drm_mm.c drm: kill dead code in drm_mm.c drm: kill drm_mm_node->private drm: use list_for_each_entry in drm_mm.c I'll be pushing out a drm-next soon, don't base any trees or pull from it. Dave.
[git pull] drm fixes
Four fixes, page alloc fix is for a regression when you load/unload drm drivers modules that use it, Jesse fixed annoying bug where starting X after console blanked would never light up screen, and two fixes to radeon to light up certain hw configurations properly. The following changes since commit 123f94f22e3d283dfe68742b269c245b0501ad82: Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2010-07-02 09:52:58 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (2): drm/radeon/kms: add ioport register access drm/radeon/kms: fix shared ddc handling Francisco Jerez (1): drm/ttm: Allocate the page pool manager in the heap. Jesse Barnes (1): drm: correctly update connector DPMS status in drm_fb_helper drivers/gpu/drm/drm_fb_helper.c| 23 - drivers/gpu/drm/radeon/atom.c |5 +- drivers/gpu/drm/radeon/atom.h |2 + drivers/gpu/drm/radeon/radeon.h| 25 ++ drivers/gpu/drm/radeon/radeon_connectors.c |4 +- drivers/gpu/drm/radeon/radeon_device.c | 34 ++ drivers/gpu/drm/ttm/ttm_page_alloc.c | 68 +-- include/drm/ttm/ttm_page_alloc.h |4 -- 8 files changed, 119 insertions(+), 46 deletions(-)
[PATCH 1/3] drm: add vblank event trace point
On Fri, Jul 2, 2010 at 9:47 AM, Jesse Barnes wrote: > Emit a trace point for vblank events. ?This can be helpful for mapping > drawing activity against the vblank frequency and period. > Pushed these 3 out to drm-core-next. Dave.
[PATCH] drm: correctly update connector DPMS status in drm_fb_helper
On Sat, Jul 3, 2010 at 3:48 AM, Jesse Barnes
wrote:
> We don't currently update the DPMS status of the connector (both in the
> connector itself and the connector's DPMS property) in the fb helper
> code. ?This means that if the kernel FB core has blanked the screen,
> sysfs will still show a DPMS status of "on". ?It also means that when X
> starts, it will try to light up the connectors, but the drm_crtc_helper
> code will ignore the DPMS change since according to the connector, the
> DPMS status is already on.
>
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28436 (the annoying
> "my screen was blanked when I started X and now it won't light up" bug).
>
Yay finally that is fixed, I apologies for not getting to it myself,
sent to Linus.
Dave.
> Signed-off-by: Jesse Barnes
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index b3779d2..32f67cb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -315,8 +315,9 @@ static void drm_fb_helper_on(struct fb_info *info)
> ? ? ? ?struct drm_device *dev = fb_helper->dev;
> ? ? ? ?struct drm_crtc *crtc;
> ? ? ? ?struct drm_crtc_helper_funcs *crtc_funcs;
> + ? ? ? struct drm_connector *connector;
> ? ? ? ?struct drm_encoder *encoder;
> - ? ? ? int i;
> + ? ? ? int i, j;
>
> ? ? ? ?/*
> ? ? ? ? * For each CRTC in this fb, turn the crtc on then,
> @@ -332,7 +333,14 @@ static void drm_fb_helper_on(struct fb_info *info)
>
> ? ? ? ? ? ? ? ?crtc_funcs->dpms(crtc, DRM_MODE_DPMS_ON);
>
> -
> + ? ? ? ? ? ? ? /* Walk the connectors & encoders on this fb turning them on
> */
> + ? ? ? ? ? ? ? for (j = 0; j < fb_helper->connector_count; j++) {
> + ? ? ? ? ? ? ? ? ? ? ? connector = fb_helper->connector_info[j]->connector;
> + ? ? ? ? ? ? ? ? ? ? ? connector->dpms = DRM_MODE_DPMS_ON;
> + ? ? ? ? ? ? ? ? ? ? ? drm_connector_property_set_value(connector,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> ?dev->mode_config.dpms_property,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DRM_MODE_DPMS_ON);
> + ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?/* Found a CRTC on this fb, now find encoders */
> ? ? ? ? ? ? ? ?list_for_each_entry(encoder, &dev->mode_config.encoder_list,
> head) {
> ? ? ? ? ? ? ? ? ? ? ? ?if (encoder->crtc == crtc) {
> @@ -352,8 +360,9 @@ static void drm_fb_helper_off(struct fb_info *info, int
> dpms_mode)
> ? ? ? ?struct drm_device *dev = fb_helper->dev;
> ? ? ? ?struct drm_crtc *crtc;
> ? ? ? ?struct drm_crtc_helper_funcs *crtc_funcs;
> + ? ? ? struct drm_connector *connector;
> ? ? ? ?struct drm_encoder *encoder;
> - ? ? ? int i;
> + ? ? ? int i, j;
>
> ? ? ? ?/*
> ? ? ? ? * For each CRTC in this fb, find all associated encoders
> @@ -367,6 +376,14 @@ static void drm_fb_helper_off(struct fb_info *info, int
> dpms_mode)
> ? ? ? ? ? ? ? ?if (!crtc->enabled)
> ? ? ? ? ? ? ? ? ? ? ? ?continue;
>
> + ? ? ? ? ? ? ? /* Walk the connectors on this fb and mark them off */
> + ? ? ? ? ? ? ? for (j = 0; j < fb_helper->connector_count; j++) {
> + ? ? ? ? ? ? ? ? ? ? ? connector = fb_helper->connector_info[j]->connector;
> + ? ? ? ? ? ? ? ? ? ? ? connector->dpms = dpms_mode;
> + ? ? ? ? ? ? ? ? ? ? ? drm_connector_property_set_value(connector,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> ?dev->mode_config.dpms_property,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dpms_mode);
> + ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?/* Found a CRTC on this fb, now find encoders */
> ? ? ? ? ? ? ? ?list_for_each_entry(encoder, &dev->mode_config.encoder_list,
> head) {
> ? ? ? ? ? ? ? ? ? ? ? ?if (encoder->crtc == crtc) {
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[git pull] drm fixes
Ignore this one, picked up a problem in the ioports patch, so its gone. new pull req sent. Dave. > > The following changes since commit 123f94f22e3d283dfe68742b269c245b0501ad82: > > Merge branch 'sched-fixes-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2010-07-02 > 09:52:58 -0700) > > are available in the git repository at: > > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git > drm-fixes > > Alex Deucher (2): > drm/radeon/kms: add ioport register access > drm/radeon/kms: fix shared ddc handling > > Francisco Jerez (1): > drm/ttm: Allocate the page pool manager in the heap. > > Jesse Barnes (1): > drm: correctly update connector DPMS status in drm_fb_helper > > drivers/gpu/drm/drm_fb_helper.c| 23 - > drivers/gpu/drm/radeon/atom.c |5 +- > drivers/gpu/drm/radeon/atom.h |2 + > drivers/gpu/drm/radeon/radeon.h| 25 ++ > drivers/gpu/drm/radeon/radeon_connectors.c |4 +- > drivers/gpu/drm/radeon/radeon_device.c | 34 ++ > drivers/gpu/drm/ttm/ttm_page_alloc.c | 68 +-- > include/drm/ttm/ttm_page_alloc.h |4 -- > 8 files changed, 119 insertions(+), 46 deletions(-) >
[git pull] drm v2 fixes
Okay I dropped the ioports patch from the last pull, it broke a few systems unexpectedly, so no more of that, just 3 simple fixes now. Dave. The following changes since commit 123f94f22e3d283dfe68742b269c245b0501ad82: Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2010-07-02 09:52:58 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (1): drm/radeon/kms: fix shared ddc handling Francisco Jerez (1): drm/ttm: Allocate the page pool manager in the heap. Jesse Barnes (1): drm: correctly update connector DPMS status in drm_fb_helper drivers/gpu/drm/drm_fb_helper.c| 23 - drivers/gpu/drm/radeon/radeon_connectors.c |4 +- drivers/gpu/drm/ttm/ttm_page_alloc.c | 68 +-- include/drm/ttm/ttm_page_alloc.h |4 -- 4 files changed, 56 insertions(+), 43 deletions(-)
[PATCH] drm/radeon/kms: add ioport register access
> ?int radeon_atombios_init(struct radeon_device *rdev)
> ?{
> ? ? ? ?struct card_info *atom_card_info =
> @@ -427,6 +443,9 @@ int radeon_atombios_init(struct radeon_device *rdev)
> ? ? ? ?atom_card_info->dev = rdev->ddev;
> ? ? ? ?atom_card_info->reg_read = cail_reg_read;
> ? ? ? ?atom_card_info->reg_write = cail_reg_write;
> + ? ? ? /* needed for iio ops */
> + ? ? ? atom_card_info->ioreg_read = cail_ioreg_read;
> + ? ? ? atom_card_info->ioreg_write = cail_ioreg_write;
> ? ? ? ?atom_card_info->mc_read = cail_mc_read;
> ? ? ? ?atom_card_info->mc_write = cail_mc_write;
> ? ? ? ?atom_card_info->pll_read = cail_pll_read;
> @@ -659,6 +678,19 @@ int radeon_device_init(struct radeon_device *rdev,
> ? ? ? ?DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)rdev->rmmio_base);
> ? ? ? ?DRM_INFO("register mmio size: %u\n", (unsigned)rdev->rmmio_size);
>
> + ? ? ? /* io port mapping */
> + ? ? ? if (rdev->family >= CHIP_RV770) {
> + ? ? ? ? ? ? ? rdev->rio_mem_size = pci_resource_len(rdev->pdev, 4);
> + ? ? ? ? ? ? ? rdev->rio_mem = pci_iomap(rdev->pdev, 4, rdev->rio_mem_size);
> + ? ? ? } else {
> + ? ? ? ? ? ? ? rdev->rio_mem_size = pci_resource_len(rdev->pdev, 1);
> + ? ? ? ? ? ? ? rdev->rio_mem = pci_iomap(rdev->pdev, 1, rdev->rio_mem_size);
> + ? ? ? }
> + ? ? ? if (rdev->rio_mem == NULL) {
> + ? ? ? ? ? ? ? iounmap(rdev->rmmio);
> + ? ? ? ? ? ? ? return -EIO;
> + ? ? ? }
> +
This is all bad, my main r600 stopped working after this, from my
quick boot test
r100->r300 are all port 1, discrete r480 and upwards (not sure about
rv410) is port 4,
IGP, rs480 is port 1, rs690 is port 4, rs780 is port 1. We need to
either guarantee these work
or fallback gracefully instead of failing to load the driver.
Dave.
> ? ? ? ?/* if we have > 1 VGA cards, then disable the radeon VGA resources */
> ? ? ? ?/* this will fail for cards that aren't VGA class devices, just
> ? ? ? ? * ignore it */
> @@ -701,6 +733,8 @@ void radeon_device_fini(struct radeon_device *rdev)
> ? ? ? ?destroy_workqueue(rdev->wq);
> ? ? ? ?vga_switcheroo_unregister_client(rdev->pdev);
> ? ? ? ?vga_client_register(rdev->pdev, NULL, NULL, NULL);
> + ? ? ? pci_iounmap(rdev->pdev, rdev->rio_mem);
> + ? ? ? rdev->rio_mem = NULL;
> ? ? ? ?iounmap(rdev->rmmio);
> ? ? ? ?rdev->rmmio = NULL;
> ?}
> --
> 1.7.0.1
>
>
[PATCH] drm/radeon/kms: add ioport register access
On Wed, Jul 7, 2010 at 12:29 AM, Dave Airlie wrote:
>> ?int radeon_atombios_init(struct radeon_device *rdev)
>> ?{
>> ? ? ? ?struct card_info *atom_card_info =
>> @@ -427,6 +443,9 @@ int radeon_atombios_init(struct radeon_device *rdev)
>> ? ? ? ?atom_card_info->dev = rdev->ddev;
>> ? ? ? ?atom_card_info->reg_read = cail_reg_read;
>> ? ? ? ?atom_card_info->reg_write = cail_reg_write;
>> + ? ? ? /* needed for iio ops */
>> + ? ? ? atom_card_info->ioreg_read = cail_ioreg_read;
>> + ? ? ? atom_card_info->ioreg_write = cail_ioreg_write;
>> ? ? ? ?atom_card_info->mc_read = cail_mc_read;
>> ? ? ? ?atom_card_info->mc_write = cail_mc_write;
>> ? ? ? ?atom_card_info->pll_read = cail_pll_read;
>> @@ -659,6 +678,19 @@ int radeon_device_init(struct radeon_device *rdev,
>> ? ? ? ?DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)rdev->rmmio_base);
>> ? ? ? ?DRM_INFO("register mmio size: %u\n", (unsigned)rdev->rmmio_size);
>>
>> + ? ? ? /* io port mapping */
>> + ? ? ? if (rdev->family >= CHIP_RV770) {
>> + ? ? ? ? ? ? ? rdev->rio_mem_size = pci_resource_len(rdev->pdev, 4);
>> + ? ? ? ? ? ? ? rdev->rio_mem = pci_iomap(rdev->pdev, 4, rdev->rio_mem_size);
>> + ? ? ? } else {
>> + ? ? ? ? ? ? ? rdev->rio_mem_size = pci_resource_len(rdev->pdev, 1);
>> + ? ? ? ? ? ? ? rdev->rio_mem = pci_iomap(rdev->pdev, 1, rdev->rio_mem_size);
>> + ? ? ? }
>> + ? ? ? if (rdev->rio_mem == NULL) {
>> + ? ? ? ? ? ? ? iounmap(rdev->rmmio);
>> + ? ? ? ? ? ? ? return -EIO;
>> + ? ? ? }
>> +
>
> This is all bad, my main r600 stopped working after this, from my
> quick boot test
> r100->r300 are all port 1, discrete r480 and upwards (not sure about
> rv410) is port 4,
> IGP, rs480 is port 1, rs690 is port 4, rs780 is port 1. We need to
> either guarantee these work
> or fallback gracefully instead of failing to load the driver.
>
The attached patch should handle it gracefully.
Alex
> Dave.
>
>> ? ? ? ?/* if we have > 1 VGA cards, then disable the radeon VGA resources */
>> ? ? ? ?/* this will fail for cards that aren't VGA class devices, just
>> ? ? ? ? * ignore it */
>> @@ -701,6 +733,8 @@ void radeon_device_fini(struct radeon_device *rdev)
>> ? ? ? ?destroy_workqueue(rdev->wq);
>> ? ? ? ?vga_switcheroo_unregister_client(rdev->pdev);
>> ? ? ? ?vga_client_register(rdev->pdev, NULL, NULL, NULL);
>> + ? ? ? pci_iounmap(rdev->pdev, rdev->rio_mem);
>> + ? ? ? rdev->rio_mem = NULL;
>> ? ? ? ?iounmap(rdev->rmmio);
>> ? ? ? ?rdev->rmmio = NULL;
>> ?}
>> --
>> 1.7.0.1
>>
>>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-ioport-fixes.patch
Type: text/x-patch
Size: 2766 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100707/e3c61214/attachment.bin>
[Bug 28940] New: rv515 (Mobility x1400) Display corruption after some time
https://bugs.freedesktop.org/show_bug.cgi?id=28940 Summary: rv515 (Mobility x1400) Display corruption after some time Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: gtdev at spearhead.de Created an attachment (id=36799) --> (https://bugs.freedesktop.org/attachment.cgi?id=36799) lspci output (graphics only) After some uptime (upwards of an hour so far), I get different kinds of display corruption on a laptop with a Radeon x1400. Currently, I'm looking at a somewhat grainy picture which looks like a badly dithered low-colour version of the screen content. There are noticeable vertical stripes, and the whole image is shimmering. The system is working fine otherwise. In an earlier instance, I had a pulsating green gradient covering the bottom of the screen. In addition, screen response was slow, like the proper content was only updating evers second or so. The effect does not show in screenshots. This is on a Debian-built 2.6.34 686 kernel, running X.org 1.7.7 and the "radeon" driver 6.13.0, libdrm2 2.4.21 from Debian packages. I'm attaching lspci output for the card, as well as dmesg and the Xorg.log from the currently "broken" running system. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28940] rv515 (Mobility x1400) Display corruption after some time
https://bugs.freedesktop.org/show_bug.cgi?id=28940 --- Comment #1 from Nicos Gollan 2010-07-07 02:55:01 PDT --- Created an attachment (id=36800) --> (https://bugs.freedesktop.org/attachment.cgi?id=36800) Xorg.log from a "broken" system -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28940] rv515 (Mobility x1400) Display corruption after some time
https://bugs.freedesktop.org/show_bug.cgi?id=28940 --- Comment #2 from Nicos Gollan 2010-07-07 02:55:36 PDT --- Created an attachment (id=36801) --> (https://bugs.freedesktop.org/attachment.cgi?id=36801) dmesg output from a "broken" system -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Report for 2.6.35-rc3-00262-g984bc96
Andrew Morton [Tue, Jul 06, 2010 at 07:42:22PM -0700]: > On Thu, 1 Jul 2010 09:40:52 +0200 Nico Schottelius schottelius.org> wrote: > > > Good morning! > > > > A short report on what's broken in 2.6.35-rc3-00262-g984bc96 with > > the Lenovo X201: > > So you see two post-2.6.34 regressions? I'm not 100% sure whether the netdev issue was not already part of 2.6.34. Just changed to 2.6.35-rc4, but noticed another issue on 2.6.35-rc3-00262-g984bc96: After several (>=3) resumes, the system completly freezes. Used to happen with 2.6.33 very often (always?), vanished with 2.6.34-something Cheers, Nico -- New PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 Please resign, if you signed 9885188C or 8D0E27A4. Currently moving *.schottelius.org to http://www.nico.schottelius.org/ ... -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100707/c9ab8d77/attachment-0001.pgp>
[Bug 28943] New: Red=cyan? Why?
https://bugs.freedesktop.org/show_bug.cgi?id=28943 Summary: Red=cyan? Why? Product: Mesa Version: unspecified Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/MGA AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: eblanca76 at users.sourceforge.net I'm having a strange color replacement in ubuntu 10.04. Hardware is matrox g550 agp dual head, 32 MB. Well, running silent hill 2 in wine, I have cyan blood when it should be red! Here you can read the (closed) bug: http://bugs.winehq.org/show_bug.cgi?id=17741 (there are a lot of details about the bug) I thought it was due to wine but it isn't, so it was closed as invalid. Please note, this `bug' appears since a couple of years ago and even now, with mesa 7.7.1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 24818] shadowtex demo doesn't work on rs780
https://bugs.freedesktop.org/show_bug.cgi?id=24818 --- Comment #7 from Andy Furniss 2010-07-07 04:37:38 PDT --- (In reply to comment #4) > I can confirm this using mesa master and RV620. > > I've noticed that corruption is random as I restart shadowtex demo until some > time. After starting it for example 10th time, corruption stops changing. So > it > indeed looks like using some random data from VRAM or something. After having > "stable" corruption I've to reboot to get random corruptions again (for a few > shadowtex restarts). Seems like there's been a further regression - probably in mesa master during the last few weeks. I now can't run this at all - shadowtex: r700_assembler.c:6355: Process_Export: Assertion `starting_register_number >= pAsm->starting_export_register_number' failed. Anyone else getting this? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 Tom Stellard changed: What|Removed |Added Attachment #36773|0 |1 is obsolete|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28932] KWin crash (KDE 4.4.90) during call to r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=28932 --- Comment #4 from Darin McBride 2010-07-07 11:34:09 PDT --- Ok, I've installed mesa from git, and, oddly, now the backtrace doesn't show function names in r600_dri.so... but obviously the fact I'm getting a backtrace again means I'm still hitting the problem. :-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 --- Comment #9 from Tom Stellard 2010-07-07 11:34:27 PDT --- Created an attachment (id=36839) View: https://bugs.freedesktop.org/attachment.cgi?id=36839 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36839 Possible Fix. Can you try again with this patch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 --- Comment #10 from Scott Moreau 2010-07-07 13:15:31 PDT --- Created an attachment (id=36845) --> (https://bugs.freedesktop.org/attachment.cgi?id=36845) compiz crash (In reply to comment #9) > Created an attachment (id=36839) View: https://bugs.freedesktop.org/attachment.cgi?id=36839 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36839 > Possible Fix. > > Can you try again with this patch. This patch works, but it only worked the first time I tried it. Since restarting compiz, it crashes after falling back to software routines for whatever reason. It doesn't matter if the effect is enabled at (compiz) runtime or if it's disabled at runtime then enabled after compiz has fully started. I have attached the bt. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28606] [r300g]: Compiz focus blur effect does not work. (causes black windows instead)
https://bugs.freedesktop.org/show_bug.cgi?id=28606 --- Comment #11 from Scott Moreau 2010-07-07 13:30:54 PDT --- (In reply to comment #9) > Created an attachment (id=36839) View: https://bugs.freedesktop.org/attachment.cgi?id=36839 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36839 > Possible Fix. > > Can you try again with this patch. (In reply to comment #10) > Created an attachment (id=36845) --> (https://bugs.freedesktop.org/attachment.cgi?id=36845) > compiz crash > > (In reply to comment #9) > > Created an attachment (id=36839) View: https://bugs.freedesktop.org/attachment.cgi?id=36839 Review: https://bugs.freedesktop.org/review?bug=28606&attachment=36839 > > Possible Fix. > > > > Can you try again with this patch. > > This patch works, but it only worked the first time I tried it. Because I failed to use the gallium driver. This bt is from classic mesa and can be ignored. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 01/18] drm: use noop_llseek
The drm device drivers currently allow seeking on the
character device but never care about the actual
file position.
When we change the default llseek operation to be
no_llseek, calling llseek on a drm device would
return an error condition, which is an API change.
Explicitly setting noop_llseek lets us keep the
current API.
Signed-off-by: Arnd Bergmann
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
Documentation/DocBook/drm.tmpl|1 +
drivers/gpu/drm/i810/i810_drv.c |1 +
drivers/gpu/drm/i830/i830_drv.c |1 +
drivers/gpu/drm/i915/i915_drv.c |1 +
drivers/gpu/drm/mga/mga_drv.c |1 +
drivers/gpu/drm/nouveau/nouveau_drv.c |1 +
drivers/gpu/drm/r128/r128_drv.c |1 +
drivers/gpu/drm/radeon/radeon_drv.c |1 +
drivers/gpu/drm/savage/savage_drv.c |1 +
drivers/gpu/drm/sis/sis_drv.c |1 +
drivers/gpu/drm/tdfx/tdfx_drv.c |1 +
drivers/gpu/drm/via/via_drv.c |1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 +
13 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 910c923..2861055 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -136,6 +136,7 @@
#ifdef CONFIG_COMPAT
.compat_ioctl = i915_compat_ioctl,
#endif
+ .llseek = noop_llseek,
},
.pci_driver = {
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
index c1e0275..199fdfa 100644
--- a/drivers/gpu/drm/i810/i810_drv.c
+++ b/drivers/gpu/drm/i810/i810_drv.c
@@ -63,6 +63,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/i830/i830_drv.c b/drivers/gpu/drm/i830/i830_drv.c
index 44f990b..3be1d7d 100644
--- a/drivers/gpu/drm/i830/i830_drv.c
+++ b/drivers/gpu/drm/i830/i830_drv.c
@@ -74,6 +74,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 423dc90..bd8c139 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -547,6 +547,7 @@ static struct drm_driver driver = {
#ifdef CONFIG_COMPAT
.compat_ioctl = i915_compat_ioctl,
#endif
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/mga/mga_drv.c b/drivers/gpu/drm/mga/mga_drv.c
index ddfe161..524185f 100644
--- a/drivers/gpu/drm/mga/mga_drv.c
+++ b/drivers/gpu/drm/mga/mga_drv.c
@@ -75,6 +75,7 @@ static struct drm_driver driver = {
#ifdef CONFIG_COMPAT
.compat_ioctl = mga_compat_ioctl,
#endif
+ .llseek = noop_llseek,
},
.pci_driver = {
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 2737704..9505fa6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -400,6 +400,7 @@ static struct drm_driver driver = {
#if defined(CONFIG_COMPAT)
.compat_ioctl = nouveau_compat_ioctl,
#endif
+ .llseek = noop_llseek,
},
.pci_driver = {
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
index b806fdc..dc22c6e 100644
--- a/drivers/gpu/drm/r128/r128_drv.c
+++ b/drivers/gpu/drm/r128/r128_drv.c
@@ -71,6 +71,7 @@ static struct drm_driver driver = {
#ifdef CONFIG_COMPAT
.compat_ioctl = r128_compat_ioctl,
#endif
+ .llseek = noop_llseek,
},
.pci_driver = {
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index e166fe4..e79dcf5 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -218,6 +218,7 @@ static struct drm_driver driver_old = {
#ifdef CONFIG_COMPAT
.compat_ioctl = radeon_compat_ioctl,
#endif
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/savage/savage_drv.c
b/drivers/gpu/drm/savage/savage_drv.c
index 021de44..2a2830f 100644
--- a/drivers/gpu/drm/savage/savage_drv.c
+++ b/drivers/gpu/drm/savage/savage_drv.c
@@ -54,6 +54,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
+.llseek = noop_llseek,
},
.pci_driver = {
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_
[Bug 28955] New: [r300g]: refresh/update/damage issues using compiz.
https://bugs.freedesktop.org/show_bug.cgi?id=28955 Summary: [r300g]: refresh/update/damage issues using compiz. Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: oreaus at gmail.com Created an attachment (id=36846) --> (https://bugs.freedesktop.org/attachment.cgi?id=36846) example Can reproduce reliably, running any compiz with r300g on rv350. While the screen is not being damaged (you can see with showrepaint plugin) any change in a window is not updated until some other window moves in front of it or animation happens in the area. It used to work a few months ago as far as I can remember, but I could not find a good commit to bisect with that would build and wouldn't crash compiz when trying to start it. Steps to reproduce: 1) Start compiz with r300g on rv350 2) Make sure the screen isn't already being damaged, then click on something in ccsm or go to a different webpage in a browser or use an irc client with text scrolling up (a terminal or any other window can also be affected) 3) Observe issue -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
