Getting Cameras Working on Surface Pro 5 (Debian 13 / Trixie)

Getting Cameras Working on Surface Pro 5 (Debian 13 / Trixie)
Hardware: Microsoft Surface Pro 5 (2017)
OS: Debian 13 (Trixie)
Kernel: 6.18.7-surface-1

Result

✅ Front camera (OV5693) — fully working
❌ Rear camera (OV8865) — detected but green image (ISP tuning file missing)

Steps Taken

Install linux-surface kernel
The stock Debian kernel has poor Surface hardware support. Install the patched kernel from the linux-surface project:
bashwget -qO - https://raw.githubusercontent.com/linux-surface/linux-surface/master/pkg/keys/surface.asc
| gpg --dearmor | sudo dd of=/etc/apt/trusted.gpg.d/linux-surface.gpg

echo "deb [arch=amd64] https://pkg.surfacelinux.com/debian release main"
| sudo tee /etc/apt/sources.list.d/linux-surface.list

sudo apt update
sudo apt install linux-image-surface linux-headers-surface libwacom-surface
sudo reboot

Install IPU3 firmware
bashsudo apt install firmware-misc-nonfree
sudo cp /lib/firmware/intel/irci_irci_ecr-master_20161208_0213_20170112_1500.bin
/lib/firmware/intel/ipu3-fw.bin
Install libcamera and tools
bashsudo apt install libcamera-tools libcamera-ipa gstreamer1.0-libcamera
gstreamer1.0-tools gstreamer1.0-plugins-base gstreamer1.0-plugins-good
v4l-utils
Verify both cameras are detected
bashcam --list

Expected output:

1: Internal back camera (_SB_.PCI0.I2C3.CAMR)
2: Internal front camera (_SB_.PCI0.I2C2.CAMF)

Install and build v4l2loopback from source
The Debian package v4l2loopback-dkms 0.15.0 is incompatible with kernel 6.18.7-surface-1 due to changed V4L2 API signatures (v4l2_fh_add, v4l2_fh_del, removed setup_timer). Build from source instead:
bashsudo apt remove v4l2loopback-dkms
sudo apt install git dkms build-essential
git clone https://github.com/umlaeute/v4l2loopback.git
cd v4l2loopback
sudo make && sudo make install
sudo depmod -a
Sign the module for Secure Boot
Secure Boot is enabled on Surface Pro 5 by default. The module must be signed:
bashsudo apt install kmod openssl

Create signing key

openssl req -new -x509 -newkey rsa:2048 -keyout ~/mok.key
-out ~/mok.crt -days 3650 -subj "/CN=v4l2loopback/" -nodes

Convert to DER format

openssl x509 -in ~/mok.crt -outform DER -out ~/mok.der

Sign the module

sudo /usr/src/linux-headers-6.18.7-surface-1/scripts/sign-file
sha256 ~/mok.key ~/mok.crt
/lib/modules/6.18.7-surface-1/updates/v4l2loopback.ko

Enroll the key

sudo mokutil --import ~/mok.der
sudo reboot
On reboot, follow the blue MOK Manager screen: Enroll MOK → Continue → Yes → enter password → Reboot.

Load v4l2loopback with virtual devices
bashecho "options v4l2loopback devices=2 video_nr=20,21 card_label="Back Camera","Front Camera" exclusive_caps=1" |
sudo tee /etc/modprobe.d/v4l2loopback.conf

echo "v4l2loopback" | sudo tee /etc/modules-load.d/v4l2loopback.conf

sudo modprobe v4l2loopback

PipeWire sees both cameras natively
No GStreamer loopback pipeline needed — PipeWire detects both cameras automatically via libcamera:
bashwpctl status
You should see ov5693 (front) and ov8865 (rear) listed under Video Devices.
For Firefox, enable PipeWire camera support:

Go to about:config
Set media.webrtc.camera.allow-pipewire to true
Restart Firefox

Known Issue — Rear Camera Green Image
The rear camera (OV8865) produces a green image in all applications. This is a known upstream issue — the ov8865.yaml ISP tuning/calibration file does not exist for the Surface Pro 5's specific hardware implementation. Without it, libcamera runs in uncalibrated mode and cannot correctly process the Bayer sensor output.
This is not a configuration problem — it requires ISP tuning work by the linux-surface or libcamera community.
Tracking: https://github.com/linux-surface/linux-surface/wiki/Camera-Support

