[ANNOUNCE] VDR developer version 1.7.37

    Moin!


    Zitat von TheChief

    eTimerMatch timerMatch = tmNone;


    Hängt vom Compiler ab. Aber ich initialisiere Variablen auch lieber mit einem Wert, den ich kenne.


    Lars.

    Hallo Klaus,


    ich würde gerne auf die OSD-Elemente einen Schatteneffekt mit ImageMagick anwenden, aber ich finde keine richtige Funktion, um an die Pixels ran zukommen um sie ImageMagick übergeben zu können.
    Wenn ich ein OSD-Element in eine cPixmap zeichne, dann bekomme ich die Pixel dort nicht mehr heraus, den ein cPixmap::GetPixel() oder ::GetBuffer() gibt es ja nicht.
    Eine cBitmap kommt dafür ja nicht in Betracht, da sie mit Paletten arbeiten und damit nicht wirklich TrueColor fähig ist, oder?
    Momentan helfe ich mir damit, dass ich die Elemente direkt in Imagemagick zeichne, dann schattiere, den Buffer in ein cImage kopiere, was dann mit cPixmap:: DrawImage() gezeichnet werden kann.
    Wirklich schön ist das aber nicht, u.a. da ImageMagick einige andere Nachteile hat (wie z.B. kein (einfaches) Zeichnen von Kreisbögen)
    Gibt es eine elegantere, einfachere Möglichkeit an die Pixeldaten ran zukommen? Oder ist dafür doch cBitmap zu benutzen?


    FireFly

    hallo,


    ich muß hier leider wieder zwecks compilierung stören: ich bekomme mit "LCLBLD=1" und gesetztem DVBDIR bei den vdr-eigenen plugins "dvbhddevice" & "dvbsddevice" folgenden fehler:


    zuletzt hatte ich das problem mit vdr-1.7.35 - da hatte mir UFO geholfen. es betrifft den 2. teil aus diesem post hier --> [Announce] VDR developer version 1.7.35


    und hier UFO's hilfe --> [Announce] VDR developer version 1.7.35


    leider funktioniert dieser "trick" mit 1.7.37 nicht mehr.


    eigentlich brauche ich die beiden plugs nicht (da softhddevice genutzt) .. aber trotzdem.


    gruß, ciax

    .. die sieht so aus:



    CFLAGS wurden einmal direkt " CFLAGS =" definiert oder mit "CFLAGS +=" erweitert ( CFLAGS += -fPIC -D__user= -D__KERNEL_STRICT_NAMES= -D__u8=uint8_t ) -- hat beides keine wirkung.


    danke, ciax

    Häng' die Parameter mal mit an die CXXFLAGS ran.


    Oder noch besser lass die CFLAGS und CXXFLAGS wie sie waren und schreib in die Make.config das hier:


    Code
    CFLAGS += -D__user= -D__u8=uint8_t
CXXFLAGS += -D__user= -D__u8=uint8_t


    Ich habe jetzt nicht nachgeschaut, aber soweit ich weiß werden an die Plugins nur die CXXFLAGS durchgegeben.

    ja, das ware es! :] DANKE!


    gruß, ciax


    Es ist bewusst nicht vorgesehen, daß man an die Pixel einer cPixmap "rankommt", damit ein Device seine cPixmaps möglichst effizient implementieren kann.
    Du wirst also wohl oder übel über cImage gehen müssen.


    Wie soll der "Schatteneffekt" denn aussehen?
    Vielleicht kann man das ja auch mit überlagerten cPixmaps und Alpha-Blending realisieren.


    Klaus

    Zitat von kls

    Wie soll der "Schatteneffekt" denn aussehen?
    Vielleicht kann man das ja auch mit überlagerten cPixmaps und Alpha-Blending realisieren.


    Siehe Anhang, Ich bin froh, dass ich den Effekt mit ImageMagick hinbekommen habe; ich bin nämlich kein Grafiker ...
    Was mich stört ist nicht das Einlesen via cImage nach dem Schattieren, sondern vor dem Schattieren das Erstellen der Grafik mit ImageMagick bzw. Erstellen mit VDR und Auslesen der Pixels. Ich denke, ich werde das Erstellen mal mit cBitmap probieren...

    Muss noch warten bis die 1.3.37 im gentoo overlay auftaucht aber....

    Zitat

    - The LCARS menu now also works if the OSD has only 1bpp (two colors).

    Da bin ich gespannt drauf, das waere ja wohl fuer meine nicht aufgeruestete FF relevant!.

    Supiiii jedesmal wenn ich VDR compiliert habe habe ich MAX_SUBTITLE_LENGTH und VFAT_MAX_FILENAME umdefiniert weil ich zwar die umcodierung der Filenamen wollte, nicht aber die Abkuerzung der Namen. Bester Patch ever


    Mal eine Frage zu Gentoo: Die haben da in ihrem build so einen riesenpatch um tausend Zusatz-Features zu enablen:


    http://gpo.zugaina.org/media-video/vdr/USE
    http://dev.gentoo.org/~hd_brum…ntoo-edition-v1.patch.bz2


    Ich benutze da zwar nix von, weil das irgendwie dazu gefuehrt hat, dass das vnsiserver plugin nicht laeuft, aber ich wundere mich halt, ob/wie diese Patches in den VDR zurueckfliessen. Wenn ueberhaupt... Scheinen ja zumindestens ein paar features drin zu sein, die schon durch die neueren VDR features obsolet geworden sind, wenn ich das richtig sehe, eg: lirc parameter. Bloss neugierig.

    Sehe ich das richtig, dass bei cBitmap und cPixmap DrawEllipse() die Quadrantenparameter -5 bis -8 keine Funktion haben? Lt. osd.h geht ja -1 bis -8, aber da bei mir mit -5 und -7 scheinbar nichts gezeichnet wird und die in den case-Zweigen in osd.c nicht erscheinen vermute ich mal dass -5 bis -8 nicht implementiert sind ohne die osd.c genauer analysiert zu haben ....

    Weil es IMHO die Bedienung des VDR deutlich verbessert noch der Hinweis auf den neuen Patch für die lirc.c auf der ML, der einen Tastendruck zu viel nach dem Loslassen der Taste eliminiert:
    http://www.linuxtv.org/piperma…2013-February/027235.html

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von FireFly

    Sehe ich das richtig, dass bei cBitmap und cPixmap DrawEllipse() die Quadrantenparameter -5 bis -8 keine Funktion haben? Lt. osd.h geht ja -1 bis -8, aber da bei mir mit -5 und -7 scheinbar nichts gezeichnet wird und die in den case-Zweigen in osd.c nicht erscheinen vermute ich mal dass -5 bis -8 nicht implementiert sind ohne die osd.c genauer analysiert zu haben ....


    Stimmt, -5 bis -8 sind nicht implementiert.
    In der Beschreibung zu DrawEllipse() heißt es

    Code
    ///< 0       draws the entire ellipse
       ///< 1..4    draws only the first, second, third or fourth quadrant, respectively
       ///< 5..8    draws the right, top, left or bottom half, respectively
       ///< -1..-8  draws the inverted part of the given quadrant(s)


    Da bei den negativen Werten nur von "quadrant" die Rede ist und nicht von "half", könnte man annehmen, daß nur -1 bis -4 gemeint sind.
    Dem widerspricht allerdings ein klein wenig das "(s)" am Ende - das könnte man wiederum so interpretieren, daß auch die jeweiligen Hälften gemeint sind.


    Fragt sich also, was tun?
    Entweder die Beschreibung anpassen oder den Code erweitern.
    Ich neige dazu, die Beschreibung nach

    Code
    ...
       ///< -1..-4  draws the inverted part of the given quadrant


    zu ändern.


    Klaus

    Warum nicht einfach


    Code
    +          case -5: DrawEllipse(x1, y1, x2, y2, Color, 7); return;
