| Summary: | [i915] page-flipping breaks extended desktop display with Compiz enabled | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | fangxun <xunx.fang> |
| Component: | Drivers/DRI/i915 | Assignee: | Chris Wilson <chris> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | CC: | martyj19, tmezzadra |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
xorg log
dmesg with debug=4 fix for flip offset bug |
||
Oh I missed this one, have you bisected? (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. This works fine on post-965. If disable pageflip, it works fine. Can you check #28788 and see if those tests behave the same way for you as well? "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. 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. 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 ..... 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? 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 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? Yeah seems to be working for me with the latest bits as well. (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 xorg master from git today libdrm master from git drm-intel-next from git xf86-video-intel from git mesa master from git 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 Lets start with a drm.debug=4 dmesg to check that the modes are being setup correctly. Created attachment 37298 [details]
dmesg with debug=4
OS is Fedora 12, desktop is gnome with compiz.
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). 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. (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. I confirm this patch fixed it. 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> Mark it as verified. 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. 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? 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. 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. 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. 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); Fixed in Chris's last patchset, I'll let him close this one out. Upstream: http://cgit.freedesktop.org/~ickle/drm-intel/ drm-intel-fixes Closed. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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