Graphlcd-plugin/touchcol/changelog

Changelog

this changelog is taken from a thread from vdr-portal.de and has been started in german. only the newer entries have been made in english.

Changes (most recent first)

Sunday, March 17th 2013, 10:33am [941]

• news (graphlcd-base):
  • showpic: fix rendering bug
  • Makefiles: rename PRESTRIP to HAVE_STRIP and unset it by default

---

Friday, January 25th 2013, 9:24pm

• news (vdr-plugin-graphlcd):
  Makefile: should now be compliant with 'new style make' and old vdr versions (incl. 1.4.x)

so. habe das Makefile ausgehend von einem via newplugin generiertem makefile neu erzeugt und angereichert, sodass es jetzt fuer div. vdr-versionen (neu, alt, sogar 1.4.x) brauchbar sein sollte, egal ob pkg-config das vdr.pc vom tree holt oder vom system, es werden auch auf keine dateien v. vdr mehr direkt zugegriffen und ich habe es in allen moeglichen und unmoeglichen anwendungsfaellen ausprobiert (ausg. jene, die ich uebersehen habe) ... achtung luxusedition: ich habe sogar ein paar kommentare hineingeschrieben ...

---

Monday, January 21st 2013, 12:57am

• news (vdr-plugin-graphlcd):
  consider that both VDRDIR and PLGCFG can be empty

wie auf seite 44 bereits vorgeschlagen, werden VDRDIR und PLGCFG jetzt separat behandelt. eine extra behandlung, dass Make.config in neueren versionen _ueberhaupt_ nicht mehr inkludiert werden kann, wird noch folgen. getestet innerhalb v. vdr sowohl v. vdr-root aus als auch v. plugin-verzeichnis aus und von plugin-verzeichnis ausserhalb v. vdr-tree (mittels VDRDIR=<path to vdr-tree> make)

• news (vdr-plugin-graphlcd):
  disallow inclusion of Make.config when VDR >= 1.7.33

---

Monday, January 7th 2013, 12:47am

• news (graphlcd-base):
  experimental support added for picoLCD 256x64 (contributed by Jochen Koch)

nota bene: needs to be activated in Make.config first because it is experimental for now

---

Saturday, October 27th 2012, 7:41pm

• bugfix (Dimmen bei Wiedergabe?):
  fehler ist gefixt, display dimmt jetzt auch bei der wiedergabe.

---

Sunday, September 23rd 2012, 10:42pm

• bugfix:
  hab die auf scaleQuantumToDouble() basierende aenderung mal gepusht ...

---

Thursday, September 13th 2012, 11:33pm

• news (vdr-plugin-graphlcd):
  plugin.c: vdr >= 1.7.30 API-change: ConfigDirectory() -> ResourceDirectory()

---

Saturday, June 16th 2012, 4:54pm

