softhdcuvid jetzt mit VAAPI und HDR support

Quote from CKone

weder mit der einen noch mit der anderen Erweiterung bekomme ich ein Bild auf den hdmi1 nach reboot, selbst wenn der TV an ist. - der vdr startet allerdings.

Ich weiß gerade nicht, ob er das initramfs bei einem update-grub automatisch mitbaut - ansonsten vorher mal ein sudo update-initramfs -u machen.

Hallo zusammen,

ich versuche schon seit Monaten vergeblich, meiner Intel-GPU eine feste Auflösung beim Booten zuzuweisen, denn ohne eingeschalteten Monitor beim Booten gibt es kein Bild vom X-Server (nach diesem Thread: Zusammenfassung Intel VAAPI & edid.bin).

Dazu hatte ich auch die edid ausgelesen, sie mir aber jetzt erst mit edid-decode angeschaut. Und wundere mich gerade, dass max. Full-HD darin angegeben wird, obwohl ich (auch aktuell) mit 2560*1440 unterwegs bin - und diese Auflösung auch beim Booten generell eingestellt haben möchte, wie es bei eingeschaltetem Monitor automatisch geschieht ...

edid-decode /sys/class/drm/card0/card0-DP-1/edid 
EDID version: 1.4
Manufacturer: DEL Model 40ea Serial Number 1110530387
Made in week 45 of 2018
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
Gamma: 2.20
DPMS levels: Off
Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
First detailed timing includes the native pixel format and preferred refresh rate
Display x,y Chromaticity:
  Red:   0.6396, 0.3300
  Green: 0.2998, 0.5996
  Blue:  0.1503, 0.0595
  White: 0.3134, 0.3291
Established timings supported:
  720x400@70Hz 9:5 HorFreq: 31469 Hz Clock: 28.320 MHz
  640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
  640x480@75Hz 4:3 HorFreq: 37500 Hz Clock: 31.500 MHz
  800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz
  800x600@75Hz 4:3 HorFreq: 46900 Hz Clock: 49.500 MHz
  1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz
  1024x768@75Hz 4:3 HorFreq: 60000 Hz Clock: 78.750 MHz
  1280x1024@75Hz 5:4 HorFreq: 80000 Hz Clock: 135.000 MHz
Standard timings supported:
  1152x864@75Hz 4:3 HorFreq: 67500 Hz Clock: 108.000 MHz
  1600x1200@60Hz 4:3 HorFreq: 75000 Hz Clock: 162.000 MHz
  1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz
  1920x1080@60Hz 16:9
Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm
               2560 2608 2640 2720 hborder 0
               1440 1443 1448 1481 vborder 0
               +hsync -vsync 
               VertFreq: 59 Hz, HorFreq: 88786 Hz
Serial number: J0XYN8BAB1YS
Monitor name: DELL U2717D
Monitor ranges (bare limits): 50-75Hz V, 30-88kHz H, max dotclock 250MHz
Has 1 extension blocks
Checksum: 0x1f (valid)

