LCDproc und Umlaute

Hallo,

darf ich einen dritten Patch in die Runde werfen? Zu finden hinter dem Link in meiner Sig.
In ein paar Wochen werde ich etwas mehr Zeit haben und mich evtl. noch einmal in vdr-LCDproc reindenken (jedesmal denke ich, "ob man dieses Plugin nicht mal komplett neu macht, so konfus wie es programmiert ist - aber ich maße mir nicht an, es dann wirklich besser hinzukriegen").
Als Reminder für mich selber soll dieses Posting dienen. Falls JoWi oder SHF jedoch schon etwas zusammenfügen, wäre es schön, wenn ihr meinen Teil dabei vielleicht mit bedenkt bzw. wenigstens nicht ignoriert. Natürlich überschneiden sich bestimmt einige Dinge. Auch ich habe mich an die Backlight-Steuerung gemacht, allerdings nur sehr speziell an meine HW angepasst.

Viele Grüße,
Chriss

Also, ich hab heute mal meinen Patch zerlegt und den Connect- (muss zuerst) und den Prio/Backlight-Teil an die jw3 angepasst. Das Anpassen war eigentlich kein Problem, es sollte mit der -jw4 eigentlich genauso laufen. Getestet hab ich allerdings noch nichts, das wird auch frühestens am WE was. Ich denke, es ist ohnehin besser, ich warte auf die -jw4 bevor ich zu viel Zeit rein stecke.

Eine Anmerkung zu den Prioritäten hab ich noch:
An sich läuft alles einwandfrei (Wechsel der Prio bei Aktivitat/Inaktivitat -> Wechsel der Anzeige je nach eingestelltem Wert, ...) nur verhalten sich die Clients merkwürdigerweise genau umgekehrt zur LCDproc-Doku (höhere Prio darf anzeigen). Die Ursache konnte ich bislang noch nicht ergründen, bin aber inzwischen einigermassen sicher, dass es nicht am Plugin liegt.

Rein informativ habe ich auch die beiden anderen Teile des Patches (allerdings gegen die 0.0.10) angefügt.

Beim Volume-Teil ist da noch eine Änderung beim Bargraph drin, so ganz sicher bin ich nicht mehr wo zu die war.
Ich glaube aber das war, weil es sonst die Länge auf meinem (kleinen) Display nicht gepasst hat. Ich schreib das nur, damit es nicht vergessen wird, wenn das da dann hakt können wir die Änderung dann noch mit rein nehmen.

Zitat

Original von theonlychriss
darf ich einen dritten Patch in die Runde werfen?

Nur zu ;).
Wobei mir da gerade auch noch der recordings-Patch von Saxman2k einfällt. An dem Teil sollte man vielleicht sowiso mal was machen, da inzwischen mehr als 4 DVB-Karten möglich sind.

Zitat

Auch ich habe mich an die Backlight-Steuerung gemacht, allerdings nur sehr speziell an meine HW angepasst.

Meine Lösung sollte eigentlich mit jeder HW arbeiten, sofern der LCDproc-Treiber das korrekt weiterleitet.

Zitat

Falls JoWi oder SHF jedoch schon etwas zusammenfügen, wäre es schön, wenn ihr meinen Teil dabei vielleicht mit bedenkt bzw. wenigstens nicht ignoriert.

Ich hab auch mal einen Blick in deine Version geworfen und musste feststellen, dass du da einiges gemacht hast (Spectrum-Analyzer, irgendwas mit femon, die Sonder-Symbole, dann noch was an einigen Screens, ... ). Ich muss gestehen, dass ich da nicht so recht durchblicke, falls du das als Einzel-Patches hast währe das echt hilfreich.

Wie sieht das denn mit den Spezial-Symbolen aus, ist der verlinkte Treiber-Patch nur für das eine Displaymodell zu brauchen, oder erweitert das die Fähigkeiten des LCDd, so dass auch andere Displays mit den gleichen Kommandos angesteuert werden können?
Es gibt ja inzwischen immer mehr Multimedia-Displays (das vom MD8800 PC zum Beispiel, bei dem kann man die Icons übrigens auch schon über LCDproc steuern) mit sehr ähnlichen Zusatz-Icons, da würde eine einigermassen universelle Lösung echt Sinn machen.

