Asahi Linux is the name of a new project aiming to get Linux properly supported and working on Apple Silicon, the new ARM based chips designed by Apple like the Apple M1 found in their latest hardware.

This is being spearheaded by Hector Martin "marcan", who some will recognise due to their work involved in porting Linux to the Sony PlayStation 4. It's a crowdfunded effort, with Martin putting up a Patreon campaign which has now hit enough funding for the work to begin. Martin also has a GitHub Sponsor account, with plenty backing there too.

Their plan is to start with the 2020 M1 Mac Mini, MacBook Air, and MacBook Pro and they don't want to just get Linux running on them as they want to get it polished to a point where it can be used as your main daily operating system. It's a lot of work though, as they explained "this requires a huge amount of work to be done, as Apple Silicon is a completely undocumented platform" and "we will be reverse engineering the Apple GPU architecture and developing an open source driver for it".

All their work will be up on GitHub .

You might not like Apple or macOS but there's no denying the hardware is nice. Even our own Linus Torvalds, the creator of Linux, said in 2020 "I'd absolutely love to have one, if it just ran Linux".

Martin is of course not the only one involved. Alyssa Rosenzweig, who works with Collabora on the Panfrost driver for ARM Mali GPUs, seems to also be involved. Rosenzweig wrote on their blog about work towards an open source Mesa driver that's hit the first milestone of understanding enough of the instruction set "to disassemble simple shaders with a free and open-source tool chain" and this work lives on the Asahi Linux GitHub here .

Now that The Khronos Group has released the official Vulkan Ray Tracing API , which NVIDIA got in early it's all a bit more official with the NVIDIA 460.32.03 stable driver release.

Following on from their 460.27.04 Beta release back in December it's mostly the same. It's also now following their new driver naming scheme as we picked up before . On top of their dedicated developer-focused Vulkan / OpenGL drivers, they have their stable drivers like this which are now split between a "Production Branch" and a "New Feature Branch" with this 460.32.03 release being in the Production Branch ( listed here ).

The biggest thing is that this is a stable driver that supports the new cross-vendor Vulkan Ray Tracing API through these supported extensions:

• VK_KHR_acceleration_structure
• VK_KHR_ray_tracing_pipeline
• VK_KHR_ray_query
• VK_KHR_pipeline_library
• VK_KHR_deferred_host_operations

On top of that this driver also adds support for these extensions:

• VK_NV_fragment_shading_rate_enums
• VK_KHR_fragment_shading_rate
• VK_KHR_shader_terminate_invocation
• VK_EXT_shader_image_atomic_int64
• VK_KHR_copy_commands2

They improved their memory allocation strategy in nvidia-modeset.ko to reduce the likelihood of out-of-memory errors, plus support for RandR rotation and reflection while using an NVIDIA-driven display as a PRIME Display Offload sink and also support for "Reverse PRIME Bypass", an optimization that bypasses the bandwidth overhead of PRIME Render Offload and PRIME Display Offload in conditions where a render offload application is fullscreen, unredirected, and visible only on a given NVIDIA-driven PRIME Display Offload output.

For gamers, you will be pleased to know NVIDIA took on plenty of feedback and increased the OpenGL + Vulkan shader disk cache size to 1024MB and they gave it a new location. Lots more new, you can see the full changelog here .

If you missed the earlier news, NVIDIA are also preparing to support hardware accelerated XWayland .

Looks like 2021 really could properly be the year of Wayland on the Linux desktop. For plenty it already is but NVIDIA have been a sore spot and it looks like they're moving forward now too.

NVIDIA's Erik Kurzinger has submitted a Merge Request to the xserver GitLab titled "Xwayland: Support hardware accelerated rendering with the proprietary NVIDIA driver", with the two patches included "intended to accompany upcoming support in the proprietary NVIDIA driver for hardware accelerated GL and Vulkan rendering with Xwayland". Kurzinger continues to mention that once a driver is out with the needed hooks, this code should "just start working".

The patches are being sent out to be considered, so that they can get some feedback and see if there's any substantial concerns about their approach to it.

As for the performance of it? They expect it to be "on-par with native X11 based on the benchmarking I've done", although there's "an annoying extra copy required for presentation of windowed applications, but the impact doesn't appear to be significant, and fll-screen applications won't have that issue (provided the compositor supports the required zwp_linux_dmabuf_v1 interface)".

Why is all this important? With Wayland coming along to replace X11 as a big shakeup for Linux as a whole, you need XWayland to provide that backwards compatibility to enable existing applications and games to continue working well into the future.

Roderick Colenbrander of Sony Interactive Entertainment has sent in a brand new and official Linux driver for the PS5 DualSense for even better out of the box support.

With the newly proposed driver , it enabled the DualSense to function in both Bluetooth and USD modes along with most other features working including LEDs, Touchpad, Motion Sensors and Rumble. However, they make it clear that the Adaptive Triggers and VCM-based Haptics are not yet supported but they hope to "have a dialog on how to expose these over time in a generic way".

Here's how the describe it will work:

DualSense supported is implemented in a new 'hid-playstation' driver, which will be used for peripherals by 'Sony Interactive Entertainment' (PlayStation). Hid-sony will be used for devices for the larger Sony Group. We intend to migrate existing devices over time gradually to hid-playstation. We do not want to cause any regressions and maintain quality. As such moving forward, unit tests are important and we started by providing these through 'hid-tools' including DualSense.

The Linux driver exposes DualSense functionality as a 'compositive device' similar to DualShock 4 in hid-sony, spanning multiple frameworks. First, it exposes 3 evdev nodes for respectively the 'gamepad', 'touchpad' and 'motion sensors'. The FF framework is used to provide basic rumble features. The leds-class is used to implement the Player indicator LEDs below the DualSense's touchpad, while the new 'leds-class-multicolor' is used for the lightbars next to the touchpad.

This will be really nice to make it into the Linux Kernel, as the more we have working out of the box the better. While Steam and SDL2 can already work with it, not everything goes through them of course and it would open up the DualSense to all sorts of other possibilities.

I'll eventually be grabbing myself a DualSense, so I'm keen to see how it feels.

Hat tip to MrPenguin.

Have some trendy Corsair hardware and you're a Linux user? You're in luck as ckb-next is a great open source alternative to their usual Windows-only applications.

Much like OpenRGB , it's community made and not officially supported by the hardware vendor. Don't let that stop you though, they're filling a gap for Linux users and ckb-next is actually great. For my own Corsair Strafe keyboard, it works really well.

With the latest ckb-next 0.4.3 release they've added in support for the Scimitar RGB Elite and also the Nightsword RGB. So the full list of devices is now quite long. Other new features include the ability to turn lights off after a set time (X11 only), macros will now loop when a key is held down, the macro UI itself went through an overhaul, modes can be set to automatically change based on the currently focused application (X11 / XWayland only) and the application now supports translations too.

Quite a big release then looking at that! It also include a bunch of quite important bug fixes too with some freezes solved, layouts for K68 / K65 / K63 and M95 were fixed, mouse settings get restored properly when resuming from suspend, working input again on Wayland and more.

While I like OpenRGB and appreciate it trying to cover a huge amount of different vendors, I find ckb-next works better for my own device. I also like that ckb-next shows you exactly what to do when starting it for the first itme.

Find ckb-next up on GitHub .

NVIDIA have released a small and sweet update to their developer focused Vulkan Beta driver series with 455.46.04 out now for Linux.

Here's the changelog:

• New:
  • VK_NV_acquire_winrt_display [Windows]
• Fixes:
  • Fixed a crash from vkCreateGraphicsPipelines when certain blend operations were used with scalar outputs from the fragment shader
  • Fixed the X driver's composition pipeline (used, e.g., for X desktop rotation, "ForceCompositionPipeline", and some OpenGL Swap Group configurations) to correctly preserve color precision in depth 30 [Linux]

You can find the NVIDIA Vulkan Beta Driver here .

Reminder: This special Vulkan beta driver is where all the shiny new stuff goes in before making its way into the stable release for everyone. Really, it's mostly aimed at developers and serious enthusiasts. Unless you need what's in them, it's generally best to use the mainline drivers (either stable or beta).

Just recently, NVIDIA actually changed how they describe all their driver releases too which should make things a bit less confusing. Previously you had this Vulkan developer beta, then their mainline drivers had a "long lived" series and then a "short lived" series. The difference of which NVIDIA explained before as:

Any given release branch is either long-lived or short-lived. The difference is in how long the branch is maintained and how many releases are made from each branch. A short-lived branch typically has only one or two (non-beta) releases, while long-lived branches will have several.
[…]
When we make changes to the driver, we evaluate the oldest branch the change needs to go into. New features go into whatever the latest branch is, while bug fixes go into the older branches and are integrated through the newer branches. So using a short-lived branch doesn’t mean that you miss out on fixes, it just means that you also get the latest features.

They've now moved to calling the different branches as "Production Branch" and "New Feature Branch" (shown here ), so the meaning on each is at least a lot more clear now. The latest Production Branch level driver is at 450.80.02 from September 30 and then the New Feature Branch at 455.45.01 from November 17.

On top of that, there's also the very latest on their mainline drivers with the Beta release 460.27.04 from December 15.

Mesa 20.3.0 is the latest and greatest when it comes to Linux open source graphics, bringing with it new hardware support, performance improvements and more. Mesa drivers are what power the likes of Intel and AMD on Linux with the latest Vulkan and OpenGL support whereas NVIDIA have their own proprietary driver.

As always, with it being a brand new release if you're concerned about stability you might want to wait for the first point release with Mesa 20.3.1.

Lots new with this version like the 'V3DV' Vulkan driver for the Raspberry Pi now being available, new extension support, big improvements to the Zink driver (OpenGL implementation on top of Vulkan), new hardware support across both AMD and Intel for the latest chips and some upcoming stuff, the Panfrost driver for Mali GPUs was extended quite a lot too and much more. You can see the release notes here , although they're quite technical and not great reading unless you really know what to look for.

Need to learn more about Mesa drivers? See the official site .

It seems NVIDIA are no longer reserving the two extra digits in their Linux driver versioning for their special Betas, as a new stable driver is out today as 455.45.01 .

Quite a small driver that's just a few bug fixes but nice to see NVIDIA do updates both big and small. Here's what they say has changed in this version:

• Fixed a bug in a Vulkan blending optimization that could produce incorrect results. Some of the Vulkan titles affected by this bug were:
  • Life is Strange 2
  • Shadow of the Tomb Raider
• Fixed an issue that caused Vulkan swapchain creation to fail for full-screen windows when a G-SYNC monitor is connected.

This is part of their "Short Lived" branch, and should be safe for everyone to upgrade to if you're sticking to that. They also have their "Long Lived" branch currently on version 450.80.02 that was released back in September.

Since the difference isn't obvious, here's our usual reminder on what the changes are between their stable driver branches on Linux as explained by NVIDIA:

Any given release branch is either long-lived or short-lived. The difference is in how long the branch is maintained and how many releases are made from each branch. A short-lived branch typically has only one or two (non-beta) releases, while long-lived branches will have several.
[…]
When we make changes to the driver, we evaluate the oldest branch the change needs to go into. New features go into whatever the latest branch is, while bug fixes go into the older branches and are integrated through the newer branches. So using a short-lived branch doesn’t mean that you miss out on fixes, it just means that you also get the latest features.

Enjoy your fancy Razer hardware on Linux? You should probably check out OpenRazer, which is a nice big collection of drivers for Linux. A project that's been going for a long time now, with no sign of it stopping and it just keeps on improving.

Another example of the open source community bridging the official support gap for users. Just recently OpenRazer 2.9.0 was released, adding in support for plenty of additional devices including these:

• Razer Atheris
• Razer Basilisk X HyperSpeed
• Razer Blade 15 Advanced (2020)
• Razer Blade 15 Base (Early 2020)
• Razer Blade Stealth (Early 2020)
• Razer Cynosa Lite
• Razer Cynosa V2
• Razer DeathAdder 2000
• Razer Kraken Kitty Edition
• Razer Kraken Ultimate
• Razer Viper Mini

Pictured - the Polychromatic UI you can use with OpenRazer.

There's also several overall improvements that came with this latest release of OpenRazer including read support for idle_time and low_battery_threshold, it's now possible to configure the battery notification frequency, razercore & razermousemat drivers were combined into the razeraccessory driver, Razer Viper & Viper Ultimate devices have been cleaned up and support more effects now, screensaver monitor now supports Xfce and the fake driver support has been improved. Additionally a few bug fixes also made it in.

I've personally been using it for some time, along with the Polychromatic UI pictured above which works without any issues with my own DeathAdder Chroma.

You can find out more about it on GitHub and their website .