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/
@Manasi, can you help here? Patch mentioned in the Bug 97244 will help here? https://bugs.freedesktop.org/show_bug.cgi?id=97244#c55
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.
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.
Thanks. Is this patch independent enough to attempt a simple revert and I could see what happens?
(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);
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.
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.
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)?
(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.
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.
(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.
> 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?
(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.
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 ```
(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
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)
Looks like I forgot to mark this as fixed. Let's remedy that. commit bed34ef544f9ab37ab349c04cf4142282c4dcf5d Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 5 16:50:43 2019 +0300 drm/i915: Bump skl+ max plane width to 5k for linear/x-tiled
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.