On the Road to Fedora Workstation 31

So I hope everyone is enjoying Fedora Workstation 30, but we don’t rest on our laurels here so I thought I share some of things we are working on for Fedora Workstation 31. This is not an exhaustive list, but some of the more major items we are working on.

Wayland – Our primary focus is still on finishing the Wayland transition and we feel we are getting close now, and thank you to the community for their help in testing and verifying Wayland over the last few years. The single biggest goal currently is fully removing our X Windowing System dependency, meaning that GNOME Shell should be able to run without needing XWayland. For those wondering why that has taken so much time, well it is simple; for 20 years developers could safely assume we where running atop of X. So refactoring everything needed to remove any code that makes the assumption that it is running on top of X.org has been a major effort. The work is mostly done now for the shell itself, but there are a few items left in regards to the GNOME Setting daemon where we need to expel the X dependency. Olivier Fourdan is working on removing those settings daemon bits as part of his work to improve the Wayland accessibility support. We are optimistic that can declare this work done within a GNOME release or two. So GNOME 3.34 or maybe 3.36. Once that work is complete an X server (XWayland) would only be started if you actually run a X application and when you shut that application down the X server will be shut down too.

Wayland logo

Wayland Graphics


Another change that Hans de Goede is working on at the moment is allowing X applications to be run as root under XWayland. In general running desktop apps as root isn’t considered adviceable from a security point of view, but since it always worked under X we feel it should continue to be there for XWayland too. This should fix a few applications out there which only works when run as root currently. One last item Hans de Goede is looking at is improving SDLs Wayland support in regards to how it deals with scaling of lower resolution games. Thanks to the great effort by Valve and others we got a huge catalog of games available under Linux now and we want to ensure that those keep running and runs well. So we will work with the SDL devs to come up with a solution here, we just don’t know the exact shape and and form the solution will take yet, so stay tuned.

Finally there is the NVidia binary driver support question. So you can run a native Wayland session on top of the binary driver and you had that ability for a very long time. Unfortunately there has been no support for the binary driver in XWayland and thus and X applications (which there are a lot of) would not be getting any HW accelerated 3D graphics support. Adam Jackson has worked on letting XWaylands load the binary NVidia x.org driver and we are now waiting on NVidia to review that work and hopefully be able to update their driver to support it.

Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is.

PipeWire – Wim Taymans keeps improving the core features of Pipewire, as we work step by step to be ready to replace Jack and PulseAudio. He has recently been focusing on improving existing features like the desktop sharing portal together with Jonas Adahl and we are planning a hackfest for Wayland in the fall, current plan is to do it around the All Systems Go conference in Berlin, but due to some scheduling conflicts by some of our core stakeholders we might need to reschedule it to a little later in fall.
A new user for the desktop sharing portal is the new Miracast support that Benjamin Berg has been steadily working on. The Miracast support is shaping up and you can grab the Network Displays test client from his COPR repository while he is working to get the package into Fedora proper. We would appreciate further users testing and feedback as we know there are definitely devices out there where things do not work properly and identifying them is the first step to figuring out how to make our support in the desktop more robust. Eventually we want to make the GNOME integration even more seamless than the standalone app, but for early testing and polish it does the trick. If you are interested in contributing the code is hosted here on github.

Network Display

Network Display application using Miracast

