In the Ubuntu 17.10 cycle we tried wayland as the default session but we didn’t feel confident at the time it was ready yet for a LTS. Things improved since, some of the blockers we found back then got resolved (desktop sharing), and that’s where the upstream focus is going. We believe now is the right time to try again, it should give us enough time before the next LTS to get proper feedback and sort out issues.
Since we decided to not upgrade our GNOME version this cycle it should also make things a bit easier. Note that nvidia users are still going to default to xorg for now but hopefully that situation will be resolved before the LTS.
We will keep this topic updated as needed, as usual community feedback is welcome and bugs are best reported on launchpad.
Fabulous news! With Ubuntu throwing in it’s weight there should be a much bigger incentive for for app/toolkit makers to polish remaining deficits in their Wayland backends.
I assume Ubuntu will also continue to make fractional scaling available in the display settings? The Wayland version is AFAIK much better (and upstream supported) than the Xorg one but unfortunately suffers from providing a worse Xwayland experience then default integer scaling - which brings us back to the first issue: apps properly supporting native Wayland.
20.04 waland still crashes a few times a month for me.
Fresh install with oem kernel. I work around it with
gnome-session-quit via ssh from my phone. Is there a recommended cli way to send a bug report?
Wayland in 17.10 wasn’t ready even for non-LTS I try it every release and some of them were really bad, but Wayland is life. Great news!
Will laptop users with Intel HD Graphics + Nvidia be treated as nvidia users? I remember the session missing even when I had prime-select intel which means Nvidia GPU did nothing.
I’m using Wayland with Ubuntu 21.04 but sometimes I’m forced to move to X11 for a very old problem: https://gitlab.gnome.org/GNOME/gimp/-/issues/1074
Start Ubuntu 21.04 in Wayland: the dock is empty and takes 20-30 seconds to be populated.
Start an app: the app icon appears i the dock about 20 seconds later
Close an app: the app icon disapperappears about 20 seconds later
Similar stuff happens in a lot of apps using legacy methods - prime example being desktop sharing in Zoom. The APIs are long there, but some app makers seem to lack interest.
I’ve found that on single-display computers and non-fractional scaling, Wayland works just fine (aka laptop or non-high res external display). However, on multiple computers running multiple high-res screens, I have many artifacts and other issues. Throw in fractional scaling & I’m right back to X with minutes. The best way I can describe Wayland is a bag of hurt, sadly.
MIR means “main inclusion request” … in this case the request was granted but to “physically” pull the package to main it needs something else to depend on it or a seed to pull it into main …
tl;dr: “the paperwork is done, the action is not yet”
Perhaps this is good thing for the long run but for now, what this mean?
That my xrandr script dosnt work anymore? I use xrandr to force give me a wanted scaling without gnome/kde/whatever own unite scaling for all displays. My simple script handle every display output as individual ones and give them scaling what i want.
So if wayland dont support monitors individual scalings, then this isnt good for people who use lots of monitors on their setup and with different resolutions on them.
People who want to keep using xrandr scripts can easily switch back to xorg in the login screen. Xrandr is specifically built for X and will never fully function on Wayland, but Xorg isn’t going away any time soon.
In the short run, you can switch back to Xorg from the login screen. It will remember your choice, so you only need to change it once.
Gnome Wayland supports individual monitor scaling. It’s even better with the experimental fractional scaling - which ironically isn’t the default yet because some Xwayland apps look worse/blurry. If you only use native Wayland apps you essentially get perfect scaling choices, way better than on Xorg.
What exactly do you mean? Something like scaling down, such as 80%? Technically there shouldn’t be a reason for to not work with fractional scaling, but I’m not sure if Mutter currently supports it. But if there’s demand for it or, more importantly, people who would be willing to do the work - then it should be possible
Please do not move to Wayland. I understand the motivation to go for a new shiny thing but it’s far from that.
Wayland brings more problems than it solves for many users. For example AMDGPU-PRO doesn’t even work on Wayland session, it suffers from terrible screen tearing and it crashes every 5min-15min so it’s unusable.
DaVinci Resolve has problems working on Wayland, idk why.
OBS Studio has problems with Wayland, it can’t stream desktop and whatnot.
Wayland has terrible color management or better to say, Wayland doesn’t have color management and that’s a huge huge problem for anyone doing anything media realted. Film, VFX, Graphic design, Photography, Game industry. Everyone depends on the OS having an excellent color management capability. In today’s world we even look for HDR capability. Well guess what. Wayland provides none of those.
So please, don’t default that thing. Then they will never implement proper color management and when they figure it out later that they were wrong then they’ll do some hackery to implement and stick it on. It will be worse than X in the end I’m telling you.
So this should be a clear requirement, no defaulting before that’s solved. If Wayland continues to ignore it, someone will fork it and Ubuntu should focus on that instead.
Until this is carefully considered and implemented in Wayland there should be no defaulting of any kind! Because that would lead to many problems down the line.
GUI graphic system Color Management Requirements
Author: Graeme W. Gill
Date: 7th December 2020
Version: 1.0
This is general, but is writen in the context of adding modern color management
to the Wayland protocol.
R. Requirement
J. Justification/explanation
P. Priority
S. Current status within desktop application programming environments:
M = Supported by Microsoft Windows
A = Supported by Apple OS X
X = Supported by X11 based systems.
R: Applications need to know display pixels colorspace, and
be able to do color transforms into this colorspace for
display on that display device.
Practically this means reference and access to an ICC profile
that defines the colorspace of each display/pixel.
P: Mandatory
X: Some key applications deal with a wide range of source colorspaces,
and their core job is to accurately render these for display.
Sources are as diverse as other RGB colorspaces, CMYK and
higher number of colorant print spaces, named colors, device independent
color specifications, etc. Sources are not necessarily defined by ICC profiles.
(See for instance how PostScript, PDF and XPS allow colors to be defined.)
Accuracy of processing and correct gamut limitation/mapping handling
is only possible with a direct conversion between the native
source colorspace and the display colorspace. Existing application
code assumes this capability is available, and these complex applications
are not trivial to re-write or re-target.
S: M, A, X
R: Applications need to be able to upload & set the profile
that defines a displays colorspace.
P: Mandatory
X: Without this only the grossest problems of non-color managed displays
can be dealt with. Manufacturer supplied profiles are at best generic,
and often misleading when derived from (say) EDID information.
Color sensitive uses of computer systems require calibration and profiling
their specific display in a state of specific adjustment, and
require verification and re-calibration/profiling on a regular basis.
Applications used for calibration and profiling are normal applications
that expect to target the same devlopment environment and API’s as
any other color managed application to be able to do their job.
Like other complex and highly technical applications they are not trivial
to create, maintain or port to new environments.
S: M, A, X
R: System wide default color management. There should be a default source
colorspace that the system will color convert to the display colorspace
if the application doesn’t want to handle the color conversion itself.
P: Desirable
X: Many application writers do not have the necessary knowledge
to deal with color management, and the extra complexity needed
in rendering with color management cannot be justified for many
applications. This capability also allows for applications to work
sucessfully in the face of unanticipated changes in display
characteristics such as wide gamut, HDR etc.
S: A
R: System will honour defacto standard display calibration curves included
in display ICC profiles. Maximum HW precision will be used.
P: Mandatory
X: Although some displays have a capability of setting white point
and brightness progromatically, this is not true for all displays
and is not published, standardized or available via a standard API.
Using graphic card 1D LUTs allows universal and standardized setting of
these key display characteristics, and this is assumed by most
existing display ICC profiles and color management tools.
Additionally it is typicall that frame buffers have a more limited
resolution that the final output of graphics cards/display adapters
(i.e. 8 bit per component frame buffers typically have 10 bit outputs
after 1D lookup tables, 10 bit frame buffers have 12/14 bit 1D LUTs etc.),
and it is desirable to use this to ensure that the more limited precision
of the frame buffer is fully utilized by using the higher precision of
the 1D LUTs to perceptually even the quantization steps out.
S: M, A, X
R: Application is able to set and get display calibration curves
P: Mandatory
X: Display calibration and verification support. See explanation above in 2).
S: M, A, X
R: Application is able to display a rectangular window of pixels
on a chosen display and set un-managed pixel values.
P: Mandatory
X: Display calibration and profiling support. See explanation above in 2).
S: M, A, X
R: Commonly used profiles be readily available to applications
P: Desirable
X: Ties in with 3), as profiles are neede by the system for implementation,
and this allows an application to determine what default system color management
is actually doing.
S: none
R: Support for easy intermixing HDR and SDR displays. This means supplementing
the display and source spaces profile information with HDR profile and handling
details.
P: Highly desirable
X: ICC profiles don’t have complete enough information to convenienly specify
HDR <-> SDR transformations.
S: none
R: Support global display modifications within the color managed context
for the purposes of applications such as “blue shift” or equivalent.
P: Desirable
X: People use and enjoy such application, and these typically rely on the
availablility of per channel lookp curves in the graphics hardware to do
crude global display modifications. A way of accomodating this while working
harmonously with color management is desirable.
I try it every release and some of them were really bad, but Wayland is life. Great news!
