#534 HIGH Trial-3: Need image for the splashscreen

[Zarro Boogs per Child]

#534: Need image for the splashscreen
----------------------------------+-----------------------------------------
  Reporter:  JordanCrouse         |       Owner:  jg     
      Type:  enhancement          |      Status:  new    
  Priority:  high                 |   Milestone:  Trial-3
 Component:  ofw - open firmware  |     Version:         
Resolution:                       |    Keywords:         
  Verified:  0                    |  
----------------------------------+-----------------------------------------
Comment (by cscott):

 10fps shouldn't be a problem, I don't think, if the images are prerendered
 and stored in native framebuffer format (16-bit 565).  The images don't
 need to be stuffed into the initrd, they can live in the main filesystem
 if we're willing to wait a fraction of a second more for it to mount
 before we start pulsing.

 My impression of boot is that the time from X startup to sugar start is
 fairly short, compared to the delay between OFW and X.  Matching the phase
 would indeed be tricky.  Can we mask this transition in some other way?
 For example, fade all the way down to outline, DCON freeze and hold there
 for a moment while X starts, and then either fade or pop to the colored
 XO?

 Rough breakdown of boot steps:
  a) open firmware starts
  b) open firmware probes USB, SD, NAND looking for boot device
  c) open firmware authenticates and decompresses linux kernel and ramdisk
 ^^^^^^ above this line, we can do a static XO image.  Mitch might be able
 to do limited
        animation, perhaps by using a timer interrupt, but he wouldn't have
 access to the
        customized XO colors and it would be hard to stuff them somewhere
 OFW could quickly get to
  d) linux begins boot and does initial initialization
 ^^^^^^ really, we can only maintain a static image here
  e) linux userland gains control (initial ramdisk)
  f) root filesystem is mounted
 ^^^^^^ by this point we can do animation.  we can't use custom colors
 until the root filesystem is mounted, as the initial ramdisk is
 cryptographically signed & thus can't be altered by the user (w/o
 developer key, etc, etc)
  g) /sbin/init runs -- this is the 'Initializing Fedora' and all the
 [OK]s.  Lots of services are started -- but we can continue animating
 through this.
  h) X is started.  Static background.  Transfer of control from the early
 userland animator to X.
  i) Full dynamic SVG rendering can occur, within X.
  j) Sugar starts, and slowly draws each left, top, bottom, (pause) right
 borders. I personally think this looks ugly, and would rather see the
 frame pop into existence.

 My suggestion would be to start the animation as soon as the root
 filesystem is mounted, and fade to white outline just before X is started
 (X may wait for animation to reach the desired point).  We then freeze the
 DCON, start X, and unfreeze once the sugar interface is completely up, so
 that it appears all at once.

 The animation rendering would happen right after user colors were chosen,
 and the animated sequence would live in /home/olpc somewhere.

 jg - if we were to do a seamless animation transition across X startup,
 could we get an X application up in the root window within 100 ms (or
 thereabouts) of invoking X?  If so, then we can consider handing off the
 animation, instead of freezing the display momentarily at the end of the
 startup sequence.

-- 
Ticket URL: <http://dev.laptop.org/ticket/534#comment:12>
One Laptop Per Child <http://laptop.org/>