Bug 111501

@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