From Fedora Project Wiki
No edit summary
Line 74: Line 74:


== 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) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* 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) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* 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) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A (not a System Wide Change)
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
 
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
Line 109: Line 105:
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.


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Revision as of 06:03, 31 July 2015

Important.png
Comments and Explanations
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: Your Name
  • Email: <your email address so we can contact you, invite you to meetings, etc.>
  • Release notes owner:

Current status

  • Targeted release: Unknown
  • Last updated: 2015-07-31
  • 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

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.

N/A (not a System Wide Change)

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.

BER mockup sequence.png

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)

Release Notes