Tested March 2026. Kernel 6.18.7-surface-1. Debian 13 Trixie.

Hi,
Im trying to get Camera to work on Surface Pro 5 using Fedora 43 with Linux-Surface kernel, but it seems to be not possible.
Can You help me, please?
Best regards
Ernesto

@ernesto5600

Hi, Im trying to get Camera to work on Surface Pro 5 using Fedora 43 with Linux-Surface kernel, but it seems to be not possible. Can You help me, please? Best regards Ernesto

Hi @ernesto5600 @Catchitall I have a surface go 2 device (where it uses the same camera hardware with pro 5). I use Fedora 43 as well on my device and I have my cameras working out-of-the-box (I installed Fedora 44 first but I downgraded to 43)

What I did was I locked my kernel to 6.17 (which was Fedora 43 ISO is using by default). The reason is because (according to my research), there was a kernel regression with the newer kernels where one of the affected hardware was the one that IPU3 is using. As a result, even though we have kernel >= 6.14, it is not linking properly with the camera hardware. I have also tried the surface-kernel but for some reason it did not work so I reinstalled Fedora again to lock myself to 6.17

Just test the Camera first with the default Gnome camera before reinstalling on Fedora 43 ISO

Hope this will help you as both! 😁️

Thank you very much, Algerico,
will try this way.

Hey, remember us? 😄

We're back with a working fix for kernel 6.19 - because apparently
someone broke it again between 6.18 and 6.19.

Two bugs this time:

dw9719 lost its i2c_device_id table - blocks async notifier,
no cameras at all
int3472 GPIO 151 avdd quirk for model 1796 - you might remember
this one from our German documentation 🇩🇪

Fixed both. Also added a self-learning on-demand daemon and GTK
switcher while we were at it - because fixing it twice deserves
a reward.

Works perfectly on 6.19.8-surface-3.
Tested with OBS, Firefox, Cheese.

👉 https://github.com/EberhartLeberhart/surface-pro5-just-works

Please don't break it again 😄

Cheers

Hi Eberhard,
thank you very much for remember me and your support.
Tried to apply proposed solution, but got into an error.

Adding also System-Information

Should I do something before running the shared procedure?
Thank you once more and best regards
Ernesto

Hi again,
would like to add, that after that last update Touch-Screen is working. Excellent. Thank you!

@ernesto5600

@ernesto5600 Hi Ernesto!

Your system runs Fedora (fc43) which uses dnf
instead of apt. Our installer currently only
supports Debian/Ubuntu/Mint based systems.

Please install dependencies manually first:

sudo dnf install gcc make gstreamer1-tools
gstreamer1-plugins-good
gstreamer1-plugins-bad-free
libcamera-tools v4l-utils zenity
python3-gobject kernel-devel-$(uname -r)

Then run ./install.sh again.

Fedora support is coming in the next update! 🐐

Is your device a Surface Pro 5 i5?

Cheers

Hi Eberhard,
thank's a lot for fast response!
Yes, my device is a Surface Pro 5 i5.
And I will try as described and let you know.
Once more, thank's a lot!
Cheers

Hi Eberhard,
seems I'm not doing this right:

So I think I'll wait for upcomming Fedora support.
Thank you very much!

@ernesto5600

@ernesto5600 Entschuldigung für die falschen Paketnamen!
Auf Fedora heißen die Pakete etwas anders:

sudo dnf install gcc make gstreamer1
gstreamer1-plugins-good
gstreamer1-plugins-bad-free
v4l-utils zenity python3-gobject
kernel-devel-$(uname -r)

Für libcamera:
sudo dnf install libcamera libcamera-tools

Dann nochmal ./install.sh ausführen.

Wir passen den Installer gerade an damit Fedora
automatisch funktioniert – sollte nicht lange dauern!

Wir haben übrigens gemerkt dass du auch Deutsch sprichst –
war die ganze Zeit unnötig auf Englisch! 😄

Viele Grüße

@ernesto5600

@ernesto5600 Installer ist aktualisiert!
Fedora Paketnamen sind jetzt korrekt.

Einfach nochmal:
git clone https://github.com/EberhartLeberhart/surface-pro5-just-works.git
cd surface-pro5-just-works
chmod +x install.sh
./install.sh

Viele Grüße 🐐

@ernesto5600

@ernesto5600 Don't worry! 😄

