Bug 28518 - [i915] page-flipping breaks extended desktop display with Compiz enabled
[i915] page-flipping breaks extended desktop display with Compiz enabled
Status: VERIFIED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915
unspecified
All Linux (All)
: medium major
Assigned To: Chris Wilson
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-13 03:10 UTC by fangxun
Modified: 2012-01-04 01:53 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg log (78.96 KB, text/plain)
2010-06-13 03:10 UTC, fangxun
Details
dmesg with debug=4 (92.25 KB, text/plain)
2010-07-22 01:55 UTC, fangxun
Details
fix for flip offset bug (2.05 KB, patch)
2010-07-23 12:02 UTC, Jesse Barnes
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description fangxun 2010-06-13 03:10:44 UTC
Created attachment 36244 [details]
xorg log

System Environment:
--------------------------
Arch:          i386
Platform:      pineview
Libdrm:        master)2.4.21
Mesa:     (7.8)mesa_7_6_1_rc1-5913-g1f756d916a48393ce4ff7c284193e48a510c175b
Xserver:      (server-1.8-branch)xorg-server-1.8.1
Xf86_video_intel: (master)2.11.0-169-g5a0a8a1cf6d9b0616d6a097e783f2aa318b45736
Kernel:  (master)e40152ee1e1c7a63f4777791863215e3faa37a86

Bug detailed description:
-------------------------
Display on Secondary(VGA) is the same as primary(LVDS). It seems as clone mode, but it is different to clone mode. We can't do any operations on Secondary display except that Mouse can be moved from Primary to Secondary display. It works well with no compiz.

Reproduce steps:
----------------
1. VGA output plugged in
2. start X and gnome desktop with compiz
3. xrandr --output LVDS1 --left-of VGA1
Comment 1 Jesse Barnes 2010-06-21 18:21:12 UTC
Oh I missed this one, have you bisected?
Comment 2 Gordon Jin 2010-06-23 02:09:34 UTC
(In reply to comment #1)
> Oh I missed this one, have you bisected?

It's hard to bisect as this usage has been blocked by other bugs:
First compiz failed since swapbuffers merge in Jan.: bug#26162
Then extended desktop displays error: bug#27408
After bug#27408 fixed, we are seeing this one.
Comment 3 Gordon Jin 2010-06-23 02:10:12 UTC
This works fine on post-965.
Comment 4 fangxun 2010-06-23 21:52:12 UTC
If disable pageflip, it works fine.
Comment 5 Jesse Barnes 2010-06-29 14:14:32 UTC
Can you check #28788 and see if those tests behave the same way for you as well?
Comment 6 fangxun 2010-06-30 03:59:39 UTC
"vbltest -s" returns correct frequency(59.85Hz).

"modetest -v" returns output like:
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 3, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 3, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 3, (OK)
drmGetBusid returned ''
trying to load module i915...success.
Comment 7 Jesse Barnes 2010-07-01 13:10:37 UTC
modetest requires other arguments, try modetest -h to see.  I use something like modetest -s 7:1024x600 -v on my aspire one to perform page flipping tests with a 1024x600 mode on the internal lvds.
Comment 8 fangxun 2010-07-02 01:50:53 UTC
Tested on Pineview:
"vbltest -s" returns correct frequency(59.85Hz).

When run "modetest -v -s 7:1024x600", a colorful picture flips and returns output like:
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 3, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 3, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 3, (OK)
drmGetBusid returned ''
trying to load module i915...success.
setting mode 1024x600 on connector 7, crtc 4
freq: 59.96Hz
freq: 59.85Hz
freq: 59.85Hz
freq: 59.85Hz
freq: 59.85Hz
freq: 59.85Hz
freq: 59.85Hz
......


Tested on Aapire1:
"vbltest -s" returns incorrect frequency, output like:
freq: 10.80Hz
freq: 11.11Hz
freq: 12.93Hz
freq: 10.91Hz
freq: 11.06Hz
freq: 11.88Hz
freq: 11.04Hz
freq: 10.82Hz
freq: 11.83Hz
.....

When run "modetest -v -s 7:1024x600", a colorful picture flips and returns output like:
freq: 17.62Hz
freq: 14.76Hz
freq: 16.26Hz
freq: 15.71Hz
freq: 14.89Hz
freq: 15.10Hz
freq: 15.09Hz
freq: 14.83Hz
.....
Comment 9 Jesse Barnes 2010-07-02 09:26:10 UTC
aspireone has what looks like a platform related interrupt handling bug.  You can work around it by booting with "clocksource=tsc".  Does it work better if you do that?
Comment 10 fangxun 2010-07-05 03:41:04 UTC
Works better with "clocksource=tsc" on aspire1.  
"vbltest -s" returns correct frequency(62.02Hz). 
"modetest -v -s 7:1024x600", a colorful picture flips and returns
output like:
freq: 62.79Hz
freq: 62.02Hz
freq: 62.02Hz
Comment 11 Chris Wilson 2010-07-19 09:55:40 UTC
Using a variety of developments trees, but loosely off master, I followed the simple steps but I'm just seeing a normal extended desktop.

Fangxun, can you please check to see if the bug still exists in the Q2 release and current tip?
Comment 12 Jesse Barnes 2010-07-19 11:42:09 UTC
Yeah seems to be working for me with the latest bits as well.
Comment 13 Tomas M. 2010-07-19 14:35:07 UTC
(In reply to comment #12)
> Yeah seems to be working for me with the latest bits as well.

describe latest bits.

ive just tried

xf86-video-intel from git
kernel 2.6.35-rc5
xorg 1.8.2 RC2

and the issue is still there
Comment 14 Jesse Barnes 2010-07-19 14:40:37 UTC
xorg master from git today
libdrm master from git
drm-intel-next from git
xf86-video-intel from git
mesa master from git
Comment 15 fangxun 2010-07-20 02:32:59 UTC
This issue still exists in the Q2 release and current tip.
I've tried with these:
xorg master from git today
libdrm master from git
drm-intel-next from git
xf86-video-intel master from git
mesa master from git
Comment 16 Chris Wilson 2010-07-21 02:40:35 UTC
Lets start with a drm.debug=4 dmesg to check that the modes are being setup correctly.
Comment 17 fangxun 2010-07-22 01:55:24 UTC
Created attachment 37298 [details]
dmesg with debug=4

OS is Fedora 12, desktop is gnome with compiz.
Comment 18 Jesse Barnes 2010-07-23 11:25:30 UTC
So you're setting both monitors to 800x600?  And the LVDS has a native mode of 1024x600?  That's the same config I'm running, but I actually tried a 1024x600 mode on the VGA output (had to add a modeline for it).  I'll try 800x600 again (using Ubuntu with GNOME+compiz).
Comment 19 Jesse Barnes 2010-07-23 12:02:44 UTC
Created attachment 37341 [details] [review]
fix for flip offset bug

Does this patch work for you?  I think I reproduced the issue and this fixed it.
Comment 20 Tomas M. 2010-07-23 19:31:28 UTC
(In reply to comment #19)
> Created an attachment (id=37341) [details]
> fix for flip offset bug
> 
> Does this patch work for you?  I think I reproduced the issue and this fixed
> it.

this patch fixes it for me.
Comment 21 fangxun 2010-07-25 21:49:02 UTC
I confirm this patch fixed it.
Comment 22 Jesse Barnes 2010-07-26 11:50:13 UTC
author	Jesse Barnes <jbarnes@virtuousgeek.org>	
	Fri, 23 Jul 2010 19:03:37 +0000 (12:03 -0700)
committer	Eric Anholt <eric@anholt.net>	
	Mon, 26 Jul 2010 17:45:55 +0000 (10:45 -0700)
commit	be9a3dbf65a69933b06011f049b1e2fdfa6bc8b9
tree	b6f127f19fc374bbdf8932b945c65f2a86d00703	tree | snapshot
parent	6f772d7e2f4105470b9f3d0f0b26f06f61b1278d	commit | diff
drm/i915: handle shared framebuffers when flipping

If a framebuffer is shared across CRTCs, the x,y position of one of them
is likely to be something other than the origin (e.g. for extended
desktop configs).  So calculate the offset at flip time so such
configurations can work.

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

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Thomas M. <tmezzadra@gmail.com>
Tested-by: fangxun <xunx.fang@intel.com>
Cc: stable@kernel.org
Signed-off-by: Eric Anholt <eric@anholt.net>
Comment 23 fangxun 2010-07-27 23:29:08 UTC
Mark it as verified.
Comment 24 Marty Jack 2010-08-08 14:23:25 UTC
Regression in 2.6.35 traced to this commit.  See recent posts to xorg mailing list "Kernel 2.6.35 misalignment".  My failure is on a DH57DD, i5-661, Intel 2.12.0, server 1.8.2, Mesa 7.8.2, the only difference between working and not working being 2.6.34.1 vs. 2.6.35.

I have a dual monitor, as follows.

Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 8192 x 8192
HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
HDMI2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 433mm x 271mm

On 2.6.35 about a quarter inch of the left side of what is on HDMI1 is displayed at the very right of HDMI2 (it is also in the correct position on HDMI1).

Also, the HDMI2 display is displaced about an inch and a half to the left, with black between that and the bogus left side of HDMI1.  The leftmost part of HDMI2 is nowhere on either monitor.  If I move a window on HDMI1 to the right until it starts to appear on HDMI2, that inch and a half is missing by the time it just starts to appear on HDMI2.

Reverting this one commit in 2.6.35 solves my failure, but would reintroduce the original problem.  Hopefully you can find a fix that solves both.
Comment 25 Jesse Barnes 2010-08-10 14:11:25 UTC
Hm, strange, afaict the offsets and flip programming look correct for ILK, which is what you have.

Ah, but the offsets work differently on 965+.  Does https://patchwork.kernel.org/patch/118217/ work for you?
Comment 26 Marty Jack 2010-08-11 10:46:52 UTC
Didn't work when I tried it, got nicely colored hash.  Didn't want to play around too much after that and maybe break the hardware.

However, that function is quite different between git head and 2.6.35 in the area of having new conditionals for IS_GEN3(dev) and a new loop to wait for the flip, I had to backport it quite a bit, and maybe I made a mistake, although I don't see one.  There's also a touch to that file between 2.6.35 and the newly released 2.6.35.1, so that will be an extra complication.

Sorry I can't be more encouraging.  Nothing worse than wrong hardware docs, which this case apparently hits bigtime.  If you give me something that would apply clean to 2.6.35.1 and that you've blessed, I'll give it another shot.  Until then I can run happily with a revert of the original change.
Comment 27 Marty Jack 2010-08-11 11:34:47 UTC
I am troubled by the amount of reprogramming of the registers that is being claimed necessary here.  It seems to me the fact that the 2.6.34.1 driver works is being overlooked when you suggest, for example, that the tiling mode is in the wrong register.
Comment 28 Jesse Barnes 2010-08-11 12:24:40 UTC
We know why 2.6.34.1 works and current code breaks.  Chris's patch just tried to introduce some other changes as well, which kept things from working.  The latest set you were cc'd on should work ok though, and it should apply to the drm-intel-next branch.
Comment 29 Marty Jack 2010-08-11 12:58:11 UTC
The intel_display.c from drm-intel-next overlaid onto 2.6.35 works only if I put back the register programming the way it was originally.  It produces the severe hash I experienced earlier if I use intel_display.c unmodified.  I am running on it now.

martyj:/usr/src/linux-2.6.35/drivers/gpu/drm/i915$ diff intel_display.c intel_display.c~4797c4797
< 		OUT_RING(fb->pitch);
---
> 		OUT_RING(fb->pitch | obj_priv->tiling_mode);
4802c4802
< 		OUT_RING(obj_priv->gtt_offset | obj_priv->tiling_mode);
---
> 		OUT_RING(obj_priv->gtt_offset);
Comment 30 Jesse Barnes 2010-08-23 13:58:11 UTC
Fixed in Chris's last patchset, I'll let him close this one out.
Comment 31 Chris Wilson 2010-09-06 04:22:25 UTC
Upstream: http://cgit.freedesktop.org/~ickle/drm-intel/ drm-intel-fixes
Comment 32 fangxun 2012-01-04 01:53:44 UTC
Closed.