CTA extension block
Extension version: 3
24 bytes of CTA data
  Video data block
    VIC  16 1920x1080@60Hz 16:9 (native) HorFreq: 67500 Hz Clock: 148.500 MHz
    VIC   5 1920x1080i@60Hz 16:9  HorFreq: 33750 Hz Clock: 74.250 MHz
    VIC   4 1280x720@60Hz 16:9  HorFreq: 45000 Hz Clock: 74.250 MHz
    VIC   3 720x480@60Hz 16:9  HorFreq: 31469 Hz Clock: 27.000 MHz
    VIC   2 720x480@60Hz 4:3  HorFreq: 31469 Hz Clock: 27.000 MHz
    VIC   7 1440x480i@60Hz 16:9  HorFreq: 15734 Hz Clock: 27.000 MHz
    VIC  22 1440x576i@50Hz 16:9  HorFreq: 15625 Hz Clock: 27.000 MHz
    VIC   1 640x480@60Hz 4:3  HorFreq: 31469 Hz Clock: 25.175 MHz
    VIC   6 1440x480i@60Hz 4:3  HorFreq: 15734 Hz Clock: 27.000 MHz
    VIC  17 720x576@50Hz 4:3  HorFreq: 31250 Hz Clock: 27.000 MHz
    VIC  18 720x576@50Hz 16:9  HorFreq: 31250 Hz Clock: 27.000 MHz
    VIC  21 1440x576i@50Hz 4:3  HorFreq: 15625 Hz Clock: 27.000 MHz
    VIC  19 1280x720@50Hz 16:9  HorFreq: 37500 Hz Clock: 74.250 MHz
    VIC  20 1920x1080i@50Hz 16:9  HorFreq: 28125 Hz Clock: 74.250 MHz
    VIC  31 1920x1080@50Hz 16:9  HorFreq: 56250 Hz Clock: 148.500 MHz
  Audio data block
    Linear PCM, max channels 2
      Supported sample rates (kHz): 96 88.2 48 44.1 32
      Supported sample sizes (bits): 24 20 16
  Speaker allocation data block
    Speaker map:
      FL/FR - Front Left/Right
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes
Detailed mode: Clock 148.500 MHz, 597 mm x 336 mm
               1920 2008 2052 2200 hborder 0
               1080 1084 1089 1125 vborder 0
               +hsync +vsync 
               VertFreq: 60 Hz, HorFreq: 67500 Hz
Detailed mode: Clock 147.180 MHz, 597 mm x 336 mm
               2048 2096 2128 2208 hborder 0
               1080 1083 1093 1111 vborder 0
               +hsync -vsync 
               VertFreq: 59 Hz, HorFreq: 66657 Hz
Detailed mode: Clock 74.250 MHz, 597 mm x 336 mm
               1280 1390 1430 1650 hborder 0
                720  725  730  750 vborder 0
               +hsync +vsync 
               VertFreq: 60 Hz, HorFreq: 45000 Hz
Detailed mode: Clock 58.230 MHz, 597 mm x 336 mm
               2048 2096 2128 2208 hborder 0
               1080 1083 1093 1099 vborder 0
               +hsync -vsync 
               VertFreq: 23 Hz, HorFreq: 26372 Hz
Checksum: 0x72 (valid)

Dies als Gegenbeweis, dass der Monitor mehr kann (aktuelle Auflösung):

xrandr 
Screen 0: minimum 8 x 8, current 2560 x 1440, maximum 32767 x 32767
DP1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440     59.95*+
   2048x1080     60.00    24.00  
   1920x1080     60.00    50.00  
   1920x1080i    60.00    50.00  
   1600x1200     60.00  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1280x720      60.00    50.00  
   1440x576i     50.00  
   1024x768      75.03    60.00  
   1440x480i     59.94  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    59.94  
   720x400       70.08  
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Hat hier jemand eine gute Idee, warum das so ist und wie ich das beheben könnte?

Denn, wenn diese Werte wirklich nur in der EDID stehen, kann "natürlich" nicht beim Booten die 2560*1440er-Auflösung gesetzt werden.

Entschuldigt bitte das Reingrätschen, die Diskussion passt aber gerade sehr gut auf das Problem ...

Danke vielmals und viele Grüße,

Chriss

Quote from theonlychriss

Und wundere mich gerade, dass max. Full-HD darin angegeben wird,

Der Mode mit 2560x1440 ist schon dabei:

Quote from theonlychriss

Code

Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm																								               2560 2608 2640 2720 hborder 0																								               1440 1443 1448 1481 vborder 0																								               +hsync -vsync 																								               VertFreq: 59 Hz, HorFreq: 88786 Hz

Wie genau sehen deine Boot-Optionen aus?

Hey Seahawk,

ups - Wald und Bäume!? Danke fürs Aufzeigen!

Meine Boot-Parameter sind diese:

