Trying wayland by default again

Desktop
#1

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.

21 Likes
#2

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.

4 Likes
#3

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?

apport-cli --file-bug --package=“gnome-session” --pid="$(pidof gdm-wayland-session)"

maybe?

#4

Wayland in 17.10 wasn’t ready even for non-LTS :smiley: 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.

#5

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

#6

An easy workaround here should be to make a screenshot, open it in Gimp and pick from there :slight_smile:

But apart from that Gimp should just start to use the appropriate APIs, see https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/171 and https://gitlab.gnome.org/World/gcolor3/-/merge_requests/141

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.

2 Likes
#7

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.

#8

Does this decision include using Pipewire for screensharing by default?

2 Likes
#9

Yes, the screen sharing requires it and the MIR got approved

6 Likes
#10

What does MIR means? Pipewire is sill in universe: https://launchpad.net/ubuntu/+source/pipewire.

#11

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”

6 Likes
#12

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.

#13

This Mutter/Pipewire change will be backported to Focal?

#14

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.

1 Like
#15

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.

3 Likes
#16

i know this coming littlebit offtopic, but can you scale opposite direction? i use that on xrandr.

#17

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 :slight_smile:

1 Like
#18

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.

1 Like
#19

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.

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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.

    S: A

Source: https://www.argyllcms.com/CM_requirements.txt

1 Like
#20

It might sound silly but for me the biggest tragedy is that middle-clicking title bars does not lower the window under Wayland :sob:

It’s possible to set a keyboard shortcut as a workaround, but it’s not the same…

1 Like