+          case -6: DrawEllipse(x1, y1, x2, y2, Color, 8); return;
+          case -7: DrawEllipse(x1, y1, x2, y2, Color, 5); return;
+          case -8: DrawEllipse(x1, y1, x2, y2, Color, 6); return;

    Hallo Klaus


    Erst mal vielen Dank für Deine Arbeit!


    Zum bevorstehenden vdr-2.0 habe ich eine kleine Frage: Spricht etwas dagegen, bei LIRC nicht nur den Tasten- sondern auch den Fernbedienungsnamen zu berücksichtigen?


    Ich habe im Wohnzimmer einen kleinen LIRC-Gateway mit dem ich alle meine Geräte steuere (bzw. steuern lasse). Wenn nun der VDR schon läuft und ich z.B. den Beamer an- oder abschalten möchte, fühlt sich der VDR fälschlicherweise auch angesprochen, weil die Taste dort auch "POWER" heißt. Natürlich ließe sich das mit einem spezifischen Namen für die VDR-Powertaste lösen, aber elegant ist das nicht.


    Ich weiß, das ist jetzt Jammern auf hohem Niveau... aber ich kann ja auch nichts dafür, dass sonst alles so prima läuft! ;)


    Gruß
    Thomas

    Zitat von wirbel

    Warum nicht einfach


    Code
    +          case -5: DrawEllipse(x1, y1, x2, y2, Color, 7); return;
+          case -6: DrawEllipse(x1, y1, x2, y2, Color, 8); return;
+          case -7: DrawEllipse(x1, y1, x2, y2, Color, 5); return;
+          case -8: DrawEllipse(x1, y1, x2, y2, Color, 6); return;


    Vielleicht weil das etwas ganz anderes zeichnen würde als das, was gewünscht ist? ;)
    Es soll ja "invertiert" und nicht "gespiegelt" gezeichnet werden. Also quasi Vorder- und Hintergrundfarbe vertauscht.


    Einen invertierten Viertelkreis kann man sehr schnell gebrauchen (siehe LCARS, quasi als "Hohlkehle").
    Ob ein invertierter Halbkreis wirklich so nötig ist, glaube ich eher nicht. Und wenn doch, dann kann man ihn ja auch leicht aus zwei entsprechenden invertierten Viertelkreisen zusammensetzen.
    Da ich jetzt möglichst zielstrebig auf die Version 2.0 hinarbeiten möchte werde ich wohl die Beschreibung anpassen. Das muß uns nicht davon abhalten, diese Funktionalität in einer späteren Version doch noch einzubauen.


    Klaus


    Ah, ok. :) Das ist in der tat etwas völlig anderes.

    nochmal was zum Makefile - das target install-conf (mindestens seit 1.7.35 ) verlässt sich auf ein cp -n ... - die Option -n ist nicht auf allen Systemen verfügbar und damit kachelt dann entsprechend der make intsall ab. Ist das bekannt?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden