search

RPi-Distro / chromium-browser

30 stars 7 forks source link

Instructions needed to build and test chromium built with patches from this repository #11

Closed viraniac closed 2 years ago

viraniac commented 3 years ago

Hi,

I am trying to port mmal patch to the chromium corresponding to latest version of google chrome stable release. The current patches available in this repository are for v84. I have been able to port them to version 85.0.4183.121. So far I have compiled the armv6-rel target and am working on compiling the others so that I can package them as a deb and install it on my raspberrypi for testing.

I have found some discrepancies though.

  1. The pi-util/pi-install-dev.sh is missing libgbm-dev, libpulse-dev and libx11-xcb-dev packages
  2. The pi-util/gngen.py defaults to pios_buster_arm while the pi-util/syncroot is still defaulting to raspian_stretch_pi1
  3. Also the build instructions in pi-util/BUILD.txt states to compile using the following instructions 
    # Build chrome
ninja -C out/armv6 chrome chrome_sandbox
# Build armv7 ffmpeg
ninja -C out/armv7 third_party/ffmpeg

    Based on debian/rules file, I believe this needs to be as follows

    # Build chrome
ninja -C out/armv6-rel chrome chrome_sandbox
ninja -C out/armv7-rel chrome chrome_sandbox
# Build armv6 & v7 ffmpeg
ninja -C out/armv6-rel-std third_party/ffmpeg
ninja -C out/armv7-rel-std third_party/ffmpeg

    As I am following instructions from pi-util/BUILD.txt for cross-compiling and not really using dpkg-buildpackage to compile natively, I am still not sure about how I will be packaging the compiled stuff, but I will figure that out once the compilation is finished.

In the mean time it will be great if you can share the instructions that you are following for cross-compiling, packaging and testing chromium for rpi.

Also, once I finish porting mmal and other patches to 87.0.4280.88, can I raise a merge request against this repository for the same?

XECDesign commented 3 years ago

We're a bit past v85 internally, so the next release is probably going to be v87 or newer. I think we're okay when it comes to porting our own changes forward, but if you have other patches that you think would be useful, we'd gladly take a look at any merge requests.

The build instructions were accurate at one point, but things are in a state of flux. There are multiple ways to go about it, depending on what you want to achieve exactly. BUILD.txt is a good starting point and I copy most of what I do from there. The next version is a bit different, since it has changes to generate sysroot without copying it from an image, which should simplify things a bit.

viraniac commented 3 years ago

Is there a way I can access your internal repository? That can save me some time trying to do the same fixes that you guys would have already done.

XECDesign commented 3 years ago

When things are ready for public release they go here.

viraniac commented 3 years ago

Ok. One last thing. The last commit in this repository is for 84.0.4147.141-rpt1. I believe the version available in pios repository is having a rpt3 suffix. Are there any fixes that are missing in this repository which are included in rpt3 package?

XECDesign commented 3 years ago

I believe the two iterations were to fix widevine and disable audio sandboxing if bluealsa is installed. It looks like that's already here.

viraniac commented 3 years ago

Are you guys building chrome_sandbox? i don't see that in the chromium-browser*.deb file. I think you are building chromedriver instead. Is that correct?

XECDesign commented 3 years ago

We're not building chrome_sandbox, since it's no longer required. We are building chromedriver, but not 'instead'.

viraniac commented 3 years ago

Yeah. "Instead" was just poor choice of words as I am not a english speaker. I understand the use for both of them and that chromedriver is not the replacement of chrome-sandbox.

chromedriver is build for armv6-rel only. Is that correct?

XECDesign commented 3 years ago

Is that correct?

It is, yes.

viraniac commented 3 years ago

Have you guys figured out the redefinition errors in src/third_party/skia/src/core/SkSpan.h for which you have added the following part in v84 patch?

+// *** Caused redefinition errors in v82 (but was OK in in v82??)
+//     but doesn't seem to be needed
+//template <size_t N, typename T>
+//inline constexpr SkSpan<T> SkMakeSpan(T(&a)[N]) { return SkSpan<T>{a, N}; }

That piece of code that gets commented is required in v86. I think the following macro definition that gets added in the src/third_party/skia/src/opts/SkBlitRow_opts.h is causing the redefinition errors

+// Macros to specify instructions to only include if targeting ARM or Thumb instruction sets
+#ifdef __thumb__
+#define A(x)
+#define T(x) x
+#else
+#define A(x) x
+#define T(x)
+#endif

In my local I have renamed those macros to RPI_TARGET_A and RPI_TARGET_T to make sure not to have things with the same name

viraniac commented 3 years ago

@XECDesign I ported the mmal patch to v85 and that worked fine when I tested it on pi. I then tried to port it to v86, but with that port when I am playing youtube video, only the audio is being played and the video stays white.

The updated patch is here

Could you please provide me some pointers on how to debug the same?

XECDesign commented 3 years ago

Just pushed v86 out

viraniac commented 3 years ago

Nice to see a lot of my changes matches with the changes in your patch. I see you guys decided to patch SkSpanView instead of renaming the macro in the patch for SkBlitRow_opts.h and uncommenting that inline function in SkSpan.h