Bug 111501 - [CFL] Kernel 5.3.0-rc6: i915 fails at typec_displayport 5120x1440
Summary: [CFL] Kernel 5.3.0-rc6: i915 fails at typec_displayport 5120x1440
Status: NEEDINFO
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-27 12:25 UTC by Leho Kraav (:macmaN :lkraav)
Modified: 2019-09-09 21:42 UTC (History)
2 users (show)

See Also:
i915 platform: CFL
i915 features: display/Other


Attachments
[PATCH] drm/i915: Don't advertise modes that exceed the max plane size (6.14 KB, patch)
2019-08-28 11:36 UTC, Ville Syrjala
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Leho Kraav (:macmaN :lkraav) 2019-08-27 12:25:30 UTC
Hardware: Dell Latitude 7400 2-in-1, Whiskey Lake, Intel 620

5120x1440 fails to display.

Next available mode 3840x1080 displays fine.

Is this a kernel, or a driver level issue? It fails both in Xorg and
Wayland, so seems something at the lower levels. This 49" monitor worked
fine on Latitude 7480 (Kaby Lake), so I'm thinking something with `i915`
module layer.

What should I try next?

```
leho@papaya ~ $ [-] uname 
Linux papaya 5.3.0-rc6+gentoo+ #95 SMP PREEMPT Mon Aug 26 23:50:08 EEST 2019 x86_64 Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz GenuineIntel GNU/Linux

leho@papaya ~ $ [-] xrandr 
Screen 0: minimum 8 x 8, current 5120 x 1440, maximum 32767 x 32767
...
DP1 disconnected (normal left inverted right x axis y axis)
DP2 connected primary 3840x1080+0+0 (normal left inverted right x axis y axis) 1200mm x 340mm
   5120x1440     59.98 +  29.98  
   3840x1080     59.97*+
   2560x1080     60.00    59.94    59.98  
   1920x1080     60.00    60.00    50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

leho@papaya ~ $ [-] xrandr --output DP2 --mode 5120x1440 --verbose
crtc 0:    5120x1440  59.98 +0+0 "DP2"
xrandr: Configure crtc 0 failed
crtc 0: disable
crtc 1: disable
crtc 2: disable
crtc 3: disable
screen 0: revert
crtc 0: revert
crtc 1: revert
crtc 2: revert
crtc 3: revert
```

Looks like I'm not alone, either

https://www.reddit.com/r/linuxquestions/comments/cddpne/linux_and_ultrawide/
Comment 1 Lakshmi 2019-08-28 08:00:35 UTC
@Manasi, can you help here? Patch mentioned in the Bug 97244 will help here?
https://bugs.freedesktop.org/show_bug.cgi?id=97244#c55
Comment 2 Leho Kraav (:macmaN :lkraav) 2019-08-28 08:45:04 UTC
I'm not sure if this U4919DW monitor is true 5K?

> 5K resolution refers to display formats with a horizontal resolution of around 5,000 pixels. The most common 5K resolution is 5120 × 2880

Our target resolution here is 5120 x 1440.

Also, bug 97244 talks about dual inputs etc, while my U4919DW monitor ran fine over a single USB-C cable on Dell 7480 KBL graphics.

But looks like people are testing drm tips as a general debugging process, so I'll give that a shot first.
Comment 3 Ville Syrjala 2019-08-28 10:00:06 UTC
This is probably due to commit 372b9ffb5799 ("drm/i915: Fix skl+ max plane width")