linux   /boot/vmlinuz-5.3.0-26-generic root=UUID=22222222-2222-2222-2222-222222222222 ro  quiet splash video=DP-1:2560x1440@59.95D drm.edid_firmware=DP-1:edid/edid.bin $vt_handoff
initrd  /boot/initrd.img-5.3.0-26-generic

Ich habe auch das mit dem Einbinden der edid mit dem im o.g. Thread angegebenen Hook, samt update-grub schon mehrfach gemacht.

#!/bin/sh
PREREQ="udev"
prereqs()
{
   echo "$PREREQ"
}
case $1 in
prereqs)
   prereqs
   exit 0
   ;;
esac
. /usr/share/initramfs-tools/hook-functions
# Begin real processing below this line
if [ ! -e "${DESTDIR}/lib/firmware/edid" ]; then
    mkdir -p "${DESTDIR}/lib/firmware/edid"
fi
if [ -r "/lib/firmware/edid/edid.bin" ]; then
   cp "/lib/firmware/edid/edid.bin" "${DESTDIR}/lib/firmware/edid/"
fi
manual_add_modules i915 radeon
exit 0

Meine edid liegt an dieser Stelle:

"Original":
/lib/firmware/edid/edid.bin

wird dann hierher kopiert:
/usr/lib/firmware/edid/edid.bin

Viele Grüße,

Chriss

Quote from seahawk1986

Ich weiß gerade nicht, ob er das initramfs bei einem update-grub automatisch mitbaut - ansonsten vorher mal ein sudo update-initramfs -u machen.

tut er nicht aber es ändert auch nichts wenn ich die initrd vorher aktualisiere.

ich teste das nochmal in Ruhe, denke ich muss das auch noch in die X11 Device Section wie bei fnu einsetzten. - vermutlich sitzt das Problem hier vor dem PC...

Quote from jojo61

Aber was mir auch aufgefallen ist, dein EDID ist Version 1.3 und das liest der Treiber nicht vollständig aus. Da wäre es besser du änderst es auf 1.4 und versorgst es per initram.

da sagst du was, wie sollte ich die Version beeinflussen?

Guten Tag,

jojo61 danke für die Arbeit auf dem softhd plugin...

Ich habe mich gestern den frischen vdr-plugin-softhdvaapi übersetzt. Gut dokumentiert, ohne probleme kompiliert. Nur bei dem ersten Start erhalte ich folgenden Fehler:

vdr: /lib/libavfilter.so.7: symbol av_sscanf version LIBAVUTIL_56 not defined in file libavutil.so.56 with link time reference

Ein bloßer ldconfig hat keinen Effekt.

Libplacebo habe ich nicht einkompiliert. Die erforderlichen Libraries habe ich aus dem Debian 10 Repo installiert:

aptitude install libglew-dev freeglut3-dev libglm-dev

FFMPEG ist 4.2.1 von GIT-Quellen, lange vor den oben bemerkten Libs durch make install in das System eingebracht.

VDR 2.4.1 und die frische VAAPI wurden auch von Quellen kompiliert (VAAPI aus dem GIT).

Wann ich den vdr-plugin-vaapidevice anstatt vdr-plugin-softhdvaapi lade, startet VDR ohne jegliches Problem.

Der ganze Script lautet

#!/bin/sh
VDR_BIN='/usr/bin/vdr'
VDR_PLUGINS_DIR='-L /usr/lib/vdr'
export ALSA_DEVICE=default

$VDR_BIN $VDR_PLUGINS_DIR --plugin="softhdvaapi -a pulse" --plugin=femon --plugin=wirbelscan

Eher als ein Coder bin ich ein System-Klempner.

Ich versuchte mit Google und auf dem vdr-portal.de zu suchen, aber es gibt keine passenden Ergebnisse.

Leider habe ich die 20 Seiten dieses Threads nicht hindurch gelesen (TL;DR).

Ich wäre dankbar für irgend einen Rat

Quote from theonlychriss

video=DP-1:2560x1440@59.95D

