Streamline behavior for recordings coming from deep standby
Remove obsoleted isNextRecordTimerAfterEventActionAuto config

As far I can see this is not required anymore after the previous commit.
I could not find any plugin or so that did still ise it, but it cannot
ensure that if might be required by some plugin.

If so it could be possible we need to revert this commit.
gdi/bcm: Remove static struct

ioctl appears to wait for completion, so no reason to use a static
array here. Put it on the stack, so that multiple calls can be
prepared concurrently.
ecanvas: Prevent using hardware blit/fill

When large enough, the code will use hardware blit or fill routines. This
appears to malfunction, so put it back the way it used to be.
VideoFinetine: cleanup and add full hd testscreen

The full HD testscreen is most likely only in full HD for hardware that
supports full HD skins.
Add testscreen.png in Makefile.am

Sorry I forget this one in my previous commit
Finetunes for recordings from deepstandby

Stop service at first standby when the clock/time is known
Add flag to go only to deepstandby when the first standby was initiated by
coming from deepstandby
VideoFinetune: Toggle with OK through all test screens
Do not increase standby counter when coming from timerwakeup
rcinput: add workaround for VU+ duo2 remote control driver.

This adds the vuduo2 to c50c3502146be124e2e82f47e8c40b59ae51c396.
gdi/bcm: Make instruction sets static again

Just an experiment to see if this solves the weird display problems
on some dreamboxes.
Further improvements for recordings coming from deep standby

Handle Auto and Do Nothing correctly (also for normal standby)
Do not poll for time/date found for services started when in standby just
stop that service before the timer is handled.
Streamline do not increase standby counter

A lot of credits to Dima73 for all comments.
Navigation: Do only go to standby when recording timer is likely

It seems that the FPWasTimerWakeup does not correctly work for all boxes
so add an extra test before going to standby if it is indeed likely the box
was initialized for a recording timer
Revert "Navigation: Do only go to standby when recording timer is likely"

This reverts commit 665190c2676010b35ff368e1e6e2c66f62f6fa84.

Sorry that I did commit this too fast... The time is not known during this
test so this will not work and therefore I need to revert this.
Optimize some png files with optipng

As it simply saves memory in an easy way
Revert "gdi/bcm: Make instruction sets static again"

This reverts commit abd023a12d817f051686e8b8cd9b310c8d792254.

Apparently, this made things worse on the DMM machines. Since fixing the
driver isn't going to happen, revert these commits to see if that solves
the issues.
Revert "gdi/bcm: Remove static struct"

This reverts commit e6bb84c6ab8b3b5e4be581299dd5c4c600eba257.
Streamline regards to recordings timers when coming from deep standby

Go to standby not directly buy after 30 seconds and not directly as it seems to make some plugins not compatible and for some hardware the wasWakeupTimer is not
functioning properly, so put the box in standby after 30 seconds when there is realty a record timer (record, zap&record or only zap) within 6 minutes. It is assumed that within 30 seconds we should have a correct timestamp as this is proven to perform well for years.

Thanks Dima73 for all comments and sorry for not always understanding you.
InfoBarGenerics: tm_year is not as tring but an integer
Merge remote-tracking branch 'pli/master'

skip timer stuff, as our's works differently.