Installation instructions for Fedora + few basic questions

[jgarciao]

First of all thanks for creating this project. I'm very interested in trying it because my laptop (Macbook Pro 2011 with Fedora 32) has a faulty discrete AMD card and I've managed to keep it as my main computer forcing the use of the integrated card (Intel). The problem is that I cannot use an external display because the display port doesn't work.

I would like to try your solution to be able to use the laptop (it has usb 2 ports) with an external 1920x1200 display and an spare Raspberry Pi 3 Model B that I have at home. I need it mainly for web browsing and programming.

I understand from the wiki that I have to boot the raspberry pi with one of the provided images. Which one would be better for the rapberry pi 3?

How can I install and configure your driver on Fedora (Gnome on Wayland) so the computer can use the external display? I'm not too familiar with compiling the kernel. I think last time I did it was more that 15 years ago...

And last question: how are the two computers connected? From one of the laptop's usb connectors to the raspberry's micro-usb? I thought the raspberry micro-usb was just for powering it, not for transferring data

Thanks a lot for your work!

[notro]

It's not possible to use the Raspberry Pi 3 because it has a usb hub that uses the only usb port on the soc. The Pi Zero is probably best as a usb display adapter. The Pi4 (usb-c) is not as convenient for usb since it needs to be powered through the gpio header since it's so power hungry, but it can use the network port instead as transport (see wiki: usbip). Or can PC USB ports deliver 3A nowadays? (anyways I haven't tried this)

You need to look up the Fedora docs for how to compile a kernel. Linux v5.9 will have all the dependencies for the host driver, v5.8 needs this: https://github.com/torvalds/linux/commit/bd34cea2a0e4b0c7a8e73d6cbaf694b233769d9d (if I'm not mistaken)

[jgarciao]

I might buy a pi zero and give it a try. So, in my case, the host is the laptop and the device is the pi zero?

If that's the case, I'll use your pi zero image and a recent kernel for Fedora. I've seen a way to install a vanilla kernel on fedora and I think when Linux 5.9 is released it will be available with this method.

Or maybe I'll just wait for Fedora 33, which might have Linux 5.9 out of the box

Thanks for your help!

[notro]

So, in my case, the host is the laptop and the device is the pi zero?

Yes

[jgarciao]

I've ordered a pi zero. I'll tell you how it goes. Thanks again

[jgarciao]

I bought a Raspberry Pi Zero and installed the kernel 5.9.0-36.vanilla.1.fc32.x86_64 in Fedora 32 using these instructions:

• Download the definitions for the Kernel vanilla repositories: curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo | sudo tee /etc/yum.repos.d/kernel-vanilla.repo
• Run this if you want the latest stable kernel: sudo dnf --enablerepo=kernel-vanilla-stable update
• Reboot

Now when connecting the zero to the usb port of the laptop I see in the logs that there is a "Pi Display Gadget":

d’oct. 28 22:37:54 rock kernel: usb 1-1.3: device descriptor read/64, error -71
d’oct. 28 22:37:54 rock kernel: usb 1-1.3: New USB device found, idVendor=1d50, idProduct=614d, bcdDevice= 5.07
d’oct. 28 22:37:54 rock kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
d’oct. 28 22:37:54 rock kernel: usb 1-1.3: Product: Pi Display Gadget
d’oct. 28 22:37:54 rock mtp-probe[4138]: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.3"

And running lsusb I see a new OpenMoko device:

Bus 001 Device 009: ID 1d50:614d OpenMoko, Inc. 

But Gnome settings doesn't recognise the usb display adapter, not when using Wayland or X.

In X, when I run xrandr --listproviders it finds only the laptop's adapter

Is there anything else I should do to configure this? Should I try with a different distro?

Thanks a lot for your help!

[jgarciao]

I forgot to mention that sometimes the laptop is not able to detect the usb device properly. When this happens lsusb takes a long time and doesn't show the OpenMoko device and I see this in the logs:

de set. 30 13:14:20 rock kernel: usb 1-1.3: new high-speed USB device number 13 using ehci-pci
de set. 30 13:14:25 rock kernel: usb 1-1.3: device descriptor read/64, error -110
de set. 30 13:14:32 rock systemd[1]: fprintd.service: Succeeded.
de set. 30 13:14:32 rock audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
de set. 30 13:14:41 rock kernel: usb 1-1.3: device descriptor read/64, error -110
de set. 30 13:14:42 rock kernel: usb 1-1.3: new high-speed USB device number 14 using ehci-pci
de set. 30 13:14:47 rock kernel: usb 1-1.3: device descriptor read/64, error -110
de set. 30 13:15:03 rock kernel: usb 1-1.3: device descriptor read/64, error -110
de set. 30 13:15:03 rock kernel: usb 1-1-port3: attempt power cycle
de set. 30 13:15:04 rock kernel: usb 1-1.3: new high-speed USB device number 15 using ehci-pci
de set. 30 13:15:15 rock kernel: usb 1-1.3: device not accepting address 15, error -110
de set. 30 13:15:15 rock kernel: usb 1-1.3: new high-speed USB device number 16 using ehci-pci
de set. 30 13:15:26 rock kernel: usb 1-1.3: device not accepting address 16, error -110
de set. 30 13:15:26 rock kernel: usb 1-1-port3: unable to enumerate USB device

[notro]

Looks like the driver isn't loaded, you're missing this:

[  126.700672] [drm] Initialized gud_drm 1.0.0 20200422 for 1-1.4:1.0 on minor 0

Check if the module is available:

$ modprobe -c | grep 614D
alias usb:v1D50p614Dd*dc*dsc*dp*icFFisc*ip*in* gud_drm

You could try loading the module manually:

# modprobe gud_drm

The timeouts (-110) you're getting could be due to rebooting host or gadget while connected. I've had this problem myself but haven't had time to look into it so I just disconnect the cable before rebooting.

I assume that you power the Pi through the power port as well and not only from the host port.

[jgarciao]

The module is not present in the kernel I'm using.

modprobe gud_drm
modprobe: FATAL: Module gud_drm not found in directory /lib/modules/5.9.0-36.vanilla.1.fc32.x86_64

According to the Fedora Vanilla Repositories FAQ the mainline kernels use basically the same configuration as the Fedora rawhide kernels. Maybe a few staging drivers might get turned on to help their development, but apart from it the plan is to stick closely to what Fedora does. I think I'll have to ask them to add the module or compile the kernel myself...

I assume that you power the Pi through the power port as well and not only from the host port.

I've tried both ways but usually just the host port. I'll will connect both of them always now

Thanks again for your help. I'll keep you informed!

[notro]

I assume that you power the Pi through the power port as well and not only from the host port.

I have checked this and it's actually not recommended to power it from 2 sources: Using Both PWR and USB in OTG Mode on the Pi Zero

I have always done that when experimenting, but maybe I've been lucky not frying anything.

[lbdroid]

Or can PC USB ports deliver 3A nowadays? (anyways I haven't tried this)

Some can. And in other circumstances, use of a powered usb hub will solve the problem.

I absolutely love this project, and have noticed that there hasn't been much action on it for several months. It would be great to see something make it upstream!

[notro]

Wrt power, I have on my todo list to measure how much power the Pi4 actually needs for this use case. The Pi zero seems to use less than 100mA judging by a quick google search.

I absolutely love this project, and have noticed that there hasn't been much action on it for several months.

Ufortunately I've been ill for the past months so I haven't been able to work on it. Lately I've had some "good periods" that I use to address the review comments I got on the version 3 of the patchset. No idea when I'm done with that though.

[jgarciao]

Ufortunately I've been ill for the past months so I haven't been able to work on it. Lately I've had some "good periods" that I use to address the review comments I got on the version 3 of the patchset. No idea when I'm done with that though.

I hope you will recover soon. I'll totally understand if you can't answer my noob questions ...

I thought this patch was already mainlined in the 5.9 kernel. That's why it didn't appear on my machine. According to this doc, it should be "easy" to compile an out of tree kernel in fedora, but downloading the patch from the mailing list is like black magic to me.

Could you add the code to this repo so I can just git clone and try to compile it using the above fedora document or something like this from Stack Overflow

Thanks again! Take care

[notro]

The patch is available here: https://patchwork.freedesktop.org/patch/367673/mbox/

[solarkraft]

I applied the patch to the kernel source, modifed the makefile for in place compilation, pulled gud_drm.h into the directory and made gud_drm_connector.c and gud_drm_drv.c use it (next time I would just take them from the patch itself instead of applying it since the relevant changes are all new files).

Here's my fork with the module (untested beyond "compiles and doesn't crash my machine" ).

[jgarciao]

Now that Fedora 32 has kernel 5.9.8 and using @solarkraft 's approach I've been able to compile the kernel, load it and test the usb device. With GNOME on Wayland, the external screen is detected in the Settings > Displays but no matter what setting I choose (using both screens side to side, mirror screen or just the external screen) the external display shows nothing. It's on but It looks like is just showing black pixels

When changing the external display resolution it shows that it's doing it, but the screen is still black

When using both screens side to side, the mouse pointer disappears when it "goes" to the side where the external display is supposed to be, but it's not shown.

I see this in the logs when trying to use the external display. The line "MESA-LOADER: failed to open gud_drm (search paths /usr/lib64/dri)" looks suspicious, maybe I forgot to do something

de nov. 16 21:57:30 rock kernel: gud_drm: loading out-of-tree module taints kernel.
de nov. 16 21:57:30 rock kernel: gud_drm: module verification failed: signature and/or required key missing - tainting kernel
de nov. 16 21:57:30 rock kernel: usbcore: registered new interface driver gud_drm
de nov. 16 21:57:30 rock sudo[5059]: pam_unix(sudo:session): session closed for user root
de nov. 16 21:57:30 rock audit[5059]: USER_END pid=5059 uid=0 auid=1000 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
de nov. 16 21:57:30 rock audit[5059]: CRED_DISP pid=5059 uid=0 auid=1000 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
de nov. 16 21:57:48 rock systemd[1]: libvirtd.service: Succeeded.
de nov. 16 21:57:48 rock audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=libvirtd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
de nov. 16 21:57:49 rock systemd[1]: fprintd.service: Succeeded.
de nov. 16 21:57:49 rock audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
de nov. 16 21:57:58 rock kernel: usb 1-1.3: new high-speed USB device number 9 using ehci-pci
de nov. 16 21:57:58 rock kernel: usb 1-1.3: device descriptor read/64, error -71
de nov. 16 21:57:59 rock kernel: usb 1-1.3: device descriptor read/64, error -71
de nov. 16 21:57:59 rock kernel: usb 1-1.3: new high-speed USB device number 10 using ehci-pci
de nov. 16 21:57:59 rock kernel: usb 1-1.3: New USB device found, idVendor=1d50, idProduct=614d, bcdDevice= 5.07
de nov. 16 21:57:59 rock kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
de nov. 16 21:57:59 rock kernel: usb 1-1.3: Product: Pi Display Gadget
de nov. 16 21:57:59 rock kernel: [drm] Initialized gud_drm 1.0.0 20200422 for 1-1.3:1.2 on minor 1
de nov. 16 21:58:00 rock kernel: fbcon: Deferring console take-over
de nov. 16 21:58:00 rock kernel: gud_drm 1-1.3:1.2: [drm] fb1: gud_drmdrmfb frame buffer device
de nov. 16 21:58:00 rock mtp-probe[5077]: checking bus 1, device 10: "/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.3"
de nov. 16 21:58:00 rock mtp-probe[5077]: bus: 1, device: 10 was not an MTP device
de nov. 16 21:58:00 rock gnome-shell[2809]: MESA-LOADER: failed to open gud_drm (search paths /usr/lib64/dri)
de nov. 16 21:58:00 rock gnome-shell[2809]: failed to load driver: gud_drm
de nov. 16 21:58:00 rock gnome-shell[2809]: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Do not want to use software renderer (llvmpipe (LLVM 10.0.1, 256 bits)), falling back to CPU copy path
de nov. 16 21:58:00 rock gnome-shell[2809]: Failed to set hardware cursor (drmModeSetCursor failed: El dispositiu o adreça no existeix), using OpenGL from now on
de nov. 16 21:58:00 rock colord[1056]: failed to get session [pid 3064]: No hi ha dades disponibles
de nov. 16 21:58:00 rock gnome-shell[2809]: Failed to set hardware cursor (drmModeSetCursor failed: El dispositiu o adreça no existeix), using OpenGL from now on
de nov. 16 21:58:00 rock kernel: swiotlb_tbl_map_single: 8 callbacks suppressed
de nov. 16 21:58:00 rock kernel: gud_drm 1-1.3:1.2: swiotlb buffer is full (sz: 2224128 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:00 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:00 rock kernel: gud_drm 1-1.3:1.2: Failed to flush framebuffer: error=-11
de nov. 16 21:58:00 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:01 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:01 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:10 rock gnome-shell[2809]: Failed to set hardware cursor (drmModeSetCursor failed: El dispositiu o adreça no existeix), using OpenGL from now on
de nov. 16 21:58:10 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:10 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:10 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:10 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:25 rock systemd[2452]: Starting Mark boot as successful...
de nov. 16 21:58:25 rock systemd[2452]: grub-boot-success.service: Succeeded.
de nov. 16 21:58:25 rock systemd[2452]: Finished Mark boot as successful.
de nov. 16 21:58:34 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:34 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:46 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:46 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:54 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:54 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:59:06 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:59:06 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:59:07 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:59:07 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:59:07 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:59:07 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:59:08 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:59:08 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 303491 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:59:09 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 1403324 bytes), total 32768 (slots), used 2 (slots)

These are the steps I've followed on Fedora 32:

# Update everything and reboot
sudo dnf update

# Check current kernel version is 5.9.8-100.fc32.x86_64
uname -a

# Install stuff required to build kernel modules
sudo dnf install kernel-devel

# Create a folder in my home folder to compile the module
mkdir $HOME/gud_drm-5.9.8-100.fc32.x86_64

# Download https://patchwork.freedesktop.org/patch/367673/mbox/ into the previous folder using the browser

# Unpack the contents of the patch
cd $HOME/gud_drm-5.9.8-100.fc32.x86_64
patch  -f -p1 < v3-4-6-drm-Add-Generic-USB-Display-driver.patch

# Copy the file gud_drm.h in the source tree of the installed kernel
sudo cp include/drm/gud_drm.h /usr/src/kernels/5.9.8-100.fc32.x86_64/include/drm/

# Build the module using @solarkraft Makefile
cd drivers/gpu/drm/gud/
mv Makefile Makefile.orig
wget https://raw.githubusercontent.com/solarkraft/gud/add_kernel_module/gud/Makefile
make

# Open another terminal and watch the logs
sudo journalctl  -f

# Back to the original terminal, load the module
sudo insmod gud_drm.ko

# Connect the raspberry pi Zero to the screen by HDMI and to the laptop by USB using the data connector (not the power connector)

[notro]

These are the relevant entries:

de nov. 16 21:58:00 rock kernel: swiotlb_tbl_map_single: 8 callbacks suppressed
de nov. 16 21:58:00 rock kernel: gud_drm 1-1.3:1.2: swiotlb buffer is full (sz: 2224128 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:00 rock kernel: ehci-pci 0000:00:1a.7: swiotlb buffer is full (sz: 2300461 bytes), total 32768 (slots), used 2 (slots)
de nov. 16 21:58:00 rock kernel: gud_drm 1-1.3:1.2: Failed to flush framebuffer: error=-11

(gud_drm prints the flushing failure error only once to avoid trashing the log)

-11 is -EAGAIN, but I don't know which function it is that actually returns it.

The swiotbl error is printed in swiotlb_tbl_map_single().

AFAIU swiotbl is used when the device can't access the buffer using DMA. In that case it uses a "bounce" buffer to copy to/from so the device can reach it. This is ofc slow due to the memcpy.

You could try this change and see if a smaller transfer buffer (512k) works (the framebuffer will be split up into smaller parts):

 static int gud_drm_probe(struct usb_interface *interface,
             const struct usb_device_id *id)

-   max_buffer_size = 1 << desc.bMaxBufferSizeOrder;
+   max_buffer_size = 512 * 1024;

[jgarciao]

I'm trilled to say that the change worked and now my external display is finally working!!!!

Thank you very much for your support all this weeks

In the end I had to put max_buffer_size = 480 * 1024 because with 512 it had the same error

The performance is correct with my 1900x1200 24 inches monitor. The mouse is slightly slow but usable. It helped to change the desktop background from a stock gnome photo to an image with a solid colour.

Now the only issue I have is what I wrote in a previous comment, when I reboot the laptop or the gadget very often it fails with this error:

Starting USB Display gadget: sh: write error: No such device

Could it be that the raspberry pi driver is not loaded in the raspberry zero fast enough?

The solution I've found is to unplug the raspberry pi, shut down the computer and wait for a 5 or more minutes. It normally works this way. If you wait just a minute it doesn't work

Anyway, thanks again for your help and patience :-)

[notro]

I'm glad you could make it work!

Wrt swiotbl, it's possible to configure it using the swiotbl= kernel commandline argument. I don't know if it will help you in any way though.

There is a serial console on the USB interface that will give you access to the gadget and the kernel log (username is root).

Here are some notes that I haven't put on the wiki yet:

Debug console

screen can be used to attach to the console:

$ screen /dev/ttyACM0 115200

Kill session: Ctrl-A k

Prevent ModemManager from capturing /dev/ttyACM0 (on the host)

One off, just stop it (or disable if not needed):

$ sudo systemctl stop ModemManager

[notro]

Scratch that, there's no USB serial console when it can't start the gadget... (maybe I should add a fallback that fires up the USB console even if the DRM device is not present)

You can however turn on output of kernel messages to the monitor by editing cmdline.txt on the sd card fat partiton (/boot).

Change these:

drm_kms_helper.fbdev_emulation=1
loglevel=6

and add these (all arguments on one line):

logo.nologo
drm.debug=0xf

There is also a serial console available on the header as is usual on the Pi.

[jgarciao]

Hi.

I've been using your driver (v3) since November daily and it works very well, at least for my usage (software developer). Even sharing my screen on video conferences or resuming from suspend. The mouse has a little lag but I got used to it and when I want to watch a video I drag the browser to the laptop's display. Performance is better when using a solid image as desktop background, at least in my setup (Pi Zero with USB 2.0).

I tried using the swiotbl= kernel commandline argument with different values but it didn't improve the problem, so I left max_buffer_size = 480 * 1024

I also still have the problem mentioned in a comment before but when It happens I just unplug the pi zero for a few minutes and plug it again to the laptop to make it work again.

I use this script to load the driver and automatically build it if there is a kernel update:

#!/bin/bash
GUD_SOURCE=/home/jorge/gud_drm-5.9.8-100.fc32.x86_64/
KERNEL_VERSION=`uname -r`
GUD_HEADERS_BUILD=/lib/modules/$KERNEL_VERSION/build/include/drm/gud_drm.h

if ! test -f "$GUD_HEADERS_BUILD"; then
    echo "Building gud module for $KERNEL_VERSION"
    sudo cp $GUD_SOURCE/include/drm/gud_drm.h /lib/modules/$KERNEL_VERSION/build/include/drm/
    cd $GUD_SOURCE/drivers/gpu/drm/gud/
    make clean all
fi

echo "loading gud module"
sudo insmod $GUD_SOURCE/drivers/gpu/drm/gud/gud_drm.ko

Usage: gud-insmod

I'm happy it's going to be mainline in kernel 5.13 so it will be much easier to use for everyone.

Thanks a lot again for your work!

[notro]

Thanks for reporting back, it's nice to hear that it's stable for daily use.