X11, xlib, multi touch simulation

Meine Zeit der rohen Xlib-Programmierung ist schon sehr lange her, aber 
du kannst synthetische Events verschicken (XSendEvent oder so). Es gibt 
auch ein Programm (xdotool), das kann das auch. Schau dir mal den 
Quellcode an.

epi schrieb:
> ok. interessanter Hinweis.
>
> Weiss man welche Funktionen man der X11 library für's Touch's anwenden
> sollte?
>
> Ich nehme an alle TouchTreiber greifen schlussunendlich auf X11
> Funktionen zurück?

Inzwischen ist es eigentlich eher so, dass der generische 
"event-device"-Treiber von X11 auf die Linux-API für Input-Devices 
zugreift. Das gilt auch für Touchscreens/Tablets etc.

Und da kannst Du mit dem "uinput"-Treiber ein virtuelles Input-Device 
anlegen und mit Events befeuern. Das funktioniert gut.

Viele Grüße,
        Simon

Die Magie scheint die XInput2-Extension zu sein. Da wurden ein Haufen 
neue Events definiert (siehe /usr/include/X11/extensions/XInput2.h bzw. 
XI2.h). Auf https://github.com/esjeon/xinput2-touch gibt es ein 
Test-Programm, was die ausgibt. Auf ähnlichem Weg sollte man eigentlich 
auch synthetische Events einspeisen können. Aber zugegeben, gute 
Dokumentation sieht anders aus...

epi schrieb:
> Simon B. schrieb:
>> Und da kannst Du mit dem "uinput"-Treiber ein virtuelles Input-Device
>> anlegen und mit Events befeuern. Das funktioniert gut.
>
> Gibt es Beispiele wie man so ein virtuellen Treiber erstellt und
> integriert?

Das ist ein normales Userspace-Programm was auf /dev/uinput zugreift. 
Ein Tutorial ist z.B. hier: 
http://thiemonge.org/getting-started-with-uinput .

Ich habe das mal genutzt, um ein uraltes Wacom-Intuos1-Tablet mit 
serieller Schnittstelle nutzbar zu machen. Das war sehr cool, vor allem, 
weil das dramatisch besser zu handlen war als der (damals schon aus X11 
verschwundene) X11-Treiber, wenn man den Rechner suspendet und das 
Tablet abgestöpselt hat.

Ich sollte das mal for hysteric reasons auf github packen...

Grüße,
        Simon

Verstehe ich dass jetzt richtig, du willst einfach einen noch nicht von 
linux unterstützten I2C Touchscreen verwenden? Wäre es da nicht 
einfacher den Linux kernel neu zu kompilieren, und darin einen i2c hid 
treiber zu schreiben/anzupassen? Ausserdem kann man die Maus ja nicht 
nur in X verwenden.

epi schrieb:
> Wie gehe ich vor?:
> 1.) input.h / uinput.h File anpassen, evtl. anlegen wenn noch nicht
> vorhanden?
> 2.) öhm und jetzt brauchts noch ein c-File?, das muss noch kompiliert
> werden?
> 3.) Dieses C-File müsste ich per Python starten und dann die X und Y
> Variablen übergeben?
>
> nicht so einfach :-(

Verzeihung, ich bin davon ausgegangen, dass etwas Erfahrung mit 
C-Programmierung und/oder Linux-Systemprogrammierung da ist.

Ja, ohne das ist es nicht so einfach.

1.) input.h bzw. uinput.h sind vom System vorgegeben, die veränderst Du 
nicht. Die beschreiben die Kommunikationsschnittstelle zum Linux-Kernel.

2.) Ja, für diesen Lösuungsansatz musst du ein Programm schreiben, das 
kann zwar auch in Python passieren, ist in C aber vermutlich etwas 
einfacher (unklar, man muss halt in python hinkriegen, die richtigen 
Datenstrukturen zusammenzubasteln und mit write/ioctl() an den 
uInput-Treiber übermitteln).

3.) Nein, das Programm läuft dauerhaft im Hintergrund, sinnvollerweise 
würde das selber die i2c-Kommunikation mit dem Touchscreen übernehmen.