• news (graphlcd-base):
  
  • Image/GraphicsMagick: use much more relieable sample() instead of scale() for scaling images:
  • problems with distorted scaled icons/images or other display errors should now be history.
  • monochrome images: fix monochrome bug in imagefile.c:
    bgcolor and color should be working again for monochrome icons/symbols
  • improved relieability of eq()/ne()/gt()/lt()/ge()/le() if comparing 'mixture' of string / bool / value
  • fixed a bug which could lead to an infinite loop under rare circumstances (if a content part contains a spare # without a variable name)
  • permit and evaluate $( )$ expressions to enable direct embedding of functions in the content part of elements such as <text/>:
    eg: <text>$(add(#SomeVar,#SomeOtherVar))$</text>
    attention: $()$ is not verified (yet) when parsing the skin. if it contains syntactical errors, the unprocessed term will be displayed at runtime.
  • clang can now be used instead of g++.
    'CXX=clang make' now compiles the whole graphlcd-base using clang.
  • added support for fontconfig font name representations:
    eg.:
    attention: specifying a size term (eg. 'size=12') is mandatory!

news (vdr-plugin-graphlcd):
fixed a bug that has been introduced in a former update and rendered some services unusable

---

Sunday, March 25th 2012, 6:35pm [738] news (vdr-plugin-graphlcd):

   plugin kompiliert jetzt auch unter vdr 1.7.27 (das eine include war in display.c ohnedies ueberfluessig)

---

Sunday, March 11th 2012, 7:20pm [725] news (vdr-plugin-graphlcd):

   unterstuetzung fuer VDR >= 1.7.26 hinzugefuegt

---

Sunday, March 11th 2012, 2:26pm [722] news (vdr-plugin-graphlcd):

   {MenuTextScroll} sollte jetzt etwas zuverlaessiger funktionieren (noch nicht perfekt, aber zumindest brauchbar(er))

---

Tuesday, March 6th 2012, 9:25pm [704] news (graphlcd-base):

   serdisplib-treiber versucht jetzt flexibler, die serdisplib zu laden.

angefangen wird bei libserdisp.so.3 (jew. ohne und mit "/usr/local/lib/") bis hinunter zu libserdisp.so.1. wenn dann noch nix dann ist, dasselbe spiel mit libserdisp.so (ohne major version).

---

Tuesday, March 6th 2012, 1:11am [695] news (graphlcd-base):

   verbessertes logging (wo wird syslog-ausgabe generiert, syslog-flooding sollte jetzt behoben sein)
   zusaetzliches feature fuer progress bar: gradient

das gradient-feature kennt zwei optionen: gradient="total|current|vertical" und gradientcolor="<farbe>"

   gradientcolor: die farbabstufungen werden zwischen color und gradientcolor berechnet

   total: die farbabstufungen werden ueber die maximale groesse des progress bars berechnet
   current: die farbabstufungen werden nur ueber den tatsaechlich angezeigten progress bar berechnet
   vertical: die farbabstufungen werden ueber die dicke des progress bars berechnet

beispiele (geordnet nach screenshots):

   <progress ... color="0xDDC0FFC0" gradientcolor="0xFF2222FF" gradient="total" direction="0" current="{PresentProgress}" total="{PresentDuration}"/>
   <progress ... color="0xDDC0FFC0" gradientcolor="0xFF2222FF"
   gradient="current" direction="0" current="{PresentProgress}"
   total="{PresentDuration}"/>
   <progress ... color="0xDDC0FFC0" gradientcolor="0xFF2222FF"
   gradient="vertical" direction="0" current="{PresentProgress}"
   total="{PresentDuration}"/>

zu beachten:

   gradient 'overruled' peak (dh. sobald gradient verwendet wird, ist keine peak-anzeige mehr moeglich).
   es muss sowohl die option gradient als auch gradientcolor definiert sein damit die gradient-funktion aktiviert wird.

---

Tuesday, November 8th 2011, 11:57pm [679] channellogos sind jetzt 1:1 jene vom graphlcd master branch (inkl. dateinamen und alles. auch die channels.alias ist vom master branch. sollten channel logos im touchcol branch neuer / mehr / ... gewesen sein (was ich kaum glaube), sind diese jetzt weg)

---

Saturday, October 29th 2011, 11:22pm [669] news:

   neue Tokens
   neuer parameter 'evaluate' fuer <variable/>
   verbesserte (konsistentere) logausgaben

tokens:

   {ActualDevice} ... liefert die ID des aktuell aktiven empfangsgeraetes (startend mit 1)
   {SignalStrength} ... ab VDR 1.7.19: signalstaerke, von 0 - 100
   {SignalQuality} .. ab VDR 1.7.19: signalqualitaet, von 0 - 100
   {SupportsSignalInfo} .. werden {SignalStrength} und {SignalQuality} unterstuetzt?

mit dem parameter evalute kann nun festgelegt werden, wann eine variable neu evaluiert wird (relevant fuer variable, die berechnet werden und/oder den wert von tokens bekommen. werte fuer evaluate:

   always: variable wird bei jedem auslesen neu berechnet. wenn diese 10x im skin verwendet wird, wird 10x neu berechnet.
   tick: die variable wird nur einmal pro displayupdate neu berechnet, ansonsten wird der zuvor berechnete wert zurueckgeben
   switch: die variable wird nach einem channel- oder menueupdate neu berechnet
   once: die variable wird nur ein einziges mal berechnet (bei der ersten verwendung, ab dann wird der berechnete wert zurueckgegeben)
   interval: ein intervall (format: interval:<interval>) kann eingestellt werden (in ms), zb: evaluate="interval:1000" -> variable wird max. 1x / sekunde neu berechnet.

tick ist ab jetzt die standardeinstellung (wenn nichts angegeben wird).

mit dieser massnahme kann eine ungewuenschte exzessive neuberechnung (zb. innerhalb eines updatezyklus) vermieden werden, oder, wenn wie im falle von {SignalStrength} / {SignalQuality} das auslesen dieser tokens sehr lange dauert, abfangen von performanceproblemen. bei mir dauert das lesen von {SignalStrength} zw. 300 und 600 ms. wenn dieses token dann 3x neu gelesen wird, kommt es zu zieml. performanceproblemen (scrolling, ...) und ausserdem laufen die werte auseinander (zb. progressbar vs. label). tick alleine faengt bereits das auseinanderlaufen ab, ein interval kann darueber hinaus eine sinnvolle update-frequenz garantieren (Es ist nicht notwendig, Signalinfo alle 100ms neu auswertet zu lassen ...)

---

Monday, October 24th 2011, 8:13pm [658] news:

   unterstuetzung v. scaling von nicht-ImageMagick bildformaten (PBM, GLCD).
   serdisp-treibr: paranoia-checks (SetBrightness() sollte nicht mehr crashen); kapselung der touchevents (touchevents sind nicht mehr statisch in der klasse definiert, sondern nun an die jew. instanz gebunden)
   image cache: beim erfolgreichen laden eines bildes wird ins syslog eine meldung geschrieben (fuer debuggingzwecke, ...)

---

Friday, October 21st 2011, 1:08am [653] news:

   der graphlcd-eigene framebuffer-support ist jetzt in farbe und bunt! unterstuetzt werden die farbtiefen 8, 16, 24, 32.
   bei farbtiefe 8 wird automatisch eine RGB332-colourmap aktiviert und die farbwerte auf diese umgerechnet
   das framebuffer-device kann jetzt konfiguriert werden (zb: Device=/dev/fb1)
   damage-reporting (fuer das udlfb, aber auch ugly-damagereporting (@C-3P0: damit sollte auch das displaylink-modul jetzt funktionieren. konnte es nur mit dem udlfb testen, da ist ugly-damagereporting wirklich ugly: kleinere darstellungsfehler beim zeichnen)
   width / height kann nicht mehr angegeben werden. die nutzbare aufloesung wird, wenn zoom=1 angegeben ist, direkt aus der zur verfuegung stehenden framebuffer-aufloesung errechnet. (zb.: framebuffer: 800x600 -> zoom=1 -> nutzbare flaeche = 400x300)
   graphlcd.conf wurde entsprechend angepasst
   der graphlcd-framebuffer-support kann jetzt mehr und ist flexibler als der der serdisplib :)

---

Sunday, October 16th 2011, 12:38am [626] news:

   scale erlaubt jetzt auch 'auto' (die beste passende skalierung wird gewaehlt)
   images werden bei skalierungen auto/autox/autoy jetzt zentriert

---

Saturday, October 15th 2011, 6:53pm [622] news:

   skalieren von images ist jetzt moeglich (aber nur fuer formate, die v. image/graphicsmagick kommen (kein glcd, pbm):
   <image scale="<scale>" .../> scale=['none', 'auto', 'autox', 'autoy', 'fill'], default: 'none'. zb: <image scale="fill" .... />

   none: keine skalierung
   auto: beruecksichtigt aspect ratio, automatisch beste ausbreitung auf die nutzflaeche
   autox, autoy: beruecksichtigt aspect ratio, orientiert sich an der breite bzw. hoehe v. <image />
   fill: fuellt das ganze <image/>, aspect ratio wird nicht beruecksichtigt
   zentrierung erfolgt automatisch bei auto/autox/autoy

---

Thursday, October 13th 2011, 1:08pm [605] es scheint sich ein fehler in der bitorder in SetPixel() eingeschlichen zu haben. habe das jetzt bei den displays, die nicht mit pages (8 bit = 8 vertikale pixel) arbeiten behoben. davon ist nur 'image' verifiziert.

news:

   bit order fehler behoben: verifiziert: image, sed1330, ks0108

nicht verifiziert: hd61830, network, sed1520 EDIT: sed1330 und ks0108 sind jetzt auch verifiziert (ks0108 ist allerdings sehr langsam. da wuerde ich den ks0108-support v. serdisplib emfehlen)

---

Thursday, October 13th 2011, 10:22am [601]

-> news:

   graphlcd-eigener t6963c-treiber ist jetzt gefixt (getestet mit allen FS8/FS6 / UpsideDown=yes/no kombinationen)
   graphlcd-zeug laeuft immer noch korrekt auf einer alten FedoraCore5-schuessel mit vdr 1.4.7.

---

Saturday, October 8th 2011, 12:53am [591] news:

   musste die SVDRP-kommandos 'SET', 'SETEXP, 'UNSET', 'GET' aendern (logischer, ausserdem ist jetzt wieder <value> mit spaces moeglich:

   <key> kann jetzt um 'unteroptionen' erweitert werden: <key>[,display=<display>][,expire=<expire>]
   dadurch wird 'SETEXP' nicht mehr benoetigt und wurde entfernt.

die definitionen fuer 'SET', 'UNSET', 'GET' sind:

SET <key>[,display=<display>][,expire=<expire>] <value> GET <key>[,display=<display>] UNSET <key>[,display=<display>]

zb:

SET somekey,display=somedisplay,expire=30 das reh huepft hoch das reh huepft weit warum auch nicht es hat ja zeit GET somekey,display=somedisplay UNSET somekey,display=somedisplay

SET someotherkey,expire=60 in 60 sekunden ist alles aus GET someotherkey UNSET someotherkey

---

Saturday, October 1st 2011, 1:28pm [561] news:

   support fuer audiotrack-auswahl (+ audio channel anzeige bei der auswahl), neue tokens: 'AudioTrackItem', 'AudioTrackCurrent', 'IsAudioTrackCurrent', 'AudioChannel'.
   skins: unterstuetzung eines zusaetzlichen display-bereiches 'audio' (<display id="audio"> ... </display>)
   default.skin: unterstuetzung fuer audiotrack-auswahl + audiochannel-auswahl hinzugefuegt, bug fixes, verbesserungen

---

Thursday, September 29th 2011, 12:56am [560] news:

   aufwaendige ueberarbeitung des default-skins (das war vielleicht eine arbeit ...). sollte jetzt auf so ziemlich jedem (unter graphlcd sinnvoll verwendbaren) display zumindest brauchbare ergebnisse liefern und auch relativ flexibel skalieren. und auch auf nicht latin1-basierenden systemen (utf8 andere als latin1 codepages, iso-8859-1/15) sollten die fonts korrekt angezeigt werden.

anmerkungen:

   es ist ein one-for-all skin. daher wird es nicht ueberall perfekt aussehen. aber es stellt abhaengig v. aufloesung mehr oder weniger informationen dar.
   graustufen-displays sind noch nicht extra behandelt. einstweilen nur monochrom und farbdisplays (graustufen = TODO)
   auch TODO: verteilung der zwischenraeumen bei grossen displays damit die information besser auf dem display verteilt ist.
   das ganze skin ist ziemlich komplex: fehler werden hoechstwahrscheinlich nicht gerade wenige enthalten sein ... (obwohl: bei meinen tests funktioniert es ganz gut)

---

Thursday, September 22nd 2011, 1:14am [524]

neuigkeiten:

   das plugin unterstuetzt jetzt bis zu 4 displays gleichzeitig (contrib v. superelchi)
   cExtData kann jetzt die gespeicherten daten zu einem display ketten (wenn nicht: globaler fokus (dh. fuer alle displays gueltig)
   ein display-spezifischer eintrag hat vorrang vor einem gleichnamigen globalen
   im Makefile kann ueber PLUGIN_GRAPHLCDCONF der pfad zur graphlcd.conf festgelegt werden (wenn nicht definiert: /etc/graphlcd.conf). war, wenn ich mich richtig erinnere, ein wunsch von Keine_Ahnung
   das SVDRP-zeug ist entsprechend aufgebohrt worden.

SVDR:

   CONNECT: ohne parameter: alle zuvor angegebenen displays werden (re)connected, CONNECT displayname: das display <displayname> wird, wenn noch nicht vorhanden, zusaetzlich angehaengt, wenn bereits vorhanden: reconnect
   DISCONN: ohne parameter: alle displays werden deaktiviert
   SET, SETEXP, UNSET, GET: zusaetzlicher optionaler parameter fuer den scope (= display name). wenn nicht angegeben: globaler scope.
   die tokens {ExtDataIsAvailable:itemname} und {ExtDataItem:itemname} beziehen automatisch diesen scope mit ein

beispiel: 2 displays 'disp1', 'disp2', beide zeigen das token {ExtDataItem:test} an:

plug graphlcd set test hurra -> beide zeigen 'hurra' an

plug graphlcd set test hallo disp2 -> disp1 zeigt weiterhin 'hurra' an, disp2 zeigt 'hallo' an

plug graphlcd set test ahoi disp1 -> disp1 zeigt 'ahoi' an, disp2 immer noch 'hallo' an

plug graphlcd unset test disp2 -> disp1 zeigt 'ahoi' an, disp2 wieder 'hurra' (da nur der display-spez. eintrag geloescht worden ist)

---

Saturday, September 17th 2011, 10:45pm [514] hab wieder ein wenig im code herumgespielt, darum folgende neuigkeiten:

anderungen eher unter der oberflaeche:

   klassenattribute 'config', 'oldConfig' weg von den div. displayklassen in die basisklasse 'cDriver' verschoben, auch die initialisierung jetzt dort.
   dadurch kann der sowohl der name ('driver') als auch der zugehoerige config-name (= 'section name') direkt ueber die basisklasse abgefragt werden (vorbereitung fuer spaeter, stichwort multi-display)
   libglcddrivers.so benoetigt keine verlinkung mehr zu libglcdgraphics.so (die abhaengigkeit zur klasse cColor wurde aufgehoben)
   in section names duerfen keine ':' verwendet werden (nur falls jemand mal auf die idee gekommen waere: wird jetzt mit fehler abgefangen ...)

aenderungen an der oberflaeche:

   unterstuetzung fuer scrolling (bzw. blaettern) v. multitext text-objekten, neues attribute 'mlrelscroll' fuer text-objekte mit multiline (gibt eine relative aenderung der startposition innerhalb der anzuzeigenden textzeilen an und sollte nur waehrend eines Tick()'s kleiner/grosser 0 sein)
   drei neue tokens: 'IsMenuList', 'MenuText', 'MenuTextScroll'. 'IsMenuList': ist das aktuelle osd-menu eine liste?, 'MenuText': text in einem detail-menue (zb. detailansicht in einem schedule), 'MenuTextScroll': passendes token fuer das neue attribut 'mlrelscroll' (siehe oben).
   ':clean', ':rest' wird (analog wie bei text2skin) jetzt unterstuetzt fuer die tokens: 'MenuTitle', 'MenuCurrent', 'MenuText'. zb: {MenuTitle} = "bla fasel - laber bla", {MenuTitle:clean} = "bla fasel", {MenuTitle:rest} = "laber bla".
   {MenuCurrent} kann jetzt auch ausserhalb von <list/> verwendet werden. ausserhalb von </list> werden bei {MenuCurrent:clean} zusaetzlich etwaige leerzeichen + eine eventuell vorhandene nummerierung entfernt. zb: {MenuCurrent} = " 1 Bla", {MenuCurrent:clean} = "Bla"
   trans() funktioniert jetzt wie erwartet: wenn zb. eine so komische sprache wie 'Deutsch' eingestellt ist: trans('Schedule') => 'Programm'.
   cExtData ist nun eine singelton-klasse und daher nicht mehr von einem display-objekt abhaengig -> die gespeicherten daten ueberleben ein DISCONN/CONNECT:

   plug graphlcd help
   214-Plugin graphlcd v0.3.0 - Output to graphic LCD
   214-SVDRP commands:
   214-  CLS     UPD     OFF     ON      SET
   214-  SETEXP  UNSET   GET     CONNECT   DISCONN
   214 End of HELP info
   plug graphlcd get test
   900 GET test: (null)
   plug graphlcd set test bla
   900 SET ok
   plug graphlcd get test
   900 GET test: bla
   plug graphlcd connect serdisp_sdl1
   900 Display serdisp_sdl1: CONNECT ok.
   plug graphlcd get test
   900 GET test: bla

dies alles ermoeglicht jetzt ein paar nette spielereien:

   in multiline-texte kann jetzt nach oben/unten gescrollt werden. und zwar unabhaengig davon, wieviele und welche displays angehaengt sind.
   mit trans() und :clean koennen nette spielereien wie icons im hauptmenue erstellt werden (siehe bild 1 (englisch) und bild 2 (deutsch), die icons habe ich zum testen vom anthra-skin v. text2skin ausgeborgt):

    <variable id="MenuLogoPath"  value="'{ConfigPath}/logos/still/08bpp/100x119/menu'" />
    <variable id="MenuLogoW"   value="100" />
    <variable id="MenuLogoH"   value="119" />

    <variable id="ShowMenuLogo"  value="1"   condition="eq({MenuTitle:clean},'VDR')" default="0" />
    <variable id="MenuWidth"   value="sub({ScreenWidth},#MenuLogoW,4)" condition="#ShowMenuLogo"  default="{ScreenWidth}" />

    <variable id="MainMenuIcon"  value="'schedule.png'"  condition="and(#ShowMenuLogo,eq({MenuCurrent:clean},trans('Schedule')))" />
    <variable id="MainMenuIcon"  value="'channels.png'"  condition="and(#ShowMenuLogo,eq({MenuCurrent:clean},trans('Channels')))" />
    <variable id="MainMenuIcon"  value="'timers.png'"  condition="and(#ShowMenuLogo,eq({MenuCurrent:clean},trans('Timers')))" />
    <variable id="MainMenuIcon"  value="'recordings.png'"  condition="and(#ShowMenuLogo,eq({MenuCurrent:clean},trans('Recordings')))" />
    <variable id="MainMenuIcon"  value="'femon.png'"  condition="and(#ShowMenuLogo,eq({MenuCurrent:clean},trans('Signal Information')))" />
    <variable id="MainMenuIcon"  value="'setup.png'"  condition="and(#ShowMenuLogo,eq({MenuCurrent:clean},trans('Setup')))" />
    <variable id="MainMenuIcon"  value="'empty.png'" />

   <block condition="#ShowMenuLogo">
       <image x="add(#MenuWidth,2)" width="#MenuLogoW" y="add(#MenuHeaderH,3)" height="#MenuLogoH" path="#MenuLogoPath/#MainMenuIcon" />
   </block>

   mit der aufnahme von {MenuText} sollte jetzt alles angezeigt werden koennen, was auch graphlcd-0.1.x anzeigen konnte (wenn doch noch etwas fehlen sollte: mir bitte hier posten). siehe bild 3

---

Friday, September 9th 2011, 8:31am [494] news:

   CONNECT / DISCONN eingebaut, contrib v. superelchi (DISCONN, da DISCONNECT anscheinend zu lang ist. jdnfalls wurde es in der hilfe nicht vollstaendig angezeigt. es wird dennoch aber auch zusaetzlich 'DISCONNECT' vom plugin verstanden (nicht dokumentiert))
   zusaetzlich bei CONNECT: es kann optional auch ein anderer skin angegeben werden
   stabilitaet: beim verbinden an ein nicht angeschlossenes display sollte es jetzt keine crashes mehr geben (gemeldet v. Keine_Ahnung, von mir bei CONNECT/DISCONN-spielereien nachvollzogen. @Keine_Ahnung: das graphlcd-base ebenfalls auf den neuesten stand bringen (ansonsten bei DISCONN crash mit serdisp-treiber. bitte testen)).

---

Saturday, August 27th 2011, 5:52pm [453] news:

• installation v. udev-rulesfile hinzugefuegt.

---

Saturday, July 30th 2011, 4:43pm [322] neu:

   unterstuetzung eines simplen includes v. (xml-)dateien. genauso als ob der enthaltene textstream direkt in der skin-definition waere. (es wird 1:1 inkludiert ohne pre-processing oder steuerung ueber ev. conditions. dh: bei einem <block condition="<cond>"><include path="<path>"/></block> wird das include-file IMMER inkludiert, egal ob die condition zieht oder nicht.
   hoch- und gleichziehen der versionstrings der 3 teilbibliotheken auf 2.1.0.
   versionsnummer des graphlcd-base paketes ist jetzt 0.3.0.
   bug fix: syslog wird nicht mehr mit 'Invalid numeric value'-meldungen zugemuellt.

beispiele zum <include/>:

<include path="somefile.inc"/> <include path="{SkinPath}/somefile.inc"/>

diese zwei angaben bewirken dasselbe (ein relativer pfad ist automatisch relativ zum skin-pfad.

---

Saturday, July 9th 2011, 2:02pm [321] neu:

   positions- und dimensionsparameter (x/y/x1/y1/x2/y2; width/height) werden nun zur laufzeit ausgewertet und nicht mehr wie bisher nur beim parsen
   unterstuetzung fuer plugin 'span' (siehe screenshot und beispiel-xml-fetzen dazu)

achtung: die verwendung der kombination span/music-plugins ist (zumindest bei mir) sehr instabil (bei vdr-restart oder beim wechsel von einem anderen mediaplayer (zb. xinelibout) zum music-plugin kann ein segfault auftreten. problem: ein thread, der (annahme von mir) im music-plugin gestartet wird nach beendigung eines anderen threads verwendet noch einen bereits invalidierten zeiger auf ein VDR player-object weiter. wenn dem so ist und das span-plugin dann noch daten abfraegt: BUMM. habe mit einem untergriff (abfrage, ob cControl-object gueltig ist) zumindest verhindern koennen, dass das music-plugin bei hin-und-herspringen v. musikauswahl und abspielmodus das span-plugin zum crashen bringt, aber weiter kann ich nicht eingreifen (zumindest habe ich nix weiter gefunden).

anmerkung: initialisert wird das span-plugin mit der allerersten ServiceIsAvailable-abfrage! -> zb: {ServiceIsAvailable:span,bands=20,delay=250,falloff=4} legt fest, dass 20 baender angelegt werden sollen, der delay zwischen 2 abfragen auf 250 ms und der falloff auf 4 eingestellt werden. diese auswertung der parameter erfolgt nur ein einziges mal! (performance)

beispiel:

<variable id="SpanX" value="10"/> <variable id="SpanY" value="100"/> <variable id="SpanVolY" value="sub(#SpanY,18)"/> <variable id="SpanH" value="64"/> <variable id="SpanBarGap" value="2"/> <variable id="SpanBarW" value="5"/> <variable id="SpanPadding" value="2"/> <variable id="SpanBarX" value="add(#SpanX,#SpanPadding)"/> <variable id="SpanBarY" value="add(#SpanY,#SpanPadding)"/> <variable id="SpanBarH" value="sub(#SpanH,#SpanPadding,#SpanPadding)"/> <variable id="SpanBarTotW" value="add(#SpanBarW,#SpanBarGap)"/> <variable id="SpanBarCol" value="'white'"/> <variable id="SpanPeakCol" value="'0xFF777777'"/> <variable id="SpanW" value="add(mul(#SpanBarW,{ServiceItem:span,bands}),mul(#SpanBarGap,sub({ServiceItem:span,bands},1)),#SpanPadding,#SpanPadding)"/>

<block condition="{ServiceIsAvailable:span,bands=20,delay=250,falloff=4}">

 <rectangle x="#SpanX" y="#SpanVolY" width="#SpanW" height="15" color="0x773333FF" filled="yes"/>
 <rectangle x="#SpanX" y="#SpanVolY" width="#SpanW" height="15" color="blue"/>
 <text x="add(#SpanX,3)" y="add(#SpanVolY,2)" color="white" align="left" font="FontSpanLabel">L</text>
 <text x="add(#SpanX,3)" y="add(#SpanVolY,8)" color="white" align="left" font="FontSpanLabel">R</text>
 <progress x="add(#SpanX,18)" y="add(#SpanVolY,2)" width="sub(#SpanW,14)" height="11" color="0x77777733" direction="0" current="{ServiceItem:span,volume}"  total="100"/>
 <progress x="add(#SpanX,18)" y="add(#SpanVolY,2)" width="sub(#SpanW,14)" height="5"  color="0xAA55FF55" direction="0" current="{ServiceItem:span,volumel}" total="100"/>
 <progress x="add(#SpanX,18)" y="add(#SpanVolY,8)" width="sub(#SpanW,14)" height="5"  color="0xAA55FF55" direction="0" current="{ServiceItem:span,volumer}" total="100"/>
 <rectangle x="#SpanX" y="#SpanY" width="#SpanW" height="#SpanH" color="0x773333FF" filled="yes"/>
 <rectangle x="#SpanX" y="#SpanY" width="#SpanW" height="#SpanH" color="blue" />
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,0))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,0}"  peak="{ServiceItem:span,peak,0}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,1))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,1}"  peak="{ServiceItem:span,peak,1}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,2))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,2}"  peak="{ServiceItem:span,peak,2}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,3))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,3}"  peak="{ServiceItem:span,peak,3}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,4))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,4}"  peak="{ServiceItem:span,peak,4}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,5))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,5}"  peak="{ServiceItem:span,peak,5}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,6))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,6}"  peak="{ServiceItem:span,peak,6}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,7))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,7}"  peak="{ServiceItem:span,peak,7}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,8))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,8}"  peak="{ServiceItem:span,peak,8}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,9))"  y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,9}"  peak="{ServiceItem:span,peak,9}"  peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,10))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,10}" peak="{ServiceItem:span,peak,10}" peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,11))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,11}" peak="{ServiceItem:span,peak,11}" peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,12))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,12}" peak="{ServiceItem:span,peak,12}" peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,13))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,13}" peak="{ServiceItem:span,peak,13}" peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,14))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,14}" peak="{ServiceItem:span,peak,14}" peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,15))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,15}" peak="{ServiceItem:span,peak,15}" peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,16))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,16}" peak="{ServiceItem:span,peak,16}" peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,17))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,17}" peak="{ServiceItem:span,peak,17}" peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,18))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,18}" peak="{ServiceItem:span,peak,18}" peakcolor="#SpanPeakCol" total="100"/>
 <progress x="add(#SpanBarX,mul(#SpanBarTotW,19))" y="#SpanBarY" height="#SpanBarH" width="#SpanBarW" color="#SpanBarCol" direction="3" current="{ServiceItem:span,height,19}" peak="{ServiceItem:span,peak,19}" peakcolor="#SpanPeakCol" total="100"/>

</block>

---

Wednesday, June 29th 2011, 10:25pm [316] neu

   treiber fuer futabaMDM166A hinzugefuegt (aus 0.1.x) und angepasst
   mem leak fix fuer image.c (aus 0.1.x) portiert
   aktuellen noritake800 aus 0.1.x genommen und angepasst

---

Wednesday, June 29th 2011, 1:25am [315] neu:

   crtfont und genfont sollten jetzt wieder funktionieren (div. tests waren erfolgreich, die generierten fonts (.fnt) haben funktioniert)
   cPBMFile kann jetzt korrekt speichern (Save())
   aus cBitmap wurden LoadPBM()/SavePBM() entfernt (die wurden ohnedies nur von crtfont und genfont verwendet). fuer das laden und speichern von PBMs ist jetzt ausschliesslich die klasse cPBMFile verantwortlich (auch crtfont und genfont verwenden jetzt diese klasse).

hoffe, dass ich keine nebeneffekte hineingebracht habe, waren doch einige grundlegende aenderungen. meine tests brachten aber keine auffaelligkeiten zu tage ...

---

Monday, June 27th 2011, 10:29pm [314] neuigkeiten:

   graphlcd-base: habe das setzen v. monochrome-flag fuer imagemagick bilder einstweilen wieder deaktiviert (das ist dann doch aufwaendiger als gedacht)
   vdr-plugin-graphlcd: paranoia mode fuer strcmp. wenn das auch nicht hilft dann muss das wohl jmd. mit rds-faehigen radiosendern debuggen (gdb, mit dem man dann auch die konkreten inhalte der structs sehen kann).

