Speed up unlock animation

Thanks @spiiroin for this workaround. But the delay is still there, no speed-up to be experienced. Could you think of a way to skip the delay as well?

@lakutalo: From lower level p.o.v. the total delay accumulates roughly from

1. kernel side wakeup from late suspend -> early suspend & input event processing (power key, ...)
2. waking up the display (early suspend -> normal operation etc)
3. waking up the ui (first draw = have content -> kernel actually turns on the backlight)
4. display backlight brightness ramp up (to manual / automatic level)
5. display=on state reached

Which add up to something like 600 ms where (1)=40ms (2)=400ms (3)=60ms (4)=90ms

In practice there is little that can be done about (1, 2 & 3).

The duration of (4) is a setting adjustable via

mcetool --set-brightness-fade-unblank=<msecs>

Using zero value disables backlight brightness fade altogether (can cause some brightness pumping if ambient light sensor wake up takes long enough). Should not really affect the overall time, but could maybe make things look / feel a bit snappier?

The ui side graphics fade in + possible animations happen in parallel starting from around (3) - the latter being what the locscreen-animation setting targets (instead of the time etc falling from top of screen, they should be in static position already when display wakes up), but I do not know where the fade in timing is defined / whether it can be tuned.

Also note: If code pages related to above need to be paged in (some background processing taking lots of memory while device is otherwise idle with display off), that will add further delays to the process.

Thank you very much, indeed, for this precise and valuable in-depth information, @spiiroin!

@spiiroin Can't (2) and (3) be performed in parallel?

@Federico: No. While there is a lot else that is done in parallel (starting sensors, etc), all of the above (1-4) needs to be done serially. For example attempting (accelerated?) drawing while display is in semi powered up state leads to reboot required -kind of troubles at least on jolla1 kernel driver side. Thus the function of (3) is to act as a stop gap / synchronization point where mce tells compositor (=lipstick) that it is now ok to draw and compositor tells mce that it is ok to continue with whatever else it needs to do. And the above mentioned 60 ms is for full mce->lipstick->mce roundtrip, there might/should be things happening on screen already earlier than that. [As a side note: Those rapid green/red panic led blinkers that used to be too common happen when mce does not get replies from compositor and is therefore unable to finish the ongoing display power up/down.]

Similarly the order of events in display blanking is roughly:

1. declare display=off state
2. fade display backlight to black
3. tell ui to stop drawing and wait for acknowledgement
4. power off display (normal op -> early suspend)

And bit later, depending on settings, policies, device state, etc: Lock screen activation, inactivity state signaling, entering late suspend and so forth.