 Welcome to the BSC Dev Room. So, let's talk about FreeBC Graphics Tech. Yep. Hello. I'm going to start with a question. How many in here are FreeBC's users? That's, well, two-thirds of the room maybe. How many of you use FreeBC on a desktop or laptop? Or in some sort of graphical environment? Well, most of the people who raise their hands for FreeBC users actually use FreeBC on a desktop or laptop. That's great. So, today I'm going to talk a bit about the Graphics Tech on FreeBC and I'll talk a bit about the team behind it and what we're doing, what we have in FreeBC today and what's coming up next. And the person doing the talking, my name is Nicholas Seising. I'm Seising at FreeBC.org, so you can reach me there. And I've been part of the... I'm an IT consultant in Stockholm, Sweden and I've been working on FreeBC for over 10 years and I've been a Committer since 2012 and for most of my work on FreeBC has been on the Graphics Tech. So, the purpose of this talk is to present what we're doing and a bit about the team and who we are. Before I start, I'd also like to thank my employer B3Init because they make it possible for me to do a bit of this on paytime and they also made it possible for me to get here. So, thank you to B3Init. So, starting with the agenda. As I said, I will talk a bit, present the team. Then I will walk through the actual Graphics Tech what's in FreeBC today? What's the Graphics Tech in FreeBC? I will talk a bit about the challenges we face. What's making this job, what's making this perhaps less than trivial? And if there is some time, I will see if I can find my crystal ball and gaze a bit into the future and see what I think is the things we need to do to make FreeBC a better desktop platform. So, let's start with the Graphics team. So, this is quite a small team. It's me. It's two guys named Johannes, both of them, to confuse things. We get some help from Warner Rush on Core to do some Lia Song and things like that. There's a guy called Pete that's helping out, keeping some things up to date, writing some documentation, things like that. So, we have a fairly small team. Then Manu, who is not in the room, is here today somewhere. He's working on the ARM platform and Graphics on ARM and we get some help from Matt Macy, who's been involved before and he's also helping out with the PowerPC64 platform. So, the workflow, we use GitHub. We have a GitHub team, I think it's called, in GitHub terminology, where we have our development repositories, so we have a fork of the FreeBC ports tree where we can have experimental updates and things like that. We have a copy of the FreeBC base tree for things that need to go into the base system eventually to support driver updates and things like that. This is where most development takes place and then we move it into the official FreeBC repositories. You can find the team here on GitHub. It's github.com slash FreeBC desktop. So, you can find all the things there. This is also where you find sources for our ports of the drivers as well as some library shims for some Linux compatibility. So, all the sources there and you can open issues there if you don't want to use FreeBC, or you can make pull requests there. So, what is the team maintaining? So, it's about 300 ports. It doesn't sound like very much. I did an experiment once and I broke one of them and almost 30% of the FreeBC ports tree stopped compiling. So, even if it's not that many ports, you'd rather not break them. If you break the wrong one, then you're in a bit of a mess. There's also some ports infrastructure. This makes it possible to easily depend on FreeBC X11 libraries using use underscore Xorg if you're familiar with ports. This also uses GL, things like that. And then we have the kernel drivers. That's also our domain, so to speak. So, the stack on FreeBC, as I said, we have the core libraries. This is all in ports. We have the core libraries, your lib X11, your lib XCB, your lib whatever basically. The X servers is, of course, something we're responsible for. We also maintain the FreeBC support of Wayland. And a whole bunch of X11 applications, small support facilities like XRDB, X font select, X font cell, I think it's named, things like that. The small applications that used to be distributed together with the X server when it was a big monolithic thing and these days are separate packages. Window managers and desktop environments and things like that like KDE and GNOME, those are maintained by other teams. That's not what we maintain. That would be just too much. So we try to make a foundation of FreeBC graphics that you can build on and you can maintain your graphics driver or you can maintain your desktop environments and window managers on top of that. So let's look into the FreeBC graphics stack. And I will do this. I will start at the bottom with the drivers and then I will work my way through the graphics stacks all the way up to the user interface you're seeing right now. So for drivers, we have a legacy driver in base unless someone did something tonight. We still have a legacy driver in base. And this driver, it's a complete port of the Linux KMS graphics drivers that was done in 2010, 11, 12, 13, something like that. So they've taken the driver, they've made a complete port. This was done by Kostik Beliso where he basically changed all the things that was Linux specific in the driver and used FreeBC kernel interfaces for that. This port has then been updated a bit along the way and in terms of hardware compatibility, it's somewhere around Linux 3.8. This driver is planned for removal in FreeBC 13. It's already disabled in the default build and it will be replaced by DRAM legacy Kmod, which is a port of the driver. It's basically we're taking the source that's in the FreeBC base system and we've made a port out of it. We have had to made some small adjustments to make it work as support and that's it. So it's basically what's in the base tree today. And the reason we're removing the DRAM legacy drivers is that some of them are conflicting with the new drivers that we are developing. So they attach to the same hardware because they support the same hardware and that makes it so that it's hard to figure out which driver is being used or using the old driver or the new driver and that makes documentation hard. It makes support hard. So that's why we're removing the driver. And as I said, it's planned for removal in FreeBC 13. I don't think it's happened yet but it will happen soon trademark. So the new drivers or DRAM next or I think it has similar names or it has a multitude of names. These new drivers, they exist in port and they will only exist in ports as kernel modules in ports and of course packages, they will never end up in FreeBC base. Part of it is because of licensing issues. Part of it is since they're based on Linux kernel code and the Linux release cycle is very different from FreeBC, it's very hard to maintain the driver entry. These drivers, they use the Linux KPI or LKPI and LKPI and FreeBC is a kernel module that implements or translates Linux kernel APIs to FreeBC kernel primitives and APIs. And the LKPI was first invented by, I think it was developed by Mellanox or something like that for their fiber channel drivers, something like that. And we build on that infrastructure, we have added things to the KPI to make graphics drivers work. And this makes it so that we can take, well in theory at least, so that we can take code from the Linux kernel, the graphics driver from the Linux kernel with very, very few changes, we can take them and we can run them on FreeBC. In practice, Linux really likes to change their KPIs, so you have to update the Linux KPI while you're doing this. So there will be some changes forever at least. As you will see, this makes it possible for us to keep fairly current with what's going on in Linux, in terms of hardware support. As I said before, the legacy driver, it's still on Linux 3.8, it was very hard to maintain, it was very hard to update since you had to go through the drivers and change Linux specific bits into FreeBC specific bits. These days, this is primarily done on AMD64, that's our primary target because that's basically what everyone is using. So our primary target is AMD64 or x86 underscore 64 in Linux land. Secondary targets are E386 for people with old hardware and PowerPC64. I would also say that ARM is a secondary target and ARM is a bit special, so there is some development to get better graphics on ARM as well. It's done by Manu. And this is also the reason why we made a legacy port or a port of the legacy driver because the legacy driver is working on 8V86 and perhaps other architectures as well. We have in FreeBC 12 stable, I'm not sure about the release. We have support for E386 for the new graphics drivers, but it's kind of an alpha-beta stage and it might be a bit unstable. PowerPC64 support is being worked on. It's done by Matt Macy and others and I think it's kind of working, but it's not stable mature yet, but hopefully it will be. So the new graphics drivers in ports. We have multiple versions because different versions of FreeBC have different support in the LKPI for different drivers. That's basically it. In short, use the meta port. That will select hopefully the correct driver for your version of FreeBC and your FreeBC architecture. Drivers, they are available in FreeBC 11.2 and 12.0. Earlier releases will not work because there's not enough support in the Linux KPI. They're not supported anyway. Perhaps they've run out of support, yeah. Okay. 10.0 or 10.4. Okay, so these are the only supported drivers or supported versions of FreeBC. So moving on upwards the stack. Drivers, moving upwards through the stack. We have the libraries. The biggest library is probably the OpenGL library called Mesa. This library has fairly quick development and it's important to keep it working because if you break it, things like that, things stop working. It's used for very many ports. You also have the libdrem library, which is a library to access the hardware in a device-independent manner. So it's a translation library between the user and the kernel driver, so to speak. And then we have the regular Xorg libraries. As I talked about, this is the Libx11 and LibxB and, well, hundreds of others, I don't know, 50 others. Then on top of that, this is the foundation on which you can build a graphical environment. On top of that, we have the Xserver. And the Xserver in FreeBSD is out of date. It's current with 1.18.4. This is an area where we need to do more work. We have had to get the drivers and things working upwards the stack, and then this is the next step. The Xorg server, it uses two ways. It needs to communicate with the graphics hardware some way, somehow. There's two methods of doing this. So you have the DDX drivers, as they're called. These are the DDX stands for device-dependent execution, I think. These are the old XF86 video intel, for instance, or XF86 input mouse, things like that. Those are still around. Upstreams seem to be heading towards something that's called mode setting or kernel mode setting, and using that to talk to the kernel directly to fiddle with graphics. And mode setting is part of the Xserver itself. So right now, we have a choice between the two. It seems like Upstream is heading towards the mode setting in the mode setting direction, but at least AMD is keeping their DDX driver up to date. There's new updates for it. Intel, well, there's co-developments. This hasn't been released in quite some time. Next step, Wayland. It's the new, not Xserver, but the new way of doing graphics on Unix and Linux systems. I believe this has been the focus Upstream for quite some time. And this is where most of the new development happens. The old Xserver is, you know, I guess a bit of a maintenance mode. Previously recently gained support in the default package bill 4 for Wayland. And this means that everything in the ports tree and the package system are built with Wayland support enabled by default. For instance, the GTK toolkit is built with Wayland support enabled. Same goes for Qt and other toolkits that build on graphics. The Mesa package is built with Wayland support out of the box. This makes it possible, makes it much easier to try the Wayland. And the Wayland library implementation itself is mostly up to date. We also have Sway, which is an i3 clone available if you want to try Wayland. However, Wayland, to use Wayland, you need the FDEV support in the kernel. And FDEV is the new Linux way or newer Linux way of handling input drivers or input devices. And this support is in the kernel for at least freebies to 12 and current. I think the code is also in freebies to 11. However, it's not in the default kernel configuration on the releases. So if you're running freebies to 11.2 or 12.0 you need to have a custom kernel. In freebies to stable and freebies to current, this FDEV is enabled by default. Unfortunately, there were some fixes that needed to go in that were not in time for the freebies to 12.0 release. So to run this, you need either a more current version of freebies to or a custom kernel. The whole Wayland stack, it needs more testing. It's fairly new. It's not very much used, as I said, until around Christmas. I think you needed to compile your port tree specifically with it enabled. So you needed to build your own packages and stuff like that. Now you can get it by just installing it. And that makes it much easier to try it. So, how do I try this then? I've talked a bunch about X-ray and X-server and I've said that you should try Wayland. How do I get started with this? I mean, most of you in here are already running it. But for those of you who might want to get started to try it out to help out testing, it's fairly simple to be honest. At least it should be fairly simple. You need a freebies to installation. Quite obvious. And if you want to release, I'd recommend freebies to 12.0. If you want even better support with FDEV enabled by default, things like that, freebies to stable or freebies to current is available. Then you simply install Xorg, like this. You install your favorite window manager or desktop environment. So, PQA install GNOME or XFC. We have a whole bunch of them. Window maker, i3, VM, things like that. Lumina. Of course, we have Lumina. Then you need the driver. As I said, yes, PQA installed there and came out. This will select the right driver for you. A bit of a caveat. If you're not running a release version of FreeBSD, and if you're running a custom kernel, and especially if you're running current, instead of installing the package of the driver, build it from ports. It needs to be in sync with your kernel, because kernel interfaces might change and things like that, and data structures might move around. So, if you're not using a release, you need to build it from ports. It's fairly quick to build. It's located in Graphics-DRM, Kmod, and you will build it for your kernel, together with the firmware needed to use the graphics card. Then, you start X. You might need to fit a little bit. If you want your favorite window manager, you might need to set up XInitRC. The default is TWM, as has been the default since forever. This should work. If you're running on Intel hardware, I think most of the bugs are sorted out. You should not need a configuration for Xorg. You should find the hardware and drivers you need to start. If you're running on AMD hardware, you might need to fit a little bit until you get the driver to work. There is currently a conflict between the EFI frame buffer, so if you're using UEFI, you might need to disable console before the driver loads. There is more documentation about this on our Viki, for which I have a link later. In general, to get a graphical environment on FreeBSD, this is what you need. It sounds very simple. What are not so simple in this? Testing for one is not very simple. It turns out it's very hard to emulate graphics cards, graphics hardware, which means you need to have the actual hardware laying around. There is quite a lot of different graphics hardware, so you can't cover all bases. This means that we need help with testing from, I'd say the public, but from users, we need help. We need to help with testing. We need help to cover our bases. This also means that sometimes it's very hard to reproduce problems. For instance, I have a friend who had a freeze when he loaded a graphics driver, and I was like, well, it works on my computers. It works on the rest of the development team's computers. We have no idea why it's not working on my friend's computer. So some things like that are a real challenge, and this comes down to all graphics hardware being alike and all graphics hardware being different, it seems. Another challenge which is perhaps easier to solve is build times. It takes time to build a graphic stack. I do most of my development on my laptop. I have a fairly modern laptop. It still takes quite some time to build, which makes build test cycles fairly slow, and I hope to be able to set up some way where we can commit things to GitHub and get the package in the other end. And doing that would also make it possible to an easier way give testers access to development packages so they just can install on their laptop or desktop and test. The third challenge is developer bandwidth. We're a small team. Upstream moves fast. Sometimes life and work happens, and this means that sometimes updates have to wait a bit. This also goes again with testing. Sometimes we don't have time to test everything. In the end you have to make the jump, but sometimes it's better to be a bit safe and perhaps stick around with an older version that's known to work instead of updating to something that's not at least a bit tested. In the future, this is me getting into the crystal ball, but I think what's going to happen in the future we never know. First off, input devices. I've talked a little bit about this, about FDV, about blip input, things like that. This is an area where Linux is changing how they're doing it, and we kind of need to tag along. I would guess that we need to improve our input device handling and somehow have a translation layer so that it looks, at least for X server and for WLAN, looks a bit Linux-y. Today it's the FDV kernel code I talked about earlier, but I think this is an area where we need to improve both in regards to what we support and also become better at automatically configure things. Mouching keyboard works, but touch screen, track pads, for instance, wake-up tablets, things like that. We also have to do something about theorem legacy. As I said, it's going away from freebies database, at least in 13, but then should it live on forever in freebies ports at some point when the new code is stable enough or when I386 is not as much of a thing, it probably needs to go. The next thing that needs to happen is outload. Today you install the kernel driver, you need to load it, and this needs to happen automatically. It does sometimes, it's not always. And previously the DDX drivers I talked about earlier did the loading of the kernel module. That's not happening anymore, so you kind of have to do it from your startup. I would like to see this happen automatically. There is a facility in Freebies D to handle this, but the graphics drivers aren't using it yet. And since the graphics drivers come from Linux, they look a bit different than native Freebies drivers, so this is something we have to look into. We also have to look into support for more architectures. I mentioned ARM and PP64, PowerPC64 as the most important ones. Support and work is ongoing. We probably have to support I386 for at least some time more, at least in 2038 or something. It was at least one person who got that joke. So, looking further into the future, and this is things that's needed to get Freebies D better as a desktop platform. We need to get a better way to manage our network on our desktop, or at least laptops, where we run them around and use them everywhere. So some sort of tool for this is probably needed. We need to become better at power management, and Wi-Fi support is always something that can improve. It's working pretty good today, but there's always some Broadcom chipset that doesn't work and things like that. So in summary, we talked a bit about the Freebies D graphic stack. I worked through it from kernel to what you see today, basically. We talked about the drivers and what we're doing there today. We talked about the libraries, the Xorg server. We talked a bit about Wayland, and we talked a bit about what I think we need to do this year and the years to come to keep Freebies D a viable desktop platform and to make it a better desktop platform. If you want to help out more resources, you can find our, as I said, we have our GitHub space where you can find us. We have a GitHub chat that integrates into GitHub where you can find us there. You can always email our main list, and we're also available on IRC, at least some of us. You can also talk to me, if you like. I know this has been fairly dry. I wouldn't say boring, but fairly dry. There's no demos or anything. In a way, this whole thing is a live demo. This whole presentation was made using Freebies D. It's done in open office on Freebies D. I'm running Freebies D. I'm running a fairly recent version of Freebies D. Thank you CFS. That makes it possible to upgrade, and then, oh, it broke, okay. Revert to the last snapshot. That was what I had today. Are there any questions? Oops, that was not meant to happen. Any questions? We have one minute for questions. I'm around here today, and I'm around here tomorrow. Let's start with the gentleman in blue. Currently, I don't know. As you've noticed, I haven't talked very much about NVIDIA drivers at all, because we used the binary blob from NVIDIA, so we're basically forced to do what NVIDIA does there, or forced, but we're using what NVIDIA provides. And I don't know if NVIDIA provides, I don't think NVIDIA, the NVIDIA driver provides the libraries needed today, but I haven't tried. Over there. Does that even work on Linux? Pardon? I don't know. I don't think optimal support is... Well, it should be doable if someone sits down and do it, but I think you have to pick either the Intel driver or the NVIDIA driver.