Kdenlive monitor issue solved by AI - Debian 13 KDE Plasma _ Kicksecure.cli Hardened

Title

Kdenlive Clip/Project Monitor missing or grey after Kicksecure/Whonix “software rendering in VMs” profile sets QMLSCENE_DEVICE=softwarecontext


Summary

After applying Kicksecure/Whonix environment hardening (specifically the script /etc/profile.d/20_software_rendering_in_vms.sh), Kdenlive started launching but the Clip Monitor and Project Monitor were either missing or showed a grey/empty area. Audio playback still worked.

The issue occurred across:

  • Debian-packaged Kdenlive

  • Flatpak version

  • AppImage version

So it was not package-specific.


System context

  • Debian-based system with Kicksecure hardening

  • KDE Plasma / Qt-based desktop

  • AMD Radeon Graphics (radeonsi, Renoir)

  • OpenGL working normally (glxinfo shows AMD renderer)

  • VAAPI functional (verified via vainfo)

  • MLT works correctly (melt runs SDL/XGL consumers)


Symptom

  • Kdenlive starts normally

  • Project opens

  • Timeline works

  • Audio playback works

  • Video monitors (Clip/Project) are missing or grey

  • Multiple QML warnings appear


Debug findings

The key issue was an environment variable:


QMLSCENE_DEVICE=softwarecontext

This was set globally by:


/etc/profile.d/20_software_rendering_in_vms.sh

Script logic summary:

  • checks eglinfo

  • if it detects llvmpipe, forces:

    
    
    export QMLSCENE_DEVICE=softwarecontext
    
  • intended for VM fallback rendering safety

However on this system:


eglinfo shows BOTH:
- AMD Radeon (radeonsi)
- llvmpipe (secondary contexts)

This caused a false positive detection, triggering software rendering mode even though hardware acceleration is available.


Root cause

The script assumes:

if ANY llvmpipe appears → system is software-rendered → force Qt software rendering

But modern systems may show:

  • multiple EGL contexts

  • mixed renderer outputs

  • fallback llvmpipe contexts alongside real GPU contexts

This results in incorrect global environment override.


Fix

Temporary per-session fix:


unset QMLSCENE_DEVICE
kdenlive

Or safer launch wrapper:


alias kdenlive='env -u QMLSCENE_DEVICE kdenlive'

Result

After unsetting QMLSCENE_DEVICE, Kdenlive monitors immediately worked again (Clip + Project Monitor restored, GPU rendering functional).


Recommendation

  • Avoid global forcing of QMLSCENE_DEVICE=softwarecontext on hybrid systems

  • Improve EGL detection logic to ensure:

    • AMD/NVIDIA GPU presence takes priority over llvmpipe fallback contexts

    • or require only llvmpipe, not “any occurrence”


Optional note

This likely affects other Qt Quick / QML applications, not only Kdenlive.


1 Like

eglinfo reports multiple EGL contexts, including llvmpipe fallback renderers, causing a false positive in a simplistic detection script.

“Suggested improvement generated with assistance from ChatGPT and refined for correctness.”

#!/bin/sh

# Require eglinfo

if ! command -v eglinfo >/dev/null 2>&1; then
true “$0 ERROR: eglinfo not found. Stop.”
return 0
exit 0
fi

# Capture primary OpenGL renderer (more meaningful than scanning all contexts)

primary_renderer=“$(eglinfo 2>/dev/null | grep -m 1 “OpenGL core profile renderer”)”

if \[ -z “$primary_renderer” \]; then
true “$0 INFO: No OpenGL renderer detected. Stop.”
return 0
exit 0
fi

# Check for full software rendering ONLY

# (must be explicitly llvmpipe as primary renderer)

echo “$primary_renderer” | grep “llvmpipe” >/dev/null 2>&1
if \[ $? -eq 0 \]; then
software_rendering_use=true
fi

# If not explicitly software-rendered system → do nothing

if \[ ! “$software_rendering_use” = “true” \]; then
true “$0 INFO: Hardware rendering detected. Stop.”
return 0
exit 0
fi

# Respect existing user overrides

if \[ ! -z “$QMLSCENE_DEVICE” \]; then
true “$0 INFO: QMLSCENE_DEVICE already set. Not changing.”
return 0
exit 0
fi

export QMLSCENE_DEVICE=softwarecontext

ChatGPT is impressive but for this kind of operating system problems it,

  • lacks access to the tools such as eglinfo
  • lacks access to comparable environments (Kicksecure, virtualizers such as VirtualBox, graphic cards),

