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 ?
Zdenek
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?
Thanks, Daniel
--
Daniel Vetter
Mail: [email protected]
Mobile: +41 (0)79 365 57 48
2012/5/22 Daniel Vetter <[email protected]>:
> 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).
Is there any suspecting patch for this chipset I should try to revert ?
Zdenek
On Tue, May 22, 2012 at 04:36:30PM +0200, Zdenek Kabelac wrote:
> 2012/5/22 Daniel Vetter <[email protected]>:
> > 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?
> 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.
Thanks, Daniel
--
Daniel Vetter
Mail: [email protected]
Mobile: +41 (0)79 365 57 48
2012/5/22 Daniel Vetter <[email protected]>:
> On Tue, May 22, 2012 at 04:36:30PM +0200, Zdenek Kabelac wrote:
>> 2012/5/22 Daniel Vetter <[email protected]>:
>> > 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.
Zdenek
2012/5/22 Zdenek Kabelac <[email protected]>:
> 2012/5/22 Daniel Vetter <[email protected]>:
>> On Tue, May 22, 2012 at 04:36:30PM +0200, Zdenek Kabelac wrote:
>>> 2012/5/22 Daniel Vetter <[email protected]>:
>>> > 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
drm/i915: Only look for matching clocks for LVDS downclock
reverting just this patch for vanilla 3.4 fixes the problem for my T61.
(I've not tried to play with those individial 3 pieces inside this patch
to check exactly which one is responsible)
Zdenek
Here is the bisect game:
git bisect start
# bad: [acc73fb11695b564dc485b1f98f8237bbdc0742f] Remove ioctl warning
git bisect bad acc73fb11695b564dc485b1f98f8237bbdc0742f
# good: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
git bisect good c16fa4f2ad19908a47c63d8fa436a1178438c7e7
# bad: [141124c02059eee9dbc5c86ea797b1ca888e77f7] Delete all instances
of asm/system.h
git bisect bad 141124c02059eee9dbc5c86ea797b1ca888e77f7
# good: [3b59bf081622b6446db77ad06c93fe23677bc533] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good 3b59bf081622b6446db77ad06c93fe23677bc533
# good: [424a6f6ef990b7e9f56f6627bfc6c46b493faeb4] Merge tag
'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
git bisect good 424a6f6ef990b7e9f56f6627bfc6c46b493faeb4
# bad: [be53bfdb8088e9d1924199cc1a96e113756b1075] Merge branch
'drm-next' of git://people.freedesktop.org/~airlied/linux
git bisect bad be53bfdb8088e9d1924199cc1a96e113756b1075
# good: [828006de1bddf83b6ecf03ec459c15f7c7c22db7] Merge tag
'asoc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound
into topic/asoc
git bisect good 828006de1bddf83b6ecf03ec459c15f7c7c22db7
# skip: [496a73bbecb81e6753715995e4519d152f814667] drm/nv50/pm: use
hwsq for engine reclocking too
git bisect skip 496a73bbecb81e6753715995e4519d152f814667
# skip: [c11dd0da5277596d0ccdccb745b273d69a94f2d7] drm/nouveau/pm: fix
oops if chipset has no pm support at all
git bisect skip c11dd0da5277596d0ccdccb745b273d69a94f2d7
# skip: [07cafff288266c3aa082f4bda3d47989e73ee85d] ALSA: hda/conexant
- Clear unsol events on unused pins
git bisect skip 07cafff288266c3aa082f4bda3d47989e73ee85d
# bad: [f3298532f71f163877b9003009d6e1eefe988258] drm/nvc0: add
initial memory type detection
git bisect bad f3298532f71f163877b9003009d6e1eefe988258
# bad: [019d96cb55ade38a4b4a52bba0304e8cd681f30a] drm: add some caps
for userspace to discover more info for dumb KMS driver (v2)
git bisect bad 019d96cb55ade38a4b4a52bba0304e8cd681f30a
# bad: [5c0480f21f9896c443b0e65d779c8e09a695da7b] drm/i915: fall
through pwrite_gtt_slow to the shmem slow path
git bisect bad 5c0480f21f9896c443b0e65d779c8e09a695da7b
# bad: [8e636784b6f76653d358d521af9c2a8c246df38b] drm/i915: fixup
assert_pipe to take the pipe A quirk into account
git bisect bad 8e636784b6f76653d358d521af9c2a8c246df38b
# bad: [23c99e775d14f01ba45a5affd2fb51af4328359c] drm/i915: Fix
assert_pch_hdmi_disabled to mention HDMI (not DP)
git bisect bad 23c99e775d14f01ba45a5affd2fb51af4328359c
# bad: [a7516a05311d0e2deb8ce8ae8b8c12a513ca8ca2] drm/i915: split out
pll divider code
git bisect bad a7516a05311d0e2deb8ce8ae8b8c12a513ca8ca2
# bad: [5a117db77e47e3946d1aaa7ce8deafafd9d76746] drm/i915: there is
no pipe CxSR on ironlake
git bisect bad 5a117db77e47e3946d1aaa7ce8deafafd9d76746
# good: [0b8ecdda1943a05c8e7896f0b5f1addf39269927] drm/i915: Silence _DSM errors
git bisect good 0b8ecdda1943a05c8e7896f0b5f1addf39269927
On Tue, May 22, 2012 at 6:15 PM, Zdenek Kabelac
<[email protected]> wrote:
> 2012/5/22 Zdenek Kabelac <[email protected]>:
>> 2012/5/22 Daniel Vetter <[email protected]>:
>>> On Tue, May 22, 2012 at 04:36:30PM +0200, Zdenek Kabelac wrote:
>>>> 2012/5/22 Daniel Vetter <[email protected]>:
>>>> > 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
Sean
> drm/i915: Only look for matching clocks for LVDS downclock
>
> reverting just ?this patch for vanilla 3.4 ?fixes the problem for my T61.
> (I've not tried to play with those individial 3 pieces inside this patch
> to check exactly which one is responsible)
>
> Zdenek
>
> Here is the bisect game:
> git bisect start
> # bad: [acc73fb11695b564dc485b1f98f8237bbdc0742f] Remove ioctl warning
> git bisect bad acc73fb11695b564dc485b1f98f8237bbdc0742f
> # good: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
> git bisect good c16fa4f2ad19908a47c63d8fa436a1178438c7e7
> # bad: [141124c02059eee9dbc5c86ea797b1ca888e77f7] Delete all instances
> of asm/system.h
> git bisect bad 141124c02059eee9dbc5c86ea797b1ca888e77f7
> # good: [3b59bf081622b6446db77ad06c93fe23677bc533] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
> git bisect good 3b59bf081622b6446db77ad06c93fe23677bc533
> # good: [424a6f6ef990b7e9f56f6627bfc6c46b493faeb4] Merge tag
> 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
> git bisect good 424a6f6ef990b7e9f56f6627bfc6c46b493faeb4
> # bad: [be53bfdb8088e9d1924199cc1a96e113756b1075] Merge branch
> 'drm-next' of git://people.freedesktop.org/~airlied/linux
> git bisect bad be53bfdb8088e9d1924199cc1a96e113756b1075
> # good: [828006de1bddf83b6ecf03ec459c15f7c7c22db7] Merge tag
> 'asoc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound
> into topic/asoc
> git bisect good 828006de1bddf83b6ecf03ec459c15f7c7c22db7
> # skip: [496a73bbecb81e6753715995e4519d152f814667] drm/nv50/pm: use
> hwsq for engine reclocking too
> git bisect skip 496a73bbecb81e6753715995e4519d152f814667
> # skip: [c11dd0da5277596d0ccdccb745b273d69a94f2d7] drm/nouveau/pm: fix
> oops if chipset has no pm support at all
> git bisect skip c11dd0da5277596d0ccdccb745b273d69a94f2d7
> # skip: [07cafff288266c3aa082f4bda3d47989e73ee85d] ALSA: hda/conexant
> - Clear unsol events on unused pins
> git bisect skip 07cafff288266c3aa082f4bda3d47989e73ee85d
> # bad: [f3298532f71f163877b9003009d6e1eefe988258] drm/nvc0: add
> initial memory type detection
> git bisect bad f3298532f71f163877b9003009d6e1eefe988258
> # bad: [019d96cb55ade38a4b4a52bba0304e8cd681f30a] drm: add some caps
> for userspace to discover more info for dumb KMS driver (v2)
> git bisect bad 019d96cb55ade38a4b4a52bba0304e8cd681f30a
> # bad: [5c0480f21f9896c443b0e65d779c8e09a695da7b] drm/i915: fall
> through pwrite_gtt_slow to the shmem slow path
> git bisect bad 5c0480f21f9896c443b0e65d779c8e09a695da7b
> # bad: [8e636784b6f76653d358d521af9c2a8c246df38b] drm/i915: fixup
> assert_pipe to take the pipe A quirk into account
> git bisect bad 8e636784b6f76653d358d521af9c2a8c246df38b
> # bad: [23c99e775d14f01ba45a5affd2fb51af4328359c] drm/i915: Fix
> assert_pch_hdmi_disabled to mention HDMI (not DP)
> git bisect bad 23c99e775d14f01ba45a5affd2fb51af4328359c
> # bad: [a7516a05311d0e2deb8ce8ae8b8c12a513ca8ca2] drm/i915: split out
> pll divider code
> git bisect bad a7516a05311d0e2deb8ce8ae8b8c12a513ca8ca2
> # bad: [5a117db77e47e3946d1aaa7ce8deafafd9d76746] drm/i915: there is
> no pipe CxSR on ironlake
> git bisect bad 5a117db77e47e3946d1aaa7ce8deafafd9d76746
> # good: [0b8ecdda1943a05c8e7896f0b5f1addf39269927] drm/i915: Silence _DSM errors
> git bisect good 0b8ecdda1943a05c8e7896f0b5f1addf39269927
On Tue, May 22, 2012 at 06:21:22PM -0400, Sean Paul wrote:
> On Tue, May 22, 2012 at 6:15 PM, Zdenek Kabelac
> <[email protected]> wrote:
> > 2012/5/22 Zdenek Kabelac <[email protected]>:
> > 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
... which is actually the default. Zdenek, are you enabling this option on
your kernel cmdline?
-Daniel
--
Daniel Vetter
Mail: [email protected]
Mobile: +41 (0)79 365 57 48
2012/5/23 Sean Paul <[email protected]>:
> On Tue, May 22, 2012 at 6:15 PM, Zdenek Kabelac
> <[email protected]> wrote:
>> 2012/5/22 Zdenek Kabelac <[email protected]>:
>>> 2012/5/22 Daniel Vetter <[email protected]>:
>>>> On Tue, May 22, 2012 at 04:36:30PM +0200, Zdenek Kabelac wrote:
>>>>> 2012/5/22 Daniel Vetter <[email protected]>:
>>>>> > 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
On Wed, May 23, 2012 at 08:59:07AM +0200, Zdenek Kabelac wrote:
> 2012/5/23 Sean Paul <[email protected]>:
> > On Tue, May 22, 2012 at 6:15 PM, Zdenek Kabelac
> > <[email protected]> wrote:
> >> 2012/5/22 Zdenek Kabelac <[email protected]>:
> >>> 2012/5/22 Daniel Vetter <[email protected]>:
> >>>> On Tue, May 22, 2012 at 04:36:30PM +0200, Zdenek Kabelac wrote:
> >>>>> 2012/5/22 Daniel Vetter <[email protected]>:
> >>>>> > 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: [email protected]
Mobile: +41 (0)79 365 57 48
On Wed, 23 May 2012 08:59:07 +0200, Zdenek Kabelac <[email protected]> wrote:
> 2012/5/23 Sean Paul <[email protected]>:
> > 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 ?
It is more likely that we did not detect a downclock mode before now and
so this is the first time that is being used in anger. (There should be
some telltales in drm.debug dmesg) If you are really, really brave you
can try http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=fastboot
which only triggers the downclock on a vblank.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, May 23, 2012 at 09:07:28AM +0200, Daniel Vetter wrote:
> On Wed, May 23, 2012 at 08:59:07AM +0200, Zdenek Kabelac wrote:
> > 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 ;-)
Quick question: What's the frequency of the brightness change? And how
regular are the changes?
-Daniel
--
Daniel Vetter
Mail: [email protected]
Mobile: +41 (0)79 365 57 48
2012/5/23 Daniel Vetter <[email protected]>:
> On Wed, May 23, 2012 at 09:07:28AM +0200, Daniel Vetter wrote:
>> On Wed, May 23, 2012 at 08:59:07AM +0200, Zdenek Kabelac wrote:
>> > 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 ;-)
>
> Quick question: What's the frequency of the brightness change? And how
> regular are the changes?
> -Daniel
Now when it's obvious it's related to powersaving - it's probably
much easier to explain,
that I've been observing those changes when some activity was happing -
i.e. opening picture - and after like 1 second image has flashed, -
then I've moved the mouse
stopped - and again image has flashed with brightness a bit.
The issue would be probably far less noticeable if the period of time
of idle GPU would have to be
much longer (i.e. in minute range)
Zdenek
On Wed, May 23, 2012 at 01:48:41PM +0200, Zdenek Kabelac wrote:
> 2012/5/23 Daniel Vetter <[email protected]>:
> > On Wed, May 23, 2012 at 09:07:28AM +0200, Daniel Vetter wrote:
> >> On Wed, May 23, 2012 at 08:59:07AM +0200, Zdenek Kabelac wrote:
> >> > 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 ;-)
> >
> > Quick question: What's the frequency of the brightness change? And how
> > regular are the changes?
> > -Daniel
>
>
> Now when it's obvious it's related to powersaving - it's probably
> much easier to explain,
> that I've been observing those changes when some activity was happing -
> i.e. opening picture - and after like 1 second image has flashed, -
> then I've moved the mouse
> stopped - and again image has flashed with brightness a bit.
>
> The issue would be probably far less noticeable if the period of time
> of idle GPU would have to be
> much longer (i.e. in minute range)
Hm, that sounds more like something ugly is happening when we switch
frequencies as opposed to the different frequency causing interference
with the backlight. Just to check: You only see a quick flash, then
brightness is back to normal?
If that's the case, please try Chris' fastboot branch. vsyncing the
frequency change might indeed fix this.
Thanks, Daniel
--
Daniel Vetter
Mail: [email protected]
Mobile: +41 (0)79 365 57 48
2012/5/23 Daniel Vetter <[email protected]>:
> On Wed, May 23, 2012 at 01:48:41PM +0200, Zdenek Kabelac wrote:
>> 2012/5/23 Daniel Vetter <[email protected]>:
>> > On Wed, May 23, 2012 at 09:07:28AM +0200, Daniel Vetter wrote:
>> >> On Wed, May 23, 2012 at 08:59:07AM +0200, Zdenek Kabelac wrote:
>> >> > 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 ;-)
>> >
>> > Quick question: What's the frequency of the brightness change? And how
>> > regular are the changes?
>> > -Daniel
>>
>>
>> Now when it's obvious it's related to powersaving ?- it's probably
>> much easier to explain,
>> that I've been observing those changes when some activity was happing -
>> i.e. opening ?picture - and after like 1 second image has flashed, -
>> then I've moved the mouse
>> stopped - and again image has flashed with brightness a bit.
>>
>> The issue would be probably far less noticeable if the period of time
>> of idle GPU would have to be
>> much longer (i.e. in minute range)
>
> Hm, that sounds more like something ugly is happening when we switch
> frequencies as opposed to the different frequency causing interference
> with the backlight. Just to check: You only see a quick flash, then
> brightness is back to normal?
In fact I'm not really noticing the moment it goes back to normal -
I'll notice when it gets darker.
i.e. when I open picture with 'qiv' - after a second I notice that
picture becomes a bit darker.
If I do not move with anything - it stays this way.
>
> If that's the case, please try Chris' fastboot branch. vsyncing the
> frequency change might indeed fix this.
>
I've tried to compile, but compilation finished with some errors - so
I've tried to rebase branch on master 3.4 - tried to resolve some
error - but probably in a wrong thus resulted kernel given me just
black screen when X has been initialized. So I'll try to remove some
config options and I'll try to rebuild original fastboot branch later.
Zdenek
On Thu, May 24, 2012 at 04:21:48PM +0200, Zdenek Kabelac wrote:
> 2012/5/23 Daniel Vetter <[email protected]>:
> > On Wed, May 23, 2012 at 01:48:41PM +0200, Zdenek Kabelac wrote:
> >> 2012/5/23 Daniel Vetter <[email protected]>:
> >> > On Wed, May 23, 2012 at 09:07:28AM +0200, Daniel Vetter wrote:
> >> >> On Wed, May 23, 2012 at 08:59:07AM +0200, Zdenek Kabelac wrote:
> >> >> > 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 ;-)
> >> >
> >> > Quick question: What's the frequency of the brightness change? And how
> >> > regular are the changes?
> >> > -Daniel
> >>
> >>
> >> Now when it's obvious it's related to powersaving ?- it's probably
> >> much easier to explain,
> >> that I've been observing those changes when some activity was happing -
> >> i.e. opening ?picture - and after like 1 second image has flashed, -
> >> then I've moved the mouse
> >> stopped - and again image has flashed with brightness a bit.
> >>
> >> The issue would be probably far less noticeable if the period of time
> >> of idle GPU would have to be
> >> much longer (i.e. in minute range)
> >
> > Hm, that sounds more like something ugly is happening when we switch
> > frequencies as opposed to the different frequency causing interference
> > with the backlight. Just to check: You only see a quick flash, then
> > brightness is back to normal?
>
> In fact I'm not really noticing the moment it goes back to normal -
> I'll notice when it gets darker.
> i.e. when I open picture with 'qiv' - after a second I notice that
> picture becomes a bit darker.
> If I do not move with anything - it stays this way.
>
> >
> > If that's the case, please try Chris' fastboot branch. vsyncing the
> > frequency change might indeed fix this.
> >
>
> I've tried to compile, but compilation finished with some errors - so
> I've tried to rebase branch on master 3.4 - tried to resolve some
> error - but probably in a wrong thus resulted kernel given me just
> black screen when X has been initialized. So I'll try to remove some
> config options and I'll try to rebuild original fastboot branch later.
Hm, maybe attach your .config and yell at Chris a bit to fix up his
branch.
-Daniel
--
Daniel Vetter
Mail: [email protected]
Mobile: +41 (0)79 365 57 48
