Looking at the current issues, it looks like it's still not ready. I think that even the official Chrome build doesn't have it enabled. We should switch once the upstream switches as we don't have the manpower to fix the issues.

Yes, it is currently experimental but default in Official Chrome OS. I don't think Chrome will ever enable it in its official linux build. What do you think about providing a different package like 'chromium-ozone' for now?

I don't like the idea of the chromium-ozone package, but if someone from the community would like to do it, then it's definitely possible (but outside of the chromium package in Fedora - as we are currently hitting over 2 days of build time on aarch64 and I don't want to prolong it even more).

Also in past we tried to enable the vaapi (through downstream patches), but it failed miserably.

I am aware of what happened with the vaapi patches, would it be possible that vaapi only works with ozone? Because ozone is enabled by default in Chrome OS and vaapi patches are enabled too. Does vaapi library require wayland or something? Chrome OS uses wayland and wayland is only supported by Ozone GPU stack in Chrome.

I am sorry, Chrome OS doesn't use wayland. What I meant is that would it be possible that vaapi only works under Ozone stack?

I maintain a chromium ozone build on my copr: https://copr.fedorainfracloud.org/coprs/akarshanbiswas/chromium-ozone/

libgtkUI is not ported and many more things. But I have managed to add support for wl_drm for amdgpu to enable multiprocess hardware acceleration.

*thanks to maxim of Igalia who helped me in adding the support of wl_drm.

Also vaapi isn't working but the VAProfiles are being detected correctly(Atleast on amdgpu).

(In reply to Akarshan Biswas from comment #6)
> I maintain a chromium ozone build on my copr:
> https://copr.fedorainfracloud.org/coprs/akarshanbiswas/chromium-ozone/

Nice, then people could use your copr, until it's officially ready.
 
> libgtkUI is not ported and many more things.

Yes, as I already said, it's not ready at all. I think that the work if mostly for CEF or Chrome OS as already was mentioned.

Let me close this bug, as there is not anything what we can (or would like to) do currently.

@Tomas I don't think this issue should be closed. There is a tracker bug upstream: https://bugs.chromium.org/p/chromium/issues/detail?id=578890&q=Proj%3DOzone-Wayland%20&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

I think we should get serious about wayland port.

@Akarshan, I have been your development of chromium-vaapi & chromium-ozone recently. I tried the ozone build too, just wanted to know if the copr build is from upstream or Igalia's fork (https://github.com/Igalia/chromium/tree/ozone-wayland-dev) ?

This issue was created only after I discovered your COPR build of ozone.

(In reply to Rajveer Malviya from comment #10)
> @Akarshan, I have been your development of chromium-vaapi & chromium-ozone
> recently. I tried the ozone build too, just wanted to know if the copr build
> is from upstream or Igalia's fork
> (https://github.com/Igalia/chromium/tree/ozone-wayland-dev) ?
> 
> This issue was created only after I discovered your COPR build of ozone.

Just upstream chromium with few back-ported patches. Every work on ozone is done fully upstream now.

@Tomas 

Google Chrome Dev (v87) started to build with ozone enabled by default.

 - https://twitter.com/maksim_sisov/status/1303677914836332545

Is it possible to enable ozone/wayland in chromium package now?

Is it planned to support VA-API straight away after enabling ozone/wayland in the chromium(-vaapi) package?

In Fedora 35, --ozone-platform=wayland is now set by default by chromium-browser.sh if running on Wayland, unfortunately this breaks the Chromium's "Web Application" feature:

Chromium no longer sets the WM_CLASS property (or whatever the Wayland equivalent to that is) to the value of the --app-id parameter prepended by "crx_", so the desktop does no longer recognise that the window belongs to the .desktop file with the corresponding StartupWMClass property set.
The result is that Chromium Web Apps appear and are handled as regular Chromium windows instead of discrete applications.

The workaround is to start the Chromium with $XDG_SESSION_TYPE and $WAYLAND_DISPLAY unset to prevent chromium-browser.sh from adding --ozone-platform=wayland to $CHROMIUM_DISTRO_FLAGS.
But if this misbehaviour cannot timely be resolved in Chromium itself, it would be great to have a nicer way to prevent Chromium from using the Wayland backend by applying a per-user or system-wide override from e.g. /etc/sysconfig/chromium to disable adding --ozone-platform=wayland or to set --ozone-platform=x11 explicitly.

it should be fixed in chromium-109.0.5414.74-1.f38