Stress mit USB-Touchscreen am Raspberry 3+

[Frank E. (Firma: Q3) (qualidat)]

Es handelt sich um einen Hanns-G HT225HPB, 21.5" Monitor.

Ich erstelle eine Xojo-App für einen Info-Monitor (Kiosk-System), die 
mit einem Touchscreen bedient werden soll. Der Touch-Teil des Monitors 
ist per USB mit dem Rechner verbunden, der Bild-Teil per HDMI. 
Betriebssystem ist das aktuelle Raspbian Stretch auf einem 3+. 
Normalerweise esetzt der Touch ja schlicht und einfach die Maus, ein Tip 
auf die richtige Stelle und ein Button feuert den "Action"- oder eine 
Listbox den "Change"-Event ... und gut ist.

Leider scheint das unter Linux nicht so zu stimmen. Wenn ich z.B. den 
Finger rel. "zaghaft" auf einen Button setze, bekommt der zwar den Focus 
oder wechselt sogar optisch in den Zustand "gedrückt", aber sonst 
passiert nix. Verfahre ich so mit einer Listbox, wird die betreffende 
Zeile zwar ge-highlighted, aber der Change-Event nicht ausgelöst und der 
Listindex ändert sich auch nicht.

Bei den Buttons habe ich mir damit geholfen, dass alle möglichen Events 
(Action, GotFocus, MouseEnter, MouseDown, MouseUp) die gleiche Funktion 
auslösen, natürlich durch eine Logik verknüpft, um Mehrfachauslösungen 
zu vermeiden. So werden immerhin (geschätze) 95% aller Fingertips 
erkannt ...

Mit Maus-Bedienung funktioniert die Anwendung übrigens absolut genau so, 
wie sie soll, jeder Klick wird erkannt.


Bei der Listbox ist das ungleich schwieriger, hier habe ich nur Chage 
und CellKlick zusammenfassen können, was die "Ausbeute" auf max. 50% 
bringt.

Mir scheint, dass die Ursache eine Art "Drucksensitivität" des Touch 
ist, obwohl Nichts dergleichen in dessen technischer Beschreibung steht, 
während es bei der Maus nur Klick oder nicht Klick gibt.

Kann man das Touch-Verhalten auf System-Ebene irgendwie "eindeutiger" 
machen?

Eigentlich ist das aber alles Sch**ße - kann man das Problem nicht an 
der Wurzel packen? Wiso gibt es überhaup solche halbgaren Reaktionen? 
Danke für Tips.

[Andreas K. (andreas_k209)]

gibt es sowas wie onTouch das Du noch abfangen musst? Touchscreens mit 
"drucksensitivität" sind mir noch nicht untergekommen.

Drucksensitivität kenne ich nur von Grafiktabletts.

Wenn das HTML/Javascript ist, gibt es bei TouchEvent u.U, mehrere 
erkannte Finger die man auswerten kann aber man kann auch nur auf den 
ersten reagieren.

[Rufus Τ. F. (rufus)]

Frank E. schrieb:
> kann man das Problem nicht an der Wurzel packen?

Das Problem scheint zu sein, daß Du den Unterschied zwischen Touch und 
Maus nicht zu verstehen scheinst. Bei einer Maus ist Klicken und 
Zeigerbewegen klar voneinander zu unterscheiden - kein Wunder, macht ja 
auch unterschiedliche Hardware.

Bei Touch ist das anders, wenn damit ein Mauszeiger bewegt werden soll, 
muss das vom Klicken oder gar dem Bewegen mit gedrückter Maustaste 
unterschieden werden.

Deswegen erzeugt der Touchtreiber jede Menge unterschiedlicher Events, 
die Deine Anwendung auseinanderhalten muss.

[Thomas (Gast)]

Frank E. schrieb:
> Eigentlich ist das aber alles Sch**ße - kann man das Problem nicht an
> der Wurzel packen? Wiso gibt es überhaup solche halbgaren Reaktionen?

Nun bisher bin ich davon ausgegangen dass du nur Probleme mit 
Netzwerktechnik hast. Aber das Problem scheint allgemeiner.

Lösung: Sag deinem Kunden, er soll ein Teil nehmen was auch unter Linux 
funktioniert.
ups Du hast es selbst rausgesucht?
Dann würde ich auf der HP schauen ob die Touchdriver für Linux anbieten.
ups Die haben nichts?
Dann würde ich mal googlen ob es andere Leute gibt die vielleicht eine 
Lösung gefunden haben.
ups Dein Google geht auch nicht?

Ich nach das mal für dich....
raspberrypi.stackexchange.com/questions/60383/

Thomas

[Daniel A. (daniel-a)]

Ich mache jetzt mal vorerst die wilde Annahme, dass deine Anwendung 
nicht das Problem ist.

Ich habe viele Geräte mit Linux und Touchscreen, aber so ein Problem 
hatte ich noch nie. Schau erstmal nach, ob die richtigen Events 
überhaupt generiert werden. Allgemein geht das mit evtest. Um zu sehen, 
was der X Server liefert, falls man den verwendet, kann man noch X Input 
verwenden. Hier mal ein paar ausgaben eines meiner Touchscreens zum 
vergleich.

Hier mit XInput, ein 4 mal drauf gedrückt, 2mal dabei noch die Position 
geändert, plus noch die Abfrage interessanter Einstellungen:

daniel@colibri:~$ grep "input driver" /var/log/Xorg.0.log
[     8.060] (II) Using input driver 'libinput' for 'Video Bus'
[     8.103] (II) Using input driver 'libinput' for 'Surface Pro 3/4 Buttons'
[     8.136] (II) No input driver specified, ignoring this device.
[     8.137] (II) No input driver specified, ignoring this device.
[     8.137] (II) No input driver specified, ignoring this device.
[     8.137] (II) No input driver specified, ignoring this device.
[     8.137] (II) No input driver specified, ignoring this device.
[     8.138] (II) No input driver specified, ignoring this device.
[     8.138] (II) Using input driver 'libinput' for 'Microsoft LifeCam Front: Micros'
[     8.200] (II) Using input driver 'libinput' for 'Microsoft LifeCam Rear: Microso'
[     8.244] (II) No input driver specified, ignoring this device.
[     8.245] (II) No input driver specified, ignoring this device.
[     8.245] (II) Using input driver 'libinput' for 'NTRG0001:01 1B96:1B05 Pen'
[     8.327] (II) No input driver specified, ignoring this device.
[     8.327] (II) Using input driver 'libinput' for 'NTRG0001:01 1B96:1B05'
[     8.356] (II) No input driver specified, ignoring this device.
[  7289.305] (II) No input driver specified, ignoring this device.
[  7289.343] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Consumer Control'
[  7289.356] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Consumer Control'
[  7289.358] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Keyboard'
[  7289.376] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Touchpad'
[ 18558.484] (II) No input driver specified, ignoring this device.
[ 18558.515] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Keyboard'
[ 18558.533] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Consumer Control'
[ 18558.557] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Consumer Control'
[ 18558.559] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Touchpad'
[ 21116.061] (II) No input driver specified, ignoring this device.
[ 21116.088] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Keyboard'
[ 21116.118] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Consumer Control'
[ 21116.134] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Consumer Control'
[ 21116.135] (II) Using input driver 'libinput' for 'Microsoft Surface Type Cover Touchpad'
daniel@colibri:~$ xinput
⎡ Virtual core pointer                      id=2  [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4  [slave  pointer  (2)]
⎜   ↳ NTRG0001:01 1B96:1B05                     id=11  [slave  pointer  (2)]
⎜   ↳ Microsoft Surface Type Cover Consumer Control  id=13  [slave  pointer  (2)]
⎜   ↳ Microsoft Surface Type Cover Touchpad     id=15  [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3  [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5  [slave  keyboard (3)]
    ↳ Video Bus                                 id=6  [slave  keyboard (3)]
    ↳ Surface Pro 3/4 Buttons                   id=7  [slave  keyboard (3)]
    ↳ Microsoft LifeCam Front: Micros           id=8  [slave  keyboard (3)]
    ↳ Microsoft LifeCam Rear: Microso           id=9  [slave  keyboard (3)]
    ↳ NTRG0001:01 1B96:1B05 Pen                 id=10  [slave  keyboard (3)]
    ↳ Microsoft Surface Type Cover Keyboard     id=12  [slave  keyboard (3)]
    ↳ Microsoft Surface Type Cover Consumer Control  id=14  [slave  keyboard (3)]
daniel@colibri:~$ xinput list --long 11
NTRG0001:01 1B96:1B05                     id=11  [slave  pointer  (2)]
  Reporting 6 classes:
    Class originated from: 11. Type: XIButtonClass
    Buttons supported: 7
    Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right"
    Button state:
    Class originated from: 11. Type: XIValuatorClass
    Detail for Valuator 0:
      Label: Abs MT Position X
      Range: 0.000000 - 65535.000000
      Resolution: 0 units/m
      Mode: absolute
      Current value: 44204.000000
    Class originated from: 11. Type: XIValuatorClass
    Detail for Valuator 1:
      Label: Abs MT Position Y
      Range: 0.000000 - 65535.000000
      Resolution: 0 units/m
      Mode: absolute
      Current value: 49817.000000
    Class originated from: 11. Type: XIValuatorClass
    Detail for Valuator 2:
      Label: Rel Horiz Scroll
      Range: -1.000000 - -1.000000
      Resolution: 0 units/m
      Mode: relative
    Class originated from: 11. Type: XIValuatorClass
    Detail for Valuator 3:
      Label: Rel Vert Scroll
      Range: -1.000000 - -1.000000
      Resolution: 0 units/m
      Mode: relative
    Class originated from: 11. Type: XITouchClass
    Touch mode: direct
    Max number of touches: 15

daniel@colibri:~$ xinput --list-props 11
Device 'NTRG0001:01 1B96:1B05':
  Device Enabled (141):  1
  Coordinate Transformation Matrix (143):  1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
  libinput Calibration Matrix (280):  1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
  libinput Calibration Matrix Default (281):  1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
  libinput Send Events Modes Available (263):  1, 0
  libinput Send Events Mode Enabled (264):  0, 0
  libinput Send Events Mode Enabled Default (265):  0, 0
  Device Node (266):  "/dev/input/event3"
  Device Product ID (267):  7062, 6917

daniel@colibri:~$ xinput --test 11
motion a[0]=41603 a[1]=40380 
button press   1 a[0]=41603 a[1]=40380 
motion a[0]=41603 a[1]=40380 
button release 1 a[0]=41603 a[1]=40380 
motion a[0]=39733 a[1]=48980 
button press   1 a[0]=39733 a[1]=48980 
motion a[0]=39808 a[1]=49053 
motion a[0]=40033 a[1]=49335 
motion a[0]=40368 a[1]=49754 
motion a[0]=40791 a[1]=50427 
motion a[0]=40791 a[1]=50427 
button release 1 a[0]=40791 a[1]=50427 
motion a[0]=32163 a[1]=54604 
button press   1 a[0]=32163 a[1]=54604 
motion a[0]=32170 a[1]=54586 
motion a[0]=32177 a[1]=54550 
motion a[0]=32190 a[1]=54504 
motion a[0]=32211 a[1]=54441 
motion a[0]=32238 a[1]=54350 
motion a[0]=32293 a[1]=54222 
motion a[0]=32347 a[1]=54058 
motion a[0]=32436 a[1]=53822 
motion a[0]=32497 a[1]=53649 
motion a[0]=32497 a[1]=53649 
button release 1 a[0]=32497 a[1]=53649 
motion a[0]=41084 a[1]=52666 
button press   1 a[0]=41084 a[1]=52666 
motion a[0]=41084 a[1]=52666 
button release 1 a[0]=41084 a[1]=52666

evtest Beispiel ist im Anhang.

Neben den Angaben von oben aber bei dir wären die Ausgabe von "cat 
/proc/bus/input/devices" und dmesg auch noch nützlich. Damit könnte man 
sehen, ob das Problem beim Touchscreen/Treiber und dessen ausgegebenen 
Daten, oder woanders liegt. In letzterem Fall könnte der verwendete X11 
input Treiber oder eine Einstellung davon problematisch sein, oder auch 
der verwendete Window Manager (oder gar das fehlen davon).

Sobald man weiss, wo das Problem liegt, kann man es lösen.

[Frank E. (Firma: Q3) (qualidat)]

Rufus Τ. F. schrieb:
> Frank E. schrieb:
>> kann man das Problem nicht an der Wurzel packen?
>
> Das Problem scheint zu sein, daß Du den Unterschied zwischen Touch und
> Maus nicht zu verstehen scheinst. Bei einer Maus ist Klicken und

Was soll der Unfug?

> Zeigerbewegen klar voneinander zu unterscheiden - kein Wunder, macht ja
> auch unterschiedliche Hardware.

Ist ein entschlossener Tip per Touchscreen auf einen Button etwa kein 
Klick?

Außerdem schrieb ich ja, dass ich das Button-Problem mit der 
Zusammenfassung der unterschiedlichsten Events fast perfekt erledigt 
habe. Bei der erreichten Erfolgsrate wird ein Benutzer bei einer der 
rel. seltenen Nicht-Reaktionen eher an einen eigenen Fehler glauben und 
einfach nochmal tippen.

Problematisch ist eher die Listbox. Dieses GUI-Element kann eigentlich 
gar keinen Unterschied zwischen dem wechselnden Highlighting einer 
Zeile, dem entsperechenen Change-Event und dem zugehörigen Property 
"Listindex" machen, schaft es aber - unter Linux - trotzdem.

Am Mac habe ich noch keinen Touchmonitor ausprobiert, aber unter Windows 
schon, und dort gibt es das Problem definitiv nicht. Muss ich also von 
einem Bug in Xojo ausgehen?

[Frank E. (Firma: Q3) (qualidat)]

Daniel A. schrieb:
> Ich mache jetzt mal vorerst die wilde Annahme, dass deine
> Anwendung
> nicht das Problem ist.
>
> Ich habe viele Geräte mit Linux und Touchscreen, aber so ein Problem
> hatte ich noch nie. Schau erstmal nach, ob die richtigen Events
> überhaupt generiert werden. Allgemein geht das mit evtest. Um zu sehen,
> was der X Server liefert, falls man den verwendet, kann man noch X Input
> verwenden. Hier mal ein paar ausgaben eines meiner Touchscreens zum
> vergleich.
>
> ...

Oh, sehr komplexe Angelegenheit. So tief wollte ich als 
Anwendungsentwickler eigentlich nicht einsteigen. Ich nahm bisher an - 
und unter Windows ist das auch so - dass ein nicht über spezielle 
Treiber eingebundener Touch als HID einfach eine Maus emuliert ... was 
er ja meistens auch tut, nur eben nicht zuverlässig. Meine Anwendung ist 
kein Multipoint- Projekt ...

[Daniel A. (daniel-a)]

Beim xinput --test ist das wichtige einfach, dass das "button press 1" 
und "button release 1" beim draufdrücken kommt. Wenn das da ist, ist des 
Problem vermutlich der X window manager. Angenommen, es wird X11 
verwendet, und nicht wayland oder Framebufferanwendungen oder so.

[Henning Block (Gast)]

Es kommt vermutlich zu spät, aber das Problem lag mit ziemlicher 
Sicherheit an der Firmware des Bildschirms. Ich habe exakt das 
beschriebene Phänomen mit dem Bildschirm und einem Raspberry Pi 4 sowohl 
unter Raspbian als auch unter Android 11 (OmniROM) erlebt, während es 
aber an einem Windows-PC tadesllos reagiert hat. Habe dann von der 
Hersteller-Seite ein Tool runtergeladen (google nach TC_PTool_2008, ist 
dann eine WIN8.rar) und danach reagierte das Display auch unter Raspbian 
und Android wie erwartet.

[Frank E. (Firma: Q3) (qualidat)]

Danke für die (wenn auch späte) Rückmeldung.

Es gibt ja hier so Experten, die immer nur die Hälfte lesen und dann 
überheblich und allwissend tun - um so wohltuender ist mal eine Antwort, 
die mein Problem versteht und wenigstens teilweise nachvollziehen kann.

Allerdings ist da sicher nicht nur in der Firmware des Bildschirmes ein 
Bug, sondern auch irgendwie im Linux-Unterbau oder meiner Xojo-IDE 
ebenfalls. Denn wenn ein GUI-Element sich zwar beim Anklicken/tippen 
einfärbt und dann aber nicht auch der zugehörige Event-Handler ausgelöst 
wird, ist sicher nicht nur der Bildschirm, daran schuld ... es ei denn, 
es gibt (systemintern) abartig exotischen Varinten von Events, mit denen 
aber sonst nienand rechnet ...

Wie ich weiter oben schrieb, ich "missbrauche" den Mouse-Enter-Event 
(Betreten des GUI-Elements), der sehr zuverlässig kommt. Beim Eintreffen 
dieses Events befördere ich die Maus per System-Call sofort wieder in 
die linke untere Ecke, so dass jeder neue Tip auf ein GUI-Element mit 
Sicherheit auch ein Mouse-Enter auslöst ... damit kann ich leben.