---

Sunday, June 26th 2011, 9:15pm [312] neu:

   bei 1bpp imagemagick bildern wird jetzt das monochrome flag gesetzt (und schwarz und weiss entsprechend aufbereitet) => 'color' und 'bgcolor' werden jetzt beruecksichtigt.

der bugfix fuer cBitmap constructor wird spaeter committed (ist gerade groessere baustelle (anpassen der div. Save*-methods() an die 32bpp internas)

---

Saturday, June 25th 2011, 10:17pm [310] neuigkeiten:

   alle treiber sollten jetzt mit der 32bit colour internen darstellung zusammenarbeiten (jeder treiber hat jetzt eine gueltigte SetPixel()-Methode). ABER: alle bis auf simlcd und serdisp sind ungeprueft!!
   Set8Pixels() ist nicht laenger 'virtual', sondern ab jetzt eine in der basis-klasse definierte generische methode.

---

Tuesday, June 21st 2011, 11:54pm [308] bug fix:

   bug(s) in WrapText() versucht zu beheben (-> mesg <langertext>)

---

Sunday, June 19th 2011, 1:24pm [307] neuigkeiten:

   alpha channel: texte mit font-effekten werden jetzt auch brauchbar unterstuetzt
   opacity support fuer images -> zusaetzlicher parameter fuer <image />: opacity="<value>", <value> = [0, 255], default 255

---

Friday, June 17th 2011, 11:20pm [303] neuigkeiten:

   support fuer alpha channel

einschraenkung: bei texten mit einem font-effect (outline, shadow) funktionierts leider nicht brauchbar (aufgrund der art und weise, wie die effekte derzeit erzeugt werden).

---

Tuesday, June 14th 2011, 11:16pm [299] neuigkeiten: grosses aufraeumen beim i18n-zeug

   strings, die im code verwendet werden, kontrolliert in 18n.c (vdr 1.4.x) und po/*.po auf uebereinstimmung
   zeug, das nicht verwendet wird, deaktiviert oder geloescht
   italienisch hinzugefuegt (aus HEAD) -> po/it_IT.po und auch angepasst/eingewebt in i18n.c (=vdr 1.4.x)
   getestet auch mit vdr 1.4.7

---

Friday, June 10th 2011, 8:22pm [291] news

   fuer die text-effekte kann jetzt der parameter radius verwendet werden ...: radius in {1,2} (default: 1), hebt bei groesseren fonts den effekt besser hervor
   bei den funktionen wurde eq() als alias fuer equal() hinzugefuegt

---

Thursday, June 9th 2011, 11:28pm [287] neuigkeiten:

   fuer alle objekte (die positioniert werden), koennen jetzt auch die attribute 'x' und 'y' verwendet werden ('x' und 'y' war vorher nur fuer <image/> moeglich)
   'font' ist ab jetzt fuer <text/> und <button/> verpflichtend (bis jetzt wurde einfach nichts angezeigt wenn keine font angegeben wurde - was etwas verwirrend war)

---

Sunday, June 5th 2011, 11:05am [258] neu:

   html-entities &#x<hexID>; und &#<decID>; werden jetzt unterstuetzt

neu2 (bug fixes):

   scrolltext laeuft nicht mehr ueber den rechten object-rand hinaus
   offset-fix wenn variablen in <text/> verwendet werden (da kam es bis jetzt zu verschiebungen, wenn nach so einer variable ein token folgte)

neu3 (bug fix):

   scrolltext bricht nicht mehr vorzeitig ab (scrollt bei 'once' jetzt fertig durch und bei 'always' ohne versatz weiter)

---

Saturday, June 4th 2011, 6:12pm [252] neuigkeiten:

   skins sind jetzt per definition immer UTF-8 (auch fuer !UTF-8 systeme)
   freier UTF8 text (zb. <text>das reh hüpft über...</text> wird auf !UTF-8 systemen automatisch konvertiert - der text selber muss aber UTF8 sein!
   token-inhalte beduerfen keiner konvertierung, da diese ohnehin bereits vom system in der richtigen kodierung geliefert werden
   token-, font- und variablennamen duerfen nur USASCII7-zeichen haben (wird zzt. noch nicht ueberprueft, wird aber kommen)
   zusaetzliches boolsches token {IsUTF8}: liefert, ob das system UTF8 ist oder nicht (relevant, wenn zb. UTF-8 fonts mit eigenen zeichen verwendet werden wollen, zb VDRSymbols - diese sind auf !UTF-8-systemen natuerlich nutzlos)

---

Tuesday, May 31st 2011, 1:05am [221] news: weil mit den texteffekten so schoen herumzuspielen ist: diese sind jetzt fixbestandteil (derzeit 2 effekte: shadow, outline) default: kein effekt (= 'none')

<text ...... effect="[none|shadow|outline]" effectcolor="[some colour]" .... >text</text>

zb: <text ...... effect="shadow" color="white" effectcolor="black">....

-> weisser text mit schwarzem schatten

---

Sunday, May 29th 2011, 6:05pm [211] die zwei angekuendigten tokens sind jetzt im vdr-plugin-graphlcd -> {ForegroundColor}, {BackgroundColor}

diese sollten (aus logischer sicht) ab jetzt statt {DefaultForegroundColor}/{DefaultBackgroundColor} in den skins verwendet werden

---

Saturday, May 28th 2011, 1:32pm [192] neue anpassungen:

   die basisklasse cDriver hat jetzt eine generische Set8Pixels()-methode. diese wird, wenn alle treiber ueberarbeitet sind, nicht mehr 'virtual' sein (dh. nicht mehr ueberlagert werden koennen - vorerst aber schon noch).
   serdisp-treiber: intern ueberarbeitung der class-members fg_colour und bg_colour: uint32_t statt long, verwenden der cColor-farben jetzt durchgehend. ausserdem wird jetzt die Set8Pixels()-methode der basisklasse verwendet (auch wenn dies zu einer merklichen verlangsamung fuehrt). aber diese methode sollte ohnehin obsolet sein (wird nur noch von 'lcdtestpattern' verwendet).

---

Tuesday, May 24th 2011, 9:30pm [181] finally: unterstuetzung fuer transparenz (aber nur alles oder nichts, keine alpha-channels).

   'text' und 'image' sind jetzt standardmaessig transparent, ein setzen v. bgcolor, um mit dem hintergrund zu korrespondieren ist nicht mehr notwendig
   nette effekte wie text mit schatten ist jetzt moeglich (wird ev. ein zusaetzl. attribut fuer 'text')
   bei bildern mit alpha-channel wird alles opaque >= 225 (willkuerlich derzeit) als transparent gewertet (interessant fuer PNGs)

und ganz wichtig: ein bug fix, ohne dem das plugin crashen kann (wenn ein cBitmap objekt mit width=0 allokiert wird) ist auch dabei

---

Thursday, May 19th 2011, 10:18am [164] der vorschlag v. Keine_Ahnung hat mir keine ruhe gelassen.

folgendes ist jetzt moeglich:

<block condition="{ExtDataIsAvailable:somemsg}">

<text x1="#W" width="90" y1="#Y" y2="-1" color="#SomeCol" font="FontInfoSignal">
 Msg: {ExtDataItem:somemsg}
</text>

</block>

   ExtDataIsAvailable:<key> prueft, ob ein wert <key> gespeichert ist
   ExtDataItem:<key> holt den wert von <key>

ueber SVDRP koennen diese werte gesetzt werden:

   SET <key> <value>: wert setzen, der ueber <key> angesprochen werden kann (value darf spaces enthalten):
   SET somemsg Das Reh huepft hoch, das Reh huepft weit, warum auch nicht, es hat ja Zeit.
   SETEXP <exp> <key> <value>: dasselbe wie oben, nur mit ablaufdatum (in sekunden):
   SETEXP 10 somemsg Ich verschwinde nach 10 Sekunden
   UNSET <key>: key loeschen
   GET <key>: <key> ueber SVDRP abfragen

---

Monday, May 16th 2011, 12:37am [145] object - farben (hinter/vordrgrund) werden jetzt zur laufzeit ausgewertet (hat mich einiges an herumhackerei inkl. einmal alles komplett verwerfen und neu starten gekostet. ist auch jetzt schoener (codetechnisch) als mein vorheriger versuch).

folgendes ist jetzt moeglich:

<variable id="ColFemonSigProg" value="'red'" condition="le({ServiceItem:femon,percent_signal},25)"/> <variable id="ColFemonSigProg" value="'green'" condition="gt({ServiceItem:femon,percent_signal},80)" default="'yellow'"/> <variable id="ColFemonSNRProg" value="'red'" condition="le({ServiceItem:femon,percent_snr},25)"/> <variable id="ColFemonSNRProg" value="'green'" condition="gt({ServiceItem:femon,percent_snr},80)" default="'yellow'"/>

<progress x1="#SomeX1" width="70" y1="#SomeY1" height="2" color="#ColFemonSigProg" direction="0" current="{ServiceItem:femon,signal}" total="65536"/> <progress x1="#SomeX2" width="70" y1="#SomeY2" height="2" color="#ColFemonSNRProg" direction="0" current="{ServiceItem:femon,snr}" total="65536"/>

die 2 aussteuerungsbalken fuer femon signal und snr werden abhaengig der prozentuellen staerke eingefaerbt: rot: <= 25 gruen: > 80 gelb: alles dazwischen

---

Thursday, May 12th 2011, 11:19pm [118]

neue updates:

• variable koennen jetzt auch werte a la "{SomeValue}" haben. kein herumtricksen mit "add({SomeValue},0)" mehr notwendig (die aenderung dafuer war minimal, hoffentlich ist das auch stabil)
• das display wird beim niederfahren des plugin (wenn der VDR beendet wird) jetzt geloscht

---

Thursday, May 12th 2011, 1:04am [107] news:

   variable, die functions enthalten (zb. <variable id="blafasel" value="add({DateTime:%S},100)" />) werden jetzt zur laufzeit evaluiert (zuvor: beim parsen einmal evaluiert und dann fix bis zum bitteren ende gespeichert).
   showpic kann jetzt auch (experimentell!) das imagemagick-zeug anzeigen (falls aktiviert).

---

Saturday, May 7th 2011, 11:06pm [48] der erste schnellpfusch in sachen imagemagick funktioniert bereits (noch nicht ganz brauchbar (orf-logo ist zb. gedithered obwohl es das nicht soll)), aber das logo ist zumindest schon in farbe zu sehen. gibts irgendwo animierte senderlogos fuer text2skin? die sollten eigentlich auch aus dem stand funktionieren jetzt ...

anmerkung: die bilder sind mit libsdl-ausgabe erstellt (da muss ich nicht fotografieren), aber mit derselben aufloesung (320x240) wie l4m320t.

EDIT: dithering problem war gar keines. das standard orf1-logo war schon so. das alternativlogo sieht hingegen brauchbar aus.

das zeug ist auch bereits committed. wenn man es testen will muss man im glcdgraphics/Makefile die variable IMAGELIB setzen: IMAGELIB = imagemagick

oder statt imagemagick sollte auch graphicsmagick funktionieren.

---

Monday, May 2nd 2011, 12:15am [1] graphlcd (base, vdr-plugin) touchcol branch

kurze zusammenfassung:

   unterstuetzung fuer farbe (urspruenglich von randy, darauf aufbauend von mir dann noch zieml. beackert)
   unterstuetzung v. touchpad (einstweilen nur l4m320t)
   anreicherung des skin-supports um weitere elemente/attribute/features
   zusammenfassung der aenderungen ist im 'HISTORY' v. graphlcd-base zu finden (bis auf das, was ich vergessen habe, aufzuzaehlen :)
   im vdr-plugin-graphlcd ist ein skin fuer das l4m320t enthalten ('touchcol'), dass fuer mich zum herumspielen dient.

benoetigte software-versionen:

   aktuelle SVN-version v. serdisplib (am besten vom 1.98-zweig)
   serdisplib muss mit ./configure --enable-experimental erstellt werden (ansonsten funktioniert der support fuer GPIs nicht (touchpad))
   sowohl v. graphlcd-base als auch von vdr-plugin-graphlcd muss der jeweilige branch 'touchcol' verwendet werden
   skin 'touchcol' wie gewohnt ins verzeichnis <path_to_vdr_stuff>/plugins/graphlcd/skin kopieren (parallel zu 'default').
   da dieses zeug sowieso nur mutige und fachkundige testen werden, erspare ich mir weitere erklaerungen zu kompilierung, installation, plugin-parameter, ...

die 2 git branches koennen geholt werden zb mit:

git clone git://projects.vdr-developer.org/graphlcd-base.git -b touchcol graphlcd-base.git.touchcol git clone git://projects.vdr-developer.org/vdr-plugin-graphlcd -b touchcol vdr-plugin-graphlcd.touchcol

aktuelle serdisplib zb mit:

svn co https://serdisplib.svn.sourceforge.net/svnroot/serdisplib/serdisplib/branches/serdisplib-1.98.x serdisplib-1.98.x_svn

das ganze dann mit dem skin touchcol aktivieren und dann sollte eigentlich schon knallbunte ausgabe am l4m320t erscheinen und dieses sogar mit herumtapserei zu bedienen sein. skin 'touchcol' ist mit focus auf das l4m320t erstellt worden und in erster linie als testskin. auf anderen displays koennte es ev. nicht gut ausschauen ;-)

aber auch ohne touchpad sollte das ganze zumindest fuer farbausgabe durchaus interessant sein (und auch schwarzweiss-displays sollten funktionieren - muss aber eingestehen, dass ich in letzter zeit nur mit farbdisplays getestet habe - da kann es unter umstaenden zu problemen kommen bei der darstellung).

werde aber in naechster zeit noch weitere skins committen (habe ein paar herumliegen, die ich aber schon lange nicht mehr angesehen habe und die einer ueberarbeitung beduerfen).

EDIT:

nicht alle treiber funktionieren derzeit.