# Porting nouveau drivers?
**URL:** https://genode.discourse.group/t/porting-nouveau-drivers/282
**Category:** General
**Created:** [February 24, 2026, 12:05pm UTC](https://genode.discourse.group/t/porting-nouveau-drivers/282 "2026-02-24T12:05:20Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@kspatlas](https://genode.discourse.group/u/kspatlas)
#### Post date: [February 24, 2026, 12:05pm UTC](https://genode.discourse.group/t/porting-nouveau-drivers/282/1 "2026-02-24T12:05:20Z")
I’m quite new to Genode, but since it seems relatively easy to port Linux drivers to Genode, how hard would it be to port, say, the Nouveau drivers for NVIDIA (or even the official open-source kernel module)?
Something like NVK could be used for the Mesa bits (someone in the Haiku community was able to port NVK to the open-source kernel modules, in fact)
Are there any complications I’m missing?
---
### Author:  [@jws](https://genode.discourse.group/u/jws)
#### Post date: [February 25, 2026, 9:48am UTC](https://genode.discourse.group/t/porting-nouveau-drivers/282/2 "2026-02-25T09:48:29Z")
> [@kspatlas](#):
>
> I’m quite new to Genode, but since it seems relatively easy to port Linux drivers to Genode, how hard would it be to port, say, the Nouveau drivers for NVIDIA (or even the official open-source kernel module)?
It is easy as in it is feasible in a _manageable_ amount of time. The [Genode Platforms 23.05](https://genode.org/documentation/genode-platforms-23-05.pdf) book (starting with _“Taking Linux out for a walk”_) describes the process on how to port a Linux driver over (with focus on an ARM SoC but it is generally applicable).
It is hard to say how difficult it actually would be to port the Nouveau DRM driver without taking a look at the inner workings first.
That being said, there is the [intel\_fb](https://github.com/genodelabs/genode/tree/master/repos/pc/src/driver/framebuffer/intel/pc) framebuffer driver based on the _i915_ driver that illustrates how to make use of the Linux driver for Genode’s _Capture_ session.
The [lima\_gpu](https://codeberg.org/genodelabs/genode-allwinner/src/branch/main/src/driver/gpu/lima) rendering driver based on Linux’ _lima_ driver, on the other hand, shows how to connect the Linux’ DRM rendering API to Genode’s _Gpu_ session (together with our [libdrm](https://github.com/genodelabs/genode/tree/master/repos/libports/src/lib/libdrm) port and naturally [mesa](https://github.com/genodelabs/genode/tree/master/repos/libports/src/lib/mesa)).
So there are examples you can look at that show the custom/glue code required to make everything work and where to make a cut.
> [@kspatlas](#):
>
> Something like NVK could be used for the Mesa bits (someone in the Haiku community was able to port NVK to the open-source kernel modules, in fact)
There is also a port of the open-source blob driver found in [Managarm](https://github.com/managarm/managarm/tree/master/drivers/gfx/nvidia-open) and from what I was told (second hand) using the abstraction layer provided by the driver directly was a straightforward endeavor and there is now a working framebuffer driver.
in general
Of course this driver only supports newer generations of devices but that would probably the road I would explore first (with having Haiku’s as well as the Managarm’s driver as examples) as the API seems to be more lean.
> [@kspatlas](#):
>
> Are there any complications I’m missing?
Well, GPU drivers tend to be quite complex beasts - as usual, the devil is in the details and there are the various parts (DRM, libdrm, mesa) involved and how to make use of them. Depending on your experience it is a lot to take in at first.
I would suggest to take a look at the available driver components first and get a feel for how they interact.
For a start I would focus on a framebuffer driver, i.e. only the display engine related parts, first as it would expose you to the DRM subsystem but not burden you with dealing with mesa.