[lvgl] Fix type of byte_order parameter#6637
Conversation
|
Caution Review failedFailed to post review comments WalkthroughRepository version metadata is bumped to 2026.6.0-dev and multiple documentation pages were updated across components (LVGL, lights, NeoPixelBus, RP2040, network, WiFi, speaker, time, packages, Nextion, Mitsubishi climate) to clarify configuration types, defaults, new options, deprecation and migration guidance, and behavior notes. ChangesDocumentation edits and version metadata
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Deploy Preview for esphome ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
LGTM but... esphome/esphome#16702 changes this somewhat as it allows LVGL to infer the correct byte order from the display byte order. Maybe tie this PR to that one, and amend the wording to add the information about the automatic byte_order selection? |
The byte_order global configuration parameter for lvgl wrongly specifies `int16` as its type; while the available values are `big_endian` or `little_endian`, which are strings.
dfe9d65 to
94c76bf
Compare
|
I've updated the wording and linked it to your PR in the description. (And rebased it to "next" instead of "current") |
Description
The byte_order global configuration parameter for lvgl wrongly specifies
int16as its type; while the available values arebig_endianorlittle_endian, which are strings.Related issue (if applicable): fixes
Pull request in esphome with YAML changes (if applicable):
esphome/esphome#16702
Checklist
I am merging into
nextbecause this is new documentation that has a matching pull-request in esphome as linked above.or
I am merging into
currentbecause this is a fix, change and/or adjustment in the current documentation and is not for a new component or feature.Link added in
/src/content/docs/components/index.mdxwhen creating new documents for new components or cookbook.New Component Images
If you are adding a new component to ESPHome, you can automatically generate a standardized black and white component name image for the documentation.
To generate a component image:
Comment on this pull request with the following command, replacing
component_namewith your component name in lower_case format with underscores (e.g.,bme280,sht3x,dallas_temp):The ESPHome bot will respond with a downloadable ZIP file containing the SVG image.
Extract the SVG file and place it in the
/public/images/folder of this repository.Use the image in your component's index table entry in
/src/content/docs/components/index.mdx.Example: For a component called "DHT22 Temperature Sensor", use:
Note: All images used in ImgTable components must be placed in
/public/images/as the component resolves them to absolute paths.