SpokenBoot

Revision 3 as of 2006-06-11 22:02:58

Clear message

Summary

Implement a mechanism to allow users to choose to receive spoken feedback on boot messages, at different levels of verbocity.

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.

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.

Scope

This specification will discuss the loading of speech-dispatcher to provide software speech as early as possible, and the implementation of spoken feedback for the Ubuntu boot process.

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.

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.
  • 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

Data preservation and migration

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.
  • 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

CategorySpec