Collabora Blog

Well, a 5-year-old chip may not count as "recent" but the RK-3588 boot chain is "almost fully open-source" [1]. And it seems like it took a major amount of effort (from Collabora, others) to get it this far. I don't know of any equivalent or newer chips that are "more" open, but would love to hear if there are. [1] https://www.collabora.com/news-and-blog/blog/2024/02/21/almost-a-fully…

Why reinvent the wheels over and over again? Just port coreboot, or something similar to the likes of https://cwwk.net/ which have done the hardware part sufficiently. Or even better, organize to have some group/org paying them to port it to their HW. Or/and get https://bootlin.com / https://www.collabora.com involved, if they are disinterested, have them coordinate the effort. They should know how to do that, instead of wasting time with reverse engineering all sorts of crap. Apply same due dilligence to the firmware running on the NIC/switch. Then continue with the 'optics' in the SFP+. They are 'smart' nowadays, and often run Linux, or some RTOS, too. See https://pon.wiki/xgs-pon/ont/bfw-solutions/was-110/#boot-log for just one example. Diz iz dä äyge of phybre. Äye vanna häff lain speed! Arr!

I believe New Vector Ltd, which builds Element [1], is in the UK. You also have Collabora [2] and probably others as well. If you are willing to work from home, you could join one from France or Germany where many of them are established, the time difference is small. You get to work in an international setting which is also relatively small size. When I was looking for a job, I actually listed open source software I may enjoy working on and find who was behind. I ended up running into my current company at an open source event, so you might also want to go to one of these. [1] https://element.io/ [2] https://collabora.com/

Apart from RedHat, a couple of successful FOSS consultancies include Igalia and Collabora. Interestingly Igalia is also a co-operative, owned by the employees. https://www.igalia.com/ https://www.collabora.com/ There are more listed in the employers section of the FOSSjobs wiki: https://github.com/fossjobs/fossjobs/wiki/resources

As it's the GPU that seems to be the issue here is there a RISC-V based SoC with an open source GPU driver? Worth noting too that there is an open source driver for Arm's own Mali GPUs. https://www.collabora.com/news-and-blog/blog/2021/06/11/open-source-op…

Oh, is there a bug for Krita to follow about it? I think color management in general is a big WIP for Wayland. Related: * https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-way… * https://www.collabora.com/news-and-blog/blog/2022/01/25/a-pixels-color… * https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_reque…

In the linked thread the Microsoft developers explicitly deny that this is the intent, if that's worth anything to you. The goal, rather, is to take all the usual (for the Linux side) GPU stuff and give it access to the Windows host's GPU, when running on WSL. That is, they are already working on getting OpenGL/Vulkan/etc. to run on top of this: https://www.collabora.com/news-and-blog/news-and-events/introducing-op… Rather than "get people to write code that runs on WSL2 but not regular Linux," the goal is "get code that runs on regular Linux but not WSL to run on WSL2."

Poor performance on Elementary OS, et al, could be caused by this kinda severe bug: https://www.collabora.com/news-and-blog/blog/2016/11/22/a-tale-of-cyli… Should be fixed up with GTK+ 4.0. That said, I also love the extensions on Gnome 3 and have been using it as my daily driver for a while now. Every once in a while I get the kick to try something else, see how unity is, check out KDE, enjoy Awesomewm for a bit, but I keep finding myself back with Gnome. Protip: if you like dark themes, install "Stylish" for Firefox and search for "dark" and install them all. In addition to the desktop UI theme, most of the web can be painted with a pleasing light on dark grey style, and I have no complaints.

> On that last point, I felt it necessary to justify why RK3576 is an interesting target. Many more casual observers seem to see an SoC with older licensed core designs and miss the forest for the trees in the process. The talk details how RK3576 is more than a cost-optimised little brother: it's a stepping stone towards future designs. Unfortunately I bought a bunch of Radxa Zero 3W's, which use the RK3566. An older design though, from around when RK3588 was also arriving. Mainline support is not that bad. But I don't think there's much focus on improving it. Mostly I just want video encoding; my original use case was using it as an HDMI -> wireless transmitter. As we head into this computing crunch, alas, these lesser chips are going to be quite important. There's some really nice Allwinner A733 chips too, but I don't think support is nearly on par with what Collabora has cooked up for Rockchip. That's a huge advantage, and it's fantastic. There was a really scary time a year ago when it felt like Rockchip was going to disappear from open source. There's still a question of availability of SBC systems, but where we are is so much better than it looked like things were going to be, 15 months ago. Great follow up post here, on the post 5 days ago about the great progress with video decoding going to mainline. I wonder how Allwinner is doing with their A733 & maybe upcoming A737. https://mastodon.social/@geerlingguy/113698847221483936…

