Felt it been to long since I did another Fedora Workstation update. We spend a lot of time trying to figure out how we can best spend our resources to produce the best desktop possible for our users, because even though Red Hat invests more into the Linux desktop than any other company by quite a margin, our resources are still far from limitless. So we have a continuous effort of asking ourselves if each of the areas we are investing in are the right ones that give our users the things they need the most, so below is a sampling of the things we are working on.
Improving integration of the NVidia binary driver
This has been ongoing for quite a while, but things have started to land now. Hans de Goede and Simone Caronni has been collaboring, building on the work by NVidia and Adam Jackson around glvnd. So if you set up Simones NVidia repository hosted on negativo17 you will be able to install the Nvidia driver without any conflicts with the Mesa stack and due to Hans work you should be fairly sure that even if the NVidia driver stops working with a given kernel update you will smoothly transition back to the open source Nouveau driver. I been testing it on my own Lenovo P70 system for the last week and it seems to work well under X. That said once you install the binary NVidia driver that is what your running on, which is of course not the behaviour you want from a hybrid graphics system. Fixing that last issue requires further collaboration between us and NVidia.
Related to this Adam Jackson is currently working on a project he calls glxmux. glxmux will allow you to have more than one GLX implementation on the system, so that you can switch between Mesa GLX for the Intel integrated graphics card and NVidia GLX for the binary driver. While we can make no promises we hope to have the framework in place for Fedora Workstation 27. Having that in place should allow us to create a solution where you only use the NVidia driver when you want the extra graphics power which will of course require significant work from Nvidia to enable it on their side so I can’t give a definite timeline for when all the puzzle pieces are in place. Just be assured we are working on it and talking regularly to NVidia about it. I will let you know here as soon as things come together.
On the Wayland side the Jonas Ådahl is working on putting the final touches on Hybrid Graphics support
Fleet Commander ready for take-off
Another major project we been working on for a long time in Fleet Commander. Fleet Commander is a tool to allow you to manage Fedora and RHEL desktops centrally. This is a tool targeted at for instance Universities or companies with tens, hundreds or thousands of workstation installation. It gives you a graphical browser based UI (accessible through Cockpit) to create configuration profiles and deploy across your organization. Currently it allows you to control anything that has a gsetting associated with it like enabling/disabling extensions and setting configuration settings in GTK+ and GNOME applications. It allows you to configure Network Manager settings so if your updating the company VPN or proxy settings you can easily push those changes out to all user in the organization. Or quickly migrate Evolution email settings to a new email server. The tool also allows you to control recommended applications in the Software Center and set bookmarks in Firefox. There is also support for controlling settings inside LibreOffice.
All this features can be set and controlled on either a user level or a group level or organization wide due to the close integration we have with FreeIPA suite of tools. The data is stored inside your organizations LDAP server alongside other user information so you don’t need to have the clients connect to a new service for this, and while it is not there in this initial release we will in the future also support Active Directory.
The initial release and Fleet Commander website will be out alongside Fedora Workstation 26.
PipeWire
I talked about PipeWire before, when it was still called Pinos, but the scope and ambition for the project has significantly changed since then. Last time when I spoke about it the goal was just to create something that could be considered a video equivalent of pulseaudio. Wim Taymans, who you might know co-created GStreamer and who has been a major PulseAudio contributor, has since expanded the scope and PipeWire now aims at unifying linux Audio and Video. The long term the goal is for PipeWire to not only provide handling of video streams, but also handle all kinds of audio. Due to this Wim has been spending a lot of time making sure PipeWire can handle audio in a way that not only address the PulseAudio usecases, but also the ones handled by Jack today. A big part of the motivation for this is that we want to make Fedora Workstation the best place to create content and we want the pro-audio crowd to be first class citizens of our desktop.
At the same time we don’t want to make this another painful subsystem transition so PipeWire so we will need to ensure that PulseAudio applications can still be run without modification.
We expect to start shipping PipeWire with Fedora Workstation 27, but at that point only have it handle video as we need this to both enable good video handling for Flatpak applications through a video portal, but also to provide an API for applications that want to do screen capture under Wayland, like web browser applications offering screen sharing. We will the bring the audio features onboard in subsequent releases as we also try to work with the Jack and PulseAudio communities to make this a joint effort. We are also working now on a proper website for PipeWire.
Red Hat developer integration
A feature we are quite excited about is the integration of support for the Red Hat developer account system into Fedora. This means that you should be able to create a Red Hat developer account through GNOME Online accounts and once you have that account set up you should be able to easily create Red Hat Enterprise Linux virtual machines or containers on your Fedora system. This is a crucial piece for the developer focus that we want the workstation to have and one that we think will make a lot of developers life easier. We where originally hoping to have this ready for Fedora Workstaton 26, but atm it looks more likely to hit Fedora Workstation 27, but we will keep you up to date as this progresses.
Fractional scaling for HiDPI systems
Fedora Workstation has been leading the charge in supporting HiDPI on Linux and we hope to build on that with the current work to enable fractional scaling support. Since we introduced HiDPI support we have been improving it step by step, for instance last year we introduced support for dealing with different DPI levels per monitor for Wayland applications. The fractional scaling work will take this a step further. The biggest problem it will resolve is that for certain monitor sizes the current scaling options either left things to small or to big. With the fractional scaling support we will introduce intermediate steps, so that you can scale your interface 1.5x times instead of having to go all the way to 2. The set of technologies we are developing for handling fractional scaling should also allow us to provide better scaling for XWayland applications as it provides us with methods for scaling that doesn’t need direct support from the windowing system or toolkit.
GNOME Shell performance
Carlos Garnacho has been doing some great work recently improving the general performance of GNOME Shell. This comes on top of his earlier performance work that was very well received. How fast/slow GNOME shell is often a subjective thing, but reducing overhead where we can is never a bad thing.
Flatpak building
Owen Taylor has been working hard on putting the pieces in place for start large scale Flatpak building in Fedora. You might see a couple of test flatpaks appear in a Fedora Workstation 26 timeframe, but the goal is to have a huge Flatpak catalog ready in time for Fedora Workstation 27. Essentially what we are doing is making it very simple for a Fedora maintainer to build a Flatpak of the application they maintain through the Fedora package building infrastructure and push that Flatpak into a central Flatpak registry. And while of course this is mainly meant to be to the benefit of Fedora users there is of course nothing stopping other distributions from offering these Flatpak packaged applications to their users also.
Atomic Workstation
Another effort that is marching forward is what we call Atomic Workstation. The idea here is to have an immutable OS image kinda like what you see on for instance Android devices. The advantage to this is that the core of the operating system gets tested and deployed as a unit and the chance of users ending with broken systems decrease significantly as we don’t need to rely on packages getting applied in the correct order or scripts executing as expected on each individual workstation out there. This effort is largely based on the Project Atomic effort, and the end goal here is to have a image based OS install and Flatpak based applications on top of it. If you are very adventerous and/or want to help out with this effort you can get the ISO image installer for Atomic Workstation here.
Firmware handling
Our Linux Firmware project is still going strong with new features being added and new vendors signing on. As Richard Hughes recently blogged about the latest vendor joining the effort is Logitech who now will upload their firmware into the service so that you can keep your Logitech peripherals updated through it. It is worthwhile pointing out here how we worked with Logitech to make this happen, with Richard working on the special tooling needed and thus reducing the threshold for Logitech to start offering their firmware through the service. We have other vendors we are having similar discussions and collaborations with so expect to see more. At this point I tend to recommend people get a Dell to run Linux, due to their strong support for efforts such as the Linux Firmware Service, but other major vendors are in the final stages of testing so expect more major vendors starting to push firmware updates soon.
High Dynamic Range
The next big thing in the display technology field is HDR (High Dynamic Range). HDR allows for deeper more vibrant colours and is a feature seen on a lot of new TVs these days and game consoles like the Playstation 4 support it. Computer monitors are appearing on the market too now with this feature, for instance the Dell UP2718Q. We want to ensure Fedora and Linux is a leader here, for the benefit of video and graphics artists using Fedora and Red Hat Enterprise Linux. We are thus kicking of an effort to make sure this technology mature as quickly as possible and be fully supported. We are not the only ones interested in this so we will hopefully be collaborating with our friends at Intel, AMD and NVidia on this. We hope to have the first monitors delivered to our office within a few weeks.
Codecs
While playback these days have moved to streaming where locally installed codecs are of less importance for the consumption usecase, having a wide selection of codecs available is still important for media editing and creation usecases, so we want you to be able to load a varity of old media files into you video editor for instance. Luckily we are at a crossroads now where a lot of widely used codecs have their essential patents expire (mp3, ac3 and more) while at the same time the industry focus seems to have moved to royalty free codec development moving forward (Opus, VP9, Alliance for Open Media). We have been spending a lot of time with the Red Hat legal team trying to clear these codecs, which resulted in mp3 and AC3 now shipping in Fedora Workstation. We have more codecs on the way though, so this effort is in no way over. My goal is that over the course of this year the situation of software patents being a huge issue when dealing with audio and video codecs on Linux will be considered a thing of the past. I would like to thank the Red Hat legal team for their support on this issue as they have had to spend significant time on it as a big company like Red Hat do need to do our own due diligence when it comes to these things, we can’t just trust statements from random people on the internet that these codecs are now free to ship.
Battery life
We been looking at this for a while now and hope to be able to start sharing information with users on which laptops they should get that will have good battery life under Fedora. Christian Kellner is now our point man on battery life and he has taken up improving the Battery Bench tool that Owen Taylor wrote some time ago.
QtGNOME platform
We will have a new version of the QtGNOME platform in Fedora 26. For those of you who have not yet heard of this effort it is a set of themes and tools to ensure that Qt applications runs without any major issues under GNOME 3. With the new version the theming expands to include the accessibility and dark themes in Adwaita, meaning that if you switch to one of these themes under GNOME shell it will also switch your Qt applications over. We are also making sure things like cut’n paste and drag and drop works well. The version in Fedora Workstation 26 is a big step forward for this effort and should hopefully make Qt applications be first class citizens under your Fedora Workstation desktop.
Wayland polish
Ever since we switched the default to Wayland we have kept the pressure up and kept fixing bugs and finding solutions for corner cases. The result should be an improved Wayland experience in Fedora Workstation 26. A big thanks for Olivier Fourdan, Jonas Ådahl and the whole Wayland community for their continued efforts here. Two major items Jonas is working on for instance is improving fractional scaling, to ensure that your desktop scales to an optimal size on HiDPI displays of various sizes. What we currently have is limited to 1x or 2x, which is either to small or to big for some screens, but with this work you can also do 1.5x scaling. He is also working on preparing an API that will allow screen sharing under Wayland, so that for instance sharing your slides over video conferencing can work under Wayland.
Great post, seem a lot of good thinks to Fedora project in a near future, the mos insteresting to me is about the nvidia driver because i have a optimus card (a mix between intel and nvidia), btw you need a sharing to social networks tool on your blog, thanks!
Does PipeWire support RAOP2? Finally, after many years of development, PulseAudio will be shipping with RAOP and RAOP2 support in the main tree. For those of us who own AirPlay compatible hardware, this is a great feature.
Today the audio features of PipeWire are quite limited, mostly core functionality to prove that the architecture can handle all audio usecases including pro-audio in terms of latency etc. As we move forward we will look into how we handle PulseAudio and all its functionality, could be we make PulseAudio output into Pipewire as an intermediate step to give ourselves more time to move PA functionality like this over.
Friends don’t let friends buy Apple.
Thank you for the update, very nice to see what is happening in the background. Keep up that good work!
One question about Wayland though – will we be able to run Wayland on regular desktop computers with a Nvidia card while making use of the proprietary driver please?
Lots of people on the internet forums state they’re running Wayland with proprietary Nvidia drivers on Fedora already but to me it’s still sort of Utopia, no matter what settings I try. I also haven’t seen any official news about it(i assume it would be quite exciting news and I wouldn’t miss it…) Thanks again!
Jonas enabled it and even got patches from NVidia to improve it. Running Wayland on the proprietary driver is still not enabled by default though due to needing the glxmux stuff I talked about to make XWayland work on top of Wayland on top of the binary NVidia driver. I will see if we can get some instructions posted for people who want to test it out.
To have some instructions for how to enable/test it would be really, really great!
Yes, instruction to enable wayland please!
gnome-shell is JavaScript dogsh1t. Should have been written in a real language from the start and then there wouldn’t be any performance issues.
If JavaScript was a good choice is a topic of debate for sure, although the reasons for choosing it seemed compelling at the time. There has been some lose discussions about rewriting the Shell and Mutter, partly to get a cleaner break as we move from X to Wayland. However in addition to being a big job it would break peoples extensions and people seem to really love their extensions these days, so in the end we have decided against going that route.
I was hoping the shell would be rewritten, using GTK4. At least for the users it is a whole theme integrating the shell with the rest of the applications and although it is currently achieved, there are things that don’t make sense as not being able to use the same types of GTK applications in the shell without rewriting a CSS file.
GTK+ is a client toolkit, and cannot be used to write a compositor/display server.
I know, I’m not against GJS, but the shell is a Mutter plugin and I basically use a totally different toolkit. It feels and looks different.
For example a different desktop but that is very consistent in its interface (panel, launcher, dock) is Pantheon and its window composer is based on libmutter. I love GNOME, but some things feel very strange (like having to open the system menu twice to turn the Wifi on/off instead of having a switch)
What do you mean by:
* “whole theme integrating the shell”
* “not being able to use the same types of GTK applications in the shell”
GNOME Shell is a compositing window manager on X, and the display server on Wayland. That means that you can’t use GTK+’s existing X and Wayland backends to draw the shell’s chrome.
Secondly, the needs of a compositor / window manager / display server are often at odds with those of an application. That’s why clutter-for-gnome-shell-mutter had to decoupled from clutter-for-applications.
I see that I wrote a word incorrectly. You can explain to me what the implementation is about but that is not the point, but the decision that led to that and how some users like me feel.
People have already gotten used to it, but it’s still a special case to have one theme for the shell and another for applications to have consistency. On the other hand I was referring to “typographies”. If a user wants to use a particular font with a certain size will only work well for applications. To see a change in the shell it is necessary to edit the CSS file to achieve it (nothing pleasant for the end user).
A “real language” won’t get you extensions in the same shape and form. So be careful what you ask for. ;)
JavaScript is not the performance bottleneck in GNOME Shell, so you should probably inform yourself a bit more.
bugzilla.gnome.org/show_bug.cgi?id=745032 – maybe clarify that here as well, from reading the bug it looks as though javascript engine is blocking the compositor. Horrible situation to be in, either do rewrite and get flack over dropping support for extensions or spend time trying to figure out how to work around it in backwards compatible way and get flack about using javascript.
Flack either way really.
I think a rewrite is best approach tbh, but understand the reluctance now. Create new api with experiments like wayland security modules taken into account. Maybe a Gnome Goal to be able to distribute a sandboxed extension with your sandboxed flatpak app.
Even if the JavaScript engine ran the GC in a separate thread, all GObject instances would have to be destroyed in the same thread that created them — largely the main thread. GObject has the same limitations in terms of thread safety as JavaScript.
Additionally, if something *really* requires a separate thread to perform (i.e. nothing that deals with anything GUI-related) then we can simply create an helper function in C, since the Shell is really a C program running an embedded JS script.
So, no: even when going into “the GC runs in the main thread” behaviour, JavaScript is not the performance bottleneck in GNOME Shell. Before we get to that point, we need to solve things like loading assets from disk, like icons, and then shoving them onto the GPU in a way that is not blocking; or optimising the scene graph for rendering without too many CPU-side work; or using modern GL/Vulkan to optimise the GPU usage and state transitions.
Of course: that stuff is harder than shouting “JavaScript is dog****”, so people do the latter.
https://negativo17.org/nvidia-driver
“First of all, Wayland support in the drivers require a patched Wayland which has been refused upstream”
Does this mean Nvidia binary driver still won’t work with gnome wayland?
Not sure what that quote refers to, it should work afaik.
Could someone provide testing instructions for the fractional HiDPI support in Fedora 26? I’d certainly be willing to test it.
Fedora 26 doesn’t have fractional HiDpi support at the moment. :)
Here are some details:
https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html
Nothing about remote desktop under wayland?
Actually Pipewire is meant to solve that usecase too :) Forgot to mention it, sorry.
Nice! Great work, gnome + fedora every time are much better. I think an area to improve would be the fedora development cycle to have better synchronization with GNOME.
About patents, it would be useful to know if gnome can use exFAT or at least be able to add it to the interface when formatting a device in Nautilus.
Fedora already tries hard to align with the GNOME cycle. However, we need to do significant QA to ensure the quality of a Fedora release, and that often leads to delays.
People are encouraged to help out, though. New contributors to both Fedora and GNOME are always welcome.
Of course, I’m not a developer but I helped by donating some money to some foundations. Fedora is not the case, but I feel it has a lot of support.
For my part my interest is more focused on GNOME improvements. I used Fedora a lot of time but I currently use Solus OS.
Thanks for donating. Much appreciated.
By the way, when I said “help out” I didn’t necessarily mean money or development effort. Helping out with QA is also a welcome contribution.
We’ll continue to push for improved alignment between the GNOME and Fedora release cycles. I know Fedora 26 is unfortunately quite significantly delayed at this point, but with the exception of F26 I think we had been doing fairly good recently. It looks like we’re on track for Fedora 27 to be released just one month after GNOME 3.26, so that’s good too. I’m fairly confident that we’ll be able to keep the fall releases tracking closely with GNOME. There are some competing pressures (specifically glibc and GCC updates) that have pushed back the spring releases two years in a row now. I agree that we need to improve on this next year.
It will help that we’ve also eliminated alpha releases beginning with the Fedora 27 cycle, removing one of the three points of schedule slippage. I’m not sure what the impact of this will be, but I think it’s a step in the right direction since the alphas were never really particularly useful, and quality of alphas is not particularly important anyway. I’ve often felt like there’s little value in delaying final releases for alpha bugs, and now that won’t happen anymore.
Lastly, as Debarshi says, there is QA value in releasing a bit later. Normally GNOME is in pretty good shape after a stable release and we only have one or two blockers to fix before a Fedora release, with most other blocker bugs being elsewhere in the OS. But this cycle, GNOME 3.24 is unfortunately currently suffering from more blocker issues than usual, mostly crashes and memory corruption issues related to the important gjs upgrade. Red Hat and Endless developers are currently working on fixing these and there’s been some progress, but it’s still possible the release could be further delayed if this is not sorted out soon. We’d rather release a good product late than release a bad product on time. So while the delays this cycle are unfortunate, at least you can be confident that F26 is not going to be released before these regressions are solved, unlike other comparable Linux operating systems.
Thanks for the interesting update Christian. Fedora never disappoints when it comes to cool new features. Kudos to you and all the people involved in making that happen. I look forward to F26. Keep up the great work!
So where does Jack and it’s developers fit in with pipewire?
Right now it’s pretty much essential plumbing for linux audio and I don’t just mean because of the low latency.
It’s the glue by which the very rich ecosystem of linux audio applications use to talk to each other.
http://jackaudio.org/applications/
Expecting all of that to be rewritten/rewired seems like a large burden on the already small audio community?
pulseaudio-module-jack solution currently works really well for me.
Wim has already been reaching out and started talking with people, but just as with the PulseAudio side this would be a long term effort where we figure out the details and get people onboard with the plans.
My usecase with fractional scaling on ubuntu is using scaling < 1.
I have a rather large 1080p monitor and thus instead of getting a huge UI I can shrink text/apps and get a much better experience. (And it works rather nicely on unity).
I know this is a rather tiny corner case but I'd ask that it be considered if it's not a lot of extra burden on the fractional scaling work.
http://blog.3v1n0.net/informatica/linux/gnome-fractional-and-multi-monitor-scaling-hackfest-the-report/ says that fractional scaling <1 is being considered.
hello, can you please not envent a bicycle and not rewrite pulseaudio, which is a mature product nowadays.
The idea of handling videos centrally is great, it will help to e.g. make virtual webcams, but why to mess it up with pulseaudio?
If you’ve ever tried to do low latency pro audio on Linux, Pipewire will be exciting news. The compatibility issues between Jack and ALSA/Pulse have been a sore spot for several years, and made it very difficult to recommend Linux as a platform for serious audio recording. This is despite several high quality Free applications for doing so.
We are experiencing serious performance lag with Gnome 3. Comparing to another feature-rich desktop – KDE Plasma, Gnome 3 falls behind greatly in visible speed experience.In addition, Gnome 3 is more remarkable in RAM and CPU consumption which is nearly 50% more than KDE plasma. Fedora workstation requires 2G RAM for a foundamental fluent desktop experience while arch base + gnome3 base will work the same with only 1G. However，512M will be almost enough for arch base + KDE plasma base.
I use Fedora workstation extensively at work due to close integration with both CentOS/RHEL and management infrastructure. Great updates as always.
Can talk more about HDR support..
*can we expect some working support for HDR TV this year from Nvidia closed drivers and AMD Mesa RadeonSI or AMDGPU Pro drivers?
*will HDR support be for OpenGL and Vulkan in 2017?
It is a bit early to make any promises here. Not only does HDR support require fixes throughout the stack and it is thus complex, but there are of course dependencies on work from the graphics card vendors themselves here too. But the ambition is to have HDR support with OpenGL and Vulkan this year, but to early to say if we can pull that off or not.