Weston DRM backend fails on 5120x1440 resolution using Intel Kaby Lake graphics

It seems that Weston is not able to find a working setting when using DRM backend on a Dell U4919DW (5120x1440@30Hz) connected via HDMI. On the same setup Gnome Mutter seems to work.

I created two log files with drm_debug redirected to weston_log output, one requesting 3840x1080@60.0 explicitly 4k.txt and 5120x1440@30.0 5k.txt.

added DRM/KMS backend label

Hi @agners! Thanks for the report.

The irony here is the bug no#. Mind posting the kernel ring buffer with drm.debug set to 0xff to see more? Wondering if Mutter is smarter here and will fallback to the next resolution available? I'd expect that it is noticeable in resolution drop (and higher frame rate) so I'm just checking, but I guess it doesn't hurt to ask. Comparing the logs I don't see anything (besides different resolution) weird, so I'd expect some pipe related issues on the driver (i915) side.

Instructions to get DRM logs: https://github.com/swaywm/wlroots/wiki/DRM-Debugging

@marius.vlad0 hehe, didn't notice the bug number, but yeah, rather accurate :-)

Sorry for the incomplete bug report, I was a bit in a rush yesterday. Here is the dmesg output with drm.debug=0xfe while starting Weston: dmesg-while-weston-start-5k.txt (and the Weston Log from the same run for completeness: weston-log-while-weston-start-5k.txt).

Unfortunately Gnome Settings does not show the screen refresh rate. However, using D-Bus shows its using the same mode busctl --user call org.gnome.Mutter.DisplayConfig /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig GetCurrentState gnome-mode-from-dbus.txt. That is also what the screen itself tells me.

Here is also dmesg when VT switching to a VT running the Gnome Desktop: dmesg-debug-vt-switch-to-gnome.

I was planning to look into this myself a bit deeper. It really seems Atomic mode set fails for this case for some reason. I noticed that Gnome uses a different plane (1B vs. 1A), and the src/dst resolutions of that plane seem to be different (although, here what Mutter is doing seems odd to me).

This seems likely the root cause:

[drm:skl_check_plane_surface [i915]] requested Y/RGB source size 5120x1440 too big (limit 4096x4096)
[drm:intel_atomic_check [i915]] [PLANE:52:plane 1B] atomic driver check failed

Side note: According to Intel Ark my GPU actually can't drive 5k: https://ark.intel.com/content/www/us/en/ark/products/97466/intel-core-i7-7600u-processor-4m-cache-up-to-3-90-ghz.html

However, as stated above, it definitly does work with Mutter. I found this discussion which sheds some light why it does: https://bugs.freedesktop.org/show_bug.cgi?id=111501

That also clears up some confusion I had: I was pretty sure that when I bought the monitor some months back, I had to run the monitor on 4k when using my Laptop. After some time I was surprised that I was actually able to use 5k. I was wondering if it was just me being too stupid to select the resolution right. But I see now that this really got changed with Linux 5.4. It seems I was sane after all

However, the question still is standing, why does it not work when using Weston? I am trying to get some more information what the exact plane configuration is with Mutter.

changed title from Weston DRM backend fails on 5120x1440 resolution to Weston DRM backend fails on 5120x1440 resolution using Intel Kaby Lake graphics

Progress: Checked also modetest while running Gnome, it shows that Gnome also uses Plane 52: modetest-gnome-desktop.txt.

It seems the Intel DRM driver uses a different resolution limit when using Weston. I assume that this case statement must take a different path: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_display.c#L3643

So it seems that Weston is using a different framebuffer modifier. From what I understand this is chosen by Mesa? With that in mind I was thinking that the pixman backend may use a different framebuffer modifier, and indeed, with using --use-pixman 5k works: weston-log-start-5k-use-pixman.txt.

Ah, right. Some modifiers use more bandwidth than others. Mutter doesn't support modifiers so is able to enable a higher resolution.

In wlroots, we had to implement a fallback to disable modifiers if modesetting fails.

This also interacts with multi-output setups (where you need to disable modifiers on already-enabled outputs to be able to light up an additional output). This part isn't yet implemented in wlroots.