Da es nur eine Refreshrate für die Auflösung gibt würde ich mal video=DP-1:2560x1440e bzw. video=DP-1:e probieren (was nach meinem Verständnis genügen sollte, wenn 2560x1440 die bevorzugte Auflösung des Monitors ist) - nich dass es daran scheitert, dass er keinen passenden Mode für die "krumme" Refreshrate findet.

Nachdem bei mir immer noch kein OSD mit vaapi angezeigt wird habe ich mal drm ausprobiert und da bekomme ich das OSD angezeigt, aber nach kurzer Zeit ruckelt das Bild, es gibt Artefakte bis zur Unkenntlichkeit des Bildes und buffer overflows im Log. Die GPU ist zwar lt. gpu-top zu 25% mit rendern beschäftigt, aber offenbar wird ja ein Großteil der Arbeit von der CPU verrichtet. Wo wird das das konfiguriert, wo kann man da was nachsehen?

Kann für das OSD mit vaapi irgendwo Testcode in das Plugin einbauen? Wenn ja wo?

Quote from jojo61

Da stimmt etwas mit deiner ffmpeg installation nicht. libavfilter und libavutil vertragen sich nicht. Sind wohl aus unterschiedlichen ffmpeg versionen.

Sie haben natürlich recht - Danke

Noch zu dem Problem mit den Libs, strace hat folgendes gezeigt:

openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavutil.so.56", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavcodec.so.58", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib/libavfilter.so.7", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib/libavformat.so.58", O_RDONLY|O_CLOEXEC) = 4

Hm. Es ist sicher meine eigene Schuld, daß ich Sachen direkt mit "make install" installiere, anstatt zuerst einen .DEB daraus zu machen.

Die Version aus dem Debian Repo hat wahrscheinlich als eine Dependency mit manchem anderen Programm gekommen.

Also als ein Workaround habe ich /lib auf die erste Zeile in /etc/ld.so.conf eingefügt, und ldconfig durchgeführt. Danach arbeitet das softhdvaapi schon normal - fast ausgezeichnet, eher

Komisch ist, das danach vaapidevice nicht mehr arbeitet. VDR mit vaapidevice startet, aber ohne das Bild, nur mit Audio. Auch top sagt mir, daß die CPU-Kerne nicht so belastet sind, als wann es das Bild gibt. Wann ich die Zeile mit /lib aus ld.so.conf entnehme, startet vaapidevice wieder normal. Ich habe versucht, VDR und FFMPEG mit /lib in dem ld.so.conf wieder zu übersetzen und re-installieren, aber das hat gar keinen Effekt... vielleicht später kann ich das weiter forschen, jetzt gibt es keine Zeit mehr und ich habe schon einen arbeitenden Ausgangs-Plugin. Halelujah

Quote from jojo61

frr Schön wenn es nun läuft. Hast du das vaapidevice mal mit den neuen ld.so.conf einstellungen compiliert ??

jojo61 Danke daß Sie sich kümmern

Das Mysterium rund um die Libs im vaapidevice ist mir kein großes Problem.

Aber ja, das war sicher eine der ersten Sachen die ich versucht habe:

cd /usr/src/vdr-2.4.1
make clean
make clean-plugins
# ./configure --prefix=/usr  # gibt es eine? Bin ich nicht mehr sicher
make -j 4
make install

Ich habe durch dem Log zurück gelesen, daß die Plugins wirklich neu kompiliert und linkt wurden und neu installiert.

Anscheinend alle Dateien wurden erneuert, aber es hat nicht geholfen.

Dasselbe habe ich später mit dem FFMPEG getan.

Auch kein Unterschied.

Vielleicht sollte ich noch kucken, welche headers die Kompilier-Stufe ladet? Die werden von dem ldconfig nicht umgeschaltet...

Aber es ist mir jetzt etwas egal

Ich könnte darauf noch mal wieder mit strace kucken - um manchen Unterschied in der Liste der geladenen Libs zu finden.

Wichtig ist, das softhdvaapi für mich arbeitet, und daß ich auch vaapidevice anwenden kann, sollte ich mich dazu noch zurückkehren wollen.

