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

Jordi Salvat i Alabart jordi.salvat.i.alabart at gmail.com
Sun Nov 15 23:32:13 PST 2015


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)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-users/attachments/20151116/5acb89a2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NoBios-kern.log.gz
Type: application/x-gzip
Size: 68634 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-users/attachments/20151116/5acb89a2/attachment-0001.bin>


More information about the mesa-users mailing list