Thanks for the analysis. > That repo is for an opaque blob Marvell patches have been going to upstream u-boot for a subset of CN-9130 functionality. Some were rejected as unwanted SoC-unique features, but that code is still public and could be consolidated into a public git repo for evaluation. Support for core features was merged, e.g. this thread from 2020 to 2023, https://lore.kernel.org/u-boot/ddd355c2-344e-4fbd-ace9-29d10f3966d3@de… > the notorious will-never-be-open-source highly-radioactive "snps blob" .. ARC core Thanks for highlighting snps+eula. While we all want blob-free hardware like the expensive Talos OpenPOWER, all modern CPUs from Intel (ME) and AMD (PSP, MS Pluton) have management cores and firmware blobs (Intel FSP, AMD Agesa). AMD has a public roadmap for open firmware with OpenSIL, but PSP code is not public. One mitigation is to keep the device offline. > Marvell.. good at hiding it While this obfuscation is undesirable, many Arm vendors don't even bother with a fig leaf of upstream support. Would you recommend any Arm SoCs that have ongoing upstream Linux and u-boot coverage/fixes? Ideally, the SoC would also have OSS code for TrustZone (TF-A) and support for ECC memory. RockChip RK-3588 looks promising, https://www.collabora.com/news-and-blog/blog/2024/02/21/almost-a-fully…

I have recommended SUSE Linux Enterprise Desktop in contexts where people have talked about supporting desktop openSUSE financially. I have also previously mentioned SUSE as an option in other forums. As an engineer-centric Linux distribution vendor, they are also well-equipped to do engineering work upstream (and have an upstream-first mentality, which I appreciate). Red Hat and SUSE engineers often work hand-in-hand upstream in many communities, including desktop ones like GNOME and KDE. They're a perfectly fine option if you want to go that way. But in this context, we're talking about Red Hat's ability to invest in desktop Linux. And that is directly mapped to RHEL Workstation sales and (to a lesser extent) adoption of Fedora Linux (as a halo driving RHEL server/cloud and OpenShift adoption). People also seriously underestimate how much work Red Hat puts into virtually every sphere of the Linux space[1], including the desktop. Many engineers spend a lot of time working in projects that don't directly pay off for RHEL because it either benefits the larger community or feeds into something they do care about in RHEL. It continues to surprise me how remarkably altruistic Red Hat is for a company. But that can only go so far. People still need to live and eat. To give an idea of something that wouldn't have been possible without Red Hat: NVIDIA opening up their drivers last year[2][3]. Red Hat has been furiously working to rework Nouveau to take advantage of the…

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? This is for the NVK project, which is creating an open source GPU driver for NVIDIA GPUs. The project has a number of considerations that are not in the blog post: > The unfortunate reality is that, while the original nouveau drivers were written by some amazing engineers and were state-of-the-art a decade ago, they have fallen behind in the last several years. The few developer hours it gets are mostly spent on basic hardware enablement and trying to get new OpenGL versions, leaving the systemic and architectural issues unaddressed. You can find more complete rationale in their announcement blog post, and it seems very thoughtful: https://www.collabora.com/news-and-blog/news-and-events/introducing-nv… If you want Yet Another Example of using Rust to write GPU drivers, you can look at the other Mesa driver in development (for the Apple AGX GPUs): https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ (see "Rust is magical!")

> your compiler Compilers of languages like C, C++, Rust, Go etc go above and beyond to maintain backwards compatibility. It is extremely likely that you will still be able to compile old code with a modern compiler. > your processor Hardware is common enough that people go out of their way to make backwards compatibility shims. Things like rosetta, qemu, all the various emulators for various old gaming systems, etc. > your hardware Apart from your CPU (see above) your hardware goes through abstraction layers designed to maintain long term backwards compatibility. Things like opengl, vulkan, metal, etc. The abstraction layers are in widespread enough use that as older ones stop being outdated people start implementing them on top of the newer layers. E.g. here is OpenGL on top of Vulkan: https://www.collabora.com/news-and-blog/blog/2018/10/31/introducing-zi… > [Your kernel] Ok, you didn't say this part, but it's the other big unpinned dependency. And it too goes above and beyond to maintain backwards compatibility. In fact Linus has a good rant on nearly this exact topic that I'd recommend watching: https://www.youtube.com/watch?v=5PmHRSeA2c8&t=298s > Pinning a dependency only _guarantees you rot the same or even faster_ because now it's less likely that you can use an updated version of the dependency that supports more recent hardware. Dependencies are far more likely to rot because they change in incompatible ways than the…

Collabora | Low-level Software Developer | Taipei, Taiwan | Full-time, REMOTE | https://www.collabora.com/careers.html Collabora is a leading global consultancy specialising in delivering the benefits of open source software to the commercial world. For over 10 years, we’ve helped our clients navigate the ever-evolving world of Open Source, enabling them to develop the best solutions. We are looking for a low-level software developer with expertise in Intel and/or AMD system architectures, UEFI programming and debugging. The candidate should be able to review and apply kernel patches, analyse electrical schematic diagrams, debug and troubleshoot issues with debugger/ITPS, scopes, and logic analysers, and be familiar with various hardware bus interfaces (USB, SMBus, LPC, I²C, etc). Spoken Mandarin Chinese and being located in Taipei, Taiwan or mainland China is a plus. More details: https://jobs.lever.co/collabora/bc35c5e5-c510-4b67-9866-cdb5c7b85d3b