Hallo SHF,

der verlinkte Treiber ist der Treiber für das iMon-LCD - und natürlich nur für dieses bzw. Clones davon, von denen mir aber keine bekannt sind.
Hmm, Einzel-Patches habe ich dafür nicht gemacht - das wurde mir irgendwann zuviel Arbeit. Es hatte ja mit den Span-Erweiterungen angefangen. Generell müsste es auch universell gehen, indem man die Werte für die Ansteuerung der einzelnen Display-Symbole in ein "Symbol"-Array oder eigene kleine Datenstruktur packt und dann beim Laden von vdr-lcdproc das richtige auswählt.
Das bisschen Code vom Femon habe ich nur drin, da ich damit den AC3-Status auslese und anzeige. Gefällt mir recht gut, jedoch funktioniert dies nicht bei Aufnahmen - aber evtl. löst sich das automatisch beim Wechsel auf .ts als Aufnahmeformat *träum*.
Und die Änderungen an ein paar Screens habe ich "für mein Empfinden" als Verbessung eingebaut. Ist auch nur auf meinem 16*2 getestet. Wie gesagt, wenn ich wieder etwas mehr Zeit habe, schaue ich es mir genauer an - nur eben jetzt erstmal nicht.

Viele Grüße,
Chriss

Hallo!

So, habe jetzt auch nochmal getestet. Schließe mich MichaelB an. Den Fehler "Taste dr?cken, um ..." kann ich reproduzieren. Ansonsten sieht das schon mal richtig gut aus. Danke dafür!

Viele Grüße
Wundertüte

Zitat

der verlinkte Treiber ist der Treiber für das iMon-LCD - und natürlich nur für dieses bzw. Clones davon, von denen mir aber keine bekannt sind.

Das war mir soweit schon klar, was ich noch nicht raus habe ist wie die Icons angesteuert werden. Geht das vom Plugin direkt zu dem Treiber oder geht das auch über LCDproc?

Zitat

Hmm, Einzel-Patches habe ich dafür nicht gemacht - das wurde mir irgendwann zuviel Arbeit.

... und ich soll das so mal eben überblicken ;).

Zitat

Es hatte ja mit den Span-Erweiterungen angefangen. Generell müsste es auch universell gehen, indem man die Werte für die Ansteuerung der einzelnen Display-Symbole in ein "Symbol"-Array oder eigene kleine Datenstruktur packt und dann beim Laden von vdr-lcdproc das richtige auswählt.

Am besten währe eine Erweiterung des LCDproc-Protokolls, zB. sowas wie:

"Icons: recordin:on cd:off antenna:blink ...

Da könnte man ein paar gebräuchliche Standard-Icons definieren und ist frei für Spezialitäten, die würden dann halt nur von ausgewählten Clients werden.

Zitat

Das bisschen Code vom Femon habe ich nur drin, da ich damit den AC3-Status auslese und anzeige. Gefällt mir recht gut, jedoch funktioniert dies nicht bei Aufnahmen

Lässt sich das nicht über den VDR bekommen, der zeigt den Audiostatus doch auch an.

Zitat

Und die Änderungen an ein paar Screens habe ich "für mein Empfinden" als Verbessung eingebaut. Ist auch nur auf meinem 16*2 getestet. Wie gesagt, wenn ich wieder etwas mehr Zeit habe, schaue ich es mir genauer an - nur eben jetzt erstmal nicht.

Mit dem Titel-Screen bin ich auch nicht glücklich, der ist auf einem 2 zeiligen Display alles andere als Optimal. Ich würde den am liebsten, zumindestens teilweise, konfigurierbar machen.
Mit den anderen Screens bin ich, bis auf Kleinigkeiten eigentlich recht zufrieden.

Btw.: Was stellt der SA-Screen bei dir eigentlich dar?

Hallo SHF,

Zitat

Geht das vom Plugin direkt zu dem Treiber oder geht das auch über LCDproc?

Es geht quasi über LCDproc direkt in den Treiber. LCDproc reicht die Werte ungesehen weiter, da es "display-spezifische" Befehle sind. Und da das iMon-Display derer so viele hat, musste ich da auch noch stark rumtricksen, denn ein Integer reicht nicht aus, um alle Symbole eindeutig anzusprechen.

Hehe, überblicken nicht, aber "einfach nur übernehmen" hätte ja evtl. funktionieren können :unsch.

Zitat

Am besten währe eine Erweiterung des LCDproc-Protokolls ...

Uhh, da bin ich raus aus der Nummer. Klar, das geht, nur ob der/die LCDproc-Chef(s) das auch mitmachen, ist 'ne andere Frage. Soweit ich weiss, sind die Treibererweiterungen für das iMon-LCD noch nicht einmal im offiziellen LCDproc übernommen worden.

Zitat

Lässt sich das nicht über den VDR bekommen, der zeigt den Audiostatus doch auch an.

Jain, er zeigt "mp2: mono, stereo bzw. ac3", aber bei ac3 nicht, wie viele Kanäle enthalten sind. Diese Info wird mit dem femon-Teil ermittelt, was ja bei Aufnahmen nicht geht.

Zitat

Was stellt der SA-Screen bei dir eigentlich dar?

Einen SA :arme, und die Titelinfos (bei richtig gepatchtem music/mp3/mp3ng/cdda). Beides auf der Hälfte des Screens, horizontal geteilt. Also bei einem Display mit 2 Zeilen je eine und bei bei 4 Zeilen (hatte ich vorher), eben je 2.

Viele Grüße,
Chriss

Zitat

Original von theonlychriss
Es geht quasi über LCDproc direkt in den Treiber. LCDproc reicht die Werte ungesehen weiter, da es "display-spezifische" Befehle sind. Und da das iMon-Display derer so viele hat, musste ich da auch noch stark rumtricksen, denn ein Integer reicht nicht aus, um alle Symbole eindeutig anzusprechen.

Das geht irgendwie über Command-Geschichte?
Beim MD8800-Display wurde das nämlich auch so gemacht.

Zitat

Hehe, überblicken nicht, aber "einfach nur übernehmen" hätte ja evtl. funktionieren können .

Von Sachen, die ich nicht verstehe und auch nicht testen kann, lasse ich die Finger, da da nie was vernünftiges raus kommt.
Die Änderungen an den Screens werde ich mir aber auf jeden Fall mal ansehen, soweit mein Display da mit macht.

Letztendlich ist es aber jowi24s Entscheidung was rein kommt.
Die Priorität liegt bei mir aber bei den LCDproc-Grundfunktionen, dass die endlich mal vernünftig laufen. Und dass das Plugin auch auf kleinen (1 und 2 Zeilen) Displays zu brauchen ist.

Zitat

Uhh, da bin ich raus aus der Nummer. Klar, das geht, nur ob der/die LCDproc-Chef(s) das auch mitmachen, ist 'ne andere Frage.

Bislang waren die bei dem was ich geändert hab immer recht aufgeschlossen, man muss halt einen gescheiten Patch (mit Dokumentation) liefern. Am LCDd selber war ich aber auch noch nicht dran.

Zitat

Jain, er zeigt "mp2: mono, stereo bzw. ac3", aber bei ac3 nicht, wie viele Kanäle enthalten sind. Diese Info wird mit dem femon-Teil ermittelt, was ja bei Aufnahmen nicht geht.

Ach so.

Hallo SHF,

wenn Du mit der "Command-Geschichte" folgendes aus der LCDproc-API meinst, dann ja:

Zitat

output { on | off | int }
Sets the general purpose output on some display modules to this value. Use on to set all outputs to high state, and off to set all to low state. The meaning of the integer value depends on your specific device, usually it is a bit pattern describing the state of each output line.

Nachdem ich ein paar Bilder vom MD8800-Display gefunden habe, würde ich Dir da zustimmen. Ich wusste gar nicht, dass es nun doch schon einige Displays mit solchen Extras gibt - die auch per LCDproc angesteuert werden können. Danke für den Hinweis! Das überzeugt mich sofort, das LCDproc-Protokoll aufzubohren.

Klar entscheidet jeder selber was in seinen eigenen Patch kommt. Es wäre nur schön, wenn nicht jeder Portal-User seinen eigenen schreibt - überspitzt formuliert - sondern wir uns da etwas abspechen, was hier ja gerade getan wird.

Viele Grüße,
Chriss

Zitat

Original von theonlychriss
wenn Du mit der "Command-Geschichte" folgendes aus der LCDproc-API meinst, dann ja:

Ups, mein Fehler, hätte "Output-Geschichte" heissen sollen.
Wir meinen aber das gleiche.

Zitat

Nachdem ich ein paar Bilder vom MD8800-Display gefunden habe, würde ich Dir da zustimmen. Ich wusste gar nicht, dass es nun doch schon einige Displays mit solchen Extras gibt - die auch per LCDproc angesteuert werden können. Danke für den Hinweis! Das überzeugt mich sofort, das LCDproc-Protokoll aufzubohren.

Derartige Displays gibt es inzwischen an einigen Multimedia-PCs und die Icons sind praktisch überall mehr oder weniger die Gleichen.
Wobei ich nicht genau weiss was das im einzelnen für Displays sind. Die erwähnten iMon-Clone dürften da aber dabei sein.

Zitat

Klar entscheidet jeder selber was in seinen eigenen Patch kommt. Es wäre nur schön, wenn nicht jeder Portal-User seinen eigenen schreibt - überspitzt formuliert - sondern wir uns da etwas abspechen, was hier ja gerade getan wird.

Das sehe ich genau so, am liebsten währe es mir, wenn am Ende eine neue semioffizielle Version dabei rauskommt.
Diese Patcherei von verschiedenen Seiten verursacht bei den Programmierern nur unnötige Mehrarbeit und Verwirrung bei den Nutzern.

Generell hab ich auch nichts dagegen neue Funktionen einzubauen, auch wenn sie mir nichts bringen (Ich hab nur so ein einfachen Kassen-VFD).
Nur die muss dann halt jemand zuliefern, der die auch testen kann und es muss sichergestellt sein dass keine Probleme mit einfachen Displays, schwächeren Computern usw. gibt.

jowi24

Bei deinem Patch wird das Logfile zugemüllt mit "conversion failed". Das kommt von Aufrufen der Convert-Routine mit NULL-Pointern. Ich habe mir nicht die Mühe gemacht, woher diese kommen, ich habe nur die Routine Convert erweitert (und auch noch Strings mit der Länge 0 aussortiert):

const char* cLcd::Convert(const char *s) {
	// do character recoding to ISO-8859-1
	if (!s) return s;
	if (strlen(s)==0) return s;
	const char *s_converted = conv->Convert(s);
	if (s_converted == s) {
	  esyslog("lcdproc-plugin: conversion to ISO-8859-1 failed:");
	  esyslog("lcdproc-plugin: '%s'",s);
	}
	return s_converted;
}

SHF, theonlychriss

Zitat

am liebsten währe es mir, wenn am Ende eine neue semioffizielle Version dabei rauskommt

Ein grosser Problem bei der Plugin-Entwicklung ist einfach, das es keine zentrale Webseite dafür gibt (auf die jedes Plugin im Source abgelegt wird) und wo es eine aktuelle Maintainerliste gibt. Da sollte dann aber nur Leute rein, die wirklich gewillt sind und auch die Zeit dazu haben ein Plugin zu betreuen. Und die sollten dann auch die Ansprechpartner für Patches sein.

Was hilft es, wenn einer sagt "ich bin der Autor von Plugin XY und schaue auch danach". Man fragt nach ob dieser sein Plugin auf gettext erweitert und dann passiert einfach nichts. Dann nimmt man das eben selbst in die Hand und pfeift auf den Autor. Wenn man nett ist stellt man einen Patch hier rein und das wars dann. Glücklich der, der sich dann die einzelnen Patches hier im Forum zusammensammeln kann (bis vor kurzem wusste ich nichtmal das es eine jw3-Version des lcdproc-Plugins gibt!).

Es gibt viele Plugins, die von den Distributionsbetreuern z.B. auf vdr 1.6 gehievt wurden. Wo sind denn da die Autoren?

Gruß

Joe_D

Zitat

Original von Joe_D
Ein grosser Problem bei der Plugin-Entwicklung ist einfach, das es keine zentrale Webseite dafür gibt (auf die jedes Plugin im Source abgelegt wird)

Da gab es letztens mal einen Ansatz dazu, was daraus geworden ist weiss ich aber nicht.

Zitat

Glücklich der, der sich dann die einzelnen Patches hier im Forum zusammensammeln kann (bis vor kurzem wusste ich nichtmal das es eine jw3-Version des lcdproc-Plugins gibt!).

Ging mir auch so, deswegen auch die Hoffnung es zu einer neuen semioffizielle Version zu bringen.

Zitat

Es gibt viele Plugins, die von den Distributionsbetreuern z.B. auf vdr 1.6 gehievt wurden. Wo sind denn da die Autoren?

Vielleicht noch bei der 1.4 :schiel.

-jw4 ist fertig

Viel Spass damit.

So, endlich bin ich zum testen gekommen, seit dem WE läuftbei mir eine -jw3 mit meinem Prio und Backlight-Patch.
Eine Kleinigkeit war noch zu ändern (siehe Anhang), aber damit läuft es und bis jetzt auch stabil.

jowi24
Wenn ich den Patch zwecks integration auch für die -JW4 machen soll, dann melde dich bei mir.
Das sollte kein grösseres Problem sein, nur testen kann ich das leider nicht (der VDR 1.6 will noch nicht).

Hallo,

leider habe ich auch trotz der genialen -jw5 Version (Danke für die stabile Version!) immer noch die Umlaute nicht.

Finde aber auch in meiner /var/log/syslog kein Eintrag über irgendwelche Conversions-Errormeldungen. Sind die woanders protokolliert?

Im Menu habe ich schon alle Charsets durchprobiert. Jedesmal kommen andere Zeichen, aber keine "normalen" Umlaute.

Ich setze die lcdproc-0.5.2 Version ein. Meine LCDd.conf hänge ich an, vielleicht findet ihr ja meine Blindheit. Ich sehe nämlich einfach nicht mein Problem.

Mein VDR hat die Version 1.6.0-1 u.a. mit dem vdr-lcdproc-0.0.10-jw5.tgz Plugin (ohne jeden weiteren Patch, wil ihr die komplett implementiert habt!)

Danke für Eure Hilfe.

Gruß,

Pit

Ich schätze das wird ein UTF8-Problem sein, dazu soll es jetzt auch eine Einstellung geben.

Bitte poste mal einen Auszug aus dem Sys-Log vom VDR-Start. Dort müsste es einen Eintrag geben, der aussagt mit welchem Zeichensatz der VDR läuft.

Hi SHF,
Hi LiamHD,

habe eben erst eure Fragen gesehen, als ich mal wieder an das Umlaute-Problem meines hd44780-Display gemacht habe. Entschuldigt bitte die Verzögerung und danke das helft...(erhöht den WAF-Faktor doch sehr...)

Ich habe als Anhang meine syslog-Datei, worin beim Start immer der Codeset UTF-8 angezeigt wird. Oder muß noch andere Einstellungen prüfen ?

Achja, wenn ich in der lcdtranstbl.h den Eintrag /* 246 ( 'ö' ) */ (unsigned char) 239, verändere kommen auch andere Zeichen im Zeichen, nur halt kein "ö" bzw. keine Umlaute...

Danke,

Pit

EDIT: Diesmal auch mit Anhang !

Zitat

Original von P3F
Ich habe als Anhang meine syslog-Datei, worin beim Start immer der Codeset UTF-8 angezeigt wird. O

Ich seh' keinen Anhang.

Hallo

seht doch auf den Patch von mir.
Die meisten Display's arbeiten noch mit dem alten Zeichensatz(Codepage) 850.
Dieses ist ein Zeichensatz den DOS und WINDOWS verwendet.

Für die lcdkeyconf.h müsst Ihr nur noch eure Codes eingeben.
Falls eure Display's keine Tastaur haben, müsste dieser Patch eigentlich mit der Page 0 im lcdproc laufen.

mfg.
billi