failed assertion on rbp4 with multiple monitors

[mmonaco]

I'm hitting an assertion on a Raspberry Pi 4 with two monitors (archlinuxarm)

• Sway Version: 1.2 (also tried building sway and wlroots from git)

• Debug Log:

2019-12-02 21:50:57 - [sway/main.c:152] Linux rpi4 4.19.86-1-ARCH swaywm/sway#1 SMP PREEMPT Sat Nov 30 18:54:34 UTC 2019 armv7l GNU/Linux
2019-12-02 21:50:57 - [sway/main.c:168] Contents of /etc/os-release:
2019-12-02 21:50:57 - [sway/main.c:152] NAME="Arch Linux ARM"
2019-12-02 21:50:57 - [sway/main.c:152] PRETTY_NAME="Arch Linux ARM"
2019-12-02 21:50:57 - [sway/main.c:152] ID=archarm
2019-12-02 21:50:57 - [sway/main.c:152] ID_LIKE=arch
2019-12-02 21:50:57 - [sway/main.c:152] BUILD_ID=rolling
2019-12-02 21:50:57 - [sway/main.c:152] ANSI_COLOR="0;36"
2019-12-02 21:50:57 - [sway/main.c:152] HOME_URL="https://archlinuxarm.org/"
2019-12-02 21:50:57 - [sway/main.c:152] DOCUMENTATION_URL="https://archlinuxarm.org/wiki"
2019-12-02 21:50:57 - [sway/main.c:152] SUPPORT_URL="https://archlinuxarm.org/forum"
2019-12-02 21:50:57 - [sway/main.c:152] BUG_REPORT_URL="https://github.com/archlinuxarm/PKGBUILDs/issues"
2019-12-02 21:50:57 - [sway/main.c:152] LOGO=archlinux
2019-12-02 21:50:57 - [sway/main.c:140] LD_LIBRARY_PATH=(null)
2019-12-02 21:50:57 - [sway/main.c:140] LD_PRELOAD=(null)
2019-12-02 21:50:57 - [sway/main.c:140] PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
2019-12-02 21:50:57 - [sway/main.c:140] SWAYSOCK=(null)
2019-12-02 21:50:57 - [sway/server.c:39] Preparing Wayland server initialization
2019-12-02 21:50:57 - [backend/session/logind.c:675] Successfully loaded logind session
2019-12-02 21:50:57 - [backend/backend.c:192] Found 2 GPUs
2019-12-02 21:50:57 - [backend/drm/backend.c:152] Initializing DRM backend for /dev/dri/card1 (vc4)
2019-12-02 21:50:57 - [backend/drm/drm.c:69] Using atomic DRM interface
2019-12-02 21:50:57 - [backend/drm/drm.c:254] Found 2 DRM CRTCs
2019-12-02 21:50:57 - [backend/drm/drm.c:175] Found 6 DRM planes
sway: backend/drm/drm.c:85: add_plane: Assertion `!(type == DRM_PLANE_TYPE_PRIMARY && crtc->primary)' failed

• Configuration File:

Reproducible with no (default) config file.

[emersion]

Can you run drm_info and share the output? (Bonus points if you upload it to drmdb :P )

[mmonaco]

https://drmdb.emersion.fr/devices/0f4161ba12dc

Note, on stderr: drmModeGetResources: Invalid argument

[emersion]

Okay, interesting. On this platform vc4 advertises a primary plane compatible with multiple CRTCs. Need to check whether this is a vc4 bug.

[emersion]

Apparently not a driver bug according to #dri-devel. So it's a wlroots bug.

[ascent12]

@emersion https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-abstraction

All drivers should provide one primary plane per CRTC to avoid surprising userspace too much

I'm going to argue that this is a driver bug, and is breaking the userspace API.

[emersion]

Maybe this means "at least one".

[TimB87]

https://drmdb.emersion.fr/devices/37e47e146687

Same problem over here on the rpi4.

[asqwerty666]

is this a wlroots bug or a sway bug? is there any workaround? is there any other wayland compositor I can try?

[TimB87]

I tried around a bit, but didn't get it to run anymore (despite that I had it running at some point before posting here): https://i.imgur.com/PrRgT3F.png

[Ongy]

Are you on fkms or "real" kms dtb?

[TimB87]

@Ongy I am on fkms, I don't think that the non fake kms dtb is supposed to run on the pi4.. IIRC, when I tried it, it hung while initializing the framebuffer.

[asqwerty666]

Are you on fkms or "real" kms dtb?

fkms. I tried manjaro and it load fkms by default. Is should say that with single monitor sway runs amazing. I was so happy that bought a second one and then I got the segfault. 🙄

[schauveau]

I have a patch that works with 2 displays on a RPI4 ... kind of.

schauveau@bad0a6e

Instead of always using the first possible CRTC (defined by the least significant bit set in possible_crtcs), my code is trying all possible CRTCs until it finds one that is not already associated with a plane of the considered kind. That seems to work fine at least for the primary planes.

However, I encounter a very strange problem with the mouse cursor. When the cursor is in my second screen, a giant cursor is appearing erratically in the first screen. It does not show in screenshots but here is a photo showing a giant cursor (most of the time they are truncated).

https://ibb.co/pnym2Y6

I also noticed something strange. At one point, I commented out the assignment of crtc->cursor in drm.c but somehow the CRTC_ID field of drm_info was still showing that the 2 Cursor planes were associated to the 2 CRTCs. Something else must be responsible for that association but I could not figure out what.

My DRM info is https://drmdb.emersion.fr/devices/01cd892b4221 and it is quite similar toTimB87's with a CRTCs list containing 8 values (2 existing CRTCS and 6 non-existing ones). That seems to be the default behavior on recent Linux 5.x kernels. Also my 2 monitors have different resolutions (1920x1200 vs 1920x1080).

@emersion How can I enable the wlroots logging faculties when using sway?

[schauveau]

I just noticed something about the giant cursor. It seems that t appears when the cursor image is changing and it always has the shape of the previous small cursor. That is as if the old cursor texture was reused in a 'magnified overlay'.

[emersion]

How can I enable the wlroots logging faculties when using sway?

sway -d >sway.log 2>&1

[schauveau]

@emersion Really? Ho! I see... I tried sway -d but without the redirections and I was not seeing any output from wlroot in the console after exiting sway. I assume that this is because the text console is disabled while sway is running. Very confusing!

[schauveau]

I think that I now understand what is going on. I monitored the CRTC planes activity with

 while sleep 1 ; do clear ; drm_info | grep -e Plane -e CRTC_ ; done

And, when using an X11 desktop, I see that the cursor planes are not associated to the CRTC when the cursor is not visible on that screen. However, Sway is behaving differently and keeps an active cursor plane for each CRTC. As far as I can tell the giant cursor is occurring when an cursor plane is fully out-of-bounds and gets a negative coordinate in either X and Y. Simply speaking, the RPi4 driver has a problem with negative cursor coordinates that are bigger than the cursor dimension (e.g. for a 64x64 cursor, a coordinate of -35 is fine but -65 is not).

It is worth noting that the X Y coordinates of out-of-bound cursor planes are only updated when the mouse shape is changed. I can probably get rid of most giant cursors by adding a proper out-of-bound check in the wlroot code in charge of that update.

I also figured out that a large negative coordinate can be obtained by moving very quickly from one screen to another. The goal is of course to obtain a first out-of-bound cursor position with a negative coordinate bigger than the cursor plane size. That one is probably a bit more difficult to fix in wlroots without disabling out-of-bound cursor planes.

Globally speaking, I think that wlroots should use the same approach than the X11 server: The cursor plane should be disabled when the cursor becomes out-of-bound cursors. That probably makes sense for performance reasons.

[emersion]

It should already do this:

wlroots/backend/drm/drm.c

Line 1003 in 751a21d

bool drm_connector_is_cursor_visible(struct wlr_drm_connector *conn) {

However the rpi driver shouldn't freak out when userspace sends negative coords. This isn't a wlroots bug (because it's perfectly valid to set negative coords), the rpi driver should be fixed.

[schauveau]

Good. For practical reasons, I was experimenting on the current Ubuntu source package based on 0.10.0 and so without that function. I guess that I will have to recompile Sway & co then :-( Hopefully, that should solve my giant cursor problem and if everything looks fine then I will make a pull request.

And I agree that the negative coordinate problem is probably a rpi driver bug. I'll report it. Not sure where exactly. Probably the v3d drm driver.

[schauveau]

I tested my improved DRM plane matching on master and that seems to work fine with 2 monitors on RPi4.
Pull request #2333

[schauveau]

I was probably a bit optimistic when I wrote that everything was working fine with 2 monitors on the RPi4.
There are still some issues with the cursors. wlroots sometime produces some error messages when updating the drm cursor planes ("Unable to add DRM framebuffer") and some cursors images become corrupted.
I do not believe that this is directly related to my pull request code. This is more likely a problem in the vc4 drm driver or a bug in wlroots master. I also noticed some very very rare giant cursors (see my previous posts) that could potentially be the cause of the DRM errors.

Fortunately, WLR_NO_HARDWARE_CURSORS=1 can be used to disable DRM cursor planes.

[schauveau]

Since my pull request is likely to be rejected in favor of a resolution in the Raspberry Pi kernels, here is a simple patch.

rpi4.patch.gz

cd wlroots/backend/drm
zcat ~/git/wlroots/rpi4.patch.gz | patch

And if your cursor is behaving strangely then set WLR_NO_HARDWARE_CURSORS=1