[Ubuntu Wiki] Update of "SpokenBoot" by LukeYelavich

[Ubuntu Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The following page has been changed by LukeYelavich:
https://wiki.ubuntu.com/SpokenBoot

The comment on the change is:
Rewrite implementation and change outstanding issues.

------------------------------------------------------------------------------
  
  == Rationale ==
  
- Currently there are only a select few blind computer users who are able to receive spoken feedback about OS boot messages. These users have to be using Linux, with a hardware speech synthesizer, and the speakup screen reader compiled into the kernel. All blind Linux users should be able to benefit from such spoken feedback, whether they are using software or hardware based speech synthesis.
+ Currently, the only way a blind computer user knows whether their system is functioning properly, is when the desktop loads, and the screen reader application they use loads and speaks a message. they have no way of knowing if there is something wrong with the boot process, or if a filesystem check has failed. If they don't hear any speech, they no something is wrong, but don't know what is wrong.
  
  == Use cases ==
  
   * Jane thinks that her computer is taking an unusually long time to boot up. She wants to be able to find out what her computer is doing while it boots the operating system.
   * Joel has recently installed a new server package, and is having trouble configuring it. He wants to know whether the server daemon, or any other boot process fails to load correctly when he restarts his system.
+  * David thinks he has a filesystem problem. He decides to reboot his system to force a filesystem check. He wants to know whether the filesystem check is going to fail, and if so, wants to be able to rectify the problem.
  
  == Scope ==
  
@@ -26, +27 @@

  
  == Design ==
  
- The vast majority of init scripts in Ubuntu use the /lib/lsb-base/init-functions file for displaying necessary text about their relevant tasks. To get spoken output of this text, it is simply a matter of adding hooks to the functions that display this text, and the result. Speech-dispatcher provides a command-line utility, spd-say, for speaking text. Whether text is spoken will depend on what is set in the configuration file. The configuration file will also contain an option to start the speakup screen reader if a filesystem fsck badly fails, so the user can enter commands and receive spoken output if they wish.
+ The Ubuntu boot process has already got mechanisms that can be leveraged to provide spoken boot information. Additionally, more spoken feedback, as well as more levels of verbocity can be reached by using the mechanisms provided by BootMessageLogging.
  
  == Implementation ==
  
+  * Sound services would have to be loaded a lot earlier in the boot process, so that speech-dispatcher has a sound card to use in the event that one is needed. With a lightweight speech synthesizer such as espeak, the sound card, speech-dispatcher, and espeak can be placed into the initramfs. If the user desires to use a particular sound card for the speech output, the appropriate settings should also be written to a configuration file.
+  * once the root and /usr filesystems have been mounted read-write, speech-dispatcher that was originally run from initramfs can be stopped, any logfile data can be transferred to the appropriate log files on the root/var filesystem, and speech-dispatcher can be restarted from the root filesystem.
+  * The code used for BootMessageLogging can be extended to output any text logged to the spd-say utility. The spoken boot mechanism would have its own verbocity setting, with the same levels defined as in BootMessageLogging.
+  * The script responsible for filesystem checking would be modified to load the speakup screen reader, in the event that a filesystem check has failed, and the user desired screen reader support for determining any problems. Once the user has completed the approrpriate tasks, the speakup screen reader would be unloaded after they exit the shell.
-  * Sound services would have to be loaded a lot earlier in the boot process, so that speech-dispatcher has a sound card to use in the event that one is needed.
-  * A special init script would be written that would be executed when the filesystem was mounted read-only. The script would take care of loading a specially built copy of the speech-dispatcher daemon that would point to a config file with alternate log locations set. When the filesystem was remounted read-write, the same, or possibly another script would shut down the currently running daemon, and restart speech-dispatcher normally.
-  * Functions for handling speech output will be added to /lib/lsb/init-functions. Function calls will then be placed in other important functions such as log_begin_msg and log_end_msg. The amount of information that is spoken will depend on the setting stored in a config file called by the speech functions. Three possible options will be available, none, fail, and all. By default, none wil be set. Fail will only speak any information related to a process that fails to function for any reason, i.e call log_end_msg with a nonzero value. All will cause all information to be spoken.
-  * The speech functions will check whether the configuration is either set to fail or all. If so, a check for the running of speech-dispatcher will be made. If successful, the requested text will be spoken.
-  * The /etc/init.d/checkfs.sh script will also be modified to provide checks for a configuration option to enable a screen reader if the fsck fails. These modifications could easily make use of init-functions, to keep all spoken feedback code in the same place.
-  * If the screen reader option is set to yes, a check for speech-dispatcher running will be performed. If not, it will be loaded. The speakup screen reader will also be loaded. Once the user exits from the shell set up after the failed fsck, the screen reader may be unloaded, and spoken feedback will be set to something other than its original setting, depending on more options in the configuration file.
  
  === Code ===
  
@@ -44, +43 @@

  == Outstanding issues ==
  
   * The SpeakupInclusion spec needs to be implemented before this spec can be useful.
-  * Some form of sound card setup needs to be performed before speech-dispatcher can be used at early boot. Since soundcards havent been loaded yet, a mechanism for determining the default sound card module to use would be necessary. Sound libraries would also need to exist in /lib, due to /usr not being mounted yet.
-  * speech-dispatcher and speechd-up need to be promoted to main.
+  * speech-dispatcher and speechd-up need to be seeded.
-  * Any packages that do not use init-functions in their init scripts will have to be changed.
-  * Contrast with ReplacementInit -- there may not be any boot messages in edgy
  
  == BoF agenda and discussion ==