[feedback] Collect ModernSetup UI visible fields and setup entry needs

[MarsDoge]

Goal

Collect feedback on which information labels, read-only fields, and setup entry points ModernSetup should expose in its IBV-style front-page UI.

ModernSetup is moving from a demo-style provider UI toward an IBV/OEM-style Setup interface. Before adding more public provider fields or UI rows, we want to collect concrete needs so the data contracts can be defined cleanly.

Scope

Please suggest items for these product-facing pages:

• Main / System Information
• Advanced
• Chipset / Platform
• Boot
• Security
• Server Management
• Power & Thermal
• Diagnostics
• Preferences / UX
• Save & Exit

What to include in a suggestion

For each requested field or option, please include:

Page / category:
Label shown to user:
Expected value example:
Read-only or editable:
Preferred source if known:
Native owner if editable:
Platform class:
Why this is useful:

Examples

Example 1: BIOS Version

Page / category: Main
Label shown to user: BIOS Version
Expected value example: v1.1.0 / 0x00010000
Read-only or editable: Read-only
Preferred source if known: SMBIOS Type 0 / gST->FirmwareRevision fallback
Native owner if editable: N/A
Platform class: All
Why this is useful: Basic firmware identity shown by most IBV Setup utilities.

Example 2: Above 4G Decoding

Page / category: Advanced / Chipset / PCIe
Label shown to user: Above 4G Decoding
Expected value example: Enabled / Disabled / Configure
Read-only or editable: Native HII entry only
Preferred source if known: Platform PCIe policy HII entry hint
Native owner if editable: Platform PCIe policy FormBrowser page
Platform class: Desktop / workstation / server
Why this is useful: Common high-churn PCIe resource setting.

Example 3: DIMM Slot Population

Page / category: Main / System Information
Label shown to user: Memory Slots
Expected value example: DIMM0 16 GB DDR5-4800, DIMM1 Empty
Read-only or editable: Read-only
Preferred source if known: SMBIOS Type 17
Native owner if editable: N/A
Platform class: Desktop / workstation / server
Why this is useful: Common IBV Setup system inventory field.

Ownership boundaries

ModernSetupApp will not become a second setup-policy engine.

Allowed:

• read-only summaries from standard sources
• native HII/FormBrowser entry points
• provider-backed field definitions
• app-owned UX preferences such as theme/language/density

Not allowed:

• direct varstore writes from ModernSetupApp
• direct ConfigAccess calls from ModernSetupApp
• IFR parsing as the default app path
• fake settings not backed by a provider or native owner
• board-specific hard-coded values in shared UI

Data-source contract

When a suggestion becomes an implementation candidate, it should map to:

Field:
Standard source:
Access API:
Provider owner:
Display surface:
Native owner:
Fallback:
Status:

Relevant docs:

• Docs/AppFeatureStandard.md
• Docs/ProductizationFeatureMatrix.md
• Docs/ProviderDataContract.md
• Docs/ConfigurableItemsAndQuickSettings.md

Useful categories to consider

System identity:

• BIOS Version
• Build Date
• Product Name
• Board Name
• Serial Number
• UUID

Processor:

• CPU model
• socket / core / thread count
• current / max speed
• cache summary

Memory:

• total memory
• DIMM slot population
• memory type / speed / ECC / rank

PCIe / I/O:

• root bridge count
• endpoint inventory
• link speed / width
• Above 4G
• ReBAR
• SR-IOV
• ASPM
• bifurcation
• hot-plug
• IOMMU / SMMU

Boot:

• BootOrder
• BootNext
• PXE / HTTP boot
• native Boot Maintenance entry

Security:

• Secure Boot
• Setup Mode
• PK / KEK / db / dbx
• TPM / TCG2 / TCM
• password status
• measured boot

Power / Thermal:

• ACPI state
• fan / thermal status
• power supply
• battery / adapter
• AC-loss restore
• WoL / RTC wake

Server Management:

• BMC
• IPMI
• Redfish
• management NIC
• SEL / logs
• remote update

Diagnostics:

• ACPI table presence
• SMBIOS presence
• memory map count
• provider health
• first degraded provider

[MarsDoge]

Refining the audience split further:

Interface users

Interface users care about UI category and display implementation:

• Which Setup category/page should this field appear under?
• How should it be grouped?
• What label/value/status should be visible?
• Is the row selectable?
• What safe native entry point should the UI expose?
• How should unavailable / not reported data be shown?

So feedback from this audience can be lightweight and UI-facing:

Category/page:
Visible label:
Expected value/status:
Selectable row or read-only display:
Native entry point if needed:
Unavailable/fallback wording:

Developer / contributor users

Developer users care about interface-flow implementation:

• Which source produces the value: SMBIOS, ACPI, UEFI service, PI protocol, native HII, app-owned NV, etc.?
• Which provider owns collection?
• How does the app consume the provider field?
• Who owns writes, if any?
• Is this read-only, app-owned, native-only, or platform-policy-owned?
• What fallback/status semantics and smoke/build validation are required?

Developer-side suggestions should use the full field contract:

Field:
Standard source:
Access API:
Provider owner:
Display surface:
Native owner:
Fallback:
Status:
Validation:

This keeps the visible UI focused on category/display clarity, while the contributor workflow defines the data/interface flow cleanly.