Github - Tuxbox Neutrino (tuxbox-neutrino.org)

[GetAway]

Hi,

wo wird denn jetzt der Support laufen, hier oder im dbx2world Board?

@dbt
Die Messagebox in 3.4.0, sollte eine Mindestanzeigedauer haben. Ein Beispiel, bei dem es
jetzt kacke aussieht, ist bei: Plugins neustarten.

...und ich würde mich freuen, wenn RC_Release und RC_Repeat
bald mal vernünftig auswertbar wird.

[flk]

Ich bastle momentan an einem PC Image. Idee war anfangs, mir eine Yocto Buildumgebung für die VM zu schaffen. Von daher kam die clutter Unterstützung genau passend ... ohne Abstraktionsschicht war das nicht so schön. Das Image basiert auf morty und befindet sich noch im Aufbau. Wenn ich dann mal zufrieden damit bin, kann ich gerne bei Interesse auch noch mehr dazu schreiben. Ich bin mir auch gar nicht sicher, ob das so distributierbar wäre. Ich habe einfach den chrome (und auch sublime) binär hineingezogen, weil der aktuelle Status der freien Browser Engines eher traurig ist. Epiphany funktioniert ... allerdings baut libwebkit ewig und noch länger, und hinterher gibts keinerlei html5 Unterstützung ... von flash erst mal gar nicht zu sprechen.

Gerade bin ich auf ein Problem mit dem glfb gestoßen. Wegen direct rendering für neuere Ati und Nvidia Karten habe ich gestern dri3 und gallium in mesa aktiviert. Nativ läuft Neutrino mit Intel oder Ati Grafik jetzt bestens, Nvidia kann ich nicht testen, sollte aber eigentlich auch tun. Nur musste ich für das r600 dri Modul llvm mit in den Build nehmen. Dadurch werden jetzt auch dri Module für die VM gebaut. Ansich ja auch schön, aber ...
Neutrino lässt sich momentan in der VM nicht mehr starten. Nativ, wie gesagt, alles gut und auch in der VM laufen so gut wie alle Programme außer Neutrino problemlos und fehlerfrei. glxgears z.B. stirbt auch bei der Ausführung. Irgendwie gibts wohl Ärger, sobald opengl verwendet wird. Konnte bisher allerdings auch nur mit qemu/kvm testen.

Code: Alles auswählen

Thread 2 "neutrino" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe8cef700 (LWP 4389)]
0x00007fffe1fc26ef in LLVMGetPointerToGlobal () from /usr/lib/libLLVM-3.6.so
(gdb) backtrace
#0  0x00007fffe1fc26ef in LLVMGetPointerToGlobal () from /usr/lib/libLLVM-3.6.so
#1  0x00007fffe359ac9b in ?? () from /usr/lib/dri/swrast_dri.so
#2  0x00007fffe3592cb0 in ?? () from /usr/lib/dri/swrast_dri.so
#3  0x00007fffe357ec3c in ?? () from /usr/lib/dri/swrast_dri.so
#4  0x00007fffe30cc533 in ?? () from /usr/lib/dri/swrast_dri.so
#5  0x00007fffe308d093 in ?? () from /usr/lib/dri/swrast_dri.so
#6  0x00007ffff29196ef in ?? () from /usr/lib/libcogl.so.20
#7  0x00007ffff2959c67 in ?? () from /usr/lib/libcogl.so.20
#8  0x00007ffff2959372 in ?? () from /usr/lib/libcogl.so.20
#9  0x00007ffff2959a14 in ?? () from /usr/lib/libcogl.so.20
#10 0x00007ffff29598b9 in ?? () from /usr/lib/libcogl.so.20
#11 0x00007ffff295ae35 in ?? () from /usr/lib/libcogl.so.20
#12 0x00007ffff292d8f8 in cogl_flush () from /usr/lib/libcogl.so.20
#13 0x00007ffff295f422 in cogl_onscreen_swap_buffers_with_damage () from /usr/lib/libcogl.so.20
#14 0x00007ffff4db7e53 in ?? () from /usr/lib/libclutter-1.0.so.0
#15 0x00007ffff4e1af77 in ?? () from /usr/lib/libclutter-1.0.so.0
#16 0x00007ffff4e05519 in ?? () from /usr/lib/libclutter-1.0.so.0
#17 0x00007fffef4f3947 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#18 0x00007fffef4f3b78 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0x00007fffef4f3e92 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#20 0x00007ffff4e0245c in clutter_main () from /usr/lib/libclutter-1.0.so.0
#21 0x00007ffff598b67e in GLFramebuffer::run() () from /usr/lib/libstb-hal.so.0
#22 0x00007ffff557058d in ?? () from /usr/lib/libOpenThreads.so.20
#23 0x00007fffef0513a4 in start_thread (arg=0x7fffe8cef700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:333
#24 0x00007fffea989e5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
(gdb) 

