| Summary: | [5.0 M3 RC1] Fail to start matchbox-desktop on beaglebone | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Yi Zhao <yi.zhao> | ||||||||||||||
| Component: | bsps-meta-yocto | Assignee: | Kevin Hao <kexin.hao> | ||||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | Yi Zhao <yi.zhao> | ||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | High | CC: | jing.hui.tham, jon.mason, randy.macleod, richard.purdie, ross.burton, yi.zhao | ||||||||||||||
| Version: | 5.0 | ||||||||||||||||
| Target Milestone: | 5.0 M4 | ||||||||||||||||
| Hardware: | BeagleBone | ||||||||||||||||
| OS: | arm | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| OS type for building Yocto: | --- | Type of Regression: | Regression (Used to work) | ||||||||||||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Yi Zhao
2024-03-11 07:00:08 UTC
Created attachment 5025 [details]
dmesg
Created attachment 5026 [details]
ps list
Kevin, Can you take time in the next few days to work on this? My immediate hunch is that the kernel framebuffer driver is broken again. I bisected it and found that this issue is caused by kernel commit: commit c91acda3a380 Author: Maíra Canal <mcanal@igalia.com> Date: Wed Apr 12 11:29:23 2023 -0300 drm/gem: Check for valid formats However, the changes in commit c91acda3a380 seem reasonable, I feel like this is more like an issue in Xorg. I have already set DefaultDepth to 16 in xorg.conf, so I find it hard to understand why Xorg would still attempt to create a framebuffer with a XR24 pixel format. My hunch was something along those lines and at the back of my mind is a memory of having the exact same problem with qemu or something previously. Although then I suspect we just switched away from bare framebuffers. I'm curious what modetest or modeprint in libdrm-tests say? Alternatively, drminfo could be useful. Maybe we just need to stop asking for a 16-bit display? Created attachment 5028 [details]
The output of modeprint
Created attachment 5029 [details]
The output of modetest
Created attachment 5030 [details]
The output of drmdevice
I have attached the output of modeprint, modetest and drmdevice. They look normal. Unfortunately, we also can't switch the 16bit bpp to others, because it will cause other issue. https://git.yoctoproject.org/poky/commit/id=e7434c17b4b3d984e11611ee7c2143a7b4557a67 The URL should be: https://git.yoctoproject.org/poky/commit/?id=e7434c17b4b3d984e11611ee7c2143a7b4557a67 Thats a very old issue, have you verified it's still valid? Yes, I have tried: 1. Just remove "DefaultDepth 16" from xorg.conf 2. Delete xorg.conf completely. No luck. I have proposed a patch [1] to fix this issue. There is also another more general but aggressive fix [2]. I like mine. Let's see what the maintainers will say. [1] https://lore.kernel.org/dri-devel/ZfePYNWY5_1XwS_A@pek-khao-d3/T/#m489e2920edfe6f27ecb15b9f2dd6f2e8eb4204eb [2] https://lore.kernel.org/dri-devel/e7ef6d422365986f49746b596735f7a0b939574d.1710698387.git.frej.drejhammar@gmail.com/T/#mf85946113936134f54807095b92d7c45428f6004 Thanks! Let's apply [1] to our kernel now as it's a more surgical fix, then if [2] does merge get backported to stable it's easy to revert. Patch has been posted to linux-yocto https://lists.yoctoproject.org/g/linux-yocto/topic/drm_tilcdc_set_preferred/105016038 Likely fixed in oe-core.git on master by: https://git.openembedded.org/openembedded-core/commit/?id=e23cbdd51ce4a8ca784f5902310a9e2d363c438a ❯ git log -1 --oneline e23cbdd51ce4a8ca784f5902310a9e2d363c438a e23cbdd51c linux-yocto/6.6: drm/tilcdc: Set preferred depth ❯ git branch --contains e23cbdd51ce4a8ca784f5902310a9e2d363c438a * master Waiting for a QA report to be sure. in review Verified with 5.0 RC4. Git rev: fb91a49387cfb0c8d48303bb3354325ba2a05587 |