The limits are admittedly a bit odd, and it seems that previously people were exceeding them without apparent issues. I've asked for clarification from the hw folks.
Comment 4 Leho Kraav (:macmaN :lkraav) 2019-08-28 10:04:14 UTC
Thanks. Is this patch independent enough to attempt a simple revert and I could see what happens?
Comment 5 Ville Syrjala 2019-08-28 10:11:31 UTC
(In reply to Leho Kraav (:macmaN :lkraav) from comment #4)
> Thanks. Is this patch independent enough to attempt a simple revert and I
> could see what happens?

Yes, I think it should be revertable.

Or alternatively you can just try something like this:

--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3392,7 +3392,7 @@ static int skl_check_main_surface(struct intel_plane_state *plane_state)
        if (w > max_width || h > max_height) {
                DRM_DEBUG_KMS("requested Y/RGB source size %dx%d too big (limit %dx%d)\n",
                              w, h, max_width, max_height);
-               return -EINVAL;
+               //return -EINVAL;
        }
 
        intel_add_fb_offsets(&x, &y, plane_state, 0);
Comment 6 Leho Kraav (:macmaN :lkraav) 2019-08-28 10:46:06 UTC
Boom, everything works again.

I think we successfully identified the underlying issue (y).

Any additional input I can provide here? I assume this max plan calculation algorithm needs some adjustment, so a bigger patch needed.
Comment 7 Ville Syrjala 2019-08-28 11:36:24 UTC
Created attachment 145190 [details] [review]
[PATCH] drm/i915: Don't advertise modes that exceed the max plane  size

Until we get some clarification from the hw people I think we might want to go with something like this. It should remove the 5k mode from the connector's mode list so that at least the mode that gets picked up automagically should work.
Comment 8 Leho Kraav (:macmaN :lkraav) 2019-08-28 11:40:06 UTC
I'm a bit confused, what would my UX be with this patch now?

Would this patch remove 5120x1440 from the available mode list altogether (until hw people clarifications)?
Comment 9 Ville Syrjala 2019-08-28 11:43:58 UTC
(In reply to Leho Kraav (:macmaN :lkraav) from comment #8)
> I'm a bit confused, what would my UX be with this patch now?
> 
> Would this patch remove 5120x1440 from the available mode list altogether
> (until hw people clarifications)?

Yes.
Comment 10 Leho Kraav (:macmaN :lkraav) 2019-08-28 11:51:33 UTC
I'm still confused :) This mode clearly works without any issues. Why are we removing it? Seems like some part of the stack is confused about what theoretically vs actually can and cannot be done on hardware x.
Comment 11 Ville Syrjala 2019-08-28 11:56:30 UTC
(In reply to Leho Kraav (:macmaN :lkraav) from comment #10)
> I'm still confused :) This mode clearly works without any issues. Why are we
> removing it? Seems like some part of the stack is confused about what
> theoretically vs actually can and cannot be done on hardware x.

The hardware specification says it's not supported. Since it does work for you it may be that the specification is just wrong, or it may be that the hw folks just didn't bother validating that configuration, or it may be that there is some kind of corner case that could cause it to fail under some circumstances which you're not hitting.
Comment 12 Leho Kraav (:macmaN :lkraav) 2019-09-03 05:30:10 UTC
> The hardware specification says it's not supported.

Morning. I find that extremely curious, since this resolution works also in Windows without a hitch.

Any updates from hardware people?
Comment 13 Ville Syrjala 2019-09-05 13:52:43 UTC
(In reply to Leho Kraav (:macmaN :lkraav) from comment #12)
> > The hardware specification says it's not supported.
> 
> Morning. I find that extremely curious, since this resolution works also in
> Windows without a hitch.
> 
> Any updates from hardware people?

I got a reply. And it was basically "not validated, has some corner cases". I need to figure out if any of those corner cases are really important or not. In the meantime I think we can bump the limit back up to 5k:
https://patchwork.freedesktop.org/series/66286/

Would be nice if you can double check that those patches work for you.
Comment 14 Leho Kraav (:macmaN :lkraav) 2019-09-05 17:14:12 UTC
Hmm, is this patchset supposed to apply on top of today's `master` (5.3.0-rc7), or some other tree?

```
$ stg import Series-without-cover-letter.mbox 
Checking for changes in the working directory ... done
Importing patch "Series-without-cover-letter.mbox" ... error: patch failed: drivers/gpu/drm/i915/display/intel_display.h:32
error: drivers/gpu/drm/i915/display/intel_display.h: patch does not apply
stg import: Diff does not apply cleanly
```
Comment 15 Ville Syrjala 2019-09-06 12:31:53 UTC
(In reply to Leho Kraav (:macmaN :lkraav) from comment #14)
> Hmm, is this patchset supposed to apply on top of today's `master`
> (5.3.0-rc7), or some other tree?
> 
> ```
> $ stg import Series-without-cover-letter.mbox 
> Checking for changes in the working directory ... done
> Importing patch "Series-without-cover-letter.mbox" ... error: patch failed:
> drivers/gpu/drm/i915/display/intel_display.h:32
> error: drivers/gpu/drm/i915/display/intel_display.h: patch does not apply
> stg import: Diff does not apply cleanly
> ```

It applies to drm-tip:
git://anongit.freedesktop.org/drm-tip drm-tip

Or here's a branch with the patches already applied:
git://github.com/vsyrjala/linux.git plane_width_bump
Comment 16 Leho Kraav (:macmaN :lkraav) 2019-09-09 08:49:44 UTC
I'm booting drm-tip with this patch series right now (mainly for screen freezes at https://bugs.freedesktop.org/show_bug.cgi?id=111500)

5120x1440 resolution loaded successfully (y)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.