On Wed, May 23, 2012 at 08:59:07AM +0200, Zdenek Kabelac wrote: > 2012/5/23 Sean Paul <seanpaul at chromium.org>: > > On Tue, May 22, 2012 at 6:15 PM, Zdenek Kabelac > > <zdenek.kabelac at gmail.com> wrote: > >> 2012/5/22 Zdenek Kabelac <zdenek.kabelac at gmail.com>: > >>> 2012/5/22 Daniel Vetter <daniel at ffwll.ch>: > >>>> On Tue, May 22, 2012 at 04:36:30PM +0200, Zdenek Kabelac wrote: > >>>>> 2012/5/22 Daniel Vetter <daniel at ffwll.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 at ffwll.ch Mobile: +41 (0)79 365 57 48
