Wayland support

[illiliti]

https://github.com/Igalia/chromium

[Eloston]

This is Linux-specific, so this should be moved to all Linux-based platform repositories.

Also, the README in that repository says that the work has moved to the Chromium project. Do we need any changes from that repo?

[antifa-ev]

@illiliti Nobody needs Wayland https://medium.com/@ohadrau/the-problem-with-wayland-and-why-it-will-never-succeed-53c5d230b457

[Eloston]

@antifa-ev Regardless of your opinion (and the article author's opinion) on Wayland, the fact is it's being adopted by major Linux distributions (Fedora, Ubuntu, even Debian). Therefore, I see no reason why we should refuse Wayland support.

I will not have Wayland support replace X11, so you are free to keep using X11.

[baerbock]

@Eloston Are you a slave of the "major Linux distributions"? They all take massive decisions for the user. This is not the freedom I expect from free software.

[Eloston]

@baerbock If you do not like my decision to satisfy both X11 and Wayland users, then you are free to fork the project and exclude Wayland users. As you said yourself, ungoogled-chromium is *free software".

I am no longer interested in continuing this discussion. As a final note, all I ask is that you consider other perspectives.

[travankor]

@Eloston,

It seems like ozone needs to be enabled for wayland support. Is there a reason why it is currently disabled?

Upstream issue: https://bugs.chromium.org/p/chromium/issues/detail?id=578890

According to this, seems like there are ~4-5 minor,unmerged patches. Everything else is upstreamed.

[Eloston]

@travankor Last time I looked at anything Ozone related, it wasn't ready for Linux. In fact, the Chromium docs suggest it is still not ready: https://chromium.googlesource.com/chromium/src/+/master/docs/ozone_overview.md#linux-desktop-waterfall

I don't think there was any good reason why it's explicitly disalbed in flags.gn, so I can remove it.

[travankor]

I think those docs are slightly outdated although things are not 100% ready. From what I read, the main issue is that an ozone build has issues in multiple backends in one build and there are some ozone-X11 issues (although ozone X11 was added in 2016, which makes me confused since the wayland backend came later).

Ideally, I could test this out with CI, but I think the free gitlab runner would swap to disk and then stop when the disk gets filled.

@msisov is the person who is in charge of Chromium Wayland.

[msisov]

Hi.

We have a requirement from Google that old legacy X11 path must be migrated to Ozone as well so that the same binary is able to run on both X11 and Wayland natively.

The problem with Ozone/X11 is that it is not ready. The code that has been there before Ozone/Wayland work has mostly been for testing, but not for production. There are many design problems, which we are working on, to make finally shutdown old X11 path and use Ozone by default.

However, Ozone/Wayland still has been missing two features - tab drag (you can drag tab inside the same window, but if one wants to drag a tab from one window to another, the browser won't let you to do it). Second feature is file dialogs. That is the feature, which will be shared (most probably) among different ozone backends. And it will be ready once we have Ozone/X11 ready.

Otherwise, one can use Ozone/Wayland easily. We are mostly in maintainer mode for Wayland now.

[mbakke]

GNU Guix has a native Wayland version of ungoogled-chromium as of this commit:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=82ccfb1d9464c8487bbb2eb4f5871b8fdb5f7bc9

It should work on any GNU/Linux distribution (but you need to install Guix first, of course).

[travankor]

hm, the guix buildserver seems to have stopped building chromium?

guix package -i ungoogled-chromium:

The following package will be installed:
   ungoogled-chromium   74.0.3729.131-0.9e33022 /gnu/store/7qc50cqwwxb7x16rw7fswq083miccl6x-ungoogled-chromium-74.0.3729.131-0.9e33022

[mbakke]

@travankor: You'll need to guix pull to fetch the latest package updates.

[travankor]

@mbakke, Thanks for the guix tip. (and sorry for the noise)

After installing the guix package, sway (with xwayland disable set in sway's config) can not run chromium --ozone-platform=wayland (works fine with Xwayland).

It seems like use_system_libdrm=true and use_sysroot=false is missing from the build. enable_swiftshader=false, enable_nacl=false, and linux_use_bundled_binutils=false might also need to be set (not sure).

[mbakke]

@travankor The Wayland version is called ungoogled-chromium-wayland (a different package).

[Eloston]

I think we should let Google push out Ozone/Wayland when it is ready.

For the adventurous, perhaps we could document some way to enable it in each of the platform repos.

[msisov]

@Eloston, Google won't push out Ozone/Wayland until we also complete Ozone/X11

[travankor]

Or add a note that Guix has it packaged (binary artifact and a build recipe so you can customize it locally)?

Note that I had to add --in-process-gpuas a run-time flag, or else I got some weird compositing issues. Otherwise, it's more reliable than Firefox Wayland.

[msisov]

It's probably because you don't have dmabuf support (you also need to have drm render nodes enabled), and Chromium switches to software compositing (which must run in ToT now. We made some patches to improve it, but more work may be required). In case of added --in-process-gpu, Chromium uses wl_egl, which is known to be supported by "all" systems available in the market.

[travankor]

Actually, I think the compositing issue is something related to Kwin_wayland or QT, since sway works fine without it (I just had the flag aliased for both).

However, there are issues like Not implemented reached in static void ui::XDGSurfaceWrapperV6::CloseTopLevel(void*, zxdg_toplevel_v6*) and some more minor issues with extension pop-ups.

[msisov]

Not implemented - is just a message log. They must be revised. If I remember correctly, we did not have a use case for that and just used NOTIMPLEMENTED macro.

Regarding the issues - wouldn't you mind to report them to crbug.com and add me to cc or paste links here?

[travankor]

The problem with CloseTopLevel is that Mod-Shift-Q can't close the window in sway although Ctrl-Shift-W does close the window.

I will look into bug reports for other issues as time allows, but like I said, chromium wayland already works better than FF-wayland.

[msisov]

@travankor, that's a good notice. I will handle this.

And thank you for your feedback

[busti]

I do not know much about the technical details of supporting wayland, but one of the compilation flags set in the guix repo enables HiDPI support in wayland (I am using sway), but still requires xwayland to be enabled.
Maybe that should be enabled by default, but again I do not know how that would impact other things.

[mbakke]

The issue with xwayland being required was a regression in the update to 78, and has been fixed with the latest version of Guix's ungoogled-chromium package.

[PanderMusubi]

Does supporting Ctrl+Q to quit the entire application fall under this issue, or do I need to create a new issue?