linux-kernel - Re: Regression on GMA965 - display seems to have slow jump changes in brightness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJJYPdnoEu6QGuACUn0e10TG3XQQsaM5AqfbhqRbH6pwUQoVwg@mail.gmail.com>
Date:	Wed, 23 May 2012 08:59:07 +0200
From:	Zdenek Kabelac <zdenek.kabelac@...il.com>
To:	Sean Paul <seanpaul@...omium.org>
Cc:	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

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 ?

Zdenek
--
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/