Aber ja: Da es sich hier um ein echtes Device handelt (und nicht eine 
"Simulation" von Events nach der du ursprünglich gefragt hattest) ist 
der Ansatz über einen "echten" Gerätetreiber im Linux-Kernel viel 
sinnvoller - wenn auch etwas anspruchsvoller. Das hat dann ein deutlich 
besseres Timing-Verhalten (die Latenz dürfte deutlich geringer werden) 
und ist direkt korrekt im System verankert: Man braucht keinen 
Hintergrundprozess der gemanaged werden muss.

Um was für ein Touchscreen-Modell handelt es sich?

Viele Grüße,
        Simon

epi schrieb:
> Simon B. schrieb:
>> 2.) Ja, für diesen Lösuungsansatz musst du ein Programm schreiben, das
>> kann zwar auch in Python passieren, ist in C aber vermutlich etwas
>> einfacher (unklar, man muss halt in python hinkriegen, die richtigen
>> Datenstrukturen zusammenzubasteln und mit write/ioctl() an den
>> uInput-Treiber übermitteln).
>
> ioctl() ist eine Funktion im uInput-Treiber, und dieser kann ich
> Koordinaten übergeben + Event-Typ + ID etc.? richtig?
> uinput müsste ich dann ins python includen? falls das überhaupt geht...
> ja muss wohl über die Bücher - aber vielleicht hast du mir 1-2 Tips
> mehr.

read(), write() und ioctl() sind die wichtigsten Funktionen ("Syscalls") 
die der Linux-Kernel anbietet um mit Gerätetreibern zu kommunizieren. 
ioctl() ist dabei das schwierigste, weil sich da das Verhalten von 
Treiber zu Treiber dramatisch unterscheiden kann.

Konkret wird bei dem uinput-Treiber ioctl() verwendet, um dem Treiber 
Namen und Achsen (inkl. Grenzen) für die Input-Geräte zu konfigurieren. 
Wenn man das gemacht hat, werden mittels write() Events an den 
uinput-Treiber geschickt, die dann von z.B. dem X-Server als Events von 
dem synthetischen Input-Gerät empfangen werden. Je nach Gerätetyp gibt 
es eine ganze Reihe von verschiedenen Events, die man nach einem 
bestimmten Schema erzeugen muss, damit das ganze korrekt funktioniert.

write() in Python ist unproblematisch, ioctl() ist lästig, da musst Du 
gucken ob Du ein schickes Beispiel findest.

Guck Dir erstmal an wie Linux-Input-Devices funktionieren, dann hast Du 
eine Vorstellung davon, was Du umgekehrt erzeugen musst um das Verhalten 
zu erzeugen was du haben möchtest.

Mindestanforderungen für einen Touchscreen: ABS_X, ABS_Y, BTN_TOUCH. Für 
Multitouch wirds dann etwas komplizierter.

Viele Grüße,
         Simon

Simon B. schrieb:
> Je nach Gerätetyp gibt es eine ganze Reihe von verschiedenen Events, die
> man nach einem bestimmten Schema erzeugen muss, damit das ganze korrekt
> funktioniert

was meinst du mit Gerätetyp? Theoretisch habe ich ja kein 
"Hardware-Touch"..

vielleicht doch einfacher als gedacht mit "evdev"?:

http://python-evdev.readthedocs.io/en/latest/index.html

epi schrieb:
> Simon B. schrieb:
>> Mindestanforderungen für einen Touchscreen: ABS_X, ABS_Y, BTN_TOUCH. Für
>> Multitouch wirds dann etwas komplizierter.
>
> phuuu, was meinst du, wieviel Zeit (falls vorhanden) würdest du
> benötigen um ein Python Programm zu schreiben das Multi-Touchs
> simuliert? (ist für komerzielle Zwecke gedacht)
>
> Die Touchs müssten vorallem von hml5/javascript Programmen erkannt
> werden z.B:
> http://scripty2.com/demos/touch/

Ich würde an dieser Stelle aufpassen: Das Input-Device zu "simulieren" 
ist die eine Sache. Ob der Browser (welcher?) dann aber die Touch-Events 
korrekt an das Javascript durchreicht, kann eine ganz andere Sache sein. 
Ich will hier keine Pferde scheu machen, aber da habe ich schon viele 
komische Dinge erlebt.

Du kannst mir gerne eine PN schicken, dann können wir uns da über eine 
eventuelle Beauftragung unterhalten.

Grüße,
        Simon

Epi K. schrieb:
> Simon B. schrieb:
>> Je nach Gerätetyp gibt es eine ganze Reihe von verschiedenen Events, die
>> man nach einem bestimmten Schema erzeugen muss, damit das ganze korrekt
>> funktioniert
>
> was meinst du mit Gerätetyp? Theoretisch habe ich ja kein
> "Hardware-Touch"..

Es macht aber einen Unterschied, ob Du einen Touchscreen (mit/ohne 
Multitouch), eine Maus oder einen 3D-Puck simulierst.

Eine Maus verwendet z.B. die Achsen REL_X und REL_Y, während 
Touchscreens ABS_X bzw. ABS_Y verwenden. Bei Multitouch-Geräten muss man 
verstehen, wie verschiedene Berührpunkte identifiziert werden (da gibt 
es sogar zwei verschiedene Strategien, wobei sich inzwischen eine 
weitgehend durchgesetzt hat). Und man muss sich über das Sync'en klar 
werden. Es macht z.B. bei einer Maus, ob die Event-Sequenz

REL_X = 1
REL_Y = 1
SYNC

oder

REL_X = 1
SYNC
REL_Y = 1
SYNC

schickt: ersteres ist eine Bewegung nach links unten, zweiteres sind 
zwei Bewegungen: erst links und dann nach unten.

Alles keine wirkliche Hexerei, aber man muss sich mal damit 
auseinandersetzen.

Um ein Gefühl dafür zu kriegen, kann man mal das "evtest"-Programm auf 
/dev/input/eventX loslassen. Das zeigt einem, welche Events da 
aufschlagen.

Viele Grüße,
       Simon

Simon B. schrieb:
> Eine Maus verwendet z.B. die Achsen REL_X und REL_Y, während
> Touchscreens ABS_X bzw. ABS_Y verwenden.

jup, und der obige Link über python evdev + 
https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt

scheint mir Hoffnung zu machen dass es nicht so ne Hexerei sein 
muss....nja ;-)

Epi K. schrieb:
> Simon B. schrieb:
>> Eine Maus verwendet z.B. die Achsen REL_X und REL_Y, während
>> Touchscreens ABS_X bzw. ABS_Y verwenden.
>
> jup, und der obige Link über python evdev +
> https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt
>
> scheint mir Hoffnung zu machen dass es nicht so ne Hexerei sein
> muss....nja ;-)

Genau  :)

Wenn Du Multitouch implementierst: Gehe direkt auf das "B"-Protokoll. 
Das "A"-Protokoll ist deprecated (weil man da jedes Mal den kompletten 
Zustand übermitteln muss und keine inkrementellen Zustandupdates machen 
kann).

Viele Grüße,
        Simon

Da das "evdev" vielversprechend und einfach tönt, wollte ich heute ein 
Anlauf versuchen.
Nur scheitere ich schon bei der Installation auf Raspian Jessie :-(

pi@raspberrypi:~ $ sudo apt-get install python-dev python-pip gcc
Reading package lists... Done
Building dependency tree
Reading state information... Done
gcc is already the newest version.
gcc set to manually installed.
python-pip is already the newest version.
The following extra packages will be installed:
  libpython-dev libpython2.7-dev python2.7-dev
The following NEW packages will be installed:
  libpython-dev libpython2.7-dev python-dev python2.7-dev
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 18.2 MB of archives.
After this operation, 25.7 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main 
libpython2.7-dev ar 
mhf 2.7.9-2
  404  Not Found [IP: 5.153.225.207 80]
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main 
python2.7-dev armhf 
2.7.9-2
  404  Not Found [IP: 5.153.225.207 80]
Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main 
python-dev armhf 
2.7.9-1 [1,188 B]
Get:2 http://mirrordirector.raspbian.org/raspbian/ jessie/main 
libpython-dev arm 
hf 2.7.9-1 [19.6 kB]
Fetched 20.8 kB in 0s (50.0 kB/s)
E: Failed to fetch 
http://mirrordirector.raspbian.org/raspbian/pool/main/p/pytho 
n2.7/libpython2.7-dev_2.7.9-2_armhf.deb  404  Not Found [IP: 
5.153.225.207 80]

E: Failed to fetch 
http://mirrordirector.raspbian.org/raspbian/pool/main/p/pytho 
n2.7/python2.7-dev_2.7.9-2_armhf.deb  404  Not Found [IP: 5.153.225.207 
80]

E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-mis 
sing?


Nachtrag: folgender Befehl funktioniert:
sudo pip3 install evdev


obs aber das richtige ist....

Epi K. schrieb:
> pi@raspberrypi:~ $ sudo apt-get install python-dev python-pip gcc
[...]
> Err http://mirrordirector.raspbian.org/raspbian/ jessie/main
> libpython2.7-dev armhf 2.7.9-2
>   404  Not Found [IP: 5.153.225.207 80]
[...]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?

Vermutlich sind die in deinem System gespeicherten Paketlisten nicht 
mehr aktuell. Probier wie vorgeschlagen "apt-get update".

Grüße,
        Simon

Simon B. schrieb:
> Probier wie vorgeschlagen "apt-get update".

jup, das war die Lösung x-)

jetzt stehe ich aber wieder beim nächsten Schritt an:

python setup.py build_ext \
> --evdev-headers buildroot/input.h:buildroot/input-event-codes.h \
> --include-dirs buildroot/ \
> install
python: can't open file 'setup.py': [Errno 2] No such file or directory
pi@raspberrypi:~ $



als can't open file... naja "Specifying header locations" für was ist 
das jetzt wieder gut...
Wenn ich diesen Schritt überspringe und ins python reingehe, und "import 
evdev" machte, kommt fehler.

ehm falsch, ich habe "sudo apt-get install linux-headers-$(uname -r)" 
vergessen.
Wobei ich dabei folgenden Fehler erhalte:


pi@raspberrypi:~ $ sudo apt-get install linux-headers-$(uname -r)
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-headers-4.4.11-v7
E: Couldn't find any package by regex 'linux-headers-4.4.11-v7'


tja

Vermutlich gab es einen neueren Kernel, und du hast noch einen der nicht 
mehr im Repo ist. Mache ein apt-get upgrade, starte neu und versuche es 
erneut. Mit "apt-cache search linux-headers" und "apt-cache search 
linux-image" kannst du dir die momentanen Kernels und deren Header 
anzeigen lassen.

nach "sudo apt-get upgrade" kommt immer noch der Fehler:
E: Unable to locate package linux-headers-4.4.11-v7
E: Couldn't find any package by regex 'linux-headers-4.4.11-v7'

What's the problem?? Hier noch:

apt-cache search linux-headers

linux-headers-3.10-3-all - All header files for Linux 3.10 
(meta-package)
linux-headers-3.10-3-all-armhf - All header files for Linux 3.10 
(meta-package)
linux-headers-3.10-3-common - Common header files for Linux 3.10-3
linux-headers-3.10-3-rpi - Header files for Linux 3.10-3-rpi
linux-headers-3.12-1-all - All header files for Linux 3.12 
(meta-package)
linux-headers-3.12-1-all-armhf - All header files for Linux 3.12 
(meta-package)
linux-headers-3.12-1-common - Common header files for Linux 3.12-1
linux-headers-3.12-1-rpi - Header files for Linux 3.12-1-rpi
linux-headers-3.16.0-4-all - All header files for Linux 3.16 
(meta-package)
linux-headers-3.16.0-4-all-armhf - All header files for Linux 3.16 
(meta-package)
linux-headers-3.16.0-4-common - Common header files for Linux 3.16.0-4
linux-headers-3.16.0-4-rpi - Header files for Linux 3.16.0-4-rpi
linux-headers-3.18.0-trunk-all - All header files for Linux 3.18 
(meta-package)
linux-headers-3.18.0-trunk-all-armhf - All header files for Linux 3.18 
(meta-package)
linux-headers-3.18.0-trunk-common - Common header files for Linux 
3.18.0-trunk
linux-headers-3.18.0-trunk-rpi - Header files for Linux 3.18.0-trunk-rpi
linux-headers-3.18.0-trunk-rpi2 - Header files for Linux 
3.18.0-trunk-rpi2
linux-headers-3.6-trunk-all - All header files for Linux 3.6 
(meta-package)
linux-headers-3.6-trunk-all-armhf - All header files for Linux 3.6 
(meta-package)
linux-headers-3.6-trunk-common - Common header files for Linux 3.6-trunk
linux-headers-3.6-trunk-rpi - Header files for Linux 3.6-trunk-rpi
linux-headers-4.4.0-1-all - All header files for Linux 4.4 
(meta-package)
linux-headers-4.4.0-1-all-armhf - All header files for Linux 4.4 
(meta-package)
linux-headers-4.4.0-1-common - Common header files for Linux 4.4.0-1
linux-headers-4.4.0-1-rpi - Header files for Linux 4.4.0-1-rpi
linux-headers-4.4.0-1-rpi2 - Header files for Linux 4.4.0-1-rpi2
linux-headers-rpi - Header files for Linux rpi configuration 
(meta-package)
linux-headers-rpi-rpfv - This metapackage will pull in the headers for 
the raspbian kernel for the
linux-headers-rpi2-rpfv - This metapackage will pull in the headers for 
the raspbian kernel for the
raspberrypi-kernel-headers - Header files for the Raspberry Pi Linux 
kernel
pi@raspberrypi:~ $



apt-cache search linux-image


linux-headers-3.10-3-rpi - Header files for Linux 3.10-3-rpi
linux-headers-3.12-1-rpi - Header files for Linux 3.12-1-rpi
linux-headers-3.16.0-4-rpi - Header files for Linux 3.16.0-4-rpi
linux-headers-3.18.0-trunk-rpi - Header files for Linux 3.18.0-trunk-rpi
linux-headers-3.18.0-trunk-rpi2 - Header files for Linux 
3.18.0-trunk-rpi2
linux-headers-3.6-trunk-rpi - Header files for Linux 3.6-trunk-rpi
linux-headers-4.4.0-1-rpi - Header files for Linux 4.4.0-1-rpi
linux-headers-4.4.0-1-rpi2 - Header files for Linux 4.4.0-1-rpi2
linux-image-3.10-3-rpi - Linux 3.10 for RaspberryPI
linux-image-3.12-1-rpi - Linux 3.12 for RaspberryPI
linux-image-3.16.0-4-rpi - Linux 3.16 for RaspberryPI
linux-image-3.18.0-trunk-rpi - Linux 3.18 for RaspberryPI
linux-image-3.18.0-trunk-rpi2 - Linux 3.18 for RaspberryPI2
linux-image-3.6-trunk-rpi - Linux 3.6 for RaspberryPI
linux-image-4.4.0-1-rpi - Linux 4.4 for RaspberryPI
linux-image-4.4.0-1-rpi2 - Linux 4.4 for RaspberryPI2
linux-image-rpi - Linux for RaspberryPI (meta-package)
linux-image-rpi-rpfv - This metapackage will pull in the raspbian kernel 
for the raspberry pi 1
linux-image-rpi2-rpfv - This metapackage will pull in the raspbian 
kernel for the raspberry pi 2
raspberrypi-kernel - Raspberry Pi bootloader
pi@raspberrypi:~ $

jetzt habe ich stattdessen mal folgendes gemacht:

"sudo apt-get install raspberrypi-kernel-headers"


nächster Schritt wäre jetzt aber Python Programm und "import evdev",

funktioniert nicht:


>>> import evdev
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named evdev
>>>

also >>> import evdev funktiert jetzt,
blöderweise hatte ich auch noch das vergessen: "$ sudo pip install 
evdev"

Anweisung "Specifying header locations" (siehe unten) funktioniert bei 
mir nicht, anyway weiss nicht für was das gut ist, und vielleicht gehts 
auch ohne.

Specifying header locations
By default, the setup script will look for the input.h and 
input-event-codes.h [1] header files /usr/include/linux.

You may use the --evdev-headers option to the build_ext setuptools 
command to specify the location of these header files. It accepts one or 
more colon-separated paths. For example:

$ python setup.py build_ext \
    --evdev-headers buildroot/input.h:buildroot/input-event-codes.h \
    --include-dirs  buildroot/ \
    install  # or any other command (e.g. develop, bdist, bdist_wheel)
[1]  input-event-codes.h is found only in more recent kernel versions.