Forum: PC-Programmierung X11, xlib, multi touch simulation


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von epi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Xnee müsste auch Touch-Events abspielen können.

von epi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
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

von epi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von epi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
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

von epi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :-(

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
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

von epi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
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

von epi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

von Epi K. (epi_k)


Bewertung
0 lesenswert
nicht lesenswert
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"..

von Epi K. (epi_k)


Bewertung
0 lesenswert
nicht lesenswert
vielleicht doch einfacher als gedacht mit "evdev"?:

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

: Bearbeitet durch User
von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
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

von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
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

von Epi K. (epi_k)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
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

von Epi K. (epi_k)


Bewertung
0 lesenswert
nicht lesenswert
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
von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
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

von Epi K. (epi_k)


Bewertung
0 lesenswert
nicht lesenswert
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
von Epi K. (epi_k)


Bewertung
0 lesenswert
nicht lesenswert
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

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Epi K. (epi_k)


Bewertung
0 lesenswert
nicht lesenswert
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:~ $

von Epi K. (epi_k)


Bewertung
0 lesenswert
nicht lesenswert
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
>>>

von Epi K. (epi_k)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.