 Okay, thank you everyone for being here. My name is Alberto Garcia, I'm going to talk about how SteamOS is contributing to the Linux ecosystem. So, first I would like to talk a bit about me. I work at Igalia, the company was founded in 2001, so we're actually coincidentally 22 years old today because this is our birthday. I'm a free software enthusiast already from since the 90s. I'm a devian developer for a long time. I'm currently working on SteamOS and in the past I was working on other projects like QMU, MMO, WebKit, et cetera. One of the reasons why I like free software and one of the reasons why I'm in this business is that I like how creating a new project contributes to other projects that are maybe related to it. So in the case of some of the projects that I work in the past and also this one, creating a new consumer device that is running Linux has an effect on the open source communities that the project is using for this hardware. So the one that I'm going to talk about today is the Steam Deck, the Steam Deck as you are, I'm sure you know, it's a handheld gaming computer released by Valve last year. It has a customer operating system called SteamOS. This is version three. There were two early versions of SteamOS but they were not for the Steam Deck and they have been discontinued. And I find the Steam Deck interesting because it's a successful consumer device with standard Linux components. So I want to explore how making a consumer device with standard Linux components has an effect on the components that the machine is using. So this is one that I want to talk about here. I'm going to mention a lot of contributions by different people. Many of them are from my colleagues from Eagalia. There's a list of the people that I mentioned here. But I want to add a disclaimer before going on. The list of examples that I'm going to have in this presentation is not complete. There has been contribution by a lot of people. I'm surely that I forgot some important project or some important contribution that I overlooked or I forgot it, so I apologize in advance. Also the contributions, although many of them are people from me or for people from my company, there are contributions by different people, companies and also for regular users who have contributed in the public user trackers. I try to give credit to everyone in the presentation but if I overlook someone or something, please apologize in advance. So let's have a closer look at the Steam Deck. The Steam Deck, as I said, is a gaming machine. This is the basic user interface that you get when you start it. This is the Steam Client browsing the Steam Store. From here you can buy games, you can browse the store, you can browse the discussions, you can play the games, et cetera. So for the purpose of this presentation is maybe not the most interesting part. This is just the regular Steam Client running in full screen. But under the hood, this is running a Linux distribution and it's based on Arch Linux. It's actually a rather standard Linux distributions. It has a few customizations that we can see later. But overall it's a typical Linux distribution with a FHS-like layout. It has a new user space, it has system D, DBAS, all the user aspects. So it looks pretty much like your average Linux desktop distribution. And another thing that is interesting that is not so common in this kind of consumer device distribution Linux is that it's unlocked by default. The user has complete access to the OS, there's nothing hidden, there's nothing. From the beginning you can already have complete access to the OS. So the Steam Deck has two modes. One of them is the gaming modes, the one that I will have seen. From here you can do basically all the essentials. Apart from playing games and buying games, et cetera, you can configure the network, you can format your SD card, and you can do all the basic. So most users, they don't actually need to leave this mode. But in addition to the gaming mode, there's a second mode that is the desktop mode. And if this looks like a regular KDE Plasma session, it's because that's what it is exactly. So the desktop mode is a regular KDE Plasma desktop. You can use it to install anything with it. You can install a web browser, you can install your favorite tools, you can install even non-Steam games, the machine doesn't prevent you from installing games that you got somewhere else. Actually the Steam Client itself allows you to run games that are not from Steam. You can add it to the menu and launch them from there. So if you plug a keyboard and a mouse and a display, you can use it like a regular desktop computer. Another interesting thing is that this mode is not hidden again. It's not like the Android developer mode that you have to find a way to activate it. This is completely visible in the regular power menu next to the reboot. And anyone can use it. So going back to the main use case of the device. The main use case of the device is, of course, to play games on Linux. So there's a problem when we talk about this thing. Linux is a Linux-based operating system, but as you know most games, most Steam games are for Windows, most games in general are for Windows, and most will never get a Linux version because either the developers are not going to do it or because many of them are so old that are not going to be a data for this. So the solution for this is Proton. Proton is a tool to run Windows games on Linux. It was developed by, it's actually been developed by Valve. It was published in 2018. And it's a collection of different open source packages. There's many packages there, but the most important ones are Wine, which is the Windows compatibility layer. There's a couple of other projects that translate Direct3D calls from Windows into Vulkan. And then there's also just streaming on other libraries. As I said, this is one of the big important projects that the Steam OS is running and is actively developed. The main component of Proton is Wine. Wine is used to run Windows applications in Linux. Wine is not an emulator. The code runs directly on the CPU. There's no emulation going on. So it's basically an implementation of Windows APIs using what's available in Linux, either standard Linux APIs or other standards like Vulkan, et cetera. Wine is an open source project that is developed by the community, but the main driver is the company called Weaver, in partnership with Valve. Those are the two repositories. The first one is the official upstream Wine one, and then the other one is the one included in Proton. Proton, I mentioned that it includes several components. All of them are actually modified. They are tailored for the Steam OS, but they contribute the changes back to the upstream projects. So when we're implementing Windows APIs, there's two possible situations. One of them is that the APIs are similar. So in this case, the compatibility layer basically translates the Windows call into a Linux call, and then there's no problem. There's maybe a bit of overhead, but it works fine. But when that is not the case, Wine needs to implement the missing parts, and this can result in overhead, depending on the complexity, and this is not always solvable in this space. So one of the tasks that people have been doing is figure out what are the APIs that are more difficult to implement, the ones that have more impact in games, and trying to find if it's possible to add new features to Linux to fill in the missing gaps. I'm going to give a couple of examples. One of them is the Windows synchronization functions. Windows has this API called Wait for Multiple Objects that is used by many Windows games, but this doesn't have a direct equivalent in Linux. It was implemented using Futex, but Futex is restricted to a single object, and the Windows API, as the name suggests, can wait for multiple objects at the same time. So doing an implementation based on Futex is slow, and it can cause performance problems in heavily multi-threaded games. So the solution for this is to develop new APIs, stack the Futex API to add its functionality. This is this work was done by Andre Almeida. Futex is a fast user space locking syscall. It's used to build other primitives like semaphores and Mutex, et cetera. It's a very old API, and it has grown over the years, and it has become hard to use and hard to extend. It has a few limitations. One of the things that it can only wait for a single object, as I said before, and the other one is that it only supports 32-bit Mutex. It has more limitations, but these are two of the important ones. So when Andre went to talk to the Linux people to see what we can do about this, and they say, okay, we cannot really extend the API because the API is already too cluttered. There's several parameters that are overloaded depending on the function that you are using, and this is too messy, you cannot do this. So we should, how about you write a new Futex2 API where every functionality is separated into a different system call. So the first part was already done. It was matched in Linux 5.16, which is FutexWaveD, which is more or less the equivalent of the Windows API that we are trying to emulate. And then there's more work still in progress to add the rest of the more APIs to the Futex2. Another example, this is very well known in Windows traditionally file systems are case-insensitive. So you cannot have two names, two files that their names only differ by the case. Linux does not have a problem because Linux file names are just a stream of bytes, so as long as the bytes are different, there's no problem. So the problem is that, of course, Windows applications expect that a file with two files with the same name, just differing by the case are the same file. So if those files are stored in a Linux file system and the Windows program tries to open them and they are not found with the original name, the application will fail. The solution for this, the slow one is to implement this in one. So when you try to open a file, the file is not found with the name that is requested, then you had to go over the path and try to look, try to see if there's a file with the same name, just differing the case. This is, of course, quite slow. So the solution for this, the faster solution is to extend the XT4 file system to support for case sensitivity. This work was done by Gabriel Griezmann from our friends in Colabora. He was later added to the F2FS file system by Daniel Rosenberg, I think, for the Android operating system from North Rome. And there's many other contributions to the Linux kernel. For example, reliable user space spinlocks. Spinlocks are an efficient synchronization mechanism that is used a lot in the kernel, but it's very hard to implement reliably in user space. There is work going on to do this. There was a presentation this week, two days ago, I think, by Andrea Meida at this conference. Another one, the SteamOS uses the BatterFS file system. In BatterFS, every file system is uniquely identified by the file system ID. And this has a property that you cannot have two file systems with exactly the same ID. Well, you can actually have them, but you cannot mount them at the same time. But in a situation like what SteamOS does, we have an AB partitioning system that I'm going to talk about later. There can be situations where you can actually have the same file system twice and you need to mount both. This was not supported and this was failing. So, there was work by Jeremy Picolli, Michael Iframigalia to support this scenario. Another one is split-locked total handling. If you do an atomic operation on non-aligned memory, those are slow and they can use to cause a denial of service. So, in order to prevent this, the kernel slows them down so they cannot attack the system, basically. The problem is that many games are using this and they are not going to change because many are old games that are not going to be modified. So, the solution here was to add an up to the kernel to control this behavior. So, if the machine is trusted, you can disable this feature and the games can run normally. There's more kernel features by Jeremy. One of them is the refactor of panning on the fires. There's also a tool to collect data when there's a kernel crash so they can report what went wrong with the system so it can be debugged and corrected. And then many other improvements and bug fixes in the kernel that too many to list here. So, after the kernel, I will talk a bit about graphics. Of course, being a gaming machine, graphics is a very important part. One of the key components is RAVV. This is the Mesa Vulkan driver for AMD GPUs. It's developed by Valve and other contributors and it's the most popular driver because AMD driver because it's shipped with Mesa. It's open source and it comes with most distros and it's the one that most people are using. Related work is ACO, which is a shared compiler for AMD graphics. It was also developed by Valve and announced in 2019 and it reduces stuttering and increases FPS in games. Talking about Vulkan, another related work is Vulkan Video. Vulkan Video is a set of extensions for Vulkan for adding a hardware accelerated video in coding and decoding. This needs support in the graphics driver itself. We have work in the Mesa driver by Harjun Koo. But it also needs support in the applications or in the multimedia frameworks in this case. So I'm going to work to add support to G-Streamer. I think the H264 is already working and there's work to add more codecs. Color Linux, the DRM subsystem, exposes a small set of color properties. They have been proposed as to extend the API but none of them have succeeded so far. And in the case of AMD GPUs, they have additional color capabilities. So there's new work to add driver-specific color API for AMD drivers. This would allow, among other things, the ability to display content with high dynamic range. This is already supported in user space by the Game of Scope Compositor that I will talk about later. And it will be available in the upcoming SteamOS 3.5 which is actually now in preview so people can already test it. This is a work done by Melissa Wen, Joshua Aston and Harry Bendler. More work by Andrea Almeida, this is better handling of GPU resets. GPUs, as you know, are very complex and shaders are also very complex and can crash. So the kernel's job is to, when there's a problem, they have to report the problem to user space. The problem is that there's no standard API to do that. So the roadmap of this work is to standardize how DRM reports GPU hangs to user space, standardize how user space drivers deal with the hang and what compositors do after a reset. This work is, as I said, it's work in progress by Andrea. It was presented this year at the North American Open Source Summit. More work by Andrea is adding a synchronous space flipping to the atomic API in DRM. And then there's Game of Scope. Game of Scope, this is user space, user space project. This is a micro compositor for games. The idea is that this works with the case where a game tries to use a resolution that is different from the native resolution of the display. So instead of changing resolutions every time for every game, Game of Scope tricks the game into thinking that is running in the resolution that the game requested and then Game of Scope scales the content to fill the screen. So this way the games can request any resolution. They will think that they are using that resolution and the content will be displaying full screen without having to change the video mode every time. There's also another feature that is frame rate limiting. You can make the game reduce the frame rate. This can be used, for example, to reduce the battery usage. Game Scope is what runs the Steam Deck game UI, the one that I showed at the beginning. So that's why all games are running with this. And this is, as I said, this is a standalone project. This can be installed in a normal distro. It's actually available in, I think, in most of them and you can use it. I was trying to run GTK application and full screen and it just works. And apart from graphics and kernel, there's, of course, the general OS work. Part of this, a big part of this, is the regular work that is maintaining a distro. So it's making sure that all components work together that all versions, they interact with each other properly, working in the OS update system, working on the boot process, many other things. But there are some parts that are interesting and that are interesting for the community overall. This is the part that I'm working on. Steam OS, as I said, is Arch Linux with a customization layer on top. Almost all packages are unmodified. They come directly from March. They are not even revealed, so they are the same binaries. And the philosophy, the philosophy Arch Linux, in general, is to keep everything as close to upstream as possible. They try to not to apply downstream patches unless it's really necessary. And in the case of Steam OS, it's the same. Having a downstream fork of the packages is something that just adds more overhead and it's not interesting for anyone. When there's a problem or something needs to be fixed, it's fixed directly upstream to the original developer or to the Arch if it's appropriate. One difference between a regular Arch installation on Steam OS is that Steam OS is immutable. So the root file system is read-only. Steam OS has an A-B partitioning scheme and this means that there's two copies of the root file system. One of them is the active one, that is the one that you are using when you're using the device. And the other one is not active. So when you try to do an OS update, the OS is downloaded into the inactive partition. If everything goes fine, then the changes switch in the boot configuration and you boot into the other partition. So if the download is interrupted, there's no problem. You can still keep using the original version of the file system. And if you're rebooting to the new one and there's problems, there's some critical bug or something, you can still go back to the previous one. So the thing is that since users are not expected to use the package manager to touch the root file system, how do you install new software there? I mean, you can do that because you have full access to the operating system. So you can make the root file system read-write and install your things there. But after an OS update, they will be lost. So what's the way to install new software? Here, there's two types. One of them is, of course, Steam games. Those just install directly from the store so you don't need to stay and take care of everything. And the other one is the actual, the normal desktop apps. And those are installed, the recommended way to install them is using Flatpak. Flatpak is a technology that has been in the world for many years. It's quite stable now. And this idea of installing everything using Flatpak and having the root file system read-only is also using other distributions like Silver Blue or Endless OS. Flatpak is two things at the same time. It's an app framework for the new desktop, but it works as a packaging system, a way to distribute applications that are independent from the distribution. So the same application can be installed anywhere. And it's also a way to isolate applications from the host. It gives a layer of, it's a containerization tool that adds a layer of security that can be adjusted depending on the tool. And it also allows applications to be handled directly by their developers. In the case of a traditional Linux model, typically the AppStream developer publishes a source targetball and each distribution has to build a targetball and distribute the binaries. In the case of Flatpak, the developers themselves, they can directly produce their binaries and put them for everyone. Flatpak itself is a technology that you can create a repository where to put those applications, but the most common one, the one that is, let's say the official one of sorts, is FlatHub, which is a Linux app store. At the moment it has more than 2,000 applications available and it's the primary distribution channel for some applications. I mentioned here the example of bottles because they published a note a couple of years ago saying that asking people to please use the Flatpak application, the Flatpak version of bottles when running this application because that's the only supported one, I think along with the Arch one. Otherwise people will be using the build of bottles by some distribution that is maybe not using the right version of each library, so there will be errors and they are easier to, more difficult to debug. So as part of, since Flatpak is the primary tool to install applications in SteamOS, there's part of the work that is keeping Flatpak alive and correcting it and adding new features that is done by some of the SteamOS developers. But there's also an already interesting aspect of that and for this I'm using this meme that I saw the other day in Masterdom by Cassidy James from Endless and is that by making Flatpak the primary distribution channel for the desktop mode of SteamOS, application developers that want to publish applications for the Steam Deck, they are indirectly supporting the Linux desktop, so they are every application that people want to develop for the Steam Deck because it's the Steam Deck because it's a gaming device, not because they are necessarily interested in Linux, they are still indirectly supporting the Linux desktop and all the work that is going on to add new features, fix bugs, improvements, et cetera, is benefiting the Linux desktop overall. In Flatpak one of the key components, key concept is the portals. Since applications are isolated from the host, portals provide a way for applications to interact with the host. Portals are used by Flatpak but they are independent of Flatpak so they can be used by others. Portals, they define a set of deep-ass interfaces for things like opening files, taking screenshots, printing, opening the settings, et cetera. The portals themselves, they define APIs but then they are implemented by different backends that are specific to each desktop. So if you open a file you get the file picker from your desktop of choice. So there's the AD backend, the GTK backend, the WL routes backend, the Kino backend, et cetera. The problem is that of course there's a lot of different desktop environments. Some of them are custom ones and not all backends work in all desktop environments. Some of them they don't, they work maybe they don't look nicely because they don't integrate well with the desktop and some of them they don't work at all. So this can cause crashes, timeouts and other issues. The backend developers, they cannot possibly test in all desktop environments. So the situation here is that since many backends can be installed at the same time, how do you choose which one to use? The problem is that there's a way to select what portal backend you want to use but there's the existing mechanism is very limited and this affects the Steam Deck. The Steam Deck runs two graphical sessions, the gaming one and the desktop one and both of them may need at some points to use portals. So selecting their wide one or which ones to use and which one not to use is very important. So this was fixed this year by Emanuele Bassi. There's a new mechanism to configure portals and with this desktops can select, have a much more elaborate method to select which portals to use and which portals not to use. This was just added to the new version of free desktop portal when I think that was released I think last Sunday and it will be soon in all major districts. Apart from all the working portals there's also many boxes in different components of the OS and here's some examples with KDE we have been doing fixes in the Discover, the application to store software, also rate flap-related fixes and fixes related to external drives. I'll also be working in UDISCs which is the storage demo used to manage different devices. And many more, there's been also fixes in network managing, also pipewires, DL and many, many others by different people. So wrapping up, SteamOS as I said is a fairly standard Linux system so it's as close to your regular desktop as it gets. Has the philosophy to keep everything upstream so every improvement, every change that is made goes directly into the Linux DevTools that we all use. In order to make SteamOS like a successful gaming device there has been a lot of work to Linux kernel, to the graphics and to the desktop and that is pretty much everything is open source and can be used by all of us. And then for people who are not necessarily Linux users themselves, this brings a new way to bring those people closer to Linux. As I said, app developers now have an incentive to publish apps in Linux thanks to this even if they are not Linux users themselves. And with this, I finished the presentation. I would like to thank you for being here. If you like this kind of technologies and working on this kind of things I would like to let you know that we're hiring so this is our website. This is all. Thank you. Anyone have questions? I will be happy to answer. It's basically a snapshot of Arch Linux with some customizations on top. The customizations are basically the minimum necessary to integrate with the Steam client and with the two sessions, et cetera. So there's not, as I said, we keep them to the minimum. So the problem that affected, the question is whether the problems that affect Arch Linux will also affect this Steam OS. Yeah. Usually we don't have the same versions of the packages because Arch Linux is a rolling release and Steam OS takes a snapshot and stays with it for a while. Like Steam OS 3.5 has a certain set of packages and they are not updated unless there's a problem with them. Oh, it depends on the pace of the update. I think the 3.4 was released, don't remember, earlier this year and 3.5 is in preview now. So it depends. I don't think there's a, I'm not the one to talk about this. I don't think there's a fixed schedule. I think things are published when they are ready. So the question is if it's possible to route the root file system the same way that you do it with Android. You have complete access. You open a terminal, you can sudo into root and there's a script to make the Steam OS the root file system read write. It's provided by the system. It's like a support tool. You are not encouraged to do that because you are on your own. If you do that and you start to store things then you can break things, but people do it. People, they want to have, I don't know, the coops server to print things. They do it. Well, that's why I would like to mention the recommended way to install applications is Flap Pack is only for desktop applications, but there's also other tools to install applications that are more for terminal command line, et cetera, that I didn't cover here. But they are not officially supported yet, but they're people experimenting with containers and with nicks and things like that. So the question is if Arch is a running release every time there's a regression of a problem the Arch package is updated. But Steam OS takes a snapshot. So how do we do that? If there's, we detect that there's a problem with one of the packages. Well, if there's a problem with one of the packages it's really a problem that deserves an update when we update it downstream. If it's something that hasn't been fixed upstream yet then we send the fix there. We give the patch private and then on the next rebase, the patch is not necessary anymore. The rebase doesn't happen. The rebase happens regularly because there's sort of development. There's an update channel that is sort of like a nightly build. It's not called like that. That is a bit more hidden from the user, but users can actually download them. But it's on their own risk because they are basically not tested. So if you can lose your data. And those, in that channel the Arch is rebased every once in a while. So every time we feel like okay, we should rebase the system because we're having a bit of two older version of pipe wire or network manager. More questions? Yeah. So the question is wasn't Steam OS debian based before? Yes, the earlier version of Steam OS was debian based. The one for the Steam Deck is Steam OS 3 only and that one is based on Arch. That happened already several years ago. So the question is why did it change from debian to Arch? No, I don't know. As a debian user myself, suppose I was a little bit disappointed, but it's okay. I mean the nice thing about Arch is that, as I said, they try to be as close to upstream as possible. So everything that is fixed there, it goes upstream quickly. More questions? Yes? Boom! Yeah, I guess there's new features that are on the works, but I don't know how much I can take about those. If you check the change lock of the new 3.5 version that you will see are some of the new features. One of the things that are going to be new now is the ability to connect regular external USB drives. And we're having a bit of issues with those, like there's some rough edges that need to be dealt with, but that's everyday work. Yes? I'm sorry, can you repeat? I didn't get the part. How many downstream patches we have on the kernel? On the kernel actually, I don't know. I suspect more than in other packages, but I think now we are using the LTS version of the kernel if I'm not wrong. I think it was not the case for previous versions of SteamOS. It's the less stable one now. Okay, it's not LTS, the long term was, no, okay. Okay, so the question is if you go from one version of the, like, SteamOS has several channels, there's the stable channel, there's the beta channel, et cetera. If you go from one to the other, how do you keep compatibility, how do you manage that going back to a previous version doesn't break compatibility, et cetera. Okay, so the root file system is read-only and that's where all the packages are. There's another file system that is the var partition, that one is read-write and that's where the, there's basically an ATC overlay that is stored there and that's where your ATC changes are there, the state of some packages are there, et cetera. So as part of the update system that downloads a new system and switches to the new one, there's a tool that copies your configuration to the configuration of the other partition and there's some tweaking going on. Sometimes in the cases that we know that there's a feature that will not work with the other version of the system that we updated manually, or we updated automatically, sorry. This came, of course, this is not without challenges because there's a lot of possible packages that people can have, especially if people install their own software, you can have a lot of things in ATC and the good thing is that you can actually wipe the var partition, the system will reboot sort of in an original state, however, you still keep all your games, you still keep, I think, all the flat pack applications should work because those are stored in the home partition. So doing a reset of the var partition should remove those compatibility problems and should still leave you with a system where you still have your games. Okay, so if there's no more, I think we're done. Thank you. Thank you.