[softhddevice] hängt bei Fenster-Skalierung in der Gnome-Shell 3.8

seahawk1986 · 27. April 2013

Hallo,
heute morgen habe ich mal unter Arch Linux mit VDR 2.0.1 und der aktuellen Softhddevice-Version aus dem Git ausprobiert wie gut softhddevice mit der Gnome-Shell 3.8 zusammenarbeitet. Mutter scheint einige Verbesserungen erfahren zu haben und die CPU-Auslastung im Betrieb ist im Gegensatz zum Stand mit Gnome 3.6 unter Ubuntu Precise kaum höher als mit einem nackten X-Server.
Leider hängt softhddevice sich gerne mal dauerhaft weg wenn man den Übersichts-Modus aufruft (in dem das Fenster in einer weichen Animation mehrfach neu skaliert wird, bis es die Zielgröße erreicht hat).
Das Log wird dann mit dieser Meldung geflutet:

Code

Apr 27 10:13:42 vdr4arch vdr[1357]: [1754] ERROR: TS packet not accepted in Transfer Mode
Apr 27 10:13:42 vdr4arch vdr[1357]: [1754] [softhddev]Clear:
Apr 27 10:13:42 vdr4arch vdr[1357]: audio/alsa: using device 'default'
Apr 27 10:13:42 vdr4arch vdr[1357]: audio/alsa: start delay 336ms
Apr 27 10:13:42 vdr4arch vdr[1357]: [1754] ERROR: TS packet not accepted in Transfer Mode

Vermutlich laufen da die Buffer voll, weil das Video nicht konstant wiedergegeben werden kann. Gäbe es evtl. eine Möglichkeit das komplette Einfrieren zu vermeiden (ein detachen über svdrp ist in dem Zustand dann auch nicht mehr möglich, nur ein Neustart des VDR hilft)?

gda · 27. April 2013

Zitat von seahawk1986

Mutter scheint einige Verbesserungen erfahren zu haben und die CPU-Auslastung im Betrieb ist im Gegensatz zum Stand mit Gnome 3.6 unter Ubuntu Precise kaum höher als mit einem nackten X-Server.

Aha!

Gerald

gda · 27. April 2013

Zitat von seahawk1986

Vermutlich laufen da die Buffer voll, weil das Video nicht konstant wiedergegeben werden kann. Gäbe es evtl. eine Möglichkeit das komplette Einfrieren zu vermeiden (ein detachen über svdrp ist in dem Zustand dann auch nicht mehr möglich, nur ein Neustart des VDR hilft)?

Komisch, mit 3.6 ging das noch, oder war das die ältere Version von SHD die ich da getestet hatte? Bei meinen Tests lief dann das Video auch in der Übersicht einfach weiter und bei dir stoppt das Bild?

Gerald

seahawk1986 · 27. April 2013

Zitat von gda

Bei meinen Tests lief dann das Video auch in der Übersicht einfach weiter und bei dir stoppt das Bild?

Ja, damit lief es mit dem VDR 1.7.33 abgesehen von der inaktzeptabel hohen Systemlast unter Precise relativ gut - das Problem tritt mit Gnome 3.8 nichtjedes mal auf, aber ist mit ein paar Versuchen eindeutig reproduzierbar, dass es mit dem aktuellen Stand wenig Sinn macht noch groß weiter zu experimentieren.

Genauer gesagt stoppt das Video und der Ton läuft nach bis der Buffer leer ist. Ich weiß nicht, ob das mit der Änderung im VDR zusammenhängt, dass Ausgabegeräte, die keine TS-Pakete annehmen können dann ein DeviceClear() bekommen und wie softhddevice darauf reagiert.

Code

- Now calling DeviceClear() in cTransfer::Receive() if the output device blocks, instead
of not retrying for 10 seconds (reported by Andreas Mair, with help from Oliver Endriss).
- Updated the Spanish OSD texts (thanks to Luca Olivetti).

johns · 27. April 2013