We just noticed your terminal was in German
("Keine Übereinstimmung für Argument" instead of
"No match for argument") - that's all!
No tracking, no virus - just paying attention to your screenshot!

surface-info only collects hardware information,
no personal data - promised! 🐐

Cheers

Hallo Eberhard
klasse, vielen Dank.
Soll ich dann nur die letzte Nachricht berücksichtigen und folgende Befehle eingeben:

git clone https://github.com/EberhartLeberhart/surface-pro5-just-works.git
cd surface-pro5-just-works
chmod +x install.sh
./install.sh

Sorry, Du hast schon gemerkt, dass ich neu in der Linux Welt bin.
Vielen Dank und viele Grüße

Hallo Ernesto!

Ja genau, das sind die richtigen Befehle!
Einfach der Reihe nach eingeben:

git clone https://github.com/EberhartLeberhart/surface-pro5-just-works.git
cd surface-pro5-just-works
chmod +x install.sh
./install.sh

Der Installer macht dann alles automatisch.
Kein Stress wenn du neu bei Linux bist -
bei Problemen einfach melden! 😄

Viele Grüße

Hallo Eberhard,
super, vielen Dank.
Installation hat gut geklappt, nur Kernel Headers konnten nicht installiert werden.

Ist dann aber gut durchgelaufen. Kameras werden erkannt und können umgeschaltet werden:

Als nächstes mache ich den Reboot und schaue ob alles funktioniert.
Melde mich anschliessend.
Vielen Dank, herzlichen Glückwunsch und viele Grüße

Hallo Eberhard,
PERFEKT!! Glückwunsch!
Kamera funktioniert, Umschalter auch (Rückkamera zeigt nur grüne Landschaft, aber das stört mich nicht).
Aus meiner Sicht kann das Ticket geschössen werden.
Recht herzlichen Dank!

Viele Grüße
Ernesto

Hallo Ernesto,

das freut uns sehr – und Dir geben wir den Glückwunsch gleich zurück! Dein Test war nämlich mehr als nur ein Test: Du läufst auf KDE Plasma, wir auf GNOME. Dass der Umschalter bei Dir sauber erscheint, war der Beweis, dass die Wayland-Anpassung von gestern Nacht auch auf einer anderen Oberfläche funktioniert. Das hätten wir allein gar nicht prüfen können.

Zwei Dinge, die Du mit Deiner Rückmeldung direkt angestoßen hast:

1. Die Meldung "Kernel Headers konnten nicht installiert werden" – die tritt bei uns genauso auf und ist harmlos: Der linux-surface-Kernel bringt seine Header selbst mit, der Installer merkt es nur einen Schritt zu spät. Wir bauen das um, damit die Warnung gar nicht erst erscheint. Sie verunsichert unnötig.

2. Die grüne Landschaft der Rückkamera – schön, dass es Dich nicht stört, aber wir haben heute einiges dazu herausgefunden, und es ist reparierbar. Es sind sogar zwei Sachen, die zusammenkommen: Zum einen kommt das allererste Bild nach dem Systemstart beschädigt an (der Sensor schickt ein paar Bytes zu viel, der Kernel meckert das auch mit). Zum anderen fehlt auf Fedora noch eine Farbkorrektur-Datei, die wir auf unserem anderen System schon haben. Beides gehen wir an.

Das kommt mit Fix 4, an dem wir gerade arbeiten. Da ist noch mehr geplant:

die Kameras sollen sich automatisch umschalten, statt dass man den Knopf drücken muss
besseres Verhalten beim ersten Start nach dem Booten
die Farbkorrektur für die Rückkamera wird mitgeliefert
der Installer wird an ein paar Ecken aufgeräumt

Das Ticket kannst Du gerne schließen. Und falls Du Lust hast, melden wir uns, sobald Fix 4 testbereit ist – Deine Rückmeldungen waren wirklich hilfreich, gerade weil Du ein anderes System hast als wir.

Vielen Dank für Deine Geduld über die ganzen Runden hinweg!

Viele Grüße

Hallo Eberhard,
ich muss Dich nochmal stören.
Ich habe einen Bock geschossen. Hatte die Meldung, dass Aktualisierungen vorliegen (auch Sicherheit) und habe diese installiert.
Überraschung kam prompt, der Surface Kernel war weg:

Habe dann deine Anweisungen befolgt und folgendes ausgeführt:

