Der bisherige Fix sieht so aus, dass man dem psmouse Treiber sagt (mit proto=bare), er solle bitte nicht das Elantech Protokoll benutzen. Dadurch wird das Touchpad nicht in den Absolute Mode versetzt, wodurch man die tollen Sachen wie Multitouch, Scrollen an der Touchpadseite etc. nicht hat, denn das Touchpad selbst liefert nur relative Koordinaten, wie eine Maus. Der Treiber für das Elantech Protokoll hingegen versetzt das Touchpad in den Absolute Mode, kann jedoch mit den Daten vom Trackpoint nichts anfangen (schaut mal ins Syslog, dort wird je nach Einstellung des psmouse Moduls die Hardware regelmäßig zurückgesetzt, weil es eben Protokollfehler gibt). Mein Patch fügt dem Elantech Treiber jetzt die Verarbeitung der Trackpoint Daten hinzu. Aber das wäre ja schön, wenn es damit schon getan wäre: Um die Eingabedaten von Eingabegeräten an die Systemprogramme weiterzureichen, werden sogenannte Event Devices erstellt, i.d.R. eins pro angeschlossene Hardware. Die Erstellung dieses Devices erledigt hier nicht der Code der für das Elantech-Protokoll zuständig ist, sondern das psmouse Modul ganz allgemein (und damit auch für andere Protokoll Codes wie synaptics oder das alte Trackpoint Protokoll [ich vermute, dass das damals separat angeschlossen war und nicht mit am Touchpad hing]). Kriegt psmouse dann mit, dass Hardware angeschlossen wurde, bittet es die Protokolle alle einmal, zu schauen, ob sie damit was anfangen können. Solange nicht proto=bare (o.ä.) angegeben ist, kommt irgendwann Elantech an die Reihe und meldet, dass das hier ein Elantech Touchpad ist.
Wie gesagt wurde das Device hier bereits schon erstellt, psmouse reicht es dann einfach an den Elantech-Protokoll-Code weiter, damit dieser darüber die Eingaben weiterleiten kann.
So weit, so gut. Es ist auch kein Problem über das Device was dort ankommt die absoluten Touchpad Koordinaten und die relativen Trackpoint Koordinaten weiterzurreichen. Das Problem liegt vielmehr bei Xorg: Der Xorg Server kann von einem Device entweder relative oder absolute Koordinaten verarbeiten, jedoch nicht beides. Da der Code jedoch wie oben beschrieben aufgebaut ist, ist es nicht grade einfach, ein zusätzliches Device für die separaten relativen Koordinaten zu basteln.
In den meisten Default-Configs nimmt der Xorg Server jetzt sein Synaptics Modul (das ist kein Kernelmodul sondern ein Xorg Modul) für das Device was er gefunden hat, dieses ignoriert einfach die relativen Koordinaten ohne sich zu beschweren. Man kann ihn jedoch zwingen, evdev zu nehmen und muss dann noch evdev sagen, er soll bitte die relativen nehmen, dann hat man mit meinem Patch einen funktionierenden Elantech Driver allerdings ohne Touchpad.
Ich hoffe, ich konnte das einigermaßen beschreiben.
Das Problem an dem ich gerade noch Arbeite ist: Ich will ein zweites Device für die Trackpoint Daten erstellen, dann würde Xorg das als separates Gerät erkennen und ohne zusätzliche Config evdev drauf ansetzen, weil dort eh nur relative Koordinaten rauskommen. Aber wie gesagt, der Code ist so doof, der ist nicht dafür ausgelegt, dass man zwei Devices brauchen könnte.
Gruß Socke
Ich bin dabei, einen Treiber zu entwickeln, der das Problem hoffentlich bald löst.
)
Keine Ahnung, ob das auch dynamisch ginge zur Laufzeit ehrlichgesagt. Habe den Patch hier eingestellt, incl. Xorg config: 
(habe leider (noch) keine Erfahrung im Treiber/Kernel/header-files compilen 