Also ich wüsste nicht was hängen kann.
Man kann einfach die Fenster Version mit jedem X11 Windowmanager testen und Fenster groß und klein ziehen.
Du kannst mal die GIT Version testen, dort habe ich für OpenGL zusätzliche Locks eingebaut, weil dies mit
Threads Probleme hatte, dies kommt auch der X11 Version zugute.

Ansonsten "gdb --pid=`pidof vdr`" und gucken wo er hängt, geht mit -dbg version und -DDEBUG besser.

Also bei mir funktioniert es, dauert nur 1-2 Minuten bis er alle Window Reseize Events abgearbeitet hat.
Es hilft hier auch das der aktuelle VDR seine Internen Puffer löcht.

Johns

seahawk1986 · 27. April 2013

Also ich habe mal ein bisschen weiter gespielt - das ganze tritt wohl nur auf, wenn das Fenster im Vollbildmodus ist (und evtl. wenn ich mittels xprop die Fensterdeko entfernt habe). Solange die Fensterdeko da ist, reagiert er nur eine Zeit lang nicht mehr auf die Skalierungs-Anweisungen.
Wenn ich dann mit gdb in den Prozess einsteige sehe ich nicht wirklich was - das unterscheidet sich nicht vom normalen Ablauf:

Code

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffc2dfe000
0x00007f57dee47c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007f57dee47c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00000000004f9812 in cCondVar::TimedWait(cMutex&, int) ()
#2  0x00000000004d1003 in cRemote::Get(int, char**) ()
#3  0x00000000004684b8 in main ()

johns · 27. April 2013

Vermute das gnome etwas anders macht, wenn die Fensterdeko da bzw. weg ist.
Ich mache nichts anderes bei mit und ohne Fensterdeko.

Das einzige was ich machen kann und dies steht schon in den Todo's, ist mehrere
Größenveränderungen zusammenzufassen. So sollte dann das Nachlaufen
reduziert werden.

Bei einem guten Windowmanager kannst es für jedes Programm einstellen ob
es "opaque" resized, bzw. die Animation machen soll. Dies würde ich für
softhddevice ausschalten.

Bei gdb guck dir alle Threads an, wichtig wäre hier der "video" thread.

Ist einer von Threads mit dem Namen "vdr", wenn ohne -DHAVE_PTHREAD_NAME gebaut wurde.

Code

(gdb) bt
#0  0x00000037f36bd8dd in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00000037f36e76e4 in usleep (useconds=useconds@entry=5000)
    at ../sysdeps/unix/sysv/linux/usleep.c:32
#2  0x00007ffff6f387be in VdpauDisplayHandlerThread () at video.c:8714
#3  0x00007ffff6f3bca9 in VideoDisplayHandlerThread (dummy=<optimized out>)
    at video.c:9560
#4  0x00000037f4208f3b in start_thread (arg=0x7fffdccf8700)
    at pthread_create.c:308
#5  0x00000037f36ee4dd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Alles anzeigen

Johns

seahawk1986 · 4. Mai 2013

