Thanks for your inputs.
Yes will look into the dependencies.
And for the first screen rendering sequence would be like,
This is the sequence to render the first screen. from point 1 to point 4
taking ~500ms to 1 Sec.
So during this initialization period, when weston clears the first screen
with glclear, we wanted to display the static image as background. This
will solve our problem.
But as per your input if we revisit reducing the weston size and bringing
into initramfs that will be good actually.
if this works we won't bother about the above said blank issue.
If I get any stripped weston dependencies that will be good.
On Mon, Jul 27, 2020 at 3:32 PM Daniel Stone firstname.lastname@example.org wrote:
On Mon, 27 Jul 2020 at 06:59, arunkrish20 email@example.com wrote:
We are working with the i.MX8 platform. We are working with weston and
DRM backend. Below are the version details.
NXP BSP Version: 4.14.98_2.0.0_ga
SC Firmware Version : 1.3.1
wayland version 1.16 am
weston- ivi - 5.0.0
We are currently working our way towards releasing Weston 9.0.0, so
this version is quite old.
Our requirement is to display the first screen in 2 Seconds.
In the current environment we are able to see the first screen in the
Ouch, that's quite long.
We tried to boot the weston in initramfs. But due to size constraints we
are not able to. Size comes around 65MB.
Is there any possibility for reducing the size of weston?
Weston itself with the DRM + GL backends only takes around 750kB once
installed. I assume the 65MB comes from extra dependencies, but that
is something you would have to investigate and configure in your Yocto
build. Weston itself does not have many dependencies, and those
dependencies are not large.
Weston taking 500ms to complete the initialization. Can we reduce this
timing? e.g if we block unwanted device probing etc, any idea?
In case if we use separate drm based rendering application for the first
screen and switching to weston are seeing blank. Instead of clearing the
weston screen buffer can we have a logo on first rendering. so that blank
can be avoided between the first drm application to weston rendering.
NXP has forked Weston and written their own backend, which is
responsible for the initialisation (both the time and the blank
screen). The default DRM backend is quite quick to come up and be
responsive, and doesn't blank the screen. So both these issues are
something you'd need to raise with NXP support, as they are due to
NXP's changes to our code.