Btw, you still need to set the enable Pipewire flag in Chrome to get the Pipewire support (chrome://flags). So I included a screenshot here to show you where to go in the browser and what the key is called:

Chrome Pipewire Flag

Chrome Pipewire Flag

Flatpak – Work on Flatpak in Fedora is continuing. Current focus is on improving the infrastructure for building Flatpaks from RPMS and automating what we can.This is pre-requisite work for eventually starting to ship some applications as Flatpaks by default and eventually shipping all applications as Flatpaks by default. We are also working on setting things up so that we can offer applications from flathub.io and quay.io out of the box and in accordance with Fedora rules for 3rd party software. We are also making progress on making a Red Hat UBI based runtime available. This means that as a 3rd party developer you can use that to build your applications on top of and be certain that it will be stay around and be supported by Red Hat for the lifetime of a given RHEL release, which means around 10 years. This frees you up as a developer to really update your application at your own pace as opposed to have to chase more short lived runtimes. It will also ensure that your application can be certified for RHEL which gives you access to all our workstation customers in addition to Fedora and all other distros.

Fedora Toolbox – Work is progressing on the Fedora Toolbox, our tool for making working with pet containers feel simple and straightforward. Debarshi Ray is currently looking on improvements to GNOME Terminal that will ensure that you get a more natural behaviour inside the terminal when interacting with pet containers, for instance ensuring that if you have a terminal open to a pet container and create a new tab that tab will also be inside the container inside of pointing at the host. We are also working on finding good ways to make the selection of containers more discoverable, so that you more easily can get access to a Red Hat UBI container or a Red Hat TensorFlow container for instance. There will probably be a bit of a slowdown in terms of new toolbox features soon though as we are going to rewrite it to make it more maintainable. The current implementation is a giant shell script, but the new version will most likely be written in Go (so that we can more easily integrate with the other container libraries and tools out there, mostly written in Go).

Fedora Toolbox

Fedora Toolbox in action

GNOME Classic – We have had Classic mode available in GNOME and Fedora for a long time, but we recently decided to give it a second look and try to improve the experience. So Allan Day reviewed the experience and we decided to make it a more pure GNOME 2 style experience by dropping the overview completely when you run classic mode.
We have also invested time and effort on improving the Classic mode workspace switcher to make life better for people who use a very workspace centric workflow. The goal of the improvements is to make the Classic mode workspace switcher more feature complete and also ensure that it can work with standard GNOME 3 in addition to Classic mode. We know this will greatly improve the experience for many of our users and at the same time hopefully let new people switch to Fedora and GNOME to get the advantage of all the other great improvements we are bringing to Linux and the Linux desktop.

Sysprof & performance – We have had a lot of focus in the community on improving GNOME Shell performance. Our particular focus has been on doing both some major re-architecting of some core subsystems that where needed to make some of the performance improvements you seen even possible. And lately Christian Hergert has been working on improving our tooling for profiling the desktop, so let our developers more easily see exactly where in the stack bottlenecks are and what is causing them. Be sure to read Christians blog for further details about sysprof and friends.

Fleet Commander – our tool for configuring large deployments of Fedora and RHEL desktops should have a release out very soon that can work with Active Directory as your LDAP server. We know a lot of RHEL and Fedora desktop users are part of bigger organizations where Linux users are a minority and thus Active Directory is being deployed in the organization. With this new release Fleet Commander can be run using Active Directory or FreeIPA as the directory server and thus a lot of organizations who previously could not easily deploy Fleet Commander can now take advantage of this powerful tool. Next step for Fleet Commander after that is finishing of some lose ends in terms of our Firefox support and also ensure that you can easily configure GNOME Shell extensions with Fleet Commander. We know a lot of our customers and users are deploying one or more GNOME Shell extensions for their desktop so we want to ensure Fleet Commander can help you do that efficiently across your whole fleet of systems.

Fingerprint support – We been working closely with our hardware partners to bring proper fingerprint reader support to Linux. Bastien Nocera worked on cleaning up the documentation of fprint and make sure there is good sample code and our hardware partners then worked with their suppliers to ensure they provided drivers conforming to the spec for hardware supplied to them. So there is a new drivers from Synaptics finger print readers coming out soon thanks to this effort. We are not stopping there though, Benjamin Berg is continuing the effort to improve the infrastructure for Linux fingerprint reader support, making sure we can support in-device storage of fingerprints for instance.

Fingerprint image

Fingerprint readers now better supported

Gamemode – Christian Kellner has been contributing a bit to gamemode recently, working to make it more secure and also ensure that it can work well with games packaged as Flatpaks. So if you play Linux games, especially those from Ferral Interactive, and want to squeeze some extra performance from your system make sure to install gamemode on your Fedora system.

Dell Totem support – Red Hat has a lot of customers in the fields of animation and CAD/CAM systems. Due to this Benjamin Tissoires and Peter Hutterer been working with Dell on enabling their Totem input device for a while now. That works is now coming to a close with the Totem support shipping in the latest libinput version with the kernel side of things being merged some time ago. You can get the full details from Peters blog about Dell Totem.

Dell Totel

The Dell Totem input device

Media codec support – So the OpenH264 2.0 release is out from Cisco now and Kalev Lember has been working to get the Fedora packages updated. This is a crucial release as it includes the support for Main and High profile that I mentioned in an earlier blog post. That work happened due to a collaboration between Cisco, Endless, Red Hat and Centricular with Jan Schmidt at Centricular doing the work implementing support for these two codecs. This work makes OpenH264 a lot more useful as it now supports playing back most files found in the wild and we been working to ensure it can be used for general playback in Firefox. At the same time Wim Taymans is working to fix some audio quality issues in the AAC implementation we ship so we should soon have both a fully working H264 decoder/encoder in Fedora and a fully functional AAC decoder/encoder. We are still trying to figure out what to do with MPEG2 video as we are ready to ship support for that too, but are still trying to figure out the details of implementation. Beyond that we don’t have any further plans around codecs atm as we feel that with H264, MPEG2 video, AAC, mp3 and AC3 we have them most critical ones covered, alongside the growing family of great free codecs such as VP9, Opus and AV1. We might take a look at the status of things like Windows Media and DivX at some point, but it is not anywhere close to the top of our priority list currently.

22 comments ↓

#1 Pieter on 06.24.19 at 18:17

Thank you for your elaborate update. It’s great to read about all the progress you are all making. F31 is looking to be another great release.

#2 liquidat on 06.24.19 at 22:33

Thanks for that detailed analysis and insight! In particular I wasn’t aware that there is even work on totem and finger print support. And the details about the current situation with nvidia are also worth a read.
Awesome! :)