Quote from jojo61

Das DRM plugin nutzt ja auch vaapi als dekoder. Ich bin immer noch der Ansicht das die glew installation nicht sauber ist. DRM nutzt im OSD kein glew und VAAPI nutzt glew im OSD. Wenn man glew neu übersetzt und dann mit ldconfig lädt, dann übermangelt Suse es wieder mit der alten Version. Deswegen sollte man es nach usr/local/lib installieren und im ld.so.conf den Pfad /usr/local/lib nach vore legen. Dann nimmt er die neue glew zuerst.

Da hast Du insofern Recht als dass in meinem selbstgebauten RPM noch ein Fehler drin war (beim install baute er es nochmal ohne EGL). Jetzt passt es aber:

# ldconfig
# ldd /usr/lib64/vdr/libvdr-softhdvaapi.so.2.4.1|grep -i glew
        libGLEW.so.2.1 => /usr/lib64/libGLEW.so.2.1 (0x00007fb7f3b3e000)
# ldd /usr/lib64/libGLEW.so.2.1|grep -i egl
        libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007fea10548000)

Erfolg hat das aber nicht gebracht:

vdr: [1808] oglThread thread started (pid=1724, tid=1808, prio=high)
vdr: [1808] [softhddev]OpenGL using display :0
vdr: [1808] [softhddev]glewInit failed with 'Missing GL version', aborting
vdr: [1808] [softhddev]Could not initiate OpenGL Context
vdr: [1808] [softhddev]OglThread cleanup
vdr: [1808] oglThread thread ended (pid=1724, tid=1808)

Ich habe schon versucht die GL Version zu setzen im Source Code oder mit MESA Umgebungsvariable, ohne Erfolg. Auch mit und ohne .drirc

Update: Ein Testprogramm liefert jetzt ebenfalls bei glewInit() keine GL Version - ich versuche das mal zu debuggen

Update2: in libglew schlägt eglInitialize() fehl, sowohl auf dem Nvidia-PC als auch auf dem Intel-PC. EGL Libs scheinen aber alle installiert zu sein

Quote from jojo61

FireFly Ich denke du musst das glewinit mal debugen. Das Missing GL version kommt ja daher und da musst du mal in den Quellen schauen wo das erzeugt wird. Soweit ich das gesehen habe gibt es da eine Funktion die die aktuelle GL Version versucht zu ermitteln und das geht bei dir irgendwie schief. Da musst du mal ein paar debug prints reinbauen um zu sehen wo es hackt.

Ja, genau das habe ich ja gemacht. Allerdings kann er die GL Version in glewInit() ermitteln, aber anschließend ruft glewInit() die Funktion eglewInit() auf wo es dann fehlschlägt (das GLEW_ERROR_NO_GL_VERSION ist so ne Art Universalfehlmeldung wenn beim Init irgendetwas schief geht):

/* Load necessary entry points */
  initialize = (PFNEGLINITIALIZEPROC)   glewGetProcAddress("eglInitialize");
  queryString = (PFNEGLQUERYSTRINGPROC) glewGetProcAddress("eglQueryString");
  if (!initialize || !queryString)
    return 1;                                       // <== das return wird nicht aufgerufen

  /* query EGK version */
  if (initialize(display, &major, &minor) != EGL_TRUE)  //<== das initialize (=eglInitialize) liefert EGL_FALSE zurück
    return 1;      // <== '1' == GLEW_ERROR_NO_GL_VERSION

Das eglInitialize steht dann in libEGL, das wiederum Funktionen in libglnvd aufruft, was an die HW-spezifischen Treiber weiterleitet oder so. Das habe ich nicht weiter gedebuggt.

Hast Du wirklich nur das ligGLEW selbst kompiliert? Mir kommt es so vor, als würde da bei mir noch was fehlen. Immerhin meldet das Beispielprogramm auch den Fehler, ist also reproduzierbar. Wenn man das return aber auskommentiert läuft es ohne sichtbare Probleme weiter :->

