| (11 intermediate revisions by the same user not shown) | |||
| Line 32: | Line 32: | ||
This should link to your home wiki page so we know who you are. | This should link to your home wiki page so we know who you are. | ||
--> | --> | ||
* Name: [[User: | * Name: [[User:Viper550]] | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: | * Email: superfox436 [at] gmail [dot] com | ||
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | ||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | ||
--> | --> | ||
* Product: Workstation | |||
* Product: | |||
== Current status == | == Current status == | ||
| Line 64: | Line 61: | ||
Windows 8 has already provided solutions to some of these issues, but we do not want to imitate them completely, and they also need to be adapted to suit the nuances of a Linux-based system. A key to these proposed changes is BGRT; it is an ACPI table accessible on most UEFI-based systems (especially those manufactured since the release of Windows 8), which stores the manufacturer logo displayed during POST. Windows 8 utilizes BGRT for its boot screen on supported devices, replacing the generic Windows logo with the manufacturer logo. The boot screen itself is otherwise a black screen with a basic throbber, which is something we should aim towards in order to maintain consistency throughout the boot process. | Windows 8 has already provided solutions to some of these issues, but we do not want to imitate them completely, and they also need to be adapted to suit the nuances of a Linux-based system. A key to these proposed changes is BGRT; it is an ACPI table accessible on most UEFI-based systems (especially those manufactured since the release of Windows 8), which stores the manufacturer logo displayed during POST. Windows 8 utilizes BGRT for its boot screen on supported devices, replacing the generic Windows logo with the manufacturer logo. The boot screen itself is otherwise a black screen with a basic throbber, which is something we should aim towards in order to maintain consistency throughout the boot process. | ||
[[Changes/SystemFirmwareUpdates|System Firmware Updates]] could, possibly, be integrated into this boot experience framework; on Windows 8, ESRT firmware updates also push an "UI capsule" that adds status text on top of the BGRT boot screen. | |||
These changes will only apply to Fedora Workstation. These changes would be of little use to server and cloud, as these users would prefer to have a standard console display rather than a graphical boot process. | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
These changes will help better emphasize the speed of our startup, and give a rather frequent sight for some users a more consistent appearance that is more in line with the design of the rest of the operating system. | |||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | ||
== Scope == | == Scope == | ||
* Proposal owners: | * Proposal owners: Implementing these changes would primarily require the work of those experienced with GRUB and Plymouth, with some contribution by the Design team. | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Other developers: N/A (not a System Wide Change) | * Other developers: N/A (not a System Wide Change) | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Release engineering: N/A (not a System Wide Change) | * Release engineering: N/A (not a System Wide Change) | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. | ||
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook --> | Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook --> | ||
* Policies and guidelines: N/A (not a System Wide Change) | * Policies and guidelines: N/A (not a System Wide Change) | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | ||
These changes would, preferably, be accomplished using existing components, such as Plymouth. The themes for Plymouth and GRUB2 would just have to be set to those that implement the boot experience refresh. | |||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== How To Test == | == How To Test == | ||
| Line 106: | Line 102: | ||
3. What are the expected results of those actions? | 3. What are the expected results of those actions? | ||
--> | --> | ||
Testing the BGRT logo would require a computer or motherboard that supports it. This new behavior seems to primarily be used on computers that shipped with Windows 8 or newer, and motherboards designed for use with Windows 8. The goal is to have as little flicker between bootloader and Plymouth as possible, if possible. | |||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== User Experience == | == User Experience == | ||
| Line 117: | Line 114: | ||
The Plymouth boot splash would, on supported systems, carry the BGRT logo into it, preferably with as little flicker as possible. This logo would then fade out and be replaced by a Fedora logo with wordmark in approximately the same area of the screen (the system logo is usually just a bit above the centre of the screen). The logo could have a little bit of flash or animation to it on a loop, but there should not be any other progress bar or status text ''unless'' something is going on of significance, such as a prompt for an encryption password, disk check, update, system upgrade, etc. The idea is to maintain consistency between screens. | The Plymouth boot splash would, on supported systems, carry the BGRT logo into it, preferably with as little flicker as possible. This logo would then fade out and be replaced by a Fedora logo with wordmark in approximately the same area of the screen (the system logo is usually just a bit above the centre of the screen). The logo could have a little bit of flash or animation to it on a loop, but there should not be any other progress bar or status text ''unless'' something is going on of significance, such as a prompt for an encryption password, disk check, update, system upgrade, etc. The idea is to maintain consistency between screens. | ||
[[File:BER mockup sequence.png|center]] | |||
On systems that do not support this type of boot logo, it can be substituted with a simple Fedora logo, or simply be blank. | |||
== Dependencies == | == Dependencies == | ||
| Line 127: | Line 128: | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: | * Contingency mechanism: Some of these changes could be done in ways that do not require trying to support new mechanisms. | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? | * Blocks release? No | ||
* Blocks product? | * Blocks product? No | ||
== Documentation == | == Documentation == | ||
| Line 147: | Line 148: | ||
--> | --> | ||
[[Category:ChangePageIncomplete]] | <!-- [[Category:ChangePageIncomplete]] --> | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
| Line 154: | Line 155: | ||
<!-- Select proper category, default is Self Contained Change --> | <!-- Select proper category, default is Self Contained Change --> | ||
[[Category:SelfContainedChange]] | <!-- [[Category:SelfContainedChange]] --> | ||
<!-- [[Category:SystemWideChange]] --> | <!-- [[Category:SystemWideChange]] --> | ||
Latest revision as of 22:50, 16 November 2015
This is a draft of a change proposal.
Boot Experience Refresh
Summary
Provides a streamlined and more consistent user experience for graphical startup across bootloader and system startup.
Owner
- Name: User:Viper550
- Email: superfox436 [at] gmail [dot] com
- Release notes owner:
- Product: Workstation
Current status
- Targeted release: Unknown
- Last updated: 2015-11-16
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
There was discussion back in 2013, led by the Design Team, surrounding proposed changes to Fedora's graphical startup process. As illustrated by this blog post, the current startup process uses several different types of displays with various design motifs, including pure text mode, a fancy looking GRUB screen that I believe has since been removed, and a boot splash that has branding inconsistent with the login screen (boot screen uses just the Fedora symbol, while login has the full wordmark).
Bolder, fancier looking boot screens were more common on older operating systems because we needed to communicate progress and activity to the user, especially if it was going to take a long time to start up (hence RHGB, Bootsplash, Splashy, Usplash, Plymouth etc.), but with the speed of startup on modern systems, it is better to go with a presentation that is streamlined, but allows us to maintain Fedora's on-screen identity. But there are still other factors we need to address, including communicating problems to users, and how to react in these scenarios. Factors introduced by fast startup, especially on UEFI-based systems, were also noted, such as a need for an easy way to access UEFI firmware settings without using a keyboard shortcut.
Windows 8 has already provided solutions to some of these issues, but we do not want to imitate them completely, and they also need to be adapted to suit the nuances of a Linux-based system. A key to these proposed changes is BGRT; it is an ACPI table accessible on most UEFI-based systems (especially those manufactured since the release of Windows 8), which stores the manufacturer logo displayed during POST. Windows 8 utilizes BGRT for its boot screen on supported devices, replacing the generic Windows logo with the manufacturer logo. The boot screen itself is otherwise a black screen with a basic throbber, which is something we should aim towards in order to maintain consistency throughout the boot process.
System Firmware Updates could, possibly, be integrated into this boot experience framework; on Windows 8, ESRT firmware updates also push an "UI capsule" that adds status text on top of the BGRT boot screen.
These changes will only apply to Fedora Workstation. These changes would be of little use to server and cloud, as these users would prefer to have a standard console display rather than a graphical boot process.
Benefit to Fedora
These changes will help better emphasize the speed of our startup, and give a rather frequent sight for some users a more consistent appearance that is more in line with the design of the rest of the operating system.
Scope
- Proposal owners: Implementing these changes would primarily require the work of those experienced with GRUB and Plymouth, with some contribution by the Design team.
- Other developers: N/A (not a System Wide Change)
- Release engineering: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
Upgrade/compatibility impact
These changes would, preferably, be accomplished using existing components, such as Plymouth. The themes for Plymouth and GRUB2 would just have to be set to those that implement the boot experience refresh.
How To Test
Testing the BGRT logo would require a computer or motherboard that supports it. This new behavior seems to primarily be used on computers that shipped with Windows 8 or newer, and motherboards designed for use with Windows 8. The goal is to have as little flicker between bootloader and Plymouth as possible, if possible.
User Experience
For the GRUB boot menu, the design will be trimmed down; the "progress bar" for timeout is removed, and the instructional prompts could be simplified to provide a distinction between "basic" startup and advanced/diagnostic options. Using a sans-serif font such as Cantarell, instead of monospaced console fonts (which may convey too much of a sophisticated or "outdated" feel) is desired and helps to provide a higher degree of continuity with the GUI, but mizmo said that the GRUB 2 font converter didn't work well with it.
As the bootloader is associated with the system's role in the startup process, we may want to carry the POST logo into GRUB. However, this would require BGRT support to be added to GRUB (although it's already in the Linux kernel), plus the interface would either be designed around the logo (although there seems to be a standard "margin" between the logo and the centre of the screen), or made into an overlay dialog. On non-UEFI/BGRT systems, the Fedora logo could be used as a fallback.
The Plymouth boot splash would, on supported systems, carry the BGRT logo into it, preferably with as little flicker as possible. This logo would then fade out and be replaced by a Fedora logo with wordmark in approximately the same area of the screen (the system logo is usually just a bit above the centre of the screen). The logo could have a little bit of flash or animation to it on a loop, but there should not be any other progress bar or status text unless something is going on of significance, such as a prompt for an encryption password, disk check, update, system upgrade, etc. The idea is to maintain consistency between screens.
On systems that do not support this type of boot logo, it can be substituted with a simple Fedora logo, or simply be blank.
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: Some of these changes could be done in ways that do not require trying to support new mechanisms.
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? No
- Blocks product? No
Documentation
N/A (not a System Wide Change)