It depends on the CPU. For Rockchip we have open source BL31 blob [1] and it's supported by mainline u-boot. And I think it's ring -2, because it's not a separate CPU. [1] https://www.collabora.com/news-and-blog/blog/2024/02/21/almost-a-fully…

ability to make some filesystems case-insensitive was also added for wine https://www.collabora.com/news-and-blog/blog/2020/08/27/using-the-linu…

I've used Linux on desktops/laptops intermittently since the year 2000, but I've been using mostly MacOS in recent years. With Apple not inspiring confidence lately, I wanted to try using Linux as a daily OS again. So I installed Fedora on a laptop last month. After installation I noticed that the colors on my OLED display were very oversaturated. After some frustrating attempts to get ICC profiles working, I was dismayed to read this: https://www.collabora.com/news-and-blog/news-and-events/12-years-of-in… Sounds like Wayland color management is... almost done? But the lack of a complete implementation didn't stop my distro from making Wayland the default. So now I'm left having to choose between using the cool new Wayland compositors and having accurate colors in my photo editing apps :(

You can read more about the organization of the work and how it's split between kernel and user space at https://www.collabora.com/news-and-blog/blog/2025/08/06/writing-a-rust…

I started learning C again for one simple reason: to understand the Linux kernel. You cannot do that without knowing C, and soon you end up learning about GCC, linkers, and how programs really run. Once I spent time with it, I saw how many smart ideas from the kernel could be used anywhere. the initcall system that runs modules in order, the way structs with function pointers create flexible drivers, the use of macros to build type-safe lists and so on. https://www.collabora.com/news-and-blog/blog/2020/07/14/introduction-t… For real work, though, life is short. I use Go.

You probably haven't looked at it for a while. It's a conformant OpenGL implementation. Zink is now the default for Nvidia GPUs in Mesa, replacing Nouveau. https://www.collabora.com/news-and-blog/news-and-events/goodbye-nouvea…

More details here: https://www.collabora.com/news-and-blog/news-and-events/apertis-v2024-…

Several companies (including mine, Toradex) have setup board farms to deal with Kernel regressions and bugs during the `-rc` window, ie, the kernel that is going to be released is heavily tested. https://kernelci.org/ is a big one, Linaro has theirs https://lkft.linaro.org/, Intel has multiple farms, Collabora works relentlessly with GitLab integration https://www.collabora.com/news-and-blog/news-and-events/patch-submitte… The kernel is very much tested before a release with gigantic automated labs on real hardware.

For the DDR, yes, but as for the GPU, is this still the case with Collabora's ongoing work on Panthor? https://www.collabora.com/news-and-blog/news-and-events/taming-the-pan…

Pretty sure the issue is that the RK3588 drivers are not upstreamed into Linux/U-Boot etc. This is the issue with most ARM CPUs in this area like the Broadcom ones RPi is using. Which is why they have Raspberry Pi OS to ship you the drivers. The first good ARM CPU to actually get mainlined will probably see more sales. RK3588 upstreaming project: https://www.collabora.com/news-and-blog/blog/2024/02/21/almost-a-fully… Risc-V JH7110[0] upsteam status: https://rvspace.org/en/project/JH7110_Upstream_Plan [0] used in https://www.starfivetech.com/en/site/boards

The NanoPi R6C/R6S as well. The rk3588 is a nice chip, but support just isn't there yet if you want to do anything with the GPU. The "Panthor" GPU driver, which is the FOSS driver which supports its GPU, was just merged in to Linux and mesa this month[1] (yay!) which means you're probably gonna have to build your own kernel if you want it. The old mali proprietary driver is borderline unusable on anything remotely modern, only really working on Linux 5.10 and special X11 builds with legacy features re-enabled. It's crazy that the rk3588 has been on the market for many years at this point and is just now starting to be usable on Linux, but it's exciting that things are taking shape. [1] https://www.collabora.com/news-and-blog/news-and-events/release-the-pa…

See also the blog post: https://www.collabora.com/news-and-blog/news-and-events/whisperfusion-… WhisperFusion, WhisperLive, WhisperSpeech, those are very interesting projects. I'm curious about latency (of all those 3 systems individually, and also the LLM), and WER numbers of WhisperLive. I did not really find any numbers on that? This is a bit strange, as those are the most crucial information about such models? Maybe I just looked at the wrong places (the GitHub repos).

https://www.collabora.com/news-and-blog/blog/2021/06/14/zink-summer-20… As of summer 2021 there was some support for exactly this.

Not neglected - complicated. This blog is nearly 3 years old now but still gives a good summary https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-way… And here is the relevant ongoing proposal https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_reque…

Any OS can "make a filesystem case insensitive"; for example in Linux you can do it if your kernel has support for it[1]. But again, that is a OS implementation detail thing, the underlying file system is still case preserving. [1] https://www.collabora.com/news-and-blog/blog/2020/08/27/using-the-linu…