Share AMOLED brightness control and optional Brookesia integration - #3
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The three AMOLED board definitions referenced duplicated Brookesia brightness plugins. Move the hardware brightness command into a public helper and share one explicit optional plugin, preserving the board features and runtime brightness controls.
boards/<model>/. Remove automatic Brookesia dependencies from board YAML.waveshare_amoled_set_brightness()ininclude/waveshare_amoled.hso ordinary Board Manager applications can control the supported QSPI AMOLED panels without Brookesia.integrations/brookesia_hal_custom/. Preserve its brightness setter/getter, 0–100 percent range, mutex, cached value, plugin/interface names, display group, and defaults. Keep all three original application profiles underprofiles/<model>/.display_lcdgroup from Board Manager instead of including the full HAL adaptor for that constant. Document opt-in setup and upstream constraints: Brookesia 0.8 lib_utils requires IDF 6.0–6.2; the standalone adapter does not depend on HAL adaptor 0.8.4's separate Board Manager 0.5.* constraint.Validation for
93028a8: 22 helper/host tests, metadata/catalog/navigation checks, actionlint, package contents, and Markdown audit passed (one expected range-audit notice for the preserved upstream changelog). Host C tests check brightness command encoding, scaling, clamping, invalid handles, and IO-error propagation. Hardware source and the three application profiles remain byte-identical to the base. All eleven local builds passed: eight plain builds across IDF v5.5.5/v6.1 plus three optional adapter builds on its native IDF v6.1, Board Manager 0.7.2. All eleven Actions builds passed on the same commit, along with metadata and aggregate checks. A separate IDF 6.1 consumer fetched this exact commit through Component Manager, discovered the 1.8 board undermanaged_components/waveshare__waveshare_boards, and compiled both the public brightness call and the optional adapter successfully. Adapter builds also check that the plugin and brightness getter/setter are linked and no HAL adaptor dependency is resolved. Physical board behavior and an unmodified full Brookesia application are not validated.