sudo dnf install kernel-surface-6.18.8-1.surface.fc43
kernel-surface-core-6.18.8-1.surface.fc43
kernel-surface-modules-6.18.8-1.surface.fc43
kernel-surface-modules-core-6.18.8-1.surface.fc43
kernel-surface-devel-6.18.8-1.surface.fc43

sudo grubby --set-default /boot/vmlinuz-6.18.8-1.surface.fc43.x86_64
Nach einen Reboot war wieder alles OK:

Vielen Dank, nochmal!

Was mir noch aufgefallen ist, das Umschaltfenster popt andauernd hoch wenn man z.B. im FireFox unterwegs ist.
Lässt sich das irgendwie anders steuern?

Viele Grüße

Ernesto

Hallo Ernesto,

Du störst überhaupt nicht – im Gegenteil, beide Punkte sind wertvoll.

Zum Kernel: Das war kein Bock von Dir, das passiert leider bauartbedingt. Fedora-Updates ersetzen gerne den laufenden Kernel durch den Standard-Fedora-Kernel, und der kann die Surface-Kameras nicht. Dass Du selbst drauf gekommen bist, die kernel-surface-Pakete nachzuinstallieren und mit grubby wieder als Standard zu setzen – genau richtig. Ich schreib das als Hinweis in die Anleitung, damit es andere nicht kalt erwischt.

Zum Umschaltfenster: Guter Hinweis, das ist ein bekannter Schwachpunkt. Der Daemon erkennt bisher nur am Programmnamen, dass eine Kamera-App läuft – nicht, ob sie die Kamera wirklich benutzt. Deshalb springt er auch an, wenn Du nur surfst.

Schnelle Abhilfe: Du kannst Firefox aus der Liste nehmen:

sudo nano /etc/surface-kamera/known-apps.conf

Dort die Zeile firefox (und ggf. firefox-bin) löschen, speichern, dann:

systemctl --user restart surface-kamera-daemon

Danach ist beim normalen Surfen Ruhe.

Ein Haken dabei: Der Daemon lernt Apps selbstständig dazu, wenn sie die Kamera tatsächlich öffnen. Wenn Du also später mal eine Videokonferenz in Firefox machst, landet er wieder auf der Liste und fängt erneut an zu poppen. Dann einfach nochmal löschen – oder Du lässt es und benutzt den Aus-Knopf, wenn es stört.

Die richtige Lösung kommt mit Fix 4: Dann soll der Daemon nicht mehr auf den Programmnamen reagieren, sondern erst dann anspringen, wenn eine App die Kamera wirklich anfordert. Damit erledigt sich das Poppen von selbst.

Danke fürs Melden – genau solche Alltagsbeobachtungen sind es, die man beim eigenen Testen übersieht.

Viele Grüße

Hallo Eberhard,
vielen Dank! Da warte ich doch eventuell auf den Fix 4.
Nächste Frage. Wie kann ich Dich kontaktieren wenn ich mal Fragen habe und dieses Ticket nicht mehr da ist?
Habe eine Möglichkeit in der GitHub gesucht, bin aber nicht fündig geworden.

Viele Grüße
Ernesto

oh [email protected] haben wir Vergessen.

Hallo Ernesto,

wir habe die letzte Nacht durchgemessen und woll dir den Stand geben, weil sich einiges grundlegend geändert hat.

Die Ursache des grünen Bildes

Es ist der gebinnte Sensormodus des OV8865 (1632x1224). In diesem Modus erzeugt der Sensor zusätzliche Null- und ABLC-Zeilen, die der Treiber nicht mitmeldet. Der Kernel erwartet 2585088 Byte, es kommen 2588672 an, und ipu3-cio2 verwirft das Bild. Daher immer genau ein Frame und dann Stillstand.

Jede Anforderung, die den gebinnten Modus in einer Dimension überschreitet, erzwingt die volle Auflösung — und dann läuft alles sauber. Gemessen mit 1920x1080, 2560x1440, 3200x2432 und sogar 1280x1232. Bei 1280x720 bleibt es kaputt.

Es war nie ein Fedora-Problem

Dasselbe Verhalten auf Mint mit libcamera 0.2 und auf Fedora mit 0.7.1, mit identischen Byte-Zahlen. Distribution, libcamera-Version, Tuning-Datei und Kernelbau sind als Ursache ausgeschlossen.

Zwei Fehler im Kernel

