Hallo, per X11 bzw. mit der Xlib ist es z.B. möglich den Mauszeiger zu simulieren, Funktion (XWarpPointer): x = 300 y = 300 display = X11.XOpenDisplay(0) rootwindow = X11.XDefaultRootWindow(display) X11.XWarpPointer(display,0,rootwindow,0,0,0,0,x,y) X11.XCloseDisplay(display) welche X11 Funktion muss verwendet werden um Touch's oder gar mehrere Touch's gleichzeitig zu simulieren? Den simulierten Touch würde ich dann mit einer HTML Anwendung testen, http://scripty2.com/demos/touch/ z.B: diese hier => http://scripty2.com/demos/touch/touchspector/ Diese Software zeigt mir im Moment halt nur den Mauszeiger. Ich teste alles im Moment per Raspberry Pi 3, Raspbian Jessie. wäre echt cool würde sich da jemand auskennen. Danke
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? Am liebsten möchte ich den Code bzw. die Funktion gleich selber/ direkt ansprechen ohne dritt-Programm... Danke
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
Georg A. schrieb: > verschicken (XSendEvent oder so). Es gibt auch ein Programm (xdotool), > das kann das auch Xdotool habe ich auch schon verwendet, aber damit scheint mir kann ich nur Maus und Tastaturbefehle simulieren... 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? Danke
Jack schrieb: > Xnee müsste auch Touch-Events abspielen können ich habe leider kein befehl gefunden mit dem ich ein touch oder mehrere simulieren bzw. auslösen könnte...
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
Simon B. schrieb: > Das ist ein normales Userspace-Programm was auf /dev/uinput zugreift. > Ein Tutorial ist z.B. hier: > http://thiemonge.org/getting-started-with-uinput . den habe ich auch schon studiert...nur ist mir die Vorgehensweise noch ein Rätsel. Zum Hintergrund, ich habe ein Raspberry Pi 3 mit Raspbian Jessie und am I2C Bus ein Touch angeschlossen. Dessen X und Y Achsen (bis 10 Finger Positionen) werte ich per Python aus. Per Xdotool-Befehl im Python Programm kann ich den Mauszeiger entsprechend den X-Y Daten bewegen. Ich suche jetzt auch eine einfache Funktion die ich aufrufen kann und die X und Y Daten übergeben kann, bzw. gleich mehrere da ja Multi-Touch. 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 :-(
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
Daniel A. schrieb: > 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. ich kann mit meinem kleinen I2C Python-Programm mit relativ wenig Anpassungen verschiedene Touch's auslesen. Z.b. im Moment gerade implementiert ein Cypress Touch für 12.3" TFT. Für mich tönt Linux Kernel kompilieren (zudem für Raspberry), hid-treiber etc. schreiben sehr kompliziert...(habs noch nie gemacht) Zudem will ich nicht den ganzen Kernel immer wieder neu kompilieren nur weil ich jetzt am Raspberry wieder ein anderen Touch anschliesse, und dann den hid-treiber immer wieder anpassen. Für mich wär was im Stile xdotool schon genial... ich muss doch dieser X11 Umgebung per Python die X-Y Koordinaten bzw. den Event übermitteln können, so wie es xdotool macht? Simon B. schrieb: > 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 Timing Verhalten ist egal (bzw. funktioniert sehr gut jetzt), ich möchte es eigentlich schon fast bewusst nicht mit einem Gerätetreiber machen. (eben weil anspruchsvoll und immer wieder kompilieren oder so zeug)... 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. Danke viel mal
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: > 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/
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
:
Bearbeitet durch User
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....
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.