Add chromium support

[Ashwin Prabhakar (Ashwin-Prabhakar)]

Include the chromium-ozone-wayland package in the qcom-multimedia-image.

[Ricardo Salveti (ricardosalveti)]

We need to evaluate the build impact this will have with the multimedia image, to decide if we indeed want to push this as the default image for our users (that is the case atm).

I'm not against including this in qcom-distro, but we might need a different image target for this that is not built by default by the qcom-distro.yml.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

We need to evaluate the build impact this will have with the multimedia image, to decide if we indeed want to push this as the default image for our users (that is the case atm).

I'm not against including this in qcom-distro, but we might need a different image target for this that is not built by default by the qcom-distro.yml.

I can create a qcom-distro-demo.yml and create a qcom-multimedia-demo-image and include chromium there. If this can help.

[Dmitry Baryshkov (lumag)]

We need to evaluate the build impact this will have with the multimedia image, to decide if we indeed want to push this as the default image for our users (that is the case atm).
I'm not against including this in qcom-distro, but we might need a different image target for this that is not built by default by the qcom-distro.yml.

I can create a qcom-distro-demo.yml and create a qcom-multimedia-demo-image and include chromium there. If this can help.

Please don't jump to the conclusion before evaluating. Meanwhile, what is the impact of this change? How long does it take to build chromium in your case? How much memory and disk space is required for the build?

[Ashwin Prabhakar (Ashwin-Prabhakar)]

We need to evaluate the build impact this will have with the multimedia image, to decide if we indeed want to push this as the default image for our users (that is the case atm).
I'm not against including this in qcom-distro, but we might need a different image target for this that is not built by default by the qcom-distro.yml.

I can create a qcom-distro-demo.yml and create a qcom-multimedia-demo-image and include chromium there. If this can help.

Please don't jump to the conclusion before evaluating. Meanwhile, what is the impact of this change? How long does it take to build chromium in your case? How much memory and disk space is required for the build?

This took me 6 hours on a 8 core 16 thread laptop. I am not sure what would be the impact on the servers though.

[Dmitry Baryshkov (lumag)]

This took me 6 hours on a 8 core 16 thread laptop. I am not sure what would be the impact on the servers though.

That's definitely too much to be enabled by default.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

This took me 6 hours on a 8 core 16 thread laptop. I am not sure what would be the impact on the servers though.

That's definitely too much to be enabled by default.

Then what would you suggest ?

[Dmitry Baryshkov (lumag)]

This took me 6 hours on a 8 core 16 thread laptop. I am not sure what would be the impact on the servers though.

That's definitely too much to be enabled by default.

Then what would you suggest ?

That depends on the reasons we have to enable chromium here.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

This took me 6 hours on a 8 core 16 thread laptop. I am not sure what would be the impact on the servers though.

That's definitely too much to be enabled by default.

Then what would you suggest ?

That depends on the reasons we have to enable chromium here.

Chromium is required in HMI systems because modern HMIs are increasingly web-based. It allows operators to monitor and control machines through graphical dashboards displayed in a browser environment.

[Dmitry Baryshkov (lumag)]

The 'HMI' usecase doesn't sound like the qcom-multimedia-image. Moreover, it sounds like being a part of the default image at all. It sounds like a requirement for a specific customer, which will have its own image, etc.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

The 'HMI' usecase doesn't sound like the qcom-multimedia-image. Moreover, it sounds like being a part of the default image at all. It sounds like a requirement for a specific customer, which will have its own image, etc.

This is also true. But otherwise how would we demonstrate webgl capabilities on the SOC which clearly relies on the GPU and falls under multimedia capabilities. I am okay either way to create a separate demo image as previously suggested if that helps.

[Nicolas Dechesne (ndechesne)]

i have never used this recipe. What does it give us? A real/full browser like on a regular desktop? or is it more of a 'kiosk' style application?

given the heavy build requirements, having a qcom-chromium-browser image might be an option. though we need to make sure it's excluded from the world build by default, and we need to decide how often we want to build it.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

i have never used this recipe. What does it give us? A real/full browser like on a regular desktop? or is it more of a 'kiosk' style application?

given the heavy build requirements, having a qcom-chromium-browser image might be an option. though we need to make sure it's excluded from the world build by default, and we need to decide how often we want to build it.

Nicolas Dechesne (@ndechesne) this will give you both a full blown browser as in Linux chromium style and you can also launch it in kiosk mode in runtime with a --kiosk flag to launch it in kiosk mode. I will take inputs and create a new image recipe if all maintainers agree.

[Ricardo Salveti (ricardosalveti)]

We need to evaluate the build impact this will have with the multimedia image, to decide if we indeed want to push this as the default image for our users (that is the case atm).
I'm not against including this in qcom-distro, but we might need a different image target for this that is not built by default by the qcom-distro.yml.

I can create a qcom-distro-demo.yml and create a qcom-multimedia-demo-image and include chromium there. If this can help.

Yeah, I think a separated image and a separated kas fragment building such image makes more sense, to avoid affecting the experience for the standard user.

