Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Chromium with wayland native's feature.
-
- Posts: 20
- Joined: 2021-07-22 01:59
Chromium with wayland native's feature.
Is there a plan to bring wayland native support for chromium to debian? yeah I know that "chrome" is already have it, but how about chromium? Thanks.
-
- Posts: 61
- Joined: 2021-09-18 00:37
- Been thanked: 2 times
Re: Chromium with wayland native's feature.
According to this post viewtopic.php?p=739899#p739899 the Wayland support should automatically work when $XDG_SESSION_TYPE is set to Wayland.
When you run a Gnome or Plasma wayland session this variable gets set, if you are creating a custom Wayland session you should be setting this variable in your script you use to start the session.
When you run a Gnome or Plasma wayland session this variable gets set, if you are creating a custom Wayland session you should be setting this variable in your script you use to start the session.
-
- Posts: 20
- Joined: 2021-07-22 01:59
Re: Chromium with wayland native's feature.
That's my comment BTW , it just works with qutebtowser (even sometimes qutebtowser are able to run natively without it) not chromium AFAIK. I also always start my session with XDG_SESSION_TYPE=wayland.seeker5528 wrote: ↑2021-10-23 15:43 According to this post viewtopic.php?p=739899#p739899 the Wayland support should automatically work when $XDG_SESSION_TYPE is set to Wayland.
-
- Posts: 61
- Joined: 2021-09-18 00:37
- Been thanked: 2 times
Re: Chromium with wayland native's feature.
The ArchWiki has this. https://wiki.archlinux.org/title/chromium
Native Wayland support
Since version 87, native Wayland support in Chromium can be enabled with the following flags [6]:
See #Making flags persistent for a permanent configuration.
If you switch between X11 and Wayland often, you can edit the Exec line in desktop file to the following:
This will apply wayland flags only when in wayland session, so you can use a single desktop entry which is working for both session types.
Debian uses a script to run chromium that sources files in /etc/chromium.d so you could create a file there and put the flags in it.
EDIT: corrected what should be file contents
Scripting isn't really my thing but based on the ArchWiki snippet, I think it should work to create a file with the contents..
Don't know why something like this isn't done already if the support has been there since version 87
'chrome --help' doesn't show the flags and 'chrome://flags' in the browser doesn't show them either, but I don't get an error if I use the flags. I'm not in a wayland session and the browser looks the same.
After editing the above examples I can create a file in /etc/chromium.d with the exports for the flags and if I run chromium from the command line in a plasma wayland session I don't get any errors about the flags.
Looks like ozone is becoming the default upstream for both X11 and wayland, and the non-ozone X11 stuff is being deprecated. I'm running unstable, don't know if there are any significant differences yet between chromium in stable and chromium in unstable relative to the ozone stuff.
Native Wayland support
Since version 87, native Wayland support in Chromium can be enabled with the following flags [6]:
Code: Select all
--enable-features=UseOzonePlatform --ozone-platform=wayland
If you switch between X11 and Wayland often, you can edit the Exec line in desktop file to the following:
Code: Select all
if [ "$XDG_SESSION_TYPE" = "wayland" ]; then /usr/bin/chromium --enable-features=UseOzonePlatform --ozone-platform=wayland %U ; else /usr/bin/chromium %U ; fi
Debian uses a script to run chromium that sources files in /etc/chromium.d so you could create a file there and put the flags in it.
EDIT: corrected what should be file contents
Code: Select all
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-features=UseOzonePlatform -ozone-platform=wayland"
Code: Select all
if [ "$XDG_SESSION_TYPE" = "wayland" ]; then export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-features=UseOzonePlatform -ozone-platform=wayland" ; fi
'chrome --help' doesn't show the flags and 'chrome://flags' in the browser doesn't show them either, but I don't get an error if I use the flags. I'm not in a wayland session and the browser looks the same.
After editing the above examples I can create a file in /etc/chromium.d with the exports for the flags and if I run chromium from the command line in a plasma wayland session I don't get any errors about the flags.
Looks like ozone is becoming the default upstream for both X11 and wayland, and the non-ozone X11 stuff is being deprecated. I'm running unstable, don't know if there are any significant differences yet between chromium in stable and chromium in unstable relative to the ozone stuff.
-
- Posts: 20
- Joined: 2021-07-22 01:59
Re: Chromium with wayland native's feature.
I tried my self, the flags didn't work. Did you try and works? Thanks.
-
- Posts: 20
- Joined: 2021-07-22 01:59
Re: Chromium with wayland native's feature.
If you tried on plasma wayland, indeed it works, perhaps because plasma wayland has xwayland. I tried on pure wayland session (hikari wm and xwayland disable) , it complaints about x display.
-
- Posts: 61
- Joined: 2021-09-18 00:37
- Been thanked: 2 times
Re: Chromium with wayland native's feature.
Maybe it is a victim of compositor developers being slow agree on and adopt standards.
There is a blog post that indicates ozone will fall back to X11/Xwayland if the protocol that allows tab drag is not supported, maybe that is still the case?
https://blogs.igalia.com/msisov/2020/11 ... n-project/
There is a blog post that indicates ozone will fall back to X11/Xwayland if the protocol that allows tab drag is not supported, maybe that is still the case?
https://blogs.igalia.com/msisov/2020/11 ... n-project/
-
- Posts: 61
- Joined: 2021-09-18 00:37
- Been thanked: 2 times
Re: Chromium with wayland native's feature.
Looks like it does the same in Gnome Wayland session. Additionally it appears the Qterminal runs Wayland native in Plasma Wayland session but uses XWayland in Gnome Wayland session.
Maybe in another 4 or 5 years the compositor developers will have sorted out standards for things that have been standard in window managers for multiple decades.
Looks like this feature is disabled even in Debian Unstable
https://salsa.debian.org/chromium-team/ ... bian/rules
Which I would think in this context means not compiled in, which fits not showing anything about the ozone related flags, but doesn't fit not giving you an error message when you supply the flags at the command line.
Maybe in another 4 or 5 years the compositor developers will have sorted out standards for things that have been standard in window managers for multiple decades.
Looks like this feature is disabled even in Debian Unstable
https://salsa.debian.org/chromium-team/ ... bian/rules
Which I would think in this context means not compiled in, which fits not showing anything about the ozone related flags, but doesn't fit not giving you an error message when you supply the flags at the command line.
-
- Posts: 20
- Joined: 2021-07-22 01:59
Re: Chromium with wayland native's feature.
Don't blame the compositor's developer! they did offer "xwayland" feature" but I disable it. Hope the chromium package maintainer (from debian) will implement native wayland support.seeker5528 wrote: ↑2021-10-27 16:52 Maybe it is a victim of compositor developers being slow agree on and adopt standards.
-
- Posts: 61
- Joined: 2021-09-18 00:37
- Been thanked: 2 times
Re: Chromium with wayland native's feature.
I'm not assigning blame to any developer or group of developers, that just happens to be the state of the Wayland landscape at the moment.
The Wayland/Weston stuff at the beginning was not intended to replace anything, it was the pet project of an individual with a limited set of design goals to be a proof of concept that things could be done a different way. I would guess that if it had not been done this way it would not have been done.
To go from that to where we are at now there had to be that wild west phase of development where developers of different compositors figure out their own ways of providing missing features and some of that gets adopted upstream and becomes standard but until they become standard and get adopted into different compositors you end up with things that work in some compositors, but not in others.
In terms of what applications generally need, things seem to be mostly sorted out, in terms of desktop user experience stuff working in a compositor/desktop independent way, things still need some work, things like positioning windows, setting background, controlling volume with a tray application, etc....
I see there is a wlr-xrandr package that provides xrandr type functionality to wlroots based compositors, but the protocol to allow it to work has not been adopted by other compositors. I primarily use LXQT as my desktop and these are the types of things that are holding the LXQT developers back from providing a Wayland version of LXQT.
The Wayland/Weston stuff at the beginning was not intended to replace anything, it was the pet project of an individual with a limited set of design goals to be a proof of concept that things could be done a different way. I would guess that if it had not been done this way it would not have been done.
To go from that to where we are at now there had to be that wild west phase of development where developers of different compositors figure out their own ways of providing missing features and some of that gets adopted upstream and becomes standard but until they become standard and get adopted into different compositors you end up with things that work in some compositors, but not in others.
In terms of what applications generally need, things seem to be mostly sorted out, in terms of desktop user experience stuff working in a compositor/desktop independent way, things still need some work, things like positioning windows, setting background, controlling volume with a tray application, etc....
I see there is a wlr-xrandr package that provides xrandr type functionality to wlroots based compositors, but the protocol to allow it to work has not been adopted by other compositors. I primarily use LXQT as my desktop and these are the types of things that are holding the LXQT developers back from providing a Wayland version of LXQT.