zephyr
zephyr copied to clipboard
zephyrproject-rtos
boards: shields: mb1166_a09: disable default STM32_LTDC_RGB888 configuration
…88 configuration
I removed the configuration for STM32_LTDC_RGB888 in the stm32h747i_disco_stm32h747xx_m7.conf. When enabling DMA2D (Chrom-ART) this line leads to significant issues (noise on display) and needs to be set to STM32_LTDC_ARGB8888 instead. Within the context of Zephyr, LVGL and the STM32H747I-DISCO many people online mention to be running into problems when activating DMA2D. Deactivating this line solved it for me.
Hello @maarten1C96, and thank you very much for your first pull request to the Zephyr project! Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary. If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi, @maarten1C96. Thanks for your contribution.
@maarten1C96 and @erwango, about using the STM32_LTDC_ARGB8888 instead of STM32_LTDC_RGB888 make sense because the current LVGL version supports the color depth ARGB8888, RGB565, RGB232, and monochrome. https://github.com/zephyrproject-rtos/zephyr/blob/de69ebd1f88854d14ca5b7c259870c35570ddfcb/modules/lvgl/Kconfig#L74
I believe that there are two approaches:
- the simplest one is to comment on the
STM32_LTDC_RGB888, as suggested, if it solves the problem. When you do this, the defaultSTM32_LTDC_PIXEL_FORMATisSTM32_LTDC_RGB565. I suggest testing it with the LVGL Music Demo to be sure (I don't have a STM32H747I-DISCO to test it). https://github.com/zephyrproject-rtos/zephyr/blob/de69ebd1f88854d14ca5b7c259870c35570ddfcb/drivers/display/Kconfig.stm32_ltdc#L17 - improved solution: considering that we are talking about a display shield, maybe it could be better to improve the configuration to fix the problem and also achieve a better benchmark, as I did for the STM32H7B3I DK board. I've had a flicking issue in the STM32H7B3I DK board when activating the DMA2D. This was fixed by the PR #68254.
@maarten1C96 and @erwango.
Strange fact. When I comment on the CONFIG_STM32_LTDC_RGB888, we have the compilation result CONFIG_STM32_LTDC_RGB565=y and CONFIG_LV_COLOR_DEPTH_32=y. Compiler command used:
west build -p -b stm32h747i_disco/stm32h747xx/m7 samples/modules/lvgl/demos/ -- -DCONFIG_LV_Z_DEMO_MUSIC=y -DSHIELD=st_b_lcd40_dsi1_mb1166
@CharlesDias @erwango
Well, I happen to have an STM32H747I-DISCO over here and did some tests:
Within the context of the demos: all compiled and flashed without errors, but all did result in a black screen. With or without CONFIG_STM32_LTDC_RGB888=y. Also when replaced by CONFIG_STM32_LTDC_ARGB8888=y in this display shield config[^1].
Within the context of my own app: CONFIG_STM32_LTDC_ARGB8888=y works both with and without DMA2D enabled. Only notable difference to CONFIG_STM32_LTDC_RGB888=y is the alteration of the colours. However, after having set the default colours to custom colours, it turns out that STM32_LTDC_RGB888 was actually producing incorrect colours in the first place.
As @CharlesDias suggested, perhaps replacing CONFIG_STM32_LTDC_RGB888=y by CONFIG_STM32_LTDC_ARGB8888=y could be even better indeed? Although I slightly prefer to keep control within my own prj.conf (which doesn't seem able to override configurations in the shield configuration?), I can imagine that users in general would appreciate not having to set this themselves.
[^1]: EDIT 2024-06-30: Since I used the most recent STM32H747I-DISCO model, this version requires adding _a09 to the shield specification. I didn't notice earlier this was not included in your build command @CharlesDias, but when compiling with -DSHIELD=st_b_lcd40_dsi1_mb1166_a09 the demos are actually working fine on my STM32H747I-DISCO as well.
[...] prj.conf (which doesn't seem able to override configurations in the shield configuration?)
It should actually. If this is not the case, then it is a bug.
@maarten1C96 and @erwango.
Strange fact. When I comment on the
CONFIG_STM32_LTDC_RGB888, we have the compilation resultCONFIG_STM32_LTDC_RGB565=yandCONFIG_LV_COLOR_DEPTH_32=y.
(Regarding RGB565: same here, but I think this is related to the demo itself. In my own project, when I comment out everything related to defining colour configurations, RGB565 is not enabled.)
@erwango
It should actually. If this is not the case, then it is a bug.
(Regarding that bug: I struggled with this issue quite a bit past week, but when I tried to replicate it today, it magically disappeared...) ✨
I've reopened it for you, but you should not merge main into your branch...
@pdgendt
Thank you for reopening this pull request, and I apologise for my foolish proceeding! Only commit d693b81053becdc24029500c583ee43d62a05901 is supposed to be mentioned in this pull request.
@pdgendt @erwango @CharlesDias @ajarmouni-st
Ok, important lessons learned. I think my first pull request now is cleaned up and ready.
@pdgendt @erwango @CharlesDias @ajarmouni-st
Ok, important lessons learned. I think my first pull request now is cleaned up and ready.
Dear @maarten1C96 and @erwango. I'm not allowed to approve.
@kartben @pdgendt @erwango @ajarmouni-st
What is the reason this pull request has not been merged yet? Any feedback would be appreciated!
(I spent quite some time figuring out why the display on my STM32H747I-DISCO (newest NT35510 version) was not working properly, I'm actually quite delighted that I seem to have found the cause)
What is the reason this pull request has not been merged yet? Any feedback would be appreciated!
It needs to be reviewed still, and a lot of people are out-of-office these days. Sorry for the delay
Hi @maarten1C96! Congratulations on getting your very first Zephyr pull request merged 🎉🥳. This is a fantastic achievement, and we're thrilled to have you as part of our community!
To celebrate this milestone and showcase your contribution, we'd love to award you the Zephyr Technical Contributor badge. If you're interested, please claim your badge by filling out this form: Claim Your Zephyr Badge.
Thank you for your valuable input, and we look forward to seeing more of your contributions in the future! 🪁