[Ursache gefunden] Tastatur im VDR ist deutsch erzeugt aber keine Umlaute

Hallo,
In den Eingabefeldern (z.B. Kanalnamen Editieren) kann ich per deutscher Tastatut (Z ergibt Z) schreiben aber die Umlaute erzeugen keine Raktion. Per SMS Methode mit der Fernbedienung gehen die Umlaute (das Feld erlaubt sie also). In der der Konsole (ALT+F1) funktioniert die Tastatur normal.

Hat da zufällig jemand ne Idee wo ich da ansetzen könnte?

Edit: Das Enviroment ist

VDR_TMP_DIR=/dev/shm/.vdr/vdr/tmp
SHLVL=1
HOME=/home/vdr
VDR_CHARSET_OVERRIDE=ISO-8859-9
_=/bin/sh
TERM=xterm
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
LANG=de_DE.UTF-8
PWD=/
LC_ALL=de_DE.UTF-8
VDR_CONFIG_BASE_DIR=/dev/shm/.vdr/vdr

Der VDR wird innerhalb des init V Startscriptes so gestartet

/bin/sh -c "\
		exec 1>/var/log/vdr/vdr.InitStdOut
		exec 2>/var/log/vdr/vdr.InitStdErr
		#dumpkeys < /dev/tty1 | loadkeys
		echo "----------"
		printenv
		echo "----------"
		while /bin/true; do
			echo \"started: \$(date)\"
			echo \"started: \$(date)\" >&2
			corename=\$(date \"+%s\")
			echo "/tmp/%e-\$corename.core" > /proc/sys/kernel/core_pattern
			$VDR_LOG_FUNCTION \"INIT: Starte VDR -> $DAEMON $VDR_CMDLINE\"
			$DAEMON $VDR_CMDLINE
			EXITCODE=\$?
<...................>
	" &

Dabei läuft er auf tty10 (was ja auch keine vollwertige Konsole ist).

cu

Auf tty6 gehts auch nicht.

Hat überhaupt irgendjemand Umlaute mit der Tasatureingabe? Evtl. ist es ja ein VDR Bug?

cu

Danke für die Bestätigung.

Ich habe jetzt mal geschaut, scheint so das sie im VDR ankommen, aber nicht korrekt verarbeitet werden

in "menuitems.c"

eOSState cMenuEditStrItem::ProcessKey(eKeys Key)
{
  esyslog("KEY: %i", Key);
  bool SameKey = NORMALKEY(Key) == lastKey;
  if (Key != kNone)
     lastKey = NORMALKEY(Key);
  else if (!newchar && k0 <= lastKey && lastKey <= k9 && autoAdvanceTimeout.TimedOut()) {

Ergibt für "a"

Jan 16 13:01:14 localhost vdr: [9589] KEY: 6357047

und für "ä"

Jan 16 13:01:51 localhost vdr: [9589] KEY: 12779575
Jan 16 13:01:51 localhost vdr: [9589] KEY: 10747959

Ich blicke da nicht wirklich durch, aber ich habe das Gefühl das kann so auch garnicht funktionieren.

Wobei ich ganricht glauben kann das ich der erste bin dem das auffällt.

cu

In remote.c "uint64_t cKbdRemote::ReadKeySequence(void)" kommen die Tasten von der Konsole rein.

"a" ergibt "0x61", was ja völlig korrekt ist.

bei "ä" kommt 0xC3 und danach 0xA4 rein, und das wird hier als 2 Byte Sequenz nicht ausgewertet (Es werden nur Sequenzen Ausgewertet die mit 0x1B starten). Hat jemand ne Ahnung wie die Zeichen die von sdtin kommen kodiert sind?

Edit:
0xC3 = 11000011
0xA4 = 10100100
Also ne 2 Byte Unicode Sequenz die 000011100100 (0xE4) Ergibt. D.h. 0xE4 = "ä"

Hier kommen also ganz einfach die Unicode Sequenzen rein. D.h. die Funktion muss einfach nur die Unicode Sequenzen decodieren wenn der VDR auf urf-8 läuft.

Edit: Ersetze ich am Ende der Funktion "a" durch "ä" bekomme ich das "ä" im Edit Feld.

if (k == 0x61) k=0xE4;
	return k;

Ist also schon der richtige Ansatz. Nun ist die Frage ob der VDR hier nen Bug in der Auswertung hat oder ob da bei mir im System ne Übersetzung fehlt?

Wobei ich irgendwie den Eindruck habe hier wird Unicode überhaupt nicht berücksichtigt.
Edit: Jup, auf de_DE@euro gehts.

cu

Zitat von kls

Mit UTF-8 stehe ich persönlich auf Kriegsfuß und benutze es nicht. Wie man sieht, macht es immer wieder Probleme

Ich vermute mal, daß irgendwo ein Aufruf an Utf8ToArray() helfen könnte.
Aber wo und wie genau müsste wohl jemand probieren, der UTF-8 benutzt.

Ich kann mich gerne mal an nem Patch versuchen und das dann ausprobieren.

Mir ist nur nicht so ganz klar was als Rückgabewert von "cKbdRemote::ReadKeySequence" möglich ist (ich verstehe das Dinhinter nicht wirklich). Aktuelll wird da nix > 255 Zurückgegeben (obwohl theoretisch uint64_t). Wäre es sicher dort höhere Werte zurückzugeben auch wenn sie später (siehe nächsten Absatz) wieder übergangen werden. Oder werden die höheren Bits für was anderes genutzt?

Edit: Ah, Scheint OK zu sein hier die vollen Unicodezeichen zurückzugeben, Für die Escape Sequenzen gibts ja auch höhere Werte.

Und dahinter kommen dann nocht Dinge wie z.B in menuitems.c die höhere Unicodezeichen eh zerstören.
--
if (c <= 0xFF) { // FIXME what about other UTF-8 characters?
--

das muss man dann wohl mal Schrittweise angehen.

Ich würde erstmal alle Unicodezeichen >255 ignorieren. Dann gibts http://www.unicodemap.org/range/1/Basic_Latin/ und http://www.unicodemap.org/range/2/Latin-1_Supplement/, das sollte ja erstmal reichen.
Nur Sprachen wie z.B. Russisch fallen dann raus, aber die sollten ja jetzt auch nicht funktionieren (Zumindest die Tastatureingabe nicht wenn der vdr auf utf-8 läuft).

cu

Zitat von kls

Du solltest also innerhalb von cKbdRemote::ReadKeySequence() ermitteln, ob es sich um ein UTF-8-Zeichen handelt und dieses dann mit Utf8ToArray() in ein 1-Byte Zeichen umwandeln. Sollte der resultierende Wert größer als 0xFF sein, ist das Zeichen nicht verwertbar.

Das ist aber nicht wirklich Unicode Und damit West-Europa only.

Ich habe mich da jetzt mal etwas eingelesen. Ich bastele da mal was längerfristiges (Utf8ToArray muss ja eh irgendwann wegfallen, auf nen Unicode System besteht ja eigentlich gar kein Grund mehr irgendwas umzumappen) und dann kannst du ja mal schauen ob das so für dich OK ist.

So wie ich das sehe spielt sich je eh alles in "cKbdRemote::Action(void)" ab. Und solange MapCodeToFunc hier funktioniert können auch vollwertige Unicodezeichen (>255) zurückgegeben werden. Ich schaue mir das mal genauer an. Kann aber etwas dauern (ist ja viel Testen dabei).

Zitat von kls

Dabei fällt mir auf, daß diese ganze Sequenz falsch eingerückt ist...

Dabei fällt mir ein das ich schon immer mal wissen wollte was für einen Code Beautifier du nutzt? Uncrustify mit klaus.cfg schient es nicht ganz zu sein.

cu

Zitat von kls

Also meine Systeme laufen alle mit ISO-8859-1, und das bleibt auch so!
Jegliche Änderung an VDR, die das verhindern würde, hat schon mal überhaupt keine Chance, übernommen zu werden

Ich hätte das "irgendwann" fett schreiben sollen Wobei das schon so gemeint war das beides gehen sollte.

Das geht hier aber auch erstmal nur bis zum Edit Feld in menuitems.c. Dann ist erstmal gut Aber ich finde schon wichtig das das bis dahin sauber gelöst ist.

Wobei das erst am Wochenende was wird (bis dahin ist dann hier erstmal Pause im Thread, nicht das du dich wunderst das dann doch nicht gleich was kommt), heute hatte ich erstmal gebraucht um das alles zu verstehen und den Weg zu planen. Aber so wild wird das dann doch nicht.

Zitat von kls

Ich verwende gar keinen "Code Beautifier". Ich schreibe den Code von Hand, so wie er gehört

Ah, dann war das nur nen Gerücht

cu

Ich hänge mal den Diff gegen den 1.6er (die relevanten Teile haben keine grossen Änderungen, reicht um zu sehen was ich ändere) mit meiner momentanen Bastelei an. Ist noch nicht wirklich schön und ich stehe mit C auch einwenig auf dem Kriegsfuß. Aber der sollte zeigen wo ich hin will.
Ich habe da länger hin und her überlegt, und ich denke das muss so in den VDR damit die Tastatur/UTF8 richtig geht.

Im Prinzip hätte ich gerne erstmal ein OK ob die Richtung prinzipiell OK ist bevor ich da weitermache (Schön machen und Diff gegen den 1.7.23er). Die Idee ist:

- der eKeys enum hat ja nur 4 Byte, so ist es schwer ist da alles vernünftig reinzubekommen, deswegen gibts da jetzt zwei Flags kKbd_control und kKbd_unicode.
Bei kKbd_control steht in den oberen 2 Byte das Steuerzeichen laut eKbdControl, dabei werden auch Tasten wie ESC und Enter zu den Steuerzeichen gemappt (vereinfacht hinterher die Verarbeitung).
Bei kKbd_unicode steht dort das Unicode Zeichen (max. 0xFFFF), ansonsten das 8-Bit Zeichen.
Und eKbdControl ist in keys.h weil die Definition ja eher zu den eKeys gehört und evtl. auch mal Plugins die Tastatur abfragen wollen.

- Ferner hat es mich immer schon gestört das man in der remote.conf nen Dummyeintrag haben musste wenn man die Tastatur nicht als Fernbedienung nutzen will. Deswegen neben dem no-kbd Kommandozeilenparameter noch no-kbd-remote und no-kbd-input um die beiden Funktionen einzeln zu deaktivieren.

- Bei den Editfeldern in menuitems.c gehen auch die Tastaturtasten Links, Rechts, Enter, Esc so das man das Feld Editieren kann ohne die Fernbedienung zur Hand zu nehmen.

- Und cCharSetConv hat ein IsUTF8, weil so ziemlich jedes Plugin bastelt sich was eigenes Zusammen um zu testen ob der VDR gerade auf UTF-8 läuft.

Wie gesagt, ist nicht schön, aber macht alles was getan werden muss. Muss nur noch innerhalb der Funktionen aufgeräumt werden.

cu

Zitat von kls

Plugins sollten die Tastatur eigentlich genau nicht abfragen!
Ein Plugin sollte keine Annahmen darüber machen, wo die Eingaben herkommen.

Nunja, im Prinzip tun sie es ja auch nicht (sie erhalten einen eKeys Key der entweder ein VDR Fernbedienungskommando oder eine Tastaturtaste (egal wo die herkommt) enthält). Die Remote Objekte (es gibt ja nicht nur die drei im VDR, es gibt auch viele als Plugins) haben ja im Prinzip zwei Möglichkeiten. Sie können eine Eingabe als VDR Fernbedienungskommando UND/ODER als Tastatureingabe Broadcasten (als eKeys Key ins System bringen).

Die Plugins erhalten beide, d.h. sie bekommen jetzt auch schon die Tastatureingaben (nur halt bissher etwas undefiniert). Und was ist wenn der Author des z.B. music Plugins denkt >>wäre schön wenn mein Plugin auch die Multimediatasten (Next/Previus Track usw.) Reagiert<<. Oder der Author das Mailbox Plugins hat langeweile und baut ne Funktion zum schreiben von Mails ein?
Das war so die Idee dahinter, wenn die Plugins schon die Tastatureingaben bekommen sollten sie sie auch ganz natürlich auswerten können.

Ist jetzt nicht wirklich wichtig, war nur so die Idee das es dort evtl. besser aufgehoben wäre.

Zitat von kls

Läßt sich das nicht anders regeln? Mir gefällt das nicht, da noch zwei weitere Optionen einzuführen.

Was hälst du von einem optionalen Argument ("input" "remote") hinter no-kbd? Wenn gegeben dann schaltet no-kbd nur diesen Teil ab.

Zitat von kls

Verstehe ich ehrlich gesagt nicht ganz. Wieso muß man da "die Fernbedienung zur Hand nehmen"?

Naja, ich wähle z.B. im Aufzeichnungsmenu das Feld um den Namen einer Aufzeichnung zu ändern, gehe zur Tastatur (liegt neben dem VDR) und will am Ende des Namens was ändern, also brauche ich wieder die Fernbedienung (vergesse ich natürlich immer gehe also zurück zum Sofa) um den Cursor mit "rechts" (der Fenbedienung) zur passenden Position zu bringen. Die Cursortaste "rechts" auf der Tastaur wird ja bissher nicht ausgewertet.
Und die entsprechenden Tastaturtasten da mit zu unterstützen schadet ja auch nicht. Und einige (insert, delete usw.) wurden ja schon unterstützt, ist also nur konsequent da gleich alle relevanten (Enter und ESC finde ich da dann auch sehr praktisch) zu unterstützen. Das macht die Bedienung insgesammt etwas natürlicher (das es so funktioniert erwartet der unbedarfte Nutzer).

Zitat von kls

Ich verstehe zwar nicht, warum sich da jedes Plugin "was eigenes zusammenbastelt", denn die Standardvorgehensweise ist doch, cCharSetConv::SystemCharacterTable() abzufragen.

Mir ist nur aufgefallen das z.B. das epgsearch Plugin das was wesendlich komplezierteres macht (das war mir auch zu komplex, deswegen hatte ich dann bei svdrp.c geklaut weil ich mich erinnerte das es das auch anzeigt, nur so bin ich überhaupt drauf gekommen uft8 auf diese Weise abzufragen). Deswegen die Idee da IsUFT8() als einfache logische Abfragemöglickeit (da weiss dann gleich jeder das das die offizielle uft8 Abfragemöglichkeit ist) reinzubringen.

Zitat von kls

Braucht's das wirklich?

Nicht unbedingt, das war eher als Verbesserungsvorschlag zu sehen. Das alles waren halt Dinge die mir so als verbesserungswürdig (so aus meiner Sicht als Anwender der API und auch als Anwender des VDR) aufgefallen sind. Deswegen auch als Frage was du davon hälst.

cu