hence ChatGPT can only talk from theory and not test any code in all environments end-to-end.

Are you using a hardware or a VM?

Because if using hardware, source file vm-config-dist/etc/profile.d/20_software_rendering_in_vms.sh at master · Kicksecure/vm-config-dist · GitHub isn’t installed by default as package vm-config-dist is installed by default inside VMs only.

If you are using a VM, then related documentation chapters are:

Related forum thread:

GBM fails with EGL on AMD Kaveri - Fedora Discussion shows eglinfo output with both.

OpenGL core profile renderer: llvmpipe
OpenGL core profile renderer: AMD

So greping for AMD (and others) is a good idea. Will implement.

2 Likes

runs on Hardware per Debian Distro Morphing - iGPU AMD Radeon Graphics + Geforce RTX xxxx (Compute Only Nvidia Open Drivers).

20_software_rendering_in_vms.sh exists in my /etc/profile.d, btw

vm-config-dist is installed?

Package Version Check

dpkg -l vm-config-dist

If yes, that is the primary bug here. vm-config-dist shouldn’t be installed on bare metal. (It’s designed to not cause bugs on bare metal and will be improved nonetheless.)

Can vm-config-dist be removed without meta package removal?

sudo apt purge vm-config-dist

Which meta package did you install during distribution morphing?

…installed by Metapaket kicksecure-baremetal-cli,

can not be removed without removal Metapaket:

[user ~]% dpkg -l vm-config-dist
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name Version Architektur Beschreibung
++±==============-============-============-==============================================
ii vm-config-dist 3:16.0-1 all usability enhancements inside virtual machines

2 Likes

apt-cache rdepends vm-config-dist
vm-config-dist
Reverse Depends:
dist-general-cli

apt-cache depends kicksecure-baremetal-cli
kicksecure-baremetal-cli
Hängt ab von (vorher): legacy-dist
Hängt ab von: kicksecure-nonqubes-cli
Hängt ab von: kicksecure-general-cli
Hängt ab von: dist-baremetal-cli
Hängt ab von: dist-nonqubes-cli
Hängt ab von: dist-general-cli
Hängt ab von: ram-wipe
Hängt ab von: wpasupplicant
Beschädigt:
Beschädigt:
Ersetzt:
Ersetzt:

apt-mark showmanual | grep -E “kicksecure|vm-config|whonix”
kicksecure-baremetal-cli

dpkg -S /etc/profile.d/20_software_rendering_in_vms.sh
vm-config-dist: /etc/profile.d/20_software_rendering_in_vms.sh

2 Likes

vm-config-dist/etc/profile.d/20_software_rendering_in_vms.sh at master · Kicksecure/vm-config-dist · GitHub

2 Likes

And credit where it’s due: Patrick didn’t just explain the behavior—he appears to have hardened the detection logic so that your exact AMD + llvmpipe mixed-renderer case won’t trigger the override anymore. That’s a pretty good outcome from a forum bug report. :blush:

(by my AI Assistant) - thanks for quick fix Patrick!

3 Likes

About the vm-config-dist package installed by default on a host operating system…

In the past, we’ve decided to

  • A) make the vm-config-dist safe for installation on host systems; and
  • B) install vm-config-dist by default in both contexts, on the host operating system and inside VMs.

As it turns out, A) had not been entirely bug free. And B) might be re-considered.

2 Likes

I’m not sure we need to immediately think about undoing this. It’s a bit of a pain to remove packages from end-user systems (we can mark them as autoremovable, but that depends on the user running sudo apt autoremove, which they might just not do). This is also the first bug that has surfaced from doing this, and it looks like it had a good solution.

If we get enough reports (or severe enough reports) to lead us to believe that vm-config-dist is dangerous on end-user machines, then I would agree that we should reconsider B.

2 Likes

I can +1 on this one. I have an Intel card that reports lvmpipe but fix: do not enable software rendering simply because `lvmpipe` is req… · Kicksecure/vm-config-dist@2182395 · GitHub solved it for me. It took me quite a while to pinpoint the issue though.

My gut feeling is adding common vendors should be enough for issues in this thread. I don’t know what else vm-config-dist does. (The name is a bit misleading since it’s installed on bare metal too. But changing the name is equally if not more disruptive.)

I don’t personally think it’s misleading. It ships configuration and programs that are only useful on virtual machines, and those things are supposed to only enable themselves on virtual machines, so it is still VM configuration. Having it present even on baremetal is useful for if you want to boot a physical hardware installation in a VM, and having it not cause problems on physical hardware is useful for if you want to boot a VM installation on physical hardware.

1 Like