Erstens fehlt dem dw9719-Treiber die i2c_device_id-Tabelle. Er kennt nur Device-Tree-Zuordnungen, deshalb bindet er auf ACPI-Systemen nie an das Gerät, das ov8865 anlegt — und der ganze Medienbaum bleibt unfertig, auch die Frontkamera. Auf einem frisch aufgesetzten Fedora ist das gut zu sehen: Das Modul liegt im Kernelpaket, wird aber nie gebunden.

Zweitens der Modusfehler oben. Beides wären kleine Patches.

Der libcamera-Selbstbau ist überflüssig

Auf Ubuntu-Basis fehlte nur das Paket libcamera-ipa. Mit ihm registriert schon libcamera 0.2 beide Kameras. Auf Fedora ist es ohnehin dabei.

Neue Richtung für Fix 4

libcamerasrc hat am Pad die Eigenschaft stream-role. Setzt ein Programm sie auf still-capture, wählt libcamera von selbst 3200x1800 statt der kaputten 1280x720 — auf beiden Systemen, auch mit der alten 0.2. Damit fallen Auflösungsraterei und ein großer Teil des bisherigen Daemons weg.

Das Ziel wäre, ganz ohne Daemon und Loopback auszukommen und die Kameras über PipeWire zu melden. Auf Fedora läuft PipeWire mit den Kameras schon ohne Absturz, auf Ubuntu-Basis stürzt die alte Fassung 1.0.5 noch ab.

Für den Installer gefunden

Der Benutzer landet nicht in der Gruppe video, libcamera-ipa und gstreamer1.0-libcamera fehlen, die Tuning-Dateien werden nicht abgelegt, und die README erklärt das grüne Bild noch falsch.

Wenn du Lust hast, wäre der interessanteste Test bei dir, ob deine Rückkamera mit einer großen Auflösung ebenfalls läuft:

cam -c 1 --capture=10 -s width=3264,height=2448 --file=/tmp/test-#.bin

Zehn Dateien statt einer, und wir hätten es auf einer dritten Maschine bestätigt.

Viele Grüße

Hi Ernesto,

there is something to test. Fix 4 is nearly there - a few small things are still open, but the important part is done.

It is not a daemon. Everything goes the official way now, the way it should have worked all along and did not, for reasons that are now understood. The daemon existed to work around a bug in the ov8865 driver: the mode registers were only ever written when the sensor woke up from runtime suspend, and on the Surface Pro 5 the sensor never suspends. So a format change never reached the chip, and only the full resolution ever worked. Four lines fix it.

I have added you to a private repository with the installer. It is not public yet because it is not finished.

./fix4-aufraeumen.sh --nur-pruefen    # only looks, changes nothing
./fix4-installer.sh
sudo reboot
cam --list

The first stage removes the leftovers of Fix 3. It asks before touching anything and moves files aside rather than deleting them. On your kernel 6.18 the dw9719 part should be skipped automatically - that is one of the things I would like to see confirmed, because I could only test the 6.19 case here.

If you want to go back afterwards, the daemon can be restored completely:

./fix4-installer.sh --rueckgaengig     # original kernel modules back
./fix4-aufraeumen.sh --zurueck         # daemon back

Do not run both at once - the daemon would grab the camera that the driver now handles on its own.

Tested here on Fedora 44 and on Linux Mint, both with kernel 6.19. Both cameras work in Firefox afterwards. One known issue that is not caused by the installer: the front camera delivers very dark images. Still open, still being looked at.

If something goes wrong, the surface-info script in the other repository collects the state - it is anonymised now, thanks for pointing that out.

Hallo Eberhard,
der Test der Rückkamera hat nicht funktioniert:
cam -c 1 --capture=10 -s width=3264,height=2448 --file=/tmp/test-#.bin

Werde als nächstes den Test für Fix 4 versuchen

Hi Eberhard,
sorry, the test for Fix 4 is not working for me:

Have stopped after that.
Best regards

Hi Ernesto,

good news first: your camera test did work. Ten frames at about 15 fps, 7.78 MB each. The line "Camera configuration adjusted" only means libcamera changed 3264x2448 to 3200x2432 - that is normal and happens here too.

What is not right is the image content, and your log says why:

Configuration file 'ov8865.yaml' not found, falling back to 'uncalibrated.yaml'
Configuration file 'ov5693.yaml' not found, falling back to 'uncalibrated.yaml'

Without a tuning file the IPA does no colour correction and no black level correction. That alone gives you a black or green image.