Ohne gdb kommt einfach diese Meldung

Code: Alles auswählen

Unable to find target for this triple (no targets are registered)
Speicherzugriffsfehler (core dumped)

Wer Interesse hat, kann sich das gerne mal anschauen. Das Problem sollte aber vermutlich ausserhalb von Neutrino liegen
http://tuxbox-images.de/images/x86/

kurzer Nachtrag dazu:
In vmware, wofür der vmgfx Treiber ja auch gedacht ist, klappt das Direct Rendering und Neutrino startet (endlich auch mal flüssig). Scheint nur ein Problem mit dem Fallback zum Software Rendering zu geben. Ist halt im qemu jetzt erst mal blöd

@seife: Eine gstreamer-basierte playback-Klasse für die libstb-hal wäre allerdings eine feine Sache ... aber wenn dir das schon Knoten ins Hirn macht, wer solls denn sonst können
Allerdings kann ich auch gut verstehen, dass das alles auch irgendwo seine privaten Grenzen hat.
Was läuft denn bei dir am PC schon ? In meinem Image hat Neutrino noch segfaults in allen Ecken

[dbt]

Hi,

wo wird denn jetzt der Support laufen...

Einfach ein Thema starten und der Rest ergibt sich aus den Ergebnissen. War ja eigentlich immer so. ;-)

[dbt]

Hi,
....
Die Messagebox in 3.4.0, sollte eine Mindestanzeigedauer haben. Ein Beispiel, bei dem es
jetzt kacke aussieht, ist bei: Plugins neustarten.

...

War eigentlich schon immer so. Ich nehme an du meinst, dass das nur kurz zu sehen ist. Dann wärs eigentlich anders rum sinnvoll, das die Messagebox sich erst einblendet wenn es sich lohnt. Sprich, wenn ein "lesbare" Zeitspanne da ist. Aber das wäre ein eigenes Thema.

[seife]

Ich bastle momentan an einem PC Image. Idee war anfangs, mir eine Yocto Buildumgebung für die VM zu schaffen. Von daher kam die clutter Unterstützung genau passend ... ohne Abstraktionsschicht war das nicht so schön. Das Image basiert auf morty und befindet sich noch im Aufbau. Wenn ich dann mal zufrieden damit bin, kann ich gerne bei Interesse auch noch mehr dazu schreiben. Ich bin mir auch gar nicht sicher, ob das so distributierbar wäre. Ich habe einfach den chrome (und auch sublime) binär hineingezogen, weil der aktuelle Status der freien Browser Engines eher traurig ist. Epiphany funktioniert ... allerdings baut libwebkit ewig und noch länger, und hinterher gibts keinerlei html5 Unterstützung ... von flash erst mal gar nicht zu sprechen.

Für den PC baue ich mir meine Distributionen nicht selbst, da bin ich dann doch zu faul für

@seife: Eine gstreamer-basierte playback-Klasse für die libstb-hal wäre allerdings eine feine Sache ... aber wenn dir das schon Knoten ins Hirn macht, wer solls denn sonst können
Allerdings kann ich auch gut verstehen, dass das alles auch irgendwo seine privaten Grenzen hat.

Für jemand, der sich öfters mit GNOME / gstreamer / glib und so zeug beschäftigt sollte das eigenltlich trivial sein, das zu implementieren.

Was läuft denn bei dir am PC schon ? In meinem Image hat Neutrino noch segfaults in allen Ecken

Also auf openSUSE Factory / Tumbleweed, gebaut mit einem Makefile vergleichbar mit Makefile.SDK von hier https://github.com/seife/meta-neutrino- ... master/doc funktioniert bei mir Live-TV und alle GUI sachen, Aufnahme habe ich nicht probiert und Playback ist nicht implementiert.
Was funktioniert ist der MP3-Player und Internetradio.
Aber der PC-Port ist wirklich nur zum debuggen von GUI-Fehlern etc. zu gebrauchen, z.B. ist der A/V-Sync-Code schon sehr "rustikal"

[flk]

Für den PC baue ich mir meine Distributionen nicht selbst, da bin ich dann doch zu faul für

ich ja normalerweise auch nicht ... aber in dem Fall wollte ich halt

a) mal schauen, was mit yocto im Bereich grafischer Oberfläche möglich ist. Auf der Coolstream gab es ja nie anständigen Grafik Support und eine zu lahme CPU. Am PC ist die Treibersituation schon erheblich besser. Deshalb würde ich einen funktionierenden PC Port von Neutrino auch sehr begrüßen. Die Plattform hat wohl jeder verfügbar und da gibt es dann auch keine Firma, die einfach mir nichts dir nichts pleite geht ... so ein NUC im Wohnzimmer wäre gar nicht mal so schlecht

b) ist das halt jetzt ein yocto morty, zumindest weitgehend. Mein Gedanke war, dass man damit evtl. mal eine gemeinsame Basis hätte, für die man entwickeln könnte. Da wären dann nämlich beispielsweise Probleme bezüglich unterschiedlicher verwendeter Software Stände Geschichte und in vielen Bereichen wären gefixte Probleme automatisch auch für alle Plattformen behoben, auf die man das dann portiert bekommt. Die Portierung eines yocto Images auf eine andere Plattform ist ja an sich keine große Sache. Gut, da sind jetzt eine Menge Dev Tools, Kernel Sourcen, dev Pakete, build appliance und sonstiger Kram drin, der für ein Benutzer Image völlig unnötig ist. Aber es ist immer einfacher, Sachen raus zu werfen, als neu hinzuzufügen. Jedenfalls erhält man durch das yocto Project eine aktuelle und supportete Basis

c) war das anfangs ja auch gar nicht als "Distribution" geplant. Ich wollte einfach nur ein schlichtes Konsolen Image haben, mit dem ich vom MacOS aus bauen kann. Dann kamen die Überlegungen von Punkt a dazu und irgendwie wurde das dann halt doch etwas umfassender

Und abschließlich geht s mir ja auch ums Lernen, und jetzt weiss ich einiges mehr, das auch für die Erstellung von Images auf anderen Plattformen nützlich sein könnte.

Ja, Playback ist bisher nur eine dummy Implementierung, war mir aufgefallen. Live TV und MP3 Playback gehen bei mir aber auch nicht
Beendet mit Segfault.

Liegt bestimmt beides am Audio

Zumindest das Abspielen von audio streams klappt jetzt. Bei libao wurden die Treiber Module in eigene Pakete gepackt und sind nicht im Image gelandet

[PauleFoul]

Also so wie ich lese scheint es garnicht so unmöglich zu sein NeutrinoHD auf eine andere Plattform zu hieven.

Wenn jemand da ein Projekt starten möchte kann er sich zwecks HW bei mir melden ;-)

[seife]

Nimm doch einfach neutrino-MP, das ist schon auf andere Plattformen "gehievt".
Wenn du jetzt im neutrino-HD die libstb-hal nochmal neu erfinden willst, dann kannst du das zwar tun, aber wozu?