Der OpenGL Benchmark glmark2-es2 bricht ebenfalls ab, glmark2 (ohne ES) funtkioniert. Geht das bei Dir?

Was gibt bei Euch denn ein glxinfo | grep OpenGL aus? Ist das normal dass dort oben 4.5 als Core Profile steht, aber unten dann nur 3.0 als version string? Bei VAAPI scheint das "normal" zu sein, bei NVidia steht da die gleiche OpenGL version wie bei core Profile: OpenGL version string: 4.6.0 NVIDIA 390.132

OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.2
....
OpenGL version string: 3.0 Mesa 18.3.2

Hi,

I see another issue with the drm version here, not sure if it is fixable.

I do use also the old mpv plugin, which I got working for softhdvaapi but did crash with drm.

Jan  8 00:04:13 localhost vdr: [14316] [mpv] cMpvControl
Jan  8 00:04:13 localhost vdr: [14316] [softhddev]SetPlayMode: 0
Jan  8 00:04:13 localhost vdr: Set Playmode 0
Jan  8 00:04:13 localhost vdr: video: set closing
Jan  8 00:04:13 localhost vdr: video: set clock --:--:--.---
Jan  8 00:04:13 localhost vdr: video: reset start
Jan  8 00:04:13 localhost vdr: video: set clock --:--:--.---
Jan  8 00:04:13 localhost vdr: video: new stream start
Jan  8 00:04:13 localhost vdr: [14316] [softhddev]SetVideoDisplayFormat: 1
Jan  8 00:04:13 localhost vdr: [14316] [softhddev]GetSpuDecoder:
Jan  8 00:04:13 localhost vdr: [14316] [softhddev]SetPlayMode: 5
Jan  8 00:04:13 localhost vdr: [14316] [softhddev] play mode external
Jan  8 00:04:13 localhost vdr: [softhddev]Suspend:
Jan  8 00:04:13 localhost vdr: Video Exit
Jan  8 00:04:13 localhost vdr: cuvid del hw decoder 
Jan  8 00:04:13 localhost vdr: video/cuvid: CuvidDestroySurfaces
Jan  8 00:04:13 localhost vdr: Last decoder closes
Jan  8 00:04:13 localhost vdr: video/cuvid: 0 missed, 32 duped, 0 dropped frames of 315,475
Jan  8 00:04:13 localhost vdr: CuvidExit
Jan  8 00:04:13 localhost vdr: video: video thread canceled
Jan  8 00:04:13 localhost vdr: decoder thread exit
Jan  8 00:04:13 localhost vdr: [14332] device 1 receiver thread ended (pid=14316, tid=14332)
Jan  8 00:04:13 localhost vdr: display thread exit
Jan  8 00:04:13 localhost vdr: video/egl: EglExit
Jan  8 00:04:13 localhost vdr: drm clean up
Jan  8 00:04:13 localhost vdr: VideoStreamClose
Jan  8 00:04:13 localhost vdr: CodecVideoClose
Jan  8 00:04:13 localhost vdr: [14316] [softhddev]stopping Ogl Thread pmExtern_THIS_SHOULD_BE_AVOIDED
Jan  8 00:04:13 localhost vdr: [14316] [softhddev]stopping OpenGL Worker Thread 
Jan  8 00:04:13 localhost vdr: [14353] [softhddev]Cleaning up OpenGL stuff
Jan  8 00:04:13 localhost vdr: [14353] [softhddev]OglThread cleanup

[470530.163338] oglThread[11576]: segfault at 7f8df626e980 ip 00007f8df626e980 sp 00007f8d92ffce08 error 14 in libglapi.so.0.0.0[7f8df6c0d000+b000]

CU

9000h

vdr als root ist irgendwie uncool.

Du hast sicherlich auch das hier gefunden:

https://stackoverflow.com/questions/2970…root-privileges

Unten ist was zu lesen von fd schließen und wieder öffnen. Ob das hier hilft, root-Privilegien zu vermeiden?