[Z690] UEFI Setup Screen Enhancements #1101
Replies: 2 comments 2 replies
-
|
Any comments? Further ideas or suggestions to these cosmetic changes? |
Beta Was this translation helpful? Give feedback.
-
|
I see no issues with those suggestions. @miczyg1 ? |
Beta Was this translation helpful? Give feedback.
-
Front page has already too little space to fit more details.
It is not straightforward to tell if XMP is used or not. It is pure request via variable set in other submenu. All of these requests for memory information is a lot of work and parsing. XMP specification is not even public. It all sounds simple, but it is not. If anything it would be better to have a separate menu for memory information and details. Still it is probably days if not weeks worth of work.
It currently displays the SMBIOS type 1 Product name. It can be changed to display, e.g., type 2 Product name (for MSI, it would result in a string you request without the manufacturer, though). Different platforms may have different product names in type 1 and type 2. We change it here, then somebody else will complain that the strings are not to their liking... I am not sure about this change. because it is purely personal view what string should be displayed. Again, it may be included in a separate menu, where both type 1 and type 1 product name could be displayed at once.
This is too much. This information cannot be extracted in a deterministic manner. The codename is just a thought up name by Intel and not included in the silicon (CPUID does not have this information). One would have to include a truth table for all 12th, 13th and 14th gen processors. And what about others, older and newer processors? The truth table would grow forever each year to an enormous size. This is a NO from my side. Adding a truth table for P/E cores disabling was already enough pain, because CPUID also does not allow to read the amount of cores of each type...
Release date is a part of different SMBIOS field. Release version format is fixed and won't be changed. Release date may be added in some different place. Like I said, there is not much free space on front page. I would opt for a separate submenu with platform/firmware information. The number of requests will only grow and the setup front page size is limited.
What kind of changelog? The changelog of the whole firmware? Again, it is not generic and including all changelogs for all platforms (or different changelogs depending on platform) in the payload is huge boilerplate...
Cosmetic changes... Cosmetic changes are usually trivial. All those requests are a ton of work with almost no gain, just to display information available elsewhere. I'm not saying these are not good ideas, but people are forgetting one simple fact. Having all those information and features is good for target-oriented BIOS which is developed for one platform on a separate branch. And only things applicable to that platform are included. In such cases it works well, despite it does not propagate to other platforms/portability is low and painful. coreboot and UEFI Payload are solutions which support multiple platforms and must be as generic as possible (except where it is not possible, e.g. for silicon initialization). Payload has to be even more generic than coreboot itself. So adding anything that cannot be obtained easily at runtime is problematic, because adding something not generic has to be handled and tested separately for all supported platforms. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome. Thanks for providing this insight. I agree that the work involved in this outweighs the benefit. Thanks for taking the time to explain. |
Beta Was this translation helpful? Give feedback.
-
A few suggestions:
Upper right side of the screen:
Upper left side of screen:
Add the complete version history/Changelog with ISO 8601 dates (YYYY-MM-DD) into the Dasharo System Features menu or elsewhere where appropriate.
Beta Was this translation helpful? Give feedback.
All reactions