Bug 31942

Summary: G41 KMS display is "blurry" in console & Xorg
Product: DRI Reporter: Ben Kohler <bkohler>
Component: DRM/IntelAssignee: Chris Wilson <chris>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: medium CC: jbarnes
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
photo of blurry vs crisp
none
intel_reg_dumper output from bad kernel
none
intel_reg_dumper output from good kernel
none
Disable pfitter for 1:1 scaling
none
Disable pfitter for 1:1 scaling
none
xrandr output
none
Only use pfit with lvds none

Description Ben Kohler 2010-11-26 14:41:38 UTC
Starting with kernel 2.6.37_rc1, I noticed that the display was obviously "blurry", it looked like I was using a non-native res and the LCD was having to resize/interpolate.  It's blurry as soon as KMS takes over, and stays blurry after xorg starts.

I verified via dmesg, xrandr, xorg logs, & the LCD's own OSD that it was indeed using the native mode correctly.  I'm going to see if I can find a camera good enough to see the problem.

I did a git bisect on the kernel and traced it to commit e9e331a8abeece1565d383510ed985945132ffe3
Comment 1 Ben Kohler 2010-11-26 15:02:18 UTC
Forgot to mention some possibly important details.  It's Intel G41 video onboard a Dell Optiplex 380.  The monitor is a Samsung 2494SW, connected via DVI.  

I have kernels built from the commits right before & after the breakage, let me know if you need info from either.
Comment 2 Chris Wilson 2010-11-27 01:38:17 UTC
A camera would be good so that I know what type of artifact is being generate. Can you also grab an intel_reg_dumper with working/blurry kernel just to confirm that the registers are indeed the same and it is "merely" a timing issue whilst bringing the panel up.
Comment 3 Ben Kohler 2010-11-28 11:43:17 UTC
Created attachment 40616 [details]
photo of blurry vs crisp

This is the best photo I can get for now.  The top of the pic is the blurry/broken one, the bottom is working/crisp.  You can see quite a difference on the words "login" and "ben" especially.
Comment 4 Ben Kohler 2010-11-28 12:29:56 UTC
I don't see intel_reg_dumper anywhere after building intel-gpu-tools, is it still named the same?  I do have intel_gpu_dump, and its output is identical on either kernel (confirmed via diff).
Comment 5 Chris Wilson 2010-11-28 12:42:08 UTC
Horizontal sub-pixel interpolation. Looks like the panel-fitter is incorrectly programmed.

intel_reg_dumper is not available in the tarball but can be found in the git repo: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools

Thanks.
Comment 6 Ben Kohler 2010-11-28 13:14:02 UTC
Created attachment 40618 [details]
intel_reg_dumper output from bad kernel
Comment 7 Ben Kohler 2010-11-28 13:15:05 UTC
Created attachment 40619 [details]
intel_reg_dumper output from good kernel

$ diff intel_reg_dumper-bad.txt intel_reg_dumper-good.txt 
44,45c44,45
<         PFIT_CONTROL: 0x80000000
<      PFIT_PGM_RATIOS: 0x10001000
---
>         PFIT_CONTROL: 0x00000000
>      PFIT_PGM_RATIOS: 0x0d551000
Comment 8 Chris Wilson 2010-11-29 08:21:04 UTC
Ben, can you also add the output of xrandr? For gen4 hw we should not be touching pgm_ratios at all (so I presume the 1:1 scale-factor there is a residual value from the BIOS). The difference appears that we now always enable auto-scaling for gen4 with the aspect-preserving fullscreen mode.
Comment 9 Chris Wilson 2010-11-29 08:21:30 UTC
Created attachment 40637 [details] [review]
Disable pfitter for 1:1 scaling
Comment 10 Ben Kohler 2010-11-29 09:31:06 UTC
$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
DVI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 287mm
   1920x1080      60.0*+
   1280x1024      75.0     60.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1
Comment 11 Chris Wilson 2010-11-29 09:41:13 UTC
Sorry, actually wanted xrandr --verbose, so I can see which scaling mode is active for the panel.
Comment 12 Chris Wilson 2010-11-29 09:41:38 UTC
Created attachment 40640 [details] [review]
Disable pfitter for 1:1 scaling
Comment 13 Chris Wilson 2010-11-29 09:46:59 UTC
/me slaps himself.

I missed the obvious, there is no LVDS on these systems - the panel fitter should be disabled in these cases.
Comment 14 Ben Kohler 2010-11-29 09:50:34 UTC
Created attachment 40642 [details]
xrandr output

xrandr output is the same on bad vs good kernels (except for 2 timestamp lines)
Comment 15 Chris Wilson 2010-11-29 10:02:15 UTC
Created attachment 40643 [details] [review]
Only use pfit with lvds
Comment 16 Ben Kohler 2010-11-29 10:27:59 UTC
I'm not going to pretend to know what's going on in that last patch(0001-drm-i915-Clear-pfit-registers-when-not-used-by-any-o.patch), but it does seem to fix the problem for me, applied against vanilla 2.6.37-rc3
Comment 17 Chris Wilson 2010-11-29 10:45:58 UTC
Ben, thanks a lot for the report and testing.

I've queued the fix for upstream:

commit c5d1b51d3559664920136b45f4d2366ed9a9e8be
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Nov 29 18:00:23 2010 +0000

    drm/i915: Clear pfit registers when not used by any outputs
    
    ... otherwise the panel-fitter may be left enabled with random settings
    and cause unintended filtering (i.e. blurring of native modes on external
    panels).
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31942
    Reported-and-tested-by: Ben Kohler <bkohler@gmail.com>
    Tested-by: Ciprian Docan <docan@eden.rutgers.edu>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

and will push as soon as kernel.org is up again.

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.