Date:	Wed, 23 May 2012 09:07:28 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Zdenek Kabelac <zdenek.kabelac@...il.com>
Cc:	Sean Paul <seanpaul@...omium.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	intel-gfx@...ts.freedesktop.org, daniel@...ll.ch,
	jbarnes@...tuousgeek.org
Subject: Re: Regression on GMA965 - display seems to have slow jump changes
 in brightness

On Wed, May 23, 2012 at 08:59:07AM +0200, Zdenek Kabelac wrote:
> 2012/5/23 Sean Paul <seanpaul@...omium.org>:
> > On Tue, May 22, 2012 at 6:15 PM, Zdenek Kabelac
> > <zdenek.kabelac@...il.com> wrote:
> >> 2012/5/22 Zdenek Kabelac <zdenek.kabelac@...il.com>:
> >>> 2012/5/22 Daniel Vetter <daniel@...ll.ch>:
> >>>> On Tue, May 22, 2012 at 04:36:30PM +0200, Zdenek Kabelac wrote:
> >>>>> 2012/5/22 Daniel Vetter <daniel@...ll.ch>:
> >>>>> > On Tue, May 22, 2012 at 02:08:46PM +0200, Zdenek Kabelac wrote:
> >>>>> >> Hi
> >>>>> >>
> >>>>> >> I've updated to 3.4 kernel, and now I'm noticing slight changes in
> >>>>> >> brightness on colorful images.
> >>>>> >> It seems the change is mostly visibly on  'darker' images i.e. it's
> >>>>> >> not really visible on white background.
> >>>>> >>
> >>>>> >> When I reboot back to 3.3  kernel - brightness changes are gone - so I
> >>>>> >> do not suspect hw fault of my T61 display.
> >>>>> >> I guess once in past there has been already such bug, so this problem
> >>>>> >> seems to me like reintroducing the same
> >>>>> >> problem again.
> >>>>> >>
> >>>>> >> xorg-x11-server-Xorg-1.12.1-1.fc18.x86_64
> >>>>> >> with SNA intel driver build from git repo.
> >>>>> >> T61, 965GM
> >>>>> >>
> >>>>> >> Is this a know issue ?
> >>>>> >> Is bisect needed ?
> >>>>> >
> >>>>> > You're the first one to report things, so a bisect would be highly
> >>>>> > appreciated. Also I'm a bit confused about what you mean by 'changing
> >>>>> > brightness'. Can you please try to explain this a bit more?
> >>>>> >
> >>>>>
> >>>>> I've some default gnome picture like this one:
> >>>>> https://lh6.googleusercontent.com/-96ZhFbfLX_M/ThHsm0ZxBgI/AAAAAAAAFQQ/3ApjzYgulso/s400/gnome-3-login-screen.png
> >>>>>
> >>>>> When I watch the picture for some period of time  I'm noticing slight
> >>>>> changes in the picture brightness looking like small change in LUT
> >>>>> table or something like that.
> >>>>> If the picture is white I'm not noticing any change.
> >>>>> (Initially I've thought my display dies - but reboot to 3.3 fixed the
> >>>>> issue immediately).
> >>>>
> >>>> "for some period", does that mean it takes you a while to notice the
> >>>> changes (because they're tiny), or are the changes happend just rather slowly?
> >>>>
> >>>
> >>> Deviation in picture is not huge - but gets noticeable by my eyes and
> >>> it's annoying,
> >>> it's like several seconds between each minor change.
> >>>
> >>> If I've monotone background in i.e. text editor  the change is
> >>> practically not visibible,
> >>> but if watch some digicam photos full screen they are quite obvious.
> >>>
> >>> Not sure if that has any influence (not tested without)  I'm using
> >>> some icc profile
> >>> ('xcalib') to get away from blue of IBM display.
> >>>
> >>>>> Is there any suspecting patch for this chipset I should try to revert ?
> >>>>
> >>>> Tbh I have no idea. If there's no changes when the picture is white, it
> >>>> can't be the backlight, we haven't frobbed around with the gamma stuff and
> >>>> temporal dithering is disabled, too. If you can bisect this it would
> >>>> greatly help.
> >>>
> >>> ok, I'll play this game in the evening if there is nothing obvious.
> >>>
> >>
> >> And we have a winner - cec2f356d59d9e070413e5966a3c5a1af136d948
> >>
> >
> > Hmm, seems like your display doesn't like to be downclocked, or rather
> > you don't like it to be downclocked :) The reason this patch triggered
> > it is because it does a better job of finding a compatible clock. You
> > can disable lvds downclocking on the kernel command line by setting
> > i915.lvds_downclock=0
> >
> 
> Hmm I've been using i915.lvds_downclock=1 on grub command line, and
> haven't noticed any visible problems with 3.3 kernel. So I'd rather
> ask if the problematic patch isn't doing downclocking in a wrong way?
> Or maybe detection that downclocking is not supported properly is not
> correct now ?

Nope, Sean's analysis is pretty much correct, that patch only makes
downclocking possible in more circumstances. And downclocking can
certainly explain what you're seeing, the backlight pwm signal is driven
off the panel dotclock, so if we change that we can very likely cause some
funny interference. I guess we could frob the backligth control settings
and adjust them for the change in clockspeed, but the current backlight
code is a bit a mess. So right now I suggest you just drop that option -
there are reasons it's not the default ;-)
-Daniel
-- 
Daniel Vetter
Mail: daniel@...ll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists