With atomic modesetting, flutter-pi can not run on db410c

[bing-mao]

I compiled a arm 64 bit version for db410c(qualcomm APQ8016), while with following change

commit id: 629c016
atomic modesetting, omxplayer rotation - implement atomic modesetting - make omxplayer satisfy device orientation

My board can no longer run the flutter-pi. I traced to kernel, looks my board does not support atomic operation.

it reports
[modesetting] Could not commit atomic request. drmModeAtomicCommit: Invalid argument

Any chance to support the old way of running flutter pi?

Thanks

[bing-mao]

read some article on internet, the atomic mode setting is modern and batter way to for graphics. It's important for cursor support. I don't expect the old way. Any comments on how to check the system why the Invalid argument happened will be appreciated.

[ardera]

Yeah, atomic modesetting is the modern approach, although it's not too bleeding edge as well (it was added in 2015)
I read that all in-kernel drivers were migrated to atomic modesetting and I needed it for the omxplayer plugin, so I just used it

I think it's possible to implement a fallback to legacy modesetting, if atomic modesetting is not supported. And then just deactivate the omxplayer plugin if legacy modesetting is being used.

drmModeAtomicCommit: Invalid argument

The invalid argument means the ioctl to the kernel returned EINVAL, which is probably returned because the device does not support atomic modesetting.

Which kernel version do you use btw?

[ardera]

Actually, atomic modesetting should be possible on your board. Freedreno (The open-source graphics driver for Qualcomm GPUs, which is also contained in the official linux source tree) supports the Adreno 306, which is the GPU of your db410c; and freedreno supports atomic modesetting since early 2015. Do you use a different driver than freedreno? Or maybe your kernel is outdated.

[bing-mao]

Hi ardera,
Thank you so much for the quick reply. My db410c has a kernel 5.7. It shall be able to support atomic. I did some test today

• I have tested modetest(test app of libdrm) with '-a' option to test my board, it does support atomic, and I can see this "ioctl(3, DRM_IOCTL_MODE_ATOMIC, 0xffffed0d6d10) = 0" if I use strace to print the system call to kernel
• I also use strace to flutter pi, I can not see the ioctl with DRM_IOCTL_MODE_ATOMIC
• Then I use gdb and step instruction by instruction to check, the function drmModeAtomicCommit in libdrm did call the "DRM_IOCTL(fd, DRM_IOCTL_MODE_ATOMIC, &atomic);", but the system call returns -1 and the errno is -13, which is EINVAL

It's strange, why the system call in modetest can be successful, while flutter-pi failed. Anything I can tweak to disable something to try?

[ardera]

• I have tested modetest(test app of libdrm) with '-a' option to test my board, it does support atomic, and I can see this "ioctl(3, DRM_IOCTL_MODE_ATOMIC, 0xffffed0d6d10) = 0" if I use strace to print the system call to kernel
• I also use strace to flutter pi, I can not see the ioctl with DRM_IOCTL_MODE_ATOMIC
• Then I use gdb and step instruction by instruction to check, the function drmModeAtomicCommit in libdrm did call the "DRM_IOCTL(fd, DRM_IOCTL_MODE_ATOMIC, &atomic);", but the system call returns -1 and the errno is -13, which is EINVAL

That's good information!

Can you try running kmscube (sudo apt install kmscube) with the --atomic flag?

If that works fine can you:

• add drm.debug=0xff parameter to /boot/cmdline.txt
• reboot
• run flutter-pi again and wait for the drmModeAtomicCommit error to happen
• terminate flutter-pi
• send me the complete output of running dmesg

It's possible that Invalid argument in this case really just means that I specified some invalid things in the atomic commit. If that's the case, the drm debugging should print some more precise error description.

Also, be sure to remove the drm.debug parameter once you're finished, it will hog up disk space really fast.

EDIT: /boot/cmdline needs to be /boot/cmdline.txt

[bing-mao]

Thanks ardera!
I can run kmscube with -A on this db410c, from the visual effect on screen, I can tell with atomic, the screen is not smooth and I can see tearing a little bit. That's strange. without atomic, the visual effect is good.
Then I captured the kernel log.
dmesg_flutter-pi.txt
dmesg_kmxcube.txt

[bing-mao]

please ignore the previous log, since directly capture from dmesg may loss some content due to the buffer size in memory.

Use these:
kmscube.txt

flutter-pi.txt

[ardera]

I can run kmscube with -A on this db410c, from the visual effect on screen, I can tell with atomic, the screen is not smooth and I can see tearing a little bit.

Yeah thats strange. vanilla kmscube uses a kinda cutting-edge synchronization mechanism (which isn't even supported on Raspberry Pi), it's possible that's causing some issues.

please ignore the previous log, since directly capture from dmesg may loss some content due to the buffer size in memory.

Use these:
kmscube.txt

flutter-pi.txt

Thanks! Unfortunately, there's not much info about the issue in the logs. It just returns EINVAL, without any explanation why. The weird thing is, it's not even checking if the atomic commit is valid. (which would print a checking <pointer> in the logs) It copies the atomic request into the kernel space and then returns EINVAL out of nowhere. (The point of interest is around the line where it says ret = -22)

I modified kmscube to use the synchronization mechanism flutter-pi uses. Can you try and see if that works for you? (You don't need to enable DRM debugging, just try if it works)

The repo is here. Instructions to build & run it:

$ sudo apt update && sudo apt install meson ninja
$ git clone https://github.com/ardera/kmscube_using_pageflips kmscube
$ cd kmscube
$ mkdir build && cd build
$ meson ../
$ ninja
$ ./kmscube

[bing-mao]

Thank you ardera. I have tried your code, both modes (with/without -A) work well.

[bing-mao]

Hi ardera,
I have checked https://github.com/ardera/kmscube_using_pageflips, I didn't see recent changes, maybe you forgot to push you change?

BR,
Bing

[ardera]

I have checked https://github.com/ardera/kmscube_using_pageflips, I didn't see recent changes, maybe you forgot to push you change?

Yep my bad, the changes are now online.

[bing-mao]

Hi ardera,
Thank you. I used your latest commit to test, still both two modes work

with -A option, it can print following logs

committing 0xaaaac2314110
page flip event ocurred: 153.713297
atomic_request 0xaaaac2315c10: plane 33: ["FB_ID"] = 116
atomic_request 0xaaaac2315c10: plane 33: ["CRTC_ID"] = 42
atomic_request 0xaaaac2315c10: plane 33: ["SRC_X"] = 0
atomic_request 0xaaaac2315c10: plane 33: ["SRC_Y"] = 0
atomic_request 0xaaaac2315c10: plane 33: ["SRC_W"] = 125829120
atomic_request 0xaaaac2315c10: plane 33: ["SRC_H"] = 78643200
atomic_request 0xaaaac2315c10: plane 33: ["CRTC_X"] = 0
atomic_request 0xaaaac2315c10: plane 33: ["CRTC_Y"] = 0
atomic_request 0xaaaac2315c10: plane 33: ["CRTC_W"] = 1920
atomic_request 0xaaaac2315c10: plane 33: ["CRTC_H"] = 1200

BR,
Bing

[ardera]

I just created a new branch called fix/db410c-compatibility. I disabled the usage of some DRM features there. It should now behave exactly the same as the kmscube code. (The content of the atomic commits, which is what the log in your comment actually contains, should now be exactly the same with flutter-pi and kmscube.)

If this doesn't work, I'm out of ideas. If it does work, I can slowly increase the DRM features used by flutter-pi and we can see where it breaks again.

Normally, I'd triage this myself but I don't have a db410c unfortunately

[bing-mao]

Hi ardera,
Thank you so much. I have tested the code on your fix/db410c-compatibility branch, it works well.

BR,
Bing

[ardera]

Okay, just reenabled modeset on that branch. Can you test again?

[bing-mao]

37f0b9e also works well

[ardera]

Okay, just pushed 4 new commits. Can you try them out in order and see where it breaks?

[bing-mao]

Hi ardera,
I have done more tests, actually your develop branch had already fixed the issue.
with this commit 1a49227, my board can work well.

BR,
Bing

[bing-mao]

Have just tested. Your latest fix/db410c-compatibility branch with the 4 new changes also works well.

[ardera]

I have done more tests, actually your develop branch had already fixed the issue.
with this commit 1a49227, my board can work well.

That's interesting. I was 100% sure that couldn't be the reason, since then it would've printed checking <pointer> and then ret = -22 in the logs you provided.
Does it print any warnings like [compositor] GPU does not support reflecting the screen in Y-direction. or [compositor] GPU does not supported the desired HW plane order.?

It should also print two messages like zpos range: <number> <= zpos <= <number> and supported rotation bits: .... Can you tell me what those messages exactly look like for you? (Just so I don't accidentally implement features that only work on Raspberry Pi)

[bing-mao]

Hi ardera,
Here is some log printed on console

atomic_request 0xffff986c6aa0: plane 33: ["SRC_W"] = 125829120
atomic_request 0xffff986c6aa0: plane 33: ["SRC_H"] = 78643200
atomic_request 0xffff986c6aa0: plane 33: ["CRTC_X"] = 0
atomic_request 0xffff986c6aa0: plane 33: ["CRTC_Y"] = 0
atomic_request 0xffff986c6aa0: plane 33: ["CRTC_W"] = 1920
atomic_request 0xffff986c6aa0: plane 33: ["CRTC_H"] = 1200
supported "rotation" bits: rotate-0, rotate-180, reflect-x, reflect-y,
atomic_request 0xffff986c6aa0: plane 33: ["rotation"] = 1
zpos range: 1 <= zpos <= 255
[compositor] GPU does nn4 supported the desired HW plane order.
Some UI layers may be invisible.
atomic_request 0xffff986c6aa0: plane 40: ["FB_ID"] = 0
atomic_request 0xffff986c6aa0: plane 40: ["CRTC_ID"] = 0
atomic_request 0xffff986c6aa0: plane 38: ["FB_ID"] = 0
atomic_request 0xffff986c6aa0: plane 38: ["CRTC_ID"] = 0
atomic_request 0xffff986c6aa0: plane 36: ["FB_ID" = 0
atomic_request 0xffff986c6aa0: plane 36: ["CRTC_ID"] = 0
committing 0xffff986c6aa0 nonblocking
[ 96.603828] pageflip ocurred at 96.587066
atomic_request 0xffff984a90: plane 33: ["FB_ID"] = 74
atomic_request 0xffff9894a090: plane 33: ["CRTC_ID"] = 42
atomic_request 0xffff9894a090: plane 33: ["SRC_X"] = 0
atomic_request 0xffff9894a090: plane 33: ["SRC_Y"] = 0
adomic_request 0xffff9894a090: plane 33: ["SRC_W"] = 125829120
atomic_request 0xffff9894a090: plane 33: ["SRC_H"] = 78643200
atomic_request 0xffff9894a090: plane 33: ["CRTC_X"] = 0
atomic_request 0xffff9894a090: plane 33: ["CRTC_Y"] = 0
atomic_request 0xffff9894a090: plane 33: ["CRTC_W"] = 1920
atomic_request 0xffff9894a090: plane 33: ["CRTC_H"] = 1200
atomic_request 0xffff9894a090: plane 33: ["rotation"] = 1
atomic_request 0xffff9894a090: plane 40: ["FB_ID"] = 0
atomic_request 0xffff9894a090: plane 40: ["CRTC_ID"] = 0
atomic_request 0xffff9894a090: plane 38 ["FB_ID"] = 0
atomic_request 0xffff9894a090 plaje 38: ["CRTC_ID"] = 0
atomic_request 0xffff9894a090: plane 36: ["FB_ID"] = 0
atomic_request 0xffff9894a090: plane 362 ["CRTC_ID"] = 0

The only difference is currently I'm testing a simple flutter app, I lost the complicated one when I reflash the device for addtional cmdline options. I will do more test to verify.

currently I can only see
[compositor] GPU does nn4 supported the desired HW plane order.
Some UI layers may be invisible.

BR,
Bing

[bing-mao]

I need more time to find back my another flutter app which is more complicated to test. but if I checkout the commit before 1a49227, the issue can still be reproduced by this simple flutter app.

[bing-mao]

Hi ardear,
Here is a full print log using your latest test branch for db410c

BR,
Bing
log.txt

[ardera]

Okay that makes sense. On Raspberry Pi, the zpos goes from 0 to 127, on your db, it goes from 1 to 255.

flutter-pi implicitly requires the zpos to start at 0. It sets the zpos of the lowest layer to 0, for example. I'll fix that

[bing-mao]

Thank you ardera!

[ardera]

no problem 😉