Ungenauer Touchscreen des TXT

[MasterOfGizmo]

Der Wunsch, eine Maus am TXT betreiben zu wollen ist m.E. vor allem dem recht ungenauen Touchscreen des TXT geschuldet.

Ich selbst habe praktisch die nie Originalfirmware verwendet (außer sie zu hacken ), aber ich hatte immer den leichten Verdacht, dass die Ungenauigkeit in der Originalfirmware etwas weniger nervig ist als in der CFW. Das kann aber gut daran liegen, dass der Touchscreen in der CFW deutlich intensiver und mit mehr und kleineren Bedienelementen benutzt wird. Die Treibereinstellungen in der Kernel-Config sind jedenfalls die gleichen. Das heisst aber nicht unbedingt etwas, da sich die genaue Bedeutung der Einstellungen geändert haben kann.

Gibt es hier Beobachtungen zu?

Unter der CFW kann man das mit dem Icon-Editor aus meinem Repository gut sichtbar machen. Einfach mal auf einen Punkt des Displays mit einem Stift wiederholt tippen. Dann tauchen nicht nur genau dort Punkte auf, sondern auch ca. jedes 10-20te Tippen ca. 2cm links und seltener auch rechts des angeklickten Punkts. Die Tatsache, dass das nur horizontal passiert ist irriierend.

Ich habe nichts desto trotz mal am Touchscreen-Treiber in der CFW gespielt. Vor allem der Parameter "charge-delay" wie unter https://www.kernel.org/doc/Documentatio ... sc-adc.txt beschrieben klingt mir gut. Das Problem tritt genau bei eben den Pen-Up-Events, also beim Loslassen auf.

Man kann diesen Wert einfach in der dts-Datei ändern wie auf der verlinkten Seite ganz unten beschrieben. Ich habe mal Werte bis 0x1800 probiert und der Kernel übernimmt diesen Wert von dort auch, was man daran sieht, dass beim Booten die Warnung, dass kein Wert für charge-delay gesetzt ist, verschwindet. Allerdings kann ich m.E. keine Verbesserung wahrnehmen.

Vielleicht hat ja noch jemand anderes Lust, sich des Themas anzunehmen.

Und wer an seinem Touchscreen total verzweifelt: Am tx-pi tritt das Problem praktisch nicht auf

[MasterOfGizmo]

Sieht so aus, als könne man mit diesem Parameter wirklich einiges fixen und ein charge-delay von 0x8000 macht einen Unterschied. Ich bin mit dem Touchscreen an meinem TXT gerade halbwegs zufrieden ... jetzt muss ich noch rausbekommen, wo der Nachteil meiner Änderungen liegt.

[MasterOfGizmo]

Wer's mal selbst testen mag: Am besten erst mit dem IconEditor etwas rumspielen und vor allem einzelne Pixel antippen. Dann die vorhandene Datei in der ersten Boot-Partition auf der CFW durch folgende ersetzen:

http://www.harbaum.org/am335x-kno_txt.dtb

Und dann nochmal testen. Es sollte eine deutliche Verbesserung bringen.

Vor allem würde mich interessieren, ob es einen Nachteil gibt. Ich habe noch keinen erkannt.

[richard.kunze]

Ich hatte auf zwei TXTs mit ti,charge-delay=0x8000 immer noch vereinzelt falsche Pen-Up-Events, erst mit ti,charge-delay=0x20000 (dezimal 131072) war Ruhe. Nachteile hab ich auch mit dem Wert nicht bemerkt, und nach den Informationen hier ist das auch unwahrscheinlich, weil der ADC wohl mit 3MHz Takt (oder sogar mehr) läuft, d.h. auch die Wartezeit von 131072 Taktzyklen sind gerade mal ca 45ms.

Ich hab den Wert jetzt so in die CFW übernommen.

[MasterOfGizmo]

Ausgezeichnet, ich werde nachher einmal schauen, ob ich mit diesen höheren Werten irgendwas negatives feststelle.

Und weil wir gerade dabei sind habe ich dem TX-Pi-Setup einen kleinen Wrapper für die Touchscreen-Kalibrierung spendiert. Das zugrundeliegende Tool (xinput-calibrator) passt mit seinen Text-Ausgaben zwar nicht so ganz auf den kleinen Bildschirm, aber zum Kalibrieren reicht's erstmal. Beim TXT ist sowas m.E. nicht nötig, die Bildschirme alles aus der gleichen Quelle stammen und sich ähnlich genug zu sein scheinen.

[PHabermehl]

Ausgezeichnet, ich werde nachher einmal schauen, ob ich mit diesen höheren Werten irgendwas negatives feststelle.

Und weil wir gerade dabei sind habe ich dem TX-Pi-Setup einen kleinen Wrapper für die Touchscreen-Kalibrierung spendiert. Das zugrundeliegende Tool (xinput-calibrator) passt mit seinen Text-Ausgaben zwar nicht so ganz auf den kleinen Bildschirm, aber zum Kalibrieren reicht's erstmal. Beim TXT ist sowas m.E. nicht nötig, die Bildschirme alles aus der gleichen Quelle stammen und sich ähnlich genug zu sein scheinen.

Das klingt super!

Schaue ich mir nachher mal an...

Gruß
Peter

[MasterOfGizmo]

Gibt's für die Originalfirmware irgendeine Art Malprogramm, mit dem man mal schauen könnte, wie genau der Touchscreen dort funktioniert? Nach dem was wir nun geändert haben halte ich es für eher unwahrscheinlich, dass dort das Problem nicht auftritt. Von daher haben die Kollegen von fischertechnik und/oder Knobloch ggf. Lust, das auch in die offizielle Firmware zu übernehmen.

[ski7777]

Es gibt zwar kein Malprogramm, aber ich habe schon oft genug Probleme mit dem Touch in der offiziellen FW gehabt.

Raphael

[PHabermehl]

Ich würde jederzeit unterschreiben, dass der Touchscreen des TXT (anscheinend auch auf Grund von Softwareproblemen) ein massives Ärgernis sein kann.
Sowohl Reaktivität als auch Kalibrierung können einem den Spaß am Gerät spürbar mindern.

Und wenn auch nur der Hauch einer Verbesserung durch Neuparametrierung möglich ist, dann sollte das getan werden.

Gruß
Peter

[MasterOfGizmo]

Bin mal gespannt, ob und wie solche Sachen ihren Weg in die offizielle Firmware finden. Aber ich denke eher nicht, dass sie da noch grosse Experimente wagen. Der TXT läuft ja halbwegs und die Zeit wäre sicher besser in einen Nachfolger investiert.

[PHabermehl]

[OT] Till, wie Du so schön in der aktuellen ft:pedia darlegst, wäre erstmal ein Sicherheitsupdate fällig. Und selbst daran glaube ich nicht, obwohl ich es für ein schwerwiegendes Problem halte... Den einen Parameter für den Touchscreen umzustellen, kostet wenige Minuten, die Verbreitung mit einem RoboPRO Update ist auch kein Ding. Sehen werden wir das wohl trotzdem nicht.[/OT]

[MasterOfGizmo]

Das Problem ist, dass man entweder ein Riesenladen wie Lego ist und tatsächlich die finanziellen und personellen Ressourcen für sowas hat. Oder man hat einen Zulieferer, der einem die Sachen mit einer großen Portion persönlicher Begeisterung quasi unter Selbstaufgabe baut. Beides hat ft m.E. nicht (mehr).

Sie könnten tatsächlich auf die Idee kommen, mit Ihrer Community zu kooperieren und damit finanzielle und personelle Lücken überbrücken. Aber dazu muss man sich ein Stück weit öffnen und das passt nicht zu der klassischen "machen wir einfach weiter wie bisher"-Denkweise eines alteingesessenen Mittelständlers.

Schauen wir mal. Vielleicht müssen die Schmerzen nur groß genug werden. Aber ich denke auch, dass es eher bleiben wird wie's ist. Solange sie daran nicht kaputt gehen ist ja alles harmlos.

[MasterOfGizmo]

[OT] Till, wie Du so schön in der aktuellen ft:pedia darlegst, wäre erstmal ein Sicherheitsupdate fällig.

Das blöde daran ist ja, dass das eh nur eines von diversen Problemen dieser Art ist. Das war ja nur stellvertretend, in der Hoffnung, dass das keinen Schaden anrichtet, weil sie ja frühzeitig vor Erscheinen des Artikels erfahren haben wie sie das Problem mit drei Zeilen Code aus der Welt schaffen.

Die anderen Probleme sind z.T. fundamentalerer Natur. Die können sie ohne tiefere Eingriffe kaum fixen. Ich hatte ursprünglich vor, auf der Süd-Süd-Convention mal live von der Veranstaltung aus in den TXT bei mir daheim einzubrechen und die Bilder der Kamera abzugreifen. Aber ich muss sagen, dass sie so träge auf sowas reagieren, dass ich Sorge hätte, dass am folgenden Tag das BSI bei denen klingelt und den TXT aus dem Verkehr zieht. Also lasse ich das lieber. Man muss es ja nicht forcieren.

[MasterOfGizmo]

Es gibt zwar kein Malprogramm, aber ich habe schon oft genug Probleme mit dem Touch in der offiziellen FW gehabt.

Doch, gibt es. Sie liefern ein Programm namens ts_test sogar mit. Einfach per ssh einloggen und ts_test starten. Ist auch bei der cfw dabei, kann man also direkt zum Vergleich nutzen.

Und nun kommt der Witz: Der Touchscreen funktioniert tatsächlich unter der Originalfirmware viel besser als unter der bisherigen CFW. Da stellt sich natürlich die Frage, wo das her kommt und ob unser Fix überhaupt der richtige ist.

... weil der ADC wohl mit 3MHz Takt (oder sogar mehr) läuft, d.h. auch die Wartezeit von 131072 Taktzyklen sind gerade mal ca 45ms.

Das wären 45ms pro ADC-Wandlung. Zur Zeit nutzen wir 16 ADC-Zyklen (7+7+2), was dann insgesamt 670ms wären. Damit hätten wir aber nur knappe 2Hz bei der Touchscreenabfrage, was m.E. definitiv nicht der Fall ist. Also ist mein aktueller Verdacht. dass die CFW einen anderen (falschen) ADC-Takt einstellt als die Originalfirmware.

[richard.kunze]

Und nun kommt der Witz: Der Touchscreen funktioniert tatsächlich unter der Originalfirmware viel besser als unter der bisherigen CFW. Da stellt sich natürlich die Frage, wo das her kommt und ob unser Fix überhaupt der richtige ist.

Interessant. Schau ich mir mal an. Eigentlich kann das ja dann nur entweder an Änderungen am Treiber im Kernel oder an der TSlib liegen...

... weil der ADC wohl mit 3MHz Takt (oder sogar mehr) läuft, d.h. auch die Wartezeit von 131072 Taktzyklen sind gerade mal ca 45ms.

Das wären 45ms pro ADC-Wandlung.

So wie ich das verstanden habe, gibt es das charge-delay einmal pro Zyklus und nicht bei jedem Sample, d.h. wir hätten 45ms Delay und dann 16 ADC-Zyklen zu jeweils einer Handvoll Takten.

Also ist mein aktueller Verdacht. dass die CFW einen anderen (falschen) ADC-Takt einstellt als die Originalfirmware.

Könnte sein. Das müsste man dann aber eigentlich irgendwo im Treiber sehen.