#3 Luya Tshimbalanga on 06.25.19 at 00:38

What is missing for majority of Linux distribution is the use of face authentification as found of laptop equipped with Windows Hello application. An attempt is done under howdy appliclation (https://github.com/boltgolt/howdy) and I made a rpm version under COPR repository. It will be interesting to integrate it for the fingerprint.

#4 Alex Villacís on 06.25.19 at 03:16

Recently mutter git has removed support code for OpenGL 1.4 support, and now has OpenGL 2.1 as a hard requirement. GNOME 3.32 currently works passably on i915 chipsets (such as mine) that offer only OpenGL 1.4. What will happen with these machines once Gnome Shell 3.34 comes out? Will they fall back to software rendering, fall back to X11, or just refuse to run Gnome Shell altogether?

#5 Luke Hutchison on 06.25.19 at 03:26

Two things I would love to see in Fedora 31:

(1) [Related to your point on CAD/Cam] ROS packages — see:
https://github.com/ros/rosdistro/issues/4918

(2) [Related to your point on AAC support] Better Bluetooth HD audio codec support — see:
https://github.com/EHfive/pulseaudio-modules-bt/issues/20#issuecomment-504678851

#6 uraeus on 06.25.19 at 12:57

Improving how bluetooth works is high on Wim Taymans agenda for Pipewire, so once we are ready to switch to Pipewire also for consumer audio you should also see a lot smoother bluetooth support.

#7 Matthew Neal Sandau on 06.25.19 at 04:48

Always love these posts thanks so much for the great detail in your updates!

#8 Tomaž Vajngerl on 06.25.19 at 06:56

Regarding codecs it would be cool to get SVT-AV1 into the repository and later on rav1e. Also work on AVIF so it is supported in GTK and Gnome apps. There is already go-avif in the repository so it’s possible to encode and decode images in the command line, but I guess a proper C library is needed for proper support.

#9 Mickael on 06.25.19 at 07:00

Any news about support of Microsoft Surface Pro series?

#10 asd on 06.25.19 at 07:58

No mention about defaulting to CgroupsV2, I hope I’ll see it in F31?

#11 swilmet on 06.25.19 at 09:13

It’s always a pleasure to read your blog and see the progress for the Linux desktop.

In your previous blog post you wrote:

> In fact we have some very interesting developments underway for Flatpak, with some major new efforts underway, efforts that I would love to talk about, but they are tied to some major Red Hat announcements that will happen at this years Red Hat Summit which will happen on May 7th – May 9th, so I will leave it as a teaser and then let you all know once the Summit is underway and Red Hats related major announcements are done.

Has the major new effort for Flatpak been announced, did I miss something? Is it what you wrote in _this_ blog post?

#12 uraeus on 06.25.19 at 12:54

Some of it is a little delayed, but I will follow-up with a post specifically about this soon.

#13 hand ocular on 06.25.19 at 12:29

Great post!

I’m glad to see next-gen tech comming to Linux desktop.
And I’m pleased to hear about Gnome Classic mode – that’s awesome but any information regarding Gnome classic on the web is horribly outdated. Is Gnome Classic for F31 (and beyond) going to be treated as a first class citizen and will it be WAYLAND native?

#14 uraeus on 06.25.19 at 12:56

GNOME Classic is a variation of GNOME 3, so all work done on GNOME 3 will carry over, like Wayland support. The work we are doing I think one could consider being upgrading it to a first class citizen in the sense that we are making it a purer Classic experience with less bleed through from standard GNOME 3.

#15 Søren Hauberg on 06.25.19 at 17:05

As always looking great!

You mention Tensorflow. One of the practical difficulties with machine learning on fedora is CUDA. The current infrastructure make it fairly easy to get the latest CUDA version installed, but often you need *all* versions of CUDA to be installed. Last time I tried that on Fedora it was quite a messy affair. Any chance the rpmfusion or negativo repos could carry all CUDA versions and allow them to install in parallel?

#16 gn0mish on 06.25.19 at 20:16

Another great post thank you!

Can you say if the initiative to rewrite gnome-shell is being taken forward or not?

https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4

#17 Leslie Satenstein on 06.25.19 at 20:26

My concern with eliminating xorg is purely with keyboard management. I run different language keyboard layouts and some layouts that have “deadkeys”, I have revised to “un-dead” them for other purposes.

I review of keyboard management and perhaps some design improvements and documentation would be appreciated.

#18 Tianyu on 06.26.19 at 00:39

I’m a heavy user of GNOME classic session. It’s nice to see that it will soon receive an overhaul, but what concerns me is that it drops the overview. GNOME classic should be a better GNOME 2 instead of a different GNOME 2 in that it should include all the goodies in vinilla GNOME 3.

GNOME classic needs polishing (like the ugly CSS overide of the window-list extension) and bug fixes instead of dropping features.

#19 bug on 06.26.19 at 08:04

in this case it would be nice if gnome fixed it’s compositor so it doesn’t make scrolling in firefox sluggish and slow or cause artefact chopping; add stutter to video playback or drop FPS

#20 W on 06.27.19 at 09:30

Great update! If only GNOME Software could get better too. It has so many bugs.

#21 uraeus on 06.28.19 at 12:20

Richard Hughes is working on it as we speak, his top focus currently is improving reliability.

#22 Andre Gompel on 06.28.19 at 11:07

I have used a Brother Scanner DS-720D for several years, it worked fine with the Brother Supplied Scanner Linux driver, until Fedora 29 X86_64.
Now it stopped working properly, I am not sure how.
dmesg seems “normal” but the apps like simple-scan or Libre-Office do not “see” the scanner.
This is a very popular scanner, so helping fix this issue, would be quite nice.
———————————————
Gnome Classic vs MATE
Unable to use and cope with GNOME 3, variations and lack of focus on usability, I have use the fork MATE for several years.
Now, when MATE is very usable (good) why exactly do we need GNOME_Classic ? Could you have a rationale explain?