Könnte es passieren, dass die OSD-Größe beim Skalieren zwischendrin extreme oder ungültige Werte annimmt?
Mit i3-wm (keine Animationen, simple Skalierung) sieht SkinnOpacity ja offenbar kurzzeitig extreme Werte für die Fensterhöhe (aus der dann die Größe der OSD-Elemente berechnet wird
[Announce] nOpacity 0.1.1

Ich habe die OSD-Größe in softhddevice auf auto stehen - wie könnte ich das am besten debuggen um zu sehen was da an Werten für die OSD-Größe von softhddevice gesetzt wird?

johns · 4. Mai 2013

Einfach die Debug Version (mit -DDEBUG) bauen.
Dann wird im Syslog jede Änderung die geholt wird ausgeben.

siehe softhddev.c:GetOsdSize()

Code

May  3 15:56:02 c60m1 vdr: [softhddev]GetOsdSize: 1920x1080 1

Es wird nicht jeder Aufruf geloggt, nur die, die eine Änderung melden.

Also ich reporte keine Änderungen an VDR, der VDR muß erst cSoftHdDevice::GetOsdSize
aufrufen um die Größenänderung mitzubekommen.

Johns

seahawk1986 · 4. Mai 2013

Ok, damit passiert das Abfragen der OSD-Größe wohl nur zwei Mal - das erste Mal nimmt er die Werte aus der setup.conf und das zweite Mal die Werte der tatsächlichen Bildschirmauflösung.
http://pastebin.com/bseQJVUr
In Zeile 1512 schalte ich in den Vollbild-Modus und dann drücke ich mehrfach die Windows-Taste um den Übersichts-Modus aufzurufen, wobei er dann mit der Bild-Ausgabe hängen bleibt.

gdb listet das wenn die Ausgabe hängen bleibt:

Code

(gdb) info threads
  Id   Target Id         Frame
  32   Thread 0x7f6c21094700 (LWP 6669) "dynamite udev m" 0x00007f6c30f35d13 in select () from /usr/lib/libc.so.6
  31   Thread 0x7f6c20893700 (LWP 6674) "tuner on fronte" 0x00007f6c32512c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  30   Thread 0x7f6c1bfff700 (LWP 6675) "section handler"
    0x00007f6c30f3409d in poll () from /usr/lib/libc.so.6
  29   Thread 0x7f6c1b7fe700 (LWP 6677) "tuner on fronte" 0x00007f6c32512c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  28   Thread 0x7f6c1affd700 (LWP 6678) "section handler" 0x00007f6c30f3409d in poll () from /usr/lib/libc.so.6
  27   Thread 0x7f6c1a7fc700 (LWP 6679) "vdr" 0x00007f6c30f3409d in poll ()
   from /usr/lib/libc.so.6
  26   Thread 0x7f6c0bfff700 (LWP 6680) "EPGSearch: sear" 0x00007f6c32512c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  25   Thread 0x7f6c19ffb700 (LWP 6681) "EPGSearch: conf" 0x00007f6c32512c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  24   Thread 0x7f6c197fa700 (LWP 6682) "vdr" 0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  23   Thread 0x7f6c18def700 (LWP 6683) "vdr" 0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  22   Thread 0x7f6c0b7fe700 (LWP 6684) "vdr" 0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
  21   Thread 0x7f6c0affd700 (LWP 6685) "vdr" 0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  20   Thread 0x7f6c0a7fc700 (LWP 6686) "vdr" 0x00007f6c30f3409d in poll ()
   from /usr/lib/libc.so.6
  19   Thread 0x7f6c09ffb700 (LWP 6687) "vdr" 0x00007f6c30f3409d in poll ()
   from /usr/lib/libc.so.6
  18   Thread 0x7f6c097fa700 (LWP 6688) "vdr" 0x00007f6c30f3d2c3 in epoll_wait
    () from /usr/lib/libc.so.6
  17   Thread 0x7f6c08ff9700 (LWP 6689) "vdr" 0x00007f6c32512c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  16   Thread 0x7f6bebfff700 (LWP 6690) "vdr" 0x00007f6c32512c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  15   Thread 0x7f6beb7fe700 (LWP 6691) "streamdev serve" 0x00007f6c30f35d13 in select () from /usr/lib/libc.so.6
  14   Thread 0x7f6beaffd700 (LWP 6692) "vdr" 0x00007f6c30f3409d in poll ()
   from /usr/lib/libc.so.6
  13   Thread 0x7f6bea7fc700 (LWP 6693) "vdr" 0x00007f6c30f3409d in poll ()
   from /usr/lib/libc.so.6
  12   Thread 0x7f6be9ffb700 (LWP 6694) "vdr" 0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  11   Thread 0x7f6be97fa700 (LWP 6695) "vdr" 0x00007f6c30f3409d in poll ()
   from /usr/lib/libc.so.6
  10   Thread 0x7f6be8ff9700 (LWP 6696) "vdr" 0x00007f6c325128b4 in pthread_cond---Type <return> to continue, or q <return> to quit---
_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  9    Thread 0x7f6bdbfff700 (LWP 6697) "vdr" 0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  8    Thread 0x7f6bdb7fe700 (LWP 6698) "vdr" 0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  7    Thread 0x7f6bdaffd700 (LWP 6699) "vdr" 0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  6    Thread 0x7f6bda7fc700 (LWP 6700) "LIRC remote con"
    0x00007f6c30f35d13 in select () from /usr/lib/libc.so.6
  5    Thread 0x7f6bd9ffb700 (LWP 6701) "receiver on dev" 0x00007f6c32512c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  4    Thread 0x7f6bd97fa700 (LWP 6702) "TS buffer on de" 0x00007f6c32512c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
  3    Thread 0x7f6bd8ff9700 (LWP 6718) "softhddev video" 0x00007f6c30f3409d in poll () from /usr/lib/libc.so.6
  2    Thread 0x7f6bd3fff700 (LWP 6719) "softhddev audio" 0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
* 1    Thread 0x7f6c32b6d740 (LWP 6668) "vdr" 0x00007f6c32512c61 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0

Alles anzeigen

Der Audio-Thread:

Code

(gdb) thread 2
[Switching to thread 2 (Thread 0x7f6bd3fff700 (LWP 6719))]
#0  0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /usr/lib/libpthread.so.0
#1  0x00007f6c2eb9a9fb in AudioPlayHandlerThread (dummy=<optimized out>)
    at audio.c:2030
#2  0x00007f6c3250edd2 in start_thread () from /usr/lib/libpthread.so.0
#3  0x00007f6c30f3cced in clone () from /usr/lib/libc.so.6
(gdb) bt full
#0  0x00007f6c325128b4 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /usr/lib/libpthread.so.0
No symbol table info available.
#1  0x00007f6c2eb9a9fb in AudioPlayHandlerThread (dummy=<optimized out>)
    at audio.c:2030
No locals.
#2  0x00007f6c3250edd2 in start_thread () from /usr/lib/libpthread.so.0
No symbol table info available.
#3  0x00007f6c30f3cced in clone () from /usr/lib/libc.so.6
No symbol table info available.

Alles anzeigen

Und der Video-Thread:

Code

(gdb) thread 3
[Switching to thread 3 (Thread 0x7f6bd8ff9700 (LWP 6718))]
#0  0x00007f6c30f3409d in poll () from /usr/lib/libc.so.6
(gdb) bt full
#0  0x00007f6c30f3409d in poll () from /usr/lib/libc.so.6
No symbol table info available.
#1  0x00007f6c18101f3f in ?? () from /usr/lib/vdpau/libvdpau_nvidia.so.1
No symbol table info available.
#2  0x00007f6c180f3e95 in ?? () from /usr/lib/vdpau/libvdpau_nvidia.so.1
No symbol table info available.
#3  0x00007f6c180f9f30 in ?? () from /usr/lib/vdpau/libvdpau_nvidia.so.1
No symbol table info available.
#4  0x00007f6c180ec17c in ?? () from /usr/lib/vdpau/libvdpau_nvidia.so.1
No symbol table info available.
#5  0x00007f6c2eb8e047 in VdpauDisplayFrame () at video.c:8191
        status = <optimized out>
        first_time = 0
        last_time = 1367668471496461856
        i = <optimized out>
#6  0x00007f6c2eb901b1 in VdpauSyncDisplayFrame () at video.c:8493
No locals.
#7  VdpauDisplayHandlerThread () at video.c:8732
        i = <optimized out>
        err = <optimized out>
        decoded = <optimized out>
        nowtime = {tv_sec = 1367678889, tv_nsec = 764239420}
        decoder = <optimized out>
#8  0x00007f6c2eb94369 in VideoDisplayHandlerThread (dummy=<optimized out>)
    at video.c:9560
No locals.
#9  0x00007f6c3250edd2 in start_thread () from /usr/lib/libpthread.so.0
No symbol table info available.
#10 0x00007f6c30f3cced in clone () from /usr/lib/libc.so.6
No symbol table info available.

Alles anzeigen

Lohnt es sich den nvidia-Treiber nochmal mit debug-Symbolen zu übersetzen?

johns · 4. Mai 2013

Sowie es aussieht hängt da X11, müsstest den Video Thread Single steppen und gucken ob er aus dem poll wieder herauskommt.
Und wenn das nicht geht, Debug Ausgaben vor und nach dem Display.

EDIT: Schalte mal den grab ab, da bin ich mir nicht sicher ob der gut gelockt ist.

Ansonsten hângt eindeutig der Videothread. Welche.xlib? Mit xcb?

Johns

seahawk1986 · 4. Mai 2013

Zitat von johns

xlib? Mit xcb?

Code

$ Xorg -version


X.Org X Server 1.14.1
Release Date: 2013-04-17
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.8.7-1-ARCH x86_64
Current Operating System: Linux vdr4arch 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST 2013 x86_64
[...]

Code

$ pacman -Qs xcb
local/cairo 1.12.14-3
    Cairo vector graphics library
local/libxcb 1.9-3
    X11 client-side library
local/xcb-proto 1.8-1
    XML-XCB protocol descriptions

Soweit ich weiß nutzt mutter clutter und Cairo hat damit AFAIK Abhängigkeiten zur Xlib und xcb - wobei clutter auf die Xlib zu setzen scheint (https://git.gnome.org/browse/clutter/tree/clutter/x11)

seahawk1986 · 4. Mai 2013

Also mit normalen steps komme ich in gdb nicht weiter, bei stepi kann ich endlos durch Zeilen ohne Symbole springen...
Was soll ich denn an Debug-Ausgaben einbauen?

seahawk1986 · 4. Mai 2013

Zitat von johns

EDIT: Schalte mal den grab ab, da bin ich mir nicht sicher ob der gut gelockt ist.

Das war nur durch das Live-Plugin, ohne den Grab passiert das aber leider auch - oder kann man den komplett für das Plugin deaktivieren?

johns · 4. Mai 2013

Also ich meinte libx11, aber die scheint es nur noch mit xcb zugeben. Zumindest kann ich es jetzt mit Gentoo nicht mehr anders auswählen.

Code

ldd /usr/lib/libX11.so
	linux-vdso.so.1 (0x00007fff947ff000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00000037f5200000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00000037f3e00000)
	libc.so.6 => /lib64/libc.so.6 (0x00000037f3600000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00000037f5600000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00000037f4a00000)
	/lib64/ld-linux-x86-64.so.2 (0x00000037f3200000)

libxcb ist aktuell, daran kann es nicht liegen.
Ich bin mir fast 100% sicher das X11 im Eventhandler hängt. Du verwendest doch GIT softhddevice?
Da habe ich noch ein paar mehr Locks eingebaut, weil sonst X11 mit OpenGL hing. Jetzt sollte alles abgesichert sein,
bis auf den Grab, den muß ich mir nochmal genau angucken.
Wenn das Liveplugin nicht mehr aktiv ist, dann solle es auch keine grab mehr machen.

Diff

diff --git a/video.c b/video.c
index 5f0cc26..a3d38e6 100644
--- a/video.c
+++ b/video.c
@@ -8490,7 +8490,9 @@ static void VdpauSyncFrame(void)
 ///
 static void VdpauSyncDisplayFrame(void)
 {
+    fprintf(stderr, "enter ");
     VdpauDisplayFrame();
+    fprintf(stderr, "leave\n");
     VdpauSyncFrame();
 }

Alles anzeigen

Gibt aber auf stderr aus. Einfach vdr per Hand starten, sind aber normal 50 Ausgaben pro Sekunde.

So meinte ich es, aber wenn der gdb nicht zurückkommt, dann hat X11 mit Threads usw. aufgegeben.
Und was kann man dagegen machen, einfach Fenster nicht mehr vergrößern verkleinern.

Johns

seahawk1986 · 4. Mai 2013

Also die libX11:

Code

$ ldd /usr/lib/libX11.so
	linux-vdso.so.1 (0x00007fffb71fe000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fea03237000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fea03033000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fea02c86000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fea02a81000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fea0287b000)
	/usr/lib64/ld-linux-x86-64.so.2 (0x00007fea037af000)

Zitat von johns

Du verwendest doch GIT softhddevice?

Ja, genau die Version aus dem Git mit dieser Konfiguration:

Code

CONFIG += -DAV_INFO -DAV_INFO_TIME=3000 # info/debug a/v sync
CONFIG += -DUSE_PIP                     # PIP support
CONFIG += -DUSE_MPEG_COMPLETE           # support only complete mpeg packets
CONFIG += -DUSE_VDR_SPU         # use VDR SPU decoder.
CONFIG += -DHAVE_PTHREAD_NAME

Das Plugin starte ich mit "-w still-h264-hw-decoder -v vdpau -D"

Zitat von johns

Gibt aber auf stderr aus. Einfach vdr per Hand starten, sind aber normal 50 Ausgaben pro Sekunde.

Da bleibt er mit einem "enter" stehen. Ab und an kommt es nach einiger Zeit in der Situation zu einem Segfault:
http://pastebin.com/zxcPTGBj

Zitat von johns

Und was kann man dagegen machen, einfach Fenster nicht mehr vergrößern verkleinern.

Genau, der einfachste Weg ist dem Fehler aus dem Weg zu gehen - bzw. die Gnome-Shell nicht zu verwenden, denn z.B. mit i3 klappt das ja jetzt wunderbar nachdem louis SkinnOpacity angepasst hat, da kann ich nach Lust und Laune das Fenster skalieren lassen.

johns · 4. Mai 2013

Den "segfault" kenne ich, der kommt meiner Meinung nach vom VDR, konnte den aber nicht nachvollziehen.
Kommt aber im normalen Betrieb nicht vor und mit valgrind läst sich VDR nicht gut analysieren.

Also bei i3 funktioniert es und bei der tollen Software von GNU geht es nicht.
Ich vermute es liegt am NVidia-Treiber und kann es sein das die Zwerge 3D bzw. OpenGL benutzen.

Ich werde mal wenn ich Langeweile habe, die Grö0e des VDR Fenster laufend verändern.
Leider habe ich xdotool nicht überzeugen können das VDR Fenster zu verändern, sonst hätte ich das
mit einem Script mal stundenlang laufen lassen.

Johns

seahawk1986 · 5. Mai 2013

Zitat von johns

Ich vermute es liegt am NVidia-Treiber und kann es sein das die Zwerge 3D bzw. OpenGL benutzen.

Ja, clutter setzt auf opengl.

Zitat von johns

Leider habe ich xdotool nicht überzeugen können das VDR Fenster zu verändern, sonst hätte ich das
mit einem Script mal stundenlang laufen lassen.

Leider kann man das softhddevice Fenster nur am Titel erkennen, weil es kein WM_CLASS Attribut hat.
Aus dem yavdr-addon-pip kenne ich einen Weg über wmctrl (https://github.com/yavdr/yavdr…ob/master/vdr-pip-sp.conf

Code

SHD=$(wmctrl -l | grep "softhddevice" | cut -d ' ' -f 1)
wmctrl -i -r $SHD -e 0,x,y,w,h

johns · 5. Mai 2013

WM_CLASS habe ich nicht eingebaut, da es schon Probleme mit dem Namen gab.

Wenn es jetzt geht, dann gibt es einen Konflikt von OpenGL und VDPAU.

Johns

seahawk1986 · 5. Mai 2013

Zitat von johns

Wenn es jetzt geht, dann gibt es einen Konflikt von OpenGL und VDPAU.

Das könnte sein (auch wenn ich das mit anderen VDPAU-fähigen Playern nicht habe), aber was meinst du mit "jetzt"?
Könnte man solche Fehlerfälle abfangen, dass der VDR dabei nicht hängen bleibt? Ich fände es weniger Schlimm, wenn das Frontend in so einem Fall detached wird als wenn sich gleich der komplette VDR weghängt. Der nVidia-Treiber und der X-Server arbeiten ja normal weiter.

[softhddevice] hängt bei Fenster-Skalierung in der Gnome-Shell 3.8

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema