Beiträge von FireFly

  • FB mit LIRC auf RasPi OK, auf PC nicht

    kls schrieb:

    Das würde dann aber heißen, dass der Fehler im lircd passiert, was aber wiederum heißen müsste, dass LIRC (zumindest in der Version, die bei openSUSE Leap 15.0 dabei ist) nirgendwo funktionieren kann - was ich mir aber eigentlich auch nicht vorstellen kann...

    Ich nutze das Original LIRC von Leap 15.0 zusammen mit einem selbstkompilierten yausbIR Modul für LIRC. Das ist zwar noch nicht im produktiven Einsatz, funktioniert aber einwandfrei. Das Problem müsste sich dann auf das serial_ir-Modul beschränken.

    Hast Du mal den Quellcode des Moduls zwischen Raspi und Leap verglichen?


    Oder ein anderes LIRC RPM probieren? https://software.opensuse.org/package/lirc

  • Fullscreen OSD

    Kannst Du nicht wie ein Skin ein neues OSD aufmachen?

    Code
    1. osd = cOsdProvider::NewOsd(OSDsize.left, OSDsize.top);

    Problem könnte nur sein, dass bereits ein OSD von einem Skin auf ist ....

  • ProSiebenSat.1: Galileo Spezial am Sonntag unverschlüsselt in UHD

    von https://www.heise.de/newsticke…sselt-in-UHD-4111534.html

    Zitat

    Am Sonntag strahlt ProSiebenSat.1 eine Folge Galileo Spezial in UHD-Auflösung aus. Die Sendung ist unverschlüsselt über Satellit empfangbar.


    Am Sonntag, den 22.07.18, zeigt ProSiebenSat.1 eine Folge Galileo Spezial in UHD. Zusätzlich zur höheren Auflösung wird der Inhalt unter Einsatz des HDR-Verfahrens Hybrid Log-Gamma (HLG) ausgestrahlt, das bessere Farben verspricht. Laut Pressemitteilung der Sendergruppe ist "Galileo Spezial: Pauschal gegen Freestyle - der beste Urlaub auf den letzten Drücker" über Astra-Satellit auf dem Sender UHD1 by HD+ unverschlüsselt empfangbar.

    Über die digitalen Kanäle von ProSiebenSat.1 kann man die UHD-Folge von Galileo ab Montag "für kurze Zeit" auch auf Abruf in hoher Auflösung ansehen. Parallel zur UHD-Ausstrahlung wird die Folge wie gewohnt in SD und HD auf den entsprechenden Sendern gezeigt. .....

  • TT S2-6400 - Kernel 4.12.14 (openSUSE Leap 15.0)

    wla schrieb:

    Wäre es vielleicht möglich, dass Du die Treiber bereits compiliert bereitstellst für Leap 15.0?

    Dann müsste ich bei neuen Kernelversionen immer neue Pakete erzeugen und wäre ständig am hinterherlaufen. Und wenn ich mal keine Zeit habe könnte keiner den Kernel upgraden (oder schlimmer: man macht einen Upgrade und es gibt keinen Treiber - was dann?). Deshalb denke ich Hilfe zur Selbsthilfe als source RPM ist da besser. Um den suse build service zu nutzen habe ich momentan weder Zeit noch Muße....

  • TT S2-6400 - Kernel 4.12.14 (openSUSE Leap 15.0)

    Ich habe die Tage schon mal mit der Beta experimentiert und mein Treiber-RPM angepasst. Es kompiliert und die Treiber werden geladen, der Testrechner hat aber keine S2-6400.

    Download des Source-RPM hier, dann das Source-RPM installieren und mit rpmbuild -bb <spec-file> die RPM Pakete für Treiber und Firmware erstellen und anschließend installieren

  • vaapidevice unter openSUSE 42.3 compilieren

    aus gegebenen Anlass (zypper will Updates einspielen):

    als Repo habe ich unter 42.3 eingebunden:

    Code
    1. Alias          : alarrosa_X11_XOrg
    2. Name           : alarrosa_X11_XOrg
    3. URI            : https://download.opensuse.org/repositories/home:/alarrosa:/branches:/X11:/XOrg/openSUSE_Leap_42.3

    und er will folgendes updaten:



  • vaapidevice unter openSUSE 42.3 compilieren

    ich habe bei mir folgende Buildrequires drin (compiliert unter 42.3 und 15.0 Beta):

    Code
    1. xcb-util-wm-devel libxcb-icccm4 libavcodec-devel libavformat-devel libavresample-devel alsa-devel libva-devel


    wobei die libav* alle von Packman kommen. Damit compiliert es erfolgreich. Ob es auch läuft kann ich mangels geeigneter CPU noch nicht testen.

  • invalid lock sequence bei den meisten Skin-Plugins

    Viele Skin-Plugins (die nicht beim VDR mitgeliefert werden ;)) fragen ja in DisplayChannel::SetEvents() ab, ob es Timer gibt um das REC-Symbol entsprechend beim Title des Present Event dazustellen. Da ab VDR 2.3.x ja die Funktion mit vorherigem LOCK_CHANNELS_READ aufruft, kann man kein Read-Lock mehr für die Timer in SetEvents() setzen (weil dann ein Deadlock drohen könnte) und VDR meldet eine invalid lock sequence im syslog.

    Wie von Klaus empfohlen habe ich die Timer-Abfrage in skinElchi testweise in DisplayChannel::Flush() ausgelagert, war aber verwundert, dass direkt beim Start wieder eine invliad lock sequence gemeldet wird:

    Wenn ich den VDR Quellcode richtig verstehe wird das Flush an beiden Stellen mit vorherigem LOCK_CHANNELS_READ aufgerufen.

    Im LCARS Skin wird im Flush nur der Present-Event benutzt, keine Timer, auch wenn das hier im Forum schon zu lesen war.


    Ich dachte man könnte Event->HasTimer() als Alternative benutzen (mit kleinen Einschränkungen bei der Funktionalität), aber da habe ich die Tage festgestellt, dass sich in VDR 2.4 das Verhalten von HasTImer() geändert hat: in VDR 2.2 wurde nur bei aktivem Timer true zurückgegeben, in VDR 2.4 wird bei aktiven und inaktiven Timern true zurück geliefert, so dass damit keine REC-Anzeige realisierbar ist.


    Sorry Klaus, dass mir das nicht früher aufgefallen ist, aber ich habe aus zeitlichen Gründen die VDR Entwicklung nicht aktiv verfolgt und wollte jetzt "nur" mein Skin-Plugin anpassen....


  • [skinnopacity] invalid lock sequence report ... mit vdr-2.4.0 und skinnopacity(gepatcht)

    Übrigens hat sich die Funktion cEvent::HasTimer() geändert: Früher war sie nur bei aktivem Timer true, jetzt ist sie auch true wenn ein inaktiver Timer existiert. Damit stimmt die Rec-Anzeige des Following Event nicht mehr wenn der Timer inaktiv ist (siehe Listing oben in Post #2 Zeile 24), Aber das ist vermutlich bei so ziemlich allen Skin-Plugins so, die nicht beim VDR mitgeliefert werden, da alle fast den gleichen Code benutzen ;-)

    Ich dachte nämlich man könnte das für den Present-Event genauso machen wie für den Following-Event, aber statt einem Workaround gibt's jetzt zwei Probleme ...