[Mesa-users] Flickering with Intel i7-5700 (HD 5600) and Samsung 156HL01-102 panel

[Albert Freeman]

On 16 November 2015 at 07:32, Jordi Salvat i Alabart
<jordi.salvat.i.alabart at gmail.com> wrote:
> I've tried commenting out these five lines in
> ./drivers/gpu/drm/i915/intel_dp.c, which perform the BIOS-induced clamping:
>
>         if (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp) {
>             DRM_DEBUG_KMS("clamping bpp for eDP panel to BIOS-provided
> %i\n",
>                       dev_priv->vbt.edp_bpp);
>             bpp = dev_priv->vbt.edp_bpp;
>         }
>
> The drivers now report using 24bpp (kern.log is attached), but the
> flickering is still there.
>
> I am at a loss as to what to try next.
>
> Should I (blindly) try quirks which have helped with other Samsung panels,
> such as EDID_QUIRK_DETAILED_SYNC_PP or EDID_QUIRK_PREFER_LARGE_60?
>
> Thanks,
>
> Jordi.
>
>
> 2015-11-16 0:46 GMT+01:00 Jordi Salvat i Alabart
> <jordi.salvat.i.alabart at gmail.com>:
>>
>> Hi Albert,
>>
>> thanks a lot for your help. Unfortunately the patches didn't help (I tried
>> the 8bit, I was still getting the flickering, so I ignored your 2nd piece of
>> advice and tried the 12bit just in case). They all show exactly the same
>> flickering :'-(
>>
>> I'm attaching kern.log for a boot with the 8bit version.
>>
>> I have a hard time reading the logs (I've been using Linux since 1994, but
>> never messed with display stuff), but if I grep for lines mentioning "bpp",
>> I see that the where Ubuntu kernel logged this:
>>
>> [drm:connected_sink_compute_bpp] clamping display bpp (was 36) to EDID
>> reported max of 18
>>
>> The same kernel with your 8bit fix logs this:
>>
>> [drm:connected_sink_compute_bpp] clamping display bpp (was 36) to EDID
>> reported max of 24
>> [drm:intel_dp_compute_config] clamping bpp for eDP panel to BIOS-provided
>> 18
>>
>> So it looks like your patch took effect, but was overridden by some BIOS
>> setting? Any idea on how to stop this from happening?
>>
>> Thanks,
>>
>> Jordi.
>>
>>
>> 2015-11-11 10:25 GMT+01:00 Albert Freeman <albertwdfreeman at gmail.com>:
>>>
>>> On 11 November 2015 at 07:21, Jordi Salvat i Alabart
>>> <jordi.salvat.i.alabart at gmail.com> wrote:
>>> > Thanks! I'll try this as soon as I can (probably over the weekend) and
>>> > report back.
>>> >
>>> > Regards,
>>> >
>>> > Jordi
>>> >
>>> > El dia 10/11/2015 2:27 p. m., "Albert Freeman"
>>> > <albertwdfreeman at gmail.com>
>>> > va escriure:
>>> >
>>> >> On 10 November 2015 at 13:10, Albert Freeman
>>> >> <albertwdfreeman at gmail.com>
>>> >> wrote:
>>> >> > On 8 November 2015 at 19:05, Jordi Salvat i Alabart
>>> >> > <jordi.salvat.i.alabart at gmail.com> wrote:
>>> >> >> Noone? Not even a hint on where I could ask for help?
>>> >> >>
>>> >> >> :'-(
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> 2015-10-26 0:18 GMT+01:00 Jordi Salvat i Alabart
>>> >> >> <jordi.salvat.i.alabart at gmail.com>:
>>> >> >>>
>>> >> >>> Hi,
>>> >> >>>
>>> >> >>> My new MSI PE60 2QE laptop mounts an Intel i7-5700HQ, which
>>> >> >>> carries
>>> >> >>> the
>>> >> >>> Integrated Graphics Chipset 5600, and a Samsung 156HL01-102 panel.
>>> >> >>>
>>> >> >>> The display works perfectly when I boot with the "nomodeset"
>>> >> >>> parameter
>>> >> >>> in
>>> >> >>> the kernel command line -- but then I'm forced to use the
>>> >> >>> framebuffer
>>> >> >>> driver, which doesn't allow multiple monitors.
>>> >> >>>
>>> >> >>> With KMS enabled (by removing the "nomodeset" parameter), X starts
>>> >> >>> correctly with the "intel" driver and I can use multiple monitors,
>>> >> >>> but
>>> >> >>> the
>>> >> >>> laptop's panel shows an irregular flicker, ranging from occasional
>>> >> >>> flickering horizontal black lines (which are really annoying) to a
>>> >> >>> constant
>>> >> >>> flashing & flickering making the display all but unusable.
>>> >> >>>
>>> >> >>> The flickering and flashing is less noticeable, but still there,
>>> >> >>> in
>>> >> >>> the
>>> >> >>> text-mode VTs, even if I never start X. So the problem has to be
>>> >> >>> in
>>> >> >>> the
>>> >> >>> kernel or modules, not in the X drivers.
>>> >> >>>
>>> >> >>> External monitors connected to the DP or HDMI ports don't show any
>>> >> >>> flickering.
>>> >> >>>
>>> >> >>> Things I have tried (among many others I've discovered were
>>> >> >>> irrelevant):
>>> >> >>>
>>> >> >>> Setting a number different video modes using xrandr
>>> >> >>> Booting with Kernel 3.19.0.25 with i915.enable_IPS=0 as suggested
>>> >> >>> here:
>>> >> >>> Screen flickering on Ubuntu Gnome 14.04 - 4K resolution
>>> >> >>> Booting with i915.powersave=0
>>> >> >>> Booting with acpi_osi=Linux
>>> >> >>> Upgrading to Ubuntu Vivid Vervet (kernel 3.19.0 with a backported
>>> >> >>> i915
>>> >> >>> module)
>>> >> >>> Upgrading to Ubuntu Willy Werewolf (kernel 4.2.0)
>>> >> >>>
>>> >> >>> None of these have helped.
>>> >> >>>
>>> >> >>> I'm attaching kern.log for a full boot sequence with
>>> >> >>> drm.debug=0xf.
>>> >> >>>
>>> >> >>> What steps can you recommend to try to diagnose and solve this
>>> >> >>> problem?
>>> >> >>>
>>> >> >>> Thanks a lot for your help,
>>> >> >>>
>>> >> >>> Jordi
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> mesa-users mailing list
>>> >> >> mesa-users at lists.freedesktop.org
>>> >> >> http://lists.freedesktop.org/mailman/listinfo/mesa-users
>>> >> >>
>>> >> > Does this solve the issue (it solves a issue with your monitor) (it
>>> >> > is
>>> >> > applied ontop of the latest linus kernel tree at time of writing):
>>> >> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> >> > index 05bb731..44c9422 100644
>>> >> > --- a/drivers/gpu/drm/drm_edid.c
>>> >> > +++ b/drivers/gpu/drm/drm_edid.c
>>> >> > @@ -139,6 +139,9 @@ static struct edid_quirk {
>>> >> >
>>> >> >         /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
>>> >> >         { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
>>> >> > +
>>> >> > +       /* Panel in Samsung 156HL01-102 display (for notebook)
>>> >> > reports
>>> >> > 6bpc instead of 8bpc */
>>> >> > +       { "SDC", 0x324c, EDID_QUIRK_FORCE_8BPC },
>>> >> >  };
>>> >> >
>>> >> >  /*
>>> >> >
>>> >> >
>>> >> >
>>> >> > !!!OR!!! Since the DRM is trying to force part of your monitor into
>>> >> > 36
>>> >> > bit mode, maybe this:
>>> >> >
>>> >> >
>>> >> >
>>> >> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> >> > index 05bb731..44c9422 100644
>>> >> > --- a/drivers/gpu/drm/drm_edid.c
>>> >> > +++ b/drivers/gpu/drm/drm_edid.c
>>> >> > @@ -139,6 +139,9 @@ static struct edid_quirk {
>>> >> >
>>> >> >         /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
>>> >> >         { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
>>> >> > +
>>> >> > +       /* Panel in Samsung 156HL01-102 display (for notebook)
>>> >> > reports
>>> >> > 6bpc instead of 12bpc */
>>> >> > +       { "SDC", 0x324c, EDID_QUIRK_FORCE_12BPC },
>>> >> >  };
>>> >> >
>>> >> >  /*
>>> >> Sorry those patches don't apply properly, here are ones that do
>>> After looking at intel drm driver code more carefully, don't use the
>>> 12 bpc one (12 * 3 == 36). The intel drm driver seems to first
>>> generate certain values based on your gpu model. It then reduces it
>>> based on display stuff (i.e. when I made the 12bpc version of the
>>> patch I was looking at the intial value based on gpu model). I don't
>>> think your display is capable of 36 bit color (12bpc) as the internet
>>> says it only has 95% sRGB (e.g. high end consumer monitor, but not
>>> perfect). 36bit is only for photographers and people producing
>>> movies/game textures/game environments and other special high end
>>> environments. Movies and games and practically every picture on the
>>> internet is sRGB which is fully supported by 8 bit stuff. So cd to the
>>> kernel source directory and execute git apply 8bit (with the 8bit
>>> "patch in the same folder)
>>
>>
>
I suspected that the color depth would not be the source of the
problem, but it was worth a try. It will be useful though (prevent
color degradation) if and when this problem gets fixed. I am not that
familar with displays, display controllers and EDIDs etc so I may not
be able to fix this. But I will do a little digging (although I am
busy tommorow so it may take a little while). This mailing list
actually isn't really a good place for this issue as it affects the
kernel and has nothing to do with mesa. #dri-users and #dri-devel
(irc channels) would be the best place to mention this.

Have you tried setting all the different display modes with xrandr?

If you cycle through xrandr modes and all of them show the issue then
these are useless: EDID_QUIRK_PREFER_LARGE_60,
EDID_QUIRK_PREFER_LARGE_75, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE
This one is useless: EDID_QUIRK_DETAILED_IN_CM as your EDID reports a
diagonally ~15 inch display which sounds right (unless your laptop
display is ~3.4 metres wide).
As for: EDID_QUIRK_135_CLOCK_TOO_HIGH your clock is not 135, while the
fix does not depend on this, it probably won't help, incorrect timings
shouldn't damage your display so you can try it.
I don't really understand: EDID_QUIRK_DETAILED_SYNC_PP, but some of
your monitor modes (google found your stackexchange post, I got your
EDID information from it):
http://askubuntu.com/questions/684833/screen-flickering-with-ubuntu-15-on-msi-pe-60-2qe
 have +hsync +vsync. So unless they programmed them all incorrectly
(i.e. have some algorithm that automatically generates them all based
on a single value), I think this would be resolved by trying all modes
in xrandr. Again, I don't understand this.

>From what I gather of the EDID standard,
EDID_QUIRK_FORCE_REDUCED_BLANKING, is only an optional feature at 60hz
and was placed in the drm code to fix some issue with VGA connectors
(eDP (or any other Displayport) != VGA).