@emersion I was wondering how the modifiers selection exactly works with EGL. It seems that the Intel GPU driver has some logic internally as well: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/mesa/drivers/dri/i965/intel_screen.c#L667

I guess a similar fallback like wlroots implements would be required to fix this issue in Weston.

Weston provides a list of modifiers to gbm_surface_create_with_modifiers. GBM internally picks the best one.

Thanks for all the digging, sounds like a legit Weston issue indeed, needing to try harder with enabling outputs.

Hm, this seems somewhat hard to do in practise as the modifiers are advertised to GBM on drm_output_enable, however, the atomic state commit fails on drm_repaint_flush, when we try to apply the initial state.

I guess we would either have to build a state and use drm_pending_state_test at output enable time, or recreate the gbm surface when the state applying fails during repaint. Both option sound not very nice.

Is there maybe another method to influence modifier selection?

have to build a state and use drm_pending_state_test at output enable

This doesn't sound that bad, there could be other situations where you might want this, where you might want to test out the pending state before doing the commit. I think that the cloning/mirror had something similar (where you could end up with a invalid commit -- for desktop was this when I tried). We could fallback in the same manner to some simpler state.

I think one the issues was that we don't really know what actions to take if we don't have distinct errno returned, but maybe having just a few use cases around we could just verify and try out one after one?

I think the best solution would be to create a BO with modifiers and use TEST_ONLY to check whether that would work.

Yeah. I don't like that at all, but I also don't see any - and I mean any - other option.

state-propose.c has some code which gets called by drm_assign_planes which tries out layer variants. But this is well after drm_output_enable. From what I can tell at drm_output_enable time we really do not do any state checks so far. I am not sure if we would have the means to build a meaningful state that early already.

@emersion do you meant to do that at drm_output_enable time or later, at render time?

A rather cheap option to side step the whole issue is to introduce a environment variable, e.g. WESTON_DISABLE_FB_MODIFIERS, similar to WESTON_DISABLE_UNIVERSAL_PLANES we already have. That isn't a proper solution but would at least give a runtime knob to get it working. Not sure how common such modifier restrictions are in practise.

do you meant to do that at drm_output_enable time or later, at render time?

Ideally should be done at enable time, so that we don't try to enable an output that really can't be enabled. This may require more work of course…

A rather cheap option to side step the whole issue is to introduce a environment variable, e.g. WESTON_DISABLE_FB_MODIFIERS, similar to WESTON_DISABLE_UNIVERSAL_PLANES we already have.

We have exactly this in wlroots as well to help with broken multi-output issues.

A rather cheap option to side step the whole issue is to introduce a environment variable, e.g. WESTON_DISABLE_FB_MODIFIERS, similar to WESTON_DISABLE_UNIVERSAL_PLANES we already have. That isn't a proper solution but would at least give a runtime knob to get it working. Not sure how common such modifier restrictions are in practise.

I don't know of any driver other than Intel where using modifiers breaks single-plane scanout.

Even when multiple outputs are light up?

Modifiers increase bw usage in general as far as I've understood, so blowing up the limit could happen on any driver theoretically. Maybe it only happens on Intel in practice....

In general it's not necessarily an increase or decrease.

The specific issue is that Intel's scanout engine still fetches single scanlines at a time, and the tiling -> linear conversion happens after the fetch, rather than being closer to the memory interface. It relies on a FIFO which is a) globally shared between all CRTCs, and b) way smaller than hoped. For Y-tiled layouts which are the most efficient for the GPU, you need to fill the FIFO with like the entire frame due to column-major tile ordering, and end up blowing through the limit pretty quickly.

Other designs - particularly AFBC - have tiling located far closer to the memory interface like AXI, don't have global FIFOs, don't have tiny FIFOs, etc. So far I haven't seen any of this other hardware suffer from the same problem as Intel.

mentioned in commit agners/weston@999301d3

mentioned in merge request !448 (merged)

mentioned in commit agners/weston@46f774eb

mentioned in commit ahe/weston@ac206db7

mentioned in commit trem/weston@d963077e

mentioned in commit agners/weston@465ab2cd