I have calibrated one for the OV8865 here, measured against a white background, and it is now in the repository. There is still none for the OV5693 - that one is on my list.

About Fix 4: my fault entirely, I never told you where to get it.

git clone https://github.com/EberhartLeberhart/surface-kamera-treiber.git
cd surface-kamera-treiber
chmod +x fix4-*.sh
./fix4-aufraeumen.sh --nur-pruefen
./fix4-installer.sh
sudo reboot

The tuning file comes with it, the installer puts it in place. Please read the README first - it lists what is known to be still open, and how to undo everything.

Team -Tunnel-

Hallo Eberhard,
vielen Dank.
Hier die Ergebnisse:

Werde jetzt rebooten. Viele Grüße

Hallo Eberhard,
SUPER. Vielen Dank!
Beide Kameras funktionieren!
Habe ich das richtig verstanden, ich könnte auch auf Fedora 44 mit kernel 6.19 wechseln?
Würde mir aber noch etwas Zeit damit lassen und erstmal ein voll funktionsfähiges System geniessen.
Toll. Vielen Dank auch an das Team, Ihr seid Super!
Viele Grüße
Ernesto

Hallo Ernesto,

das freut uns sehr — und danke fürs Testen. Du bist der Erste, bei dem es auf einem Gerät läuft, an dem von uns nie jemand selbst gesessen hat. Das ist für uns mehr wert als jeder eigene Testlauf.

Zu deiner Frage: Ja, Fedora 44 mit Kernel 6.19 funktioniert, das läuft hier so. Der Installer erkennt selbst, was auf dem jeweiligen Kernel nötig ist — bei dir auf 6.18 hat er den dw9719-Teil übersprungen, auf 6.19 macht er ihn mit.

Aber genieß erst mal dein funktionierendes System. Es gibt keinen Grund zur Eile, und ein laufendes Gerät ist mehr wert als die neueste Nummer.

Eine Sache solltest du wissen, egal ob du wechselst oder bleibst: Nach jedem Kernelupdate muss der Installer erneut laufen. Ein neuer Kernel bringt sein eigenes Modulverzeichnis mit, die gepatchten Treiber sind dann nicht mehr dabei, und die Kameras fallen ohne Meldung aus. Das lässt sich später automatisieren, bisher ist es Handarbeit.

Und was bei dir vermutlich auch noch auffällt: Die Rückkamera steht auf dem Kopf. Daran sitzen wir gerade.

Viele Grüße

Team -Tunnel-

Navigation Menu

Repository navigation

Getting Cameras Working on Surface Pro 5 (Debian 13 / Trixie) #2045

Create signing key

Convert to DER format

Sign the module

Enroll the key

34 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Getting Cameras Working on Surface Pro 5 (Debian 13 / Trixie) #2045

Description

Create signing key

Convert to DER format

Sign the module

Enroll the key

Activity

ernesto5600 commented on Jun 24, 2026

algerico-abad commented on Jun 30, 2026

ernesto5600 commented on Jul 1, 2026

EberhartLeberhart commented on Jul 19, 2026

ernesto5600 commented on Jul 20, 2026

ernesto5600 commented on Jul 20, 2026

EberhartLeberhart commented on Jul 20, 2026

ernesto5600 commented on Jul 20, 2026

ernesto5600 commented on Jul 20, 2026

ernesto5600 commented on Jul 20, 2026

EberhartLeberhart commented on Jul 20, 2026

EberhartLeberhart commented on Jul 20, 2026

EberhartLeberhart commented on Jul 20, 2026

ernesto5600 commented on Jul 20, 2026

EberhartLeberhart commented on Jul 20, 2026

34 remaining items

ernesto5600 commented on Jul 23, 2026

ernesto5600 commented on Jul 23, 2026

EberhartLeberhart commented on Jul 23, 2026

ernesto5600 commented on Jul 23, 2026

EberhartLeberhart commented on Jul 23, 2026

ernesto5600 commented on Jul 23, 2026

EberhartLeberhart commented on Jul 23, 2026

EberhartLeberhart commented on Jul 25, 2026

EberhartLeberhart commented on Jul 26, 2026

ernesto5600 commented on Jul 27, 2026

ernesto5600 commented on Jul 27, 2026

EberhartLeberhart commented on Jul 28, 2026

ernesto5600 commented on Jul 28, 2026

ernesto5600 commented on Jul 28, 2026

EberhartLeberhart commented on Jul 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions