flutter-pi doesn't run on stm32mp15x-ev1, drmModeAtomicCommit errors out

[compenguy]

I'm trying to bring up a flutter app on an STM32MP1 (eval board) on the etnaviv mesa driver, using flutter-pi (current tip of master branch).

kmscube -a runs fine, but flutter-pi is throwing this error:

[modesetting] Could not commit atomic request. drmModeAtomicCommit: Invalid argument
[compositor] Could not present frame. drmModeAtomicCommit: Invalid argument

I see some similarities to issue #86.

Attached is the program output (with a little bit of extra output added by me), as well as the dmesg logs from running flutter-pi and kmscube -a under drm.debug=0xff:

• output.txt
• dmesg_flutter_pi.txt
• dmesg_kmscube.txt

[ardera]

The logs are pretty small, maybe enabling DRM debugging at runtime doesn't work that good in your case. Can you try the following:

• add drm.debug=0x3ff to the kernel command line (don't know how to do that on the STM though)
• run flutter-pi / kmscube again
• include the full output of dmesg, even better would be the syslog

I guess you're using a Raydium RM68200 LCD Controller, right? If that's the case, the drivers are mainline and should be printing some more debugging information.

Just for comparison, I once forgot to disable DRM debugging on my Pi, had some flutter app running for an hour and the syslog files in /var/log grew by ~22GB.

If that doesn't work, you can also try using dynamic debugging (if that's possible with your kernel) and enable some of the logging inside linux/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c.

If we can't find out the reason drmModeAtomicCommit returns EINVAL via DRM logs, I guess I can just create a new flutter-pi branch for debugging and step-by-step remove args passed to drmModeAtomicCommit until it works again.

[compenguy]

Sorry about that, I cleared the dmesg logs to remove the spew from some other things I had tried right before I ran flutter-pi to make it obvious exactly what output corresponded to the lifetime of the program. I'm attaching a full syslog (journalctl --system) for each (clean boot before each one, I <ctrl>+ced kmscube after a few frames, so the log should show the teardown, too, but I suspended flutter-pi, so the log should stop right at the point where it returned EINVAL):

• syslog_flutter_pi.txt
• syslog_kmscube.txt

Also, I don't know what display controller it has, and I'm not sure how to check.

[ardera]

It seems flutter-pi tries to present "nothing" on the screen which results in the EINVAL. (Actually, presenting nothing is fine by the kernel, it's just that the kernel can't signal flutter-pi when it's done)

The only case that can be happening is when flutter somehow tries to present nothing. Which is also weird because I tested that (with a flutter app that doesn't call runApp in it's main, so it's basically a overkill dart cmdline executable), but in my experience flutter wouldn't even call flutter-pi's present method. In your case, flutter does call the present method, just with empty args kinda.

What flutter app are you using? Can you try a standard one like flutter-gallery? (Instructions in the readme)

If the flutter app is fine, I'll add some logging to the present function & you can run your app again, so I can see what's going on there

Also, I don't know what display controller it has, and I'm not sure how to check.

I just assumed it was that one because I looked at the wiki a bit to find out the relevant kernel drivers. The wiki had example configs for two display controllers, one being the Raydium RM68200 which has a 720x1280p50 display mode and DSI, so it matches the display mode printed out by flutter-pi.

[compenguy]

I have determined that it was a problem with the flutter engine I had cross-compiled. Using the prebuilt one from the engine-binaries branch seems to work fine.

[compenguy]

Thanks for your help, the error messages coming from flutter-pi left me certain there was a problem interfacing with the gpu, but that wasn't the case at all.

[ardera]

It's an edge case, theoretically the drmModeAtomicCommit error is flutter-pi's fault, but since it only ocurrs when the flutter engine does things it shouldn't do (present "nothing"), I'll probably not fix it. Maybe I can add an assert with an error message so it's easier to find the cause if someone else happens to have the same error in the future.

[compenguy]

An assert would be great, but even if you do nothing, it's at least documented via this issue.