Re: [PATCH] drm/i915: Prune 2560x2880 mode for 5K tiled dual DP monitors

[Jani Nikula <jani.nikula@linux.intel.com>]

On Mon, 09 Sep 2019, Manasi Navare <manasi.d.navare@intel.com> wrote:
> On Thu, Sep 05, 2019 at 11:03:12AM +0530, Nautiyal, Ankit K wrote:
>> Hi,
>> 
>> I was able to get 5K HPz27q 317b monitor for some time. Below are the
>> observation on HPz27q Monitor with two DP cables connected to a KBL machine.
>> 
>> *****General Observation*****
>> The monitor settings has two modes, DP1.0 and DP1.2.
>> One of the connector is enumerated as 'tiled' and the other as non tiled.
>> 
>> The non-tiled connector has modes starting from 2K and below, and the tiled
>> connector has just one mode 2560x2880.
>> No corruption observed in this case.
>> 
>> In case of DP2.0 two connectors are enumerated, both tiled.
>> One connector has modes from 3849x2160 and below. 2560x2880 being preferred
>> mode.
>> The other has 2560x2880 mode, also preferred.
>> 
>> The issue is seen when both the modes selected are 2560x2880. This results
>> like two halves of screens not in sync.
>> 
>> *****Experiment with different patches*****
>> 
>> As discussed I collected logs in 3 cases:
>> 1. Without any patch (vanilla)
>> 2. With patch to prune the 2560x2880 mode, only for tile with HLOC and VLOC
>> as 0.
>> 3. With a patch to force the connector property as 'false'
>> 
>> Logs for which are attached in fdo bug #97244
>> https://bugs.freedesktop.org/show_bug.cgi?id=97244
>> https://bugs.freedesktop.org/attachment.cgi?id=145267
>> 
>> Note 1: I had changed the display info to provide the Tile information, in
>> case the connector 'has_tile' is true.
>> Note 2: I had checked and collected logs with single display and also with
>> dual display configuration with DP1.2 monitor settings.
>> Note 3: The mode is changed using xrandr.
>> 
>> case1:
>> -Without any patch : 2560x2880 modeset on both connectors causes corruption.
>> 
>> case2:
>> -With 2560x2880 mode pruned for one of the tile : Only one of the connector
>> shows 2560x2880 mode.
>> 2560x2880 modeset on any the remaining connector resulted in blank screen.
>> Any other modeset works.
>> 
>> case3:
>> -With has_tile connector property forcibly reset : The connector are listed
>> as not tiled but still, 2560x2880 modeset on any the connectors causes blank
>> screen.
>> Any other modeset works.
>> 
>> To summarize, pruning on just one tiled connector does not solve the issue,
>> if we need to prune, we need to do it for both the connectors.
>> Secondly, the forcible setting of has_tile = 'false' also, does not help,
>> and resulted in blank screen when 2560x2880 mode is applied.
>> So IMHO if we need to prune the mode 2560x2880, we need to prune it for both
>> the connectors.
>>
>
> Thanks Ankit for these experiments and logs.
> So looks like the solution would be to add a quirk for thsi specific EDID for
> the panel and then  prune 2560x2880 on both connectors.
>
> Jani does that sound like a good acceptable solution?

So you'd have to disable the mode for both displays, but then it would
seem odd to expose the tiling configuration with a non-existing mode,
wouldn't it?

The quirk should be: on these displays, disable tiling and prune the
modes listed in the tile info. That's a fairly generic quirk that makes
sense to *define* in drm. However you'd only *implement* that quirk in
affected drivers, i.e. i915.

The question remains, what does it take to actually fix this? I haven't
looked at the patches in detail, what makes them so icl specific?

I'll repeat what I said up-thread:

On Wed, 28 Aug 2019, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> Finally, and perhaps most importantly, there are people on the bug that
> are going to be rather underwhelmed that after three years they get a
> patch that simply rejects the very mode that was the reason for buying
> the display they have. Insult to injury, the real fix is for a platform
> that didn't exist when they bought the displays.

Some of those folks apparently can actually make it work when they try
hard enough. You'd take that away too.


BR,
Jani.



-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx