[modesetting] Could not commit atomic request.

[jaydeetay]

Hi,
A few of us have been developing some simple Flutter games for the Pi and have run into an odd issue. More often than not, the game will render an initial screen but not show any further updates. The game appears to have frozen, but through adding logging statements etc we've confirmed that keyboard inputs are being received and processed - just no further updates to the screen are being made. There's a randomness to it - sometimes the game will work fine, sometimes not. By adding sleep statements or setState calls in different places (we're clutching at straws!) we can change the odds of the game working, but we haven't found a hack that reliably fixes the problem. The main clue we have so far is that when the game fails to work we see this error:

[modesetting] Could not commit atomic request. drmModeAtomicCommit: Device or resource busy

Any ideas?

John

PS There are a couple of other warnings in the logs that are probably red herrings since they occur whether or not the game works:
WARNING: display has non-square pixels
and
WARNING: Kernel didn't return a valid vblank timestamp. (timestamp == 0) VSync with be disabled.

[ardera]

Hi,
A few of us have been developing some simple Flutter games for the Pi

That's awesome! What games are you developing? Do you have a repo link?

[modesetting] Could not commit atomic request. drmModeAtomicCommit: Device or resource busy

That's not an uncommon problem. Someone else had the same problem before and I implemented a workaround (because the underlying issue most likely lies in the kernel).

If drmModeAtomicCommit fails with EBUSY the first time, flutter-pi should print the following message in the log:

[compositor] Non-blocking drmModeAtomicCommit failed with EBUSY.
             Future drmModeAtomicCommits will be executed blockingly.
             This may have have an impact on performance.

Is that message printed out in your case?

Also, can you try running this program? If it fails to start, you can try invoking it with -D /dev/dri/card1. If that program fails with Device or resource busy too, it's 99% a kernel problem.

Furthermore, what Raspberry Pi model do you use and do you use a HDMI or DSI display?

[jaydeetay]

Thanks for the quick reply.

That's awesome! What games are you developing? Do you have a repo link?

No public repo link as yet - I'll talk to the other devs about what they might want to put up on github. A bunch of us built these Picade kits for a team fun event. At the moment we're just making simple clones of some classic 70s arcade games and adding a little 'team flavor' to make them more interesting. The kit itself runs RetroPi. Somewhat surprisingly, running flutter-pi from the commandline on the device was much more successful in avoiding the problem than running flutter-pi from EmulationStation though still not 100% reliable.

[modesetting] Could not commit atomic request. drmModeAtomicCommit: Device or resource busy

That's not an uncommon problem. Someone else had the same problem before and I implemented a workaround (because the underlying issue most likely lies in the kernel).

Ah! I did read through most of the issues (open and closed) in the tracker to see what I could find but didn't see this exact same problem.

If drmModeAtomicCommit fails with EBUSY the first time, flutter-pi should print the following message in the log:

[compositor] Non-blocking drmModeAtomicCommit failed with EBUSY.
             Future drmModeAtomicCommits will be executed blockingly.
             This may have have an impact on performance.

Is that message printed out in your case?

I don't see that one I'm afraid.

Here are some of the other warnings I see:

[modesetting] Could not set DRM client universal planes capable. drmSetClientCap: Operation not supported
[flutter-pi] Could not set DRM channel from device at "/dev/dri/card1". Continuing.
[flutter-pi] WARNING: display has non-square pixels. Non-square pixels are not supported by flutter.

Also, can you try running this program? If it fails to start, you can try invoking it with -D /dev/dri/card1. If that program fails with Device or resource busy too, it's 99% a kernel problem.

Sure! Assuming I built it correctly (meson is new to me) I see a multicolored spinning cube.

BTW - one of my teammates hardcoded use_atomic_modesetting to false and that worked around the problem.

Furthermore, what Raspberry Pi model do you use and do you use a HDMI or DSI display?

It's a 2 gig Raspberry Pi 4. The Picade uses HDMI.

[ardera]

No public repo link as yet - I'll talk to the other devs about what they might want to put up on github. A bunch of us built these Picade kits for a team fun event. At the moment we're just making simple clones of some classic 70s arcade games and adding a little 'team flavor' to make them more interesting. The kit itself runs RetroPi.

Sounds interesting! Good luck.

Somewhat surprisingly, running flutter-pi from the commandline on the device was much more successful in avoiding the problem than running flutter-pi from EmulationStation though still not 100% reliable.

The issue is kinda strange. I think in the future, I should switch to using syncobj synchronization instead, which is what SDL / Emulation Station and kmscube use by default, too; it seems a lot more reliable.

Ah! I did read through most of the issues (open and closed) in the tracker to see what I could find but didn't see this exact same problem.

You didn't miss it, I think it was reported to me via e-mail

I don't see that one I'm afraid.

Oops, that's my bad. I accidentally disabled the workaround. I'll fix it.

BTW - one of my teammates hardcoded use_atomic_modesetting to false and that worked around the problem.

That works too. Actually, for most people it doesn't make a difference whether atomic modesetting is or is not used. It's really only necessary when you want to use the video player plugin.

[jaydeetay]

Thanks for the quick fix!