I'm fine trying to enable in our CI once we evaluate the impact here, but only for one target, as we don't need a matrix job to validate a generic component like this.

Can you split into a fragment and image and add to our CI build as a separated build combination? Add it to https://github.com/qualcomm-linux/meta-qcom/blob/master/.github/workflows/build-yocto.yml#L402 based on the target that will be more frequently used here.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

We need to evaluate the build impact this will have with the multimedia image, to decide if we indeed want to push this as the default image for our users (that is the case atm).
I'm not against including this in qcom-distro, but we might need a different image target for this that is not built by default by the qcom-distro.yml.

I can create a qcom-distro-demo.yml and create a qcom-multimedia-demo-image and include chromium there. If this can help.

Yeah, I think a separated image and a separated kas fragment building such image makes more sense, to avoid affecting the experience for the standard user.

I'm fine trying to enable in our CI once we evaluate the impact here, but only for one target, as we don't need a matrix job to validate a generic component like this.

Can you split into a fragment and image and add to our CI build as a separated build combination? Add it to https://github.com/qualcomm-linux/meta-qcom/blob/master/.github/workflows/build-yocto.yml#L402 based on the target that will be more frequently used here.

Taken your feedback onboard and have updated the PR please take a look and provide me some further feedback.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

Invert the order of the commits, the fragment should be the last one.

I have changed the order of commits.

[Dmitry Baryshkov (lumag)]

Weekly is fine, we just don't yet have a workflow for it (we only have for nightlys), would have to be defined.

Whatever cadence is selected, it must be enabled in this PR.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

Weekly is fine, we just don't yet have a workflow for it (we only have for nightlys), would have to be defined.

Whatever cadence is selected, it must be enabled in this PR.

Is there a reference on how this can be done. This could help me to make the expected changes.

[Dmitry Baryshkov (lumag)]

Is there a reference on how this can be done. This could help me to make the expected changes.

.github/workflows/nightly*

[Dmitry Baryshkov (lumag)]

And also monthly.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

Is there a reference on how this can be done. This could help me to make the expected changes.

.github/workflows/nightly*

Dmitry Baryshkov (@lumag) is there a preferred day and time for scheduling the weekly build corn job ?

[Ricardo Salveti (ricardosalveti)]

Is there a reference on how this can be done. This could help me to make the expected changes.

.github/workflows/nightly*

Dmitry Baryshkov (@lumag) is there a preferred day and time for scheduling the weekly build corn job ?

Late saturday or early sunday would be OK.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

Is there a reference on how this can be done. This could help me to make the expected changes.

.github/workflows/nightly*

Dmitry Baryshkov (@lumag) is there a preferred day and time for scheduling the weekly build corn job ?

Late saturday or early sunday would be OK.

Ricardo Salveti (@ricardosalveti) / Nicolas Dechesne (@ndechesne) Can i create a new weekly profile in build-yocto.yml or do you prefer if I created a new build-yocto-weekly.yml for this ?

[Dmitry Baryshkov (lumag)]

Ricardo Salveti (@ricardosalveti) / Nicolas Dechesne (@ndechesne) Can i create a new weekly profile in build-yocto.yml or do you prefer if I created a new build-yocto-weekly.yml for this ?

Please create a weekly-build.yml

[Ricardo Salveti (ricardosalveti)]

Yeah, weekly-build.yml is fine.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

Yeah, weekly-build.yml is fine.

Ricardo Salveti (@ricardosalveti) / Dmitry Baryshkov (@lumag) I have tried to create a workflow as suggested. I am not sure how I can test this. I have kept the corn job times similar to other workflows. I would appreciate if you can have a look.

[Ricardo Salveti (ricardosalveti)]

Please rebase your changes to fix the conflicts.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

Please rebase your changes to fix the conflicts.

fixed the merge conflicts now.

[Ricardo Salveti (ricardosalveti)]

Commit sha: 35c6228, Author: Ashwin Prabhakar, Committer: Ashwin Prabhakar; Expected "Ashwin Prabhakar ashwin.prabhakar@oss.qualcomm.com", but got "Ashwin Prabhakar ashwin.prabhakar@oss.qualcom.com".

Email is incorrect, DCO is failing.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

Commit sha: 35c6228, Author: Ashwin Prabhakar, Committer: Ashwin Prabhakar; Expected "Ashwin Prabhakar ashwin.prabhakar@oss.qualcomm.com", but got "Ashwin Prabhakar ashwin.prabhakar@oss.qualcom.com".

Email is incorrect, DCO is failing.

Fixed it. Thank you.

[Ashwin Prabhakar (Ashwin-Prabhakar)]

Commit sha: 35c6228, Author: Ashwin Prabhakar, Committer: Ashwin Prabhakar; Expected "Ashwin Prabhakar ashwin.prabhakar@oss.qualcomm.com", but got "Ashwin Prabhakar ashwin.prabhakar@oss.qualcom.com".
Email is incorrect, DCO is failing.

Fixed it. Thank you.

Ricardo Salveti (@ricardosalveti) / Jose Quaresma (@quaresmajose) I have addressed all the concerns raised here.can you please have a look and let me know what you think.