Bug 43071
| Summary: | [945gm regression] laptop screen aligned left at lower resolutions | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Hans de Bruin (jmdebruin) |
| Component: | Video(DRI - Intel) | Assignee: | drivers_video-dri-intel (drivers_video-dri-intel) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | chris, daniel, florian |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.4.0-rc1 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
output lspci
normal behaviour regression regression xrandr output intel_reg_dumper normal behaviour 800x600 intel_reg_dumper regression 800x600 restore set_crtcinfo calls Comment #8: 3.3.0 640x480 xrandr -- verbose Comment #9 dmesg_3.4-rc2+ Comment #10 intel_reg_dumper_800x600_patch001.txt Comment #14 dmesg_3.3.0 don't clobber the special upsacling lvds timings |
||
|
Description
Hans de Bruin
2012-04-08 08:02:00 UTC
Ok, a few things to check: - Please install v1.2 of intel-gpu-tools and grab the full output of intel_reg_dumper for both a working kernel and a broken kernel. - Please attach the output of xrandr --verbose when using one of these lower resolutions. - For clarification, please attach working/broken pictures (quality doesn't really matter). - Does reverting the offending commit on top of -rc1 fix your problems? Created attachment 72864 [details]
normal behaviour
Created attachment 72865 [details]
regression
Created attachment 72866 [details]
regression xrandr output
I ran into some dependencies when compiling intel-gpu-tools. I will try to sort them out on Wednesday. Created attachment 72880 [details]
intel_reg_dumper normal behaviour 800x600
Created attachment 72881 [details]
intel_reg_dumper regression 800x600
It's programmed a completely different mode:
HTOTAL_B: 0x058a04ff (1280 active, 1419 total)
HBLANK_B: 0x058a04ff (1280 start, 1419 end)
HSYNC_B: 0x054f052f (1328 start, 1360 end)
VTOTAL_B: 0x032f031f (800 active, 816 total)
VBLANK_B: 0x032f031f (800 start, 816 end)
VSYNC_B: 0x03280322 (803 start, 809 end)
versus:
HTOTAL_B: 0x058a0429 (1066 active, 1419 total)
HBLANK_B: 0x05200495 (1174 start, 1313 end)
HSYNC_B: 0x04eb04cb (1228 start, 1260 end)
VTOTAL_B: 0x032f031f (800 active, 816 total)
VBLANK_B: 0x032f031f (800 start, 816 end)
VSYNC_B: 0x03280322 (803 start, 809 end)
For reference, the BIOS used (1280x1024):
HTOTAL_A: 0x06af04ff (1280 active, 1712 total)
HBLANK_A: 0x06af04ff (1280 start, 1712 end)
HSYNC_A: 0x05d70557 (1368 start, 1496 end)
VTOTAL_A: 0x044f03ff (1024 active, 1104 total)
VBLANK_A: 0x044f03ff (1024 start, 1104 end)
VSYNC_A: 0x04090402 (1027 start, 1034 end)
can you also please attach the normal xrandr --verbose.
Also please boot with drm.debug=0xe added to the kernel cmdline and attach the full dmesg. Doesn't really matter much which kernel. Created attachment 72882 [details]
restore set_crtcinfo calls
Please test the attached patch. I don't have an idea how this could fix things yet, but given your registers dumps and the bisected commit, this is the most likely thing to try imho.
Created attachment 72883 [details] Comment #8: 3.3.0 640x480 xrandr -- verbose So the bug is completely internal to the mode calculation. And set_crtcinfo is just plain magic (or as Daniel is discovering used to sweep bugs under the carpet). Created attachment 72884 [details] Comment #9 dmesg_3.4-rc2+ The attached dmesg isn't really complete, I guess a few things got lost due to a small logbuffer. You can increase that by adding log_buf_len=4M to your kernel cmdline and grab the dmesg again. Please make sure that everything starting from early boot is in it. Created attachment 72886 [details] Comment #10 intel_reg_dumper_800x600_patch001.txt The patch did not help. Created attachment 72887 [details] Comment #14 dmesg_3.3.0 This looks complete. after I inserted a usb drive I switched to 800x600. Comment #1 - Does reverting the offending commit on top of -rc1 fix your problems? reverting on top of rc2+ fixes my problem. Created attachment 72906 [details]
don't clobber the special upsacling lvds timings
Ok, I think I see what's going on. Let's see whether I also can write a patch that works for you. Please test.
Daniel, I applied on top of rc2. The regression has gone. I have switched back and forth to all the resolution my laptop screen supports, Had some fun with an old game running on xdosemu. It looks like you have succeeded. I will close the bug when the patch enters mainline. Changing to patch_aready_available to make the regression tracking team happy, code_fix is for when the fix has landed in Linus' tree. resolved by commit 19853301ef3289bda2d5264c1093e74efddaeab9 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux A patch referencing this bug report has been merged in Linux v3.4-rc4: commit f9bef081c3c3f77bec54454872e98d3ec635756f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Apr 15 19:53:19 2012 +0200 drm/i915: don't clobber the special upscaling lvds timings A patch referencing a commit referencing this bug report has been merged in Linux v3.5-rc1: commit f7bacf195e100a028eaa26c4b5f5e07665d51cee Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu May 3 15:51:58 2012 +0200 drm/i915: rip out unnecessary calls to drm_mode_set_crtcinfo |