staging.inyokaproject.org

So, jetzt mal ganz rudimentär:

• Notebook ausgeschaltet, USB-Stick (mit ubuntu-22.04-Installation) eingesteckt.

• Notebook eingeschaltet, F7, Starten von USB ausgewählt.

• Im Boot-Start-Auswahlmenü: "try or install ubuntu" ausgewählt.

• Notebook mit Ubuntu-Setup fährt hoch.

• Bereits ab dem ersten Moment, wo eine grafische Oberfläche zu sehen ist, noch kurz vor der Auswahl, wo man auf "try ubuntu" oder "install ubuntu" klickt, erscheint ein sich drehender Mauszeiger.

• Ab hier funktioniert das Touchpad einwandfrei ohne hakeln!

• * So nun kommts:

• Wenn ich nun oben rechts im Eck auf Ausschalten und dann entweder

• Bereitschaft

• Neustart

• Ausschalten

• Abmelden

• klicken will, dann funktioniert an dieser Stelle im Setup-Menü NUR der Punkt: Bereitschaft/SUSPEND

• Beim Klick auf Neustart, Ausschalten, Abmelden passiert gar nichts!

• Wahlweise kann ich nun also SUSPEND wählen, oder das Display zuklappen

• Daraufhin schaltet das Notebook in den Ruhezustand.

• Nach dem Aufwecken, mittels kurzem Druck auf den Ein/Ausschalter kommt die Setup-Anzeige zurück und ab jetzt ist das Touchpad wieder hakelig.

• Und das bleibt dann auch so.

• Erst wenn ich die gesamte Routine mit "hartem/kaltem" Ausschalten erneut wiederhole, USB-Stick-boot, etc. funktioniert das Touchpad wieder.

• Mir scheint, laienhaft, als würde beim Start irgendwelche Treiber in einen "Speicher" geschrieben werden, der durch den SUSPEND-Modus gelöscht wird.

Es geht noch weiter:

• Wenn ich also wieder hochfahre, USB-Stick, Ubuntu-Setup, Touchpad funktioniert.

• Nun klicke ich nicht auf "try ubuntu" oder "install ubuntu" sondern auf das "x" dieses Windows

• es kommt die Nachfrage: "Do you want to quit installation" und ich klicke an dieser Stelle auf "QUIT"

• dann startet das Ubuntu-Setup offensichtlich mit der Option "try ubuntu" anstatt das Setup komplett abzubrechen. (das ist jetzt mal egal)

• es erscheint also der normale Desktop um Ubuntu auszuprobieren

• Touchpad nach wie vor funktionsfähig, kein Hakeln.

• Wenn ich nun an dieser Stelle wieder rechts oben ins Eck klicke, dann auf Ausschalten>Neustart

• das Notebook macht einen Neustart,

• Notebook (nicht zugeklappt)!

• der Bildschirm wird schwarz (Boot-Bildschirm)

• Notebook startet nun mein bereits zuvor installiertes Ubuntu 22.04 ganz regulär, also nicht das Ubuntu-setup vom USB-Stick, sondern das Ubuntu auf meiner Festplatte.

• Es kommt der Passwort-Anmeldeschirm, Abfrage Passwort, Einloggen, Ubuntu startet

• UND

• das Touchpad funktioniert weiterhin einwandfrei (SELBST NACH DEM NEUSTART)

• Sobald aber das Notebook in SUSPEND gebracht wird oder zugeklappt wird, ist das Touchpad nach dem Aufwachen wieder hakelig und ohne Gesten.

Ein letzter Versuch:

• wieder wie zuvor, USB-Stick-boot usw.

• Touchpad funktioniert

• installation quit

• Neustart

• Festplatten-Ubuntu startet, anmelden, Touchpad funktioniert.

• Wenn ich an dieser Stelle anstatt SUSPEND oder Zuklappen

• sondern rechts oben klicke auf Ausschalten>Ausschalten

• Notebook fährt runter

• Neustart mit Einschalter

• Ubuntu startet von Festplatte

• Auch hier funktioniert das Touchpad nicht mehr, hakelt. *

Es scheint also der Schlüssel zum Problem zu sein, dass beim SUSPEND oder Zuklappen (sowie Ausschalten) irgendetwas aus einem temporären Speicher gelöscht wird, was das Touchpad zum Funktionieren bräuchte. Das könnte jetzt also erfordern, dass man es schafft, Ubuntu zu veranlassen, nach dem SUSPEND/Aufwachen irgendeinen Touchpad-Treiber in diesen "onimösen" Speicher nachzuladen. Eigentlich könnte man sagen, Ubuntu lädt die Touchpadtreiber NUR beim Ubuntu-Setup-Programm oder sonst mal aus unerfindlichen Gründen (bei meinen 100 letzten Versuchen/Kommandos) Aber Ubuntu schafft es nicht, die Touchpadtreiber beim NEUSTART, SUSPEND oder AUFKLAPPEN heraus direkt zu laden.

Hat jemand ne Idee?

Sorry für den langen Text, aber ich wollte es nun wirklich nachvollziehbar darstellen.

Der lange Text ist überhaupt nicht schlimm, allerdings haben wir noch viele offene Ansatzpunkte, bzw. kein Feedback. Es gibt nun im Livemedium mehrere Ansatzpunkte. Vergleichen der geladenen Kernelmodule vor und nach dem suspend und Vergleichen der Einstellungen/Werte vor und nach suspend, so wie manuelles entladen und laden des Moduls vor/nach suspend.

Starte dein Livemedium, öffne da ein Terminal und nutze lsmod > /tmp/module um die aktuell geladenen Informationen zu speichern. Zudem wie weiter oben beschrieben das Verzeichnis des Touchpads rausfinden und die Daten (teilweise binäre Hyroglyphen) sichern mit

find /sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-DLL09FF:01/0018:06CB:CE39.0002/ -type f -exec bash -c 'dateiname="{}"; echo "$dateiname"; cat "$dateiname"' \; > /tmp/werte

Den Pfad musst du natürlich anpassen, der Rest sollte mit Hilfe von find verständlich sein. Nach dem Aufwachen machst du das selbe nochmal mit anderen Dateinamen wie module2 und werte2 oder so und kannst diese dann mit diff vergleichen, bspw. diff /tmp/werte{,2}. diff bietet auch einige Optionen wie Spaltenansicht, etc. Musst du gucken was dir bequemer vorkommt.
Die Inhalte der Dateien bitte nicht hier posten. Falls es Unterschiede gibt, kannst du die natürlich erwähnen 😉 Ich erwarte eigentlich, das vor und nach dem Aufwachen keine nennenswerten Änderungen vorhanden sind.

Nach einen frischen Start in dem wieder alles funktionieren würde: Du entlädst manuell das Modul modprobe -ra psmouse i2c_hid, gehst in den suspend (mit systemctl suspend bspw.) und lädst nach dem Aufwachen die Module mit modprobe -a psmouse i2c_hid wieder in den Speicher. Wenn es dann noch immer ruckelt, müssen wir Grafikeistellungen testen. Übrigens: Die Modulnamen gelten, wenn diese auch zuständig sind. psmouse ist an sich Standard und i2c der häufigste Controller. Da du die Ausgaben nie veröffentlicht hast, ist das also geraten und muss ggf. angepasst werden.

Sowohl bei deinen Versuchen, als auch den neuen bitte immer das Log im Auge behalten. „Live“ verfolgen kannst du das mit journalctl -f, filtern ist an der Stelle aber sinnvoller. Warnungen (-p warning), Fehler (-p err), Kernelmeldungen (-k), etc.

ich hänge fest: Wie finde ich den Pfad des Touchpad ? Bei deinem find-Befehl wird der Pfad nicht gefunden.

du schreibst:

find /sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-DLL09FF:01/0018:06CB:CE39.0002/

ich finde lediglich:

/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/

"i2c-1" gibts bei mir nicht.

nun zu lsmod:

Die geladenen module unterscheiden sich wie folgt: ("module-vor"= Boot mit Livemedium, "module-nach"= nach dem SUSPEND/AUFWACHEN) hier die Differenz:

diff module-vor module-nach
1a2
> binfmt_misc            24576  1
125c126
< nls_iso8859_1          16384  0
---
> nls_iso8859_1          16384  1
130c131
< usb_storage            77824  3 uas
---
> usb_storage            77824  4 uas
132c133
< i915                 3059712  39
---
> i915                 3059712  25
157c158
< nvme                   45056  0
---
> nvme                   45056  2
165c166
< nvme_core             126976  1 nvme
---
> nvme_core             126976  3 nvme

Wie gesagt die Werte (Hieroglyphen) liefere ich nach, wenn ich das mit dem Pfad weiß.

Fortsetzung folgt gleich, etws Geduld noch

Eins nach dem anderen. Wie hier beschrieben, kannst du den Pfad über die Datei /proc/bus/input/devices herausfinden. Mein find-Beispiel ist natürlich nur bei mir funktionsfähig.

Wenn du den ermittelt hast (/sys vornedranstellen nicht vergessen), kannst du ihn für den find-Befehl nutzen. Dieser durchsucht die Verzeichnisstruktur nach Dateien (type f=file), gibt deren vollständigen Pfad und Namen an die Subshell (bash -command) durch das "{}" weiter und selbige zeigt dann Pfad/Datei und den Inhalt an. Da ich nicht weiß, welche Daten bei dir vorhanden sind (stände in der libinput-Info), habe ich einfach alle genommen. Da gibt es automatisch ein paar Fehler durch Dateien, die nur beschreibbar, aber nicht lesbar sind und eben einen Block an Hyroglyphen, weil auch Binärdaten vorliegen. Ist aber nicht tragisch. Es geht hauptsächlich um sich verändernde Werte an den Einstellungen, die vor und nach dem suspend anders sind.

Wenn nicht, teste erst den Teil mit dem manuellen Entladen und manuellem Einlesen der Kernelmodule. Die bei dir verfügbaren kannst du dir ja mit lsmod auch ansehen und gucken, ob es die beiden bei dir gibt.

Damit dir der allgemeine Weg klar wird. Du hast ein Eingabegerät (Tastatur, Maus, Touch, Powerbutton, Kamera,etc.) an einem Bussystem hängen (bspw. USB, PS/2, etc.). Wenn du nun ein Signal lossendest wie einen Fingerdruck auf das Touchpad, dann übermittelt das Gerät über den Bus mehrere „Signalpakete“ in denen die Informationen stehen, was du wann wie lange gemacht hast. Diese werden vom Kernel durch den entsprechenden Treiber gejagt, dessen Aufgabe es ist das Event (Ereignis) fürs System nutzbar aufzubereiten. Dieses aufbereitete Informationspaket wird dann über evdev im Kernel an der Schnittstelle (/dev/input/…) bereitgestellt. In modernen Systemen wird das dort von libinput aufgegriffen und zusammen mit anderen Hardware-Events in ein logisches Ereignis zusammengepackt, so das du bspw. bei gedrückt gehaltener Shift-Taste (Eingabegerät Tastatur) zusammen mit einer Bewegungseingabe (Tastatur-Pfeile, Maus, Touchpad) und ggf. einer gedrückten linken Maustaste etwas markieren kannst.

Wenn es „ruckelt“ kann das zum Beispiel an der Auflösung liegen, die von der Auflösung des Gerätes auf die Auflösung des angezeigten Bildschirms umgerechnet wird. Auflösung klingt kompliziert, aber ist eigentlich nur eine Art Maßstab („1cm auf der Karte ist 1km in der Wirklichkeit“). Du bewegst den Finger 3 Pixel nach rechts und 50 nach unten und der Mauszeiger wandert dann kerzengerade an den unteren Bildschirmrand, egal ob dein Monitor FullHD, 4K oder 640x480 Pixel anzeigt.
Diese Umrechnung macht der Treiber, es gibt Hardwaredatenbanken mit Zusatzinfos, etc. pp. Wir merken das natürlich nicht, aber da passiert hinter den Kulissen richtig viel, bis ein Buchstabe angezeigt oder ein Mauszeiger bewegt wird.

Das Timing wäre eine andere Fehlerquelle. Diese Geräte haben eine „Abtastrate“, was nichts anderes bedeutet als das der im Gerät enthaltene Controller in dieser Frequenz die veränderten Daten abgreift und über den Bus schickt. Damit das dann flüssig aussieht werden bei der Bewegung vereinfacht gesagt Mittelwerte verwendet, so das Geschwindigkeitsunterschiede nicht 1:1 übertragen werden, da der Bildschirm eine andere Rate hat als das Gerät.
An dem ganzen Kram können wir theoretisch viel ändern, praktisch ist das aber nicht nötig und beinhaltet auch unheimlich viele Abstraktionsebenen, einstellbare und zu berücksichtigende Optionen, etc.

Bei dir scheint es ja NUR schiefzugehen, wenn du suspend nutzt, was das ganze stark vereinfacht. Wir brauchen also den Treiber und das Gerät nicht prüfen, sondern müssen nur ermitteln ob es am Kernelmodul (Treiber) des Touchpads oder der Grafikkarte liegt.

von.wert schrieb:

almanya schrieb:

Ich müsste wahrscheinlich erst libinput installieren?

1 2	sudo apt install libinput-tools sudo libinput list-devices

Wenn's Dich interessiert.

Um die nötigen Informationen über Pfadangaben von Touchpad zu erhalten wollte ich libinput-tools installieren. Leider nicht möglich.

E: Paket libinput-tools kann nicht gefunden werden.

Vorneweg nochmals im Detail:

Wow, deine Beschreibung, wie das Ganze funktioniert, ist brilliant! Damit du genau weißt, was ich mit "hakelig" meine:

Wenn ich sage, das Touchpad funktioniert nicht richtig, bedeutet dies:

• Die Gestensteuerung (z.B. Scrollen mit 2 Fingern) nicht möglich, scheint deaktiviert, Veränderungen bei den "Einstellungen-gui" bewirken Null.

• Der Mauszeiger bewegt sich zwar flüssig, aber nur, wenn der Finger auf dem Touchpad in Bewegung ist.

• sobald der Finger anhält und man weiterbewegen will, bewegt sich der Mauszeiger entweder nicht/kaum/sehr träge.

• ist der Finger wieder in Bewegung läuft der Zeiger wieder flüssig.

• Das was mich stört ist, dass du minmale Detail-Bewegungen nicht hinbekommst.

• Steuere ich z.B. auf ein Symbol grob hin, bremse ab, um den Mauszeiger millimetergenau zu positionieren, bleibt der Zeiger erst mal kurz vorm Ziel stehen und durch diese träge Reaktion komme ich nicht auf dem Ziel an, sondern bleibe entweder davor oder springe ein Stück dahinter.

• Die sehr langsamen Bewegungen nimmt der Zeiger also gar nicht an.

• Das meinte ich wenn ich sage, der Zeiger reagiert hakelig.

erster Schritt (Inhalt in devices): damit arbeite ich gleich weiter

I: Bus=0018 Vendor=2808 Product=0102 Version=0100
N: Name="FTCS1000:00 2808:0102 Touchpad"
P: Phys=i2c-FTCS1000:00
S: Sysfs=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/input/input24
U: Uniq=
H: Handlers=mouse1 event5
B: PROP=5
B: EV=1b
B: KEY=e520 10000 0 0 0 0
B: ABS=2e0800000000003
B: MSC=20

Damit mache ich also meinen Befehl

find /sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/ -type f -exec bash -c 'dateiname="{}"; echo "$dateiname"; cat "$dateiname"' \; > /tmp/werte-vor

und erhalte:

cat: '/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/power/autosuspend_delay_ms': Eingabe-/Ausgabefehler
cat: '/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/input/input24/event5/power/autosuspend_delay_ms': Eingabe-/Ausgabefehler
cat: '/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/input/input24/power/autosuspend_delay_ms': Eingabe-/Ausgabefehler
cat: '/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/input/input24/mouse1/power/autosuspend_delay_ms': Eingabe-/Ausgabefehler
cat: '/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/input/input23/power/autosuspend_delay_ms': Eingabe-/Ausgabefehler
cat: '/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/input/input23/mouse0/power/autosuspend_delay_ms': Eingabe-/Ausgabefehler
cat: '/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/input/input23/event4/power/autosuspend_delay_ms': Eingabe-/Ausgabefehler
cat: '/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTCS1000:00/0018:2808:0102.0001/hidraw/hidraw0/power/autosuspend_delay_ms': Eingabe-/Ausgabefehler

und den Rest schreibt er in /tmp/werte-vor

und nach SUSPEND/AUFWACHEN in /tmp/werte-nach

Fortsetzung folgt, ich werde das jetzt angehen.

Den Pfad gibt es immer. less /proc/bus/input/devices. /proc ist ein Systempfad im temporären Dateisystem (Teil vom RAM), in dem der Kernel seine Informationen ablegt. Wenn du dich grafisch wohler fühlst, müsste das bei Ubuntu gedit sein. Also gedit /proc/bus/input/devices. Ändern sollst du da aber nichts drin, nur angucken.

Die libinput-tools liegen in universe, was du möglicherweise nicht aktiv hast (→ sources.list). Aber da du die gerade nicht brauchst, schreib das für später auf 😉

ChickenLipsRfun2eat schrieb:

Nach einen frischen Start in dem wieder alles funktionieren würde: Du entlädst manuell das Modul modprobe -ra psmouse i2c_hid, gehst in den suspend (mit systemctl suspend bspw.) und lädst nach dem Aufwachen die Module mit modprobe -a psmouse i2c_hid wieder in den Speicher. Wenn es dann noch immer ruckelt, müssen wir Grafikeistellungen testen. Übrigens: Die Modulnamen gelten, wenn diese auch zuständig sind. psmouse ist an sich Standard und i2c der häufigste Controller. Da du die Ausgaben nie veröffentlicht hast, ist das also geraten und muss ggf. angepasst werden.

Sowohl bei deinen Versuchen, als auch den neuen bitte immer das Log im Auge behalten. „Live“ verfolgen kannst du das mit journalctl -f, filtern ist an der Stelle aber sinnvoller. Warnungen (-p warning), Fehler (-p err), Kernelmeldungen (-k), etc.

Frage dazu, wo finde ich dann die bei mir richtigen Namen für "psmouse" und "i2c_hid" um diese dann zu entladen und laden? Ich glaube nämlich, dass diese richtig sein könnten. Denn der Befehl 'modprobe -ra psmouse i2c_hid' ergab die Fehlermeldung

modprobe: WARNING: Module i2c_hid is in use.

Und psmouse entladen scheint geklappt zu haben.

Nur wie kann ich i2c_hid entladen, wenn aktuell in use ?

Ich lese den Rest später, aber auf die Schnelle: almanya schrieb:

Nur wie kann ich i2c_hid entladen, wenn aktuell in use ?

Die Module können voneinander abhängen, wie bspw. bei Paketen, die Bibliotheken und andere Pakete brauchen. Wenn ein Modul das verwendet, kannst du es nicht so entladen. Rausfinden kannst du das mit kmod, bzw. einer der darauf basierenden Namen:

root@delly[~]› rmmod -v i2c_hid
rmmod: ERROR: Module i2c_hid is in use by: i2c_hid_acpi
root@delly[~]› 

In dem Fall müsste ich also

rmmod i2c_hid_acpi && rmmod i2c_hid && sleep 2; && modprobe -a i2c_hid i2c_hid_acpi

laufen lassen, um den Treiber zu entladen, zwei Sekunden zu warten und dann wieder neu zu laden. -v, bzw. --verbose gibt es bei den meisten Programmen. Wenn du also mehr Informationen willst, nach verbose oder debug gucken.

An sich nimmt man das „intelligentere“ modprobe -r i2c_hid i2c_hid_acpi um Module zu entfernen, wenn es aber nicht will, dann mit rmmod. Da aber dann einzeln, das kann nur ein Modul auf einmal. Beides tut das selbe, modprobe ist nur vorzuziehen. Insofern habe ich das Beispiel gerade falsch geschrieben, da modprobe -r in den codeblock gehört und rmmod in den Fließtext. Egal. Melde mich später wieder!

Achtung jetzt wirds spannend, zumindest in der Livemedium-Testumgebung, in der das Problem ja bekanntermaßen gut nachvollziehbar ist. Wiederholbar.

Ich habe wie von dir gewünscht, ausgeführt:

sudo modprobe -ra psmouse i2c_hid
modprobe: WARNING: Module i2c_hid is in use.

okay, wie beschrieben kommt ja zurück, dass i2c_hid in use ist.

Aber offensichtlich hat es für "psmouse" funktioniert. Es zeigt sich auch darin, dass ab diesem Zeitpunkt das Touchpad nicht mehr funktioniert.

In meinen jetzt gleichen kommenden Tests (ja es werden mehrere werden, wusste ich zu diesem Zeitpunkt noch nicht)

verwende ich nur noch 'sudo modprobe -ra psmouse' und 'sudo modprobe -a psmouse'

Die Ergebisse sind wiederholbar:

• Start Livemedium, Touchpad funktioniert

• SUSPEND/AUFWACHEN, Touchpad hakelt

• 'sudo modprobe -ra psmouse', Touchpad funktioniert komischerweise noch (dies gilt allerdings nur für den jeweils ersten Versuch nach dem Booten)

• SUSPEND/AUFWACHEN, Touchpad funktioniert, huch, ja funktioniert, ohne 'sudo modprobe -a psmouse' einzugeben

• und nochmals

• SUSPEND/AUFWACHEN, Touchpad funktioniert, huch, ja funktioniert, ohne 'sudo modprobe -a psmouse' einzugeben

• und immer wiederholbar, Touchpad bleibt funktionsfähig, mit Gestensteuerung

• Wenn ich nun aber 'sudo modprobe -a psmouse' eintippe, ACHTUNG, dann schalte ich mit diesem Befehl um, und das Touchpad hakelt wieder.

• Wenn ich nun 'sudo modprobe -ra psmouse' eintippe, ACHTUNG, dann schalte ich mit diesem Befehl das Touchpad komplett aus.

• SUSPEND/AUFWACHEN, Touchpad funktioniert, huch, ja funktioniert, ohne 'sudo modprobe -a psmouse' einzugeben

Es scheint, als würde sich beim AUFWACHEN automatisch das Touchpad korrekt aktivieren und funktionieren.

• Sobald ich mit einem Befehl 'sudo modprobe -a psmouse' daherkomme, hakelt das Touchpad sofort

• Wenn ich nun wieder 'sudo modprobe -ra psmouse' eintippe, ACHTUNG, dann schalte ich mit diesem Befehl das Touchpad komplett aus.

• SUSPEND/AUFWACHEN und das Touchpad ist wieder voll funktionsfähig.

Falls das jetzt zu kompliziert war. Irgendwas scheint mit diesem psmouse nicht zu stimmen. Wenn ich es mit -ra entladen habe, dann lädt das System nach dem AUFWACHEN sein eigenes funktionierendes "AUFWACH-psmouse" nach, es sei denn, es war im Moment des SUSPEND ein anderes SUSPEND-psmouse vorhanden, dann blockiert dieses SUSPEND-psmouse, das AUFWACH-psmouse.

Ich weiß, bei meiner Beschreibung stehen Euch die Haare zu Berge, aber vielleicht hilft es, dem Problem näher zu kommen und ihr könnt mir sagen, wo wir psmouse loggen oder analysieren können.

Ich erweitere gleich noch meinen Test, werde jetzt mal schnell in mein installiertes Festplatten-Ubuntu reingehen und schaunen, welche Reaktionen ich da mit dem entladen und laden von psmouse erzeugen kann,

ERGEBNIS:

• Die "Lösung", sagen wir der erste Schritt zur Notlösung.

• * Ich starte mein Ubuntu 22.04 ganz normal von der Festplatte.

• Das Touchpad hakelt schon beim Sperrbildschirm.

• Ich melde mich an (nach unzähligen Versuchen spielt es keine Rolle ob per ubuntu-Wayland oder ubuntu-auf-Xorg)

• Ich öffnen ein Terminal, gebe ein 'sudo modprobe -ra psmouse"

• Das Touchpad ist sofort KOMPLETT OHNE Funktion

• Ich gehe in SUSPEND/oder Zuklappen

• Nach dem AUFWACHEN/ oder Aufklappen funktioniert das Touchpad einwandfrei mit Gestensteuerung.

• Und dieser Zustand bleibt erhalten! Auch ohne je wieder 'sudo modprobe -a psmouse' eingeben zu müssen.!

• Auch mehrfache SUSPEND/AUFWACHEN und das Touchpad bleibt voll funktionsfähig.

• * Aber wenn ich das Ubuntu wieder herunterfahre/ausschalte, dann ist beim nächsten Systemstart bereits vor dem Anmelden/Passwort das Touchpad hakelig.

Ziel wäre es also, die psmouse-Version, die sich beim Booten einbaut durch die AUFWACH-psmouse-Version zu ersetzen. Wahrscheinlich ist aber der Fehler irgendwo anders begraben, weil es die von mir vermuteten 2 psmouse-Versionen gar nicht gibt (sondern eben nur eine?) Vielleicht blockiert o.ä. der SUSPEND/AUFWACH-Vorgang irgendeine Routine, die das Touchpad lahm legt, so dass es weiterhin voll funktioniert?

Frage für einen Workaround:

Ich würde mir gerne ein Script oder eine *.desktop basteln (zum Doppelklick vom Desktop aus), das mir den Befehl "sudo modprobe -ra psmouse" ausführt (mit solchen Rechten, dass ich nicht extra mein Passwort eingeben muss (wegen sudo), dann automatisch einen quasi SUSPEND/AUFWACHEN durchführt. Allerdings nicht soweit, dass ich wieder das Passwort eintippen muss. Also ein Script was sozusagen die psmouse entlädt und dann die gleichen Routinen ausführt wie bei einem SUSPEND/AUFWACHEN.

Träum.... oder hast du ne Lösung, die sauber implementiert werden kann?

So jetzt freue ich mich wieder auf Euren Input. Herzlichen Dank, ich hab schon soviel gelernt dadurch...

almanya schrieb:

…

• Der Mauszeiger bewegt sich zwar flüssig, aber nur, wenn der Finger auf dem Touchpad in Bewegung ist.

• sobald der Finger anhält und man weiterbewegen will, bewegt sich der Mauszeiger entweder nicht/kaum/sehr träge.

…

Das liest sich wie die Zeigerbeschleunigung. Damit Bewegungen flüssig aussehen, werden sie umgerechnet. Frag mich gerade nicht, wo die in GNOME eingestellt wird. Vermutlich in Tweaks.

und erhalte:
(Fehler)

Offensichtlich. Schrieb ich oben. Diese Dateien dienen nur zum Schreiben und sind nicht lesbar. Damit setzt du Optionen im Gerät, wenn du reinschreibst. Als wenig schädliches Beispiel kannst du mal als root echo 100 > /sys/class/backlight/intel_backlight/brightness ausprobieren (Hattest du nen Intel-Chip?). Das verändert deine Bildschirmhelligkeit. Leider ist das Beispiel insofern doof, als die Datei auch zeitgleich lesbar und beschreibbar ist und den aktuellen Wert enthält.

almanya schrieb:

okay, wie beschrieben kommt ja zurück, dass i2c_hid in use ist.

Aber offensichtlich hat es für "psmouse" funktioniert.

Schau dir man modprobe oder modprobe --help an. Das -a bedeutet alle angegebenen Module. Das Tool geht also die Liste durch, die in einem Fall aus zwei Modulen besteht. Beim einen klappts, beim anderen nicht. Dein sudo modprobe -ra psmouse ist also gleichbedeutend mit sudo modprobe -r psmouse. Bitte nicht einfach Befehle übernehmen, sondern vorher gucken was die machen. Ich sitze nicht an deinem System und kann die Beispiele nur allgemein oder von meinem bringen. Das -a ist an der Stelle natürlich nicht schlimm, zeigt mir nur, das du ausprobierst, anstatt mitzudenken 😉

psmouse ist da das Standardmodul für alle Eingabegeräte. Den Controller musst du nur deaktivieren, wenn das Touchpad trotz Entladen reagiert. Wie das genau funktioniert kann ich dir auch nicht darstellen. Beim An-/Abstecken eines Gerätes läuft UDEV und dort werden ggf. auch Module ge-/entladen und andere Strukturen vorbereitet oder entfernt, zudem werden Dinge nicht einfach gnadenlos aus dem Speicher gelöscht, sondern bestehenden Zugriffe abgewartet. Das geht hier zu sehr ins Detail gerade, ist nur ein grober Hinweis auf den Grund wieso trotz entladenem psmouse das Touchpad noch reagiert, wie du in

• 'sudo modprobe -ra psmouse', Touchpad funktioniert komischerweise noch (dies gilt allerdings nur für den jeweils ersten Versuch nach dem Booten)

selbst festgestellt hast.

Nun zum Aufwachen. Wenn du in suspend gehst, werden alle unnötigen Teile entladen und nach dem Aufwachen wieder geladen. Ist also völlig normal, das das Touchpad dann wieder funktioniert. Dieses Verhalten kann beeinflusst werden, wenn systemd-sleep entsprechende Anweisungen in Scriptform mitgegeben werden. Alle in /usr/lib/systemd/system-sleep/ befindlichen ausführbaren Dateien werden mit zwei Argumenten aufgerufen. Das erste Argument gibt an, ob gerade geschlafen wird oder aufgewacht ("pre" und "post"), das zweite ist der Modus (sleep, hibernate,…). Details in man systemd-sleep.

ERGEBNIS: …

• Aber wenn ich das Ubuntu wieder herunterfahre/ausschalte, dann ist beim nächsten Systemstart bereits vor dem Anmelden/Passwort das Touchpad hakelig.

Ziel wäre es also, die psmouse-Version, die sich beim Booten einbaut durch die AUFWACH-psmouse-Version zu ersetzen.

Jein. Beim Systemstart scheint irgendwas zu hakeln. Das müsstest du dir mal genauer angucken (journalctl -k enthält alle Kernelmeldungen). Als einfache Lösung könntest du dir eine systemd-unit anlegen, die nach dem Start das Modul entlädt, kurz wartet und wieder lädt.

Frage für einen Workaround:

Du weißt ja jetzt, wie du ein Modul entladen kannst und wie du es wieder laden kannst. Wenn du das per Script haben möchtest, gibt es mehrere Wege. Der sauberste wäre das über PolicyKit zu machen. In dem Fall wäre aber ein Eintrag mittelsn visudo sinnvoller, weil wenig kompliziert. ⇨ sudo. Danach legst du dir für besagtes Script eine .desktop-Datei an.

oder hast du ne Lösung, die sauber implementiert werden kann?

Einige mögliche Lösungen. Kommt darauf an, wie sauber du das haben willst. Ich persönlich würde den Ablauf nun bis ins kleinste untersuchen wollen, bis ich das auf der niedrigsten Ebene verstanden habe. Ich bin aber auch kein Maßstab und verballere da viel Lebenszeit^^ Ausgehend von deinen Werten würde ich mir noch parallel den i915 vornehmen (Intel Grafiktreiber). Die systemd-unit wäre für mich ansonsten die Lösung der Wahl, die einfach das Modul nochmal entlädt und lädt. Zum weiteren Untersuchen natürlich nicht brauchbar. Da wäre dein Script mit Desktopdatei besser, weil du dann manuell entscheiden kannst, wann du den Fehler umgehst und wann nicht. Du könntest auch die

Hallo,

das ganze geht auf einen Kernel-Bug zurück. Besitze auch ein Schenker-Notebook mit ähnlichen Problemen, zum Glück nicht so extrem.

Zu diesem Problem findet sich im Log ein Eintrag. Gib mal im Terminal

journalctl | grep libinput

ein.

Bei mir kommt dann die Ausgabe

Jul 21 20:18:04 nautilus /usr/libexec/gdm-x-session^[42825]: See https://wayland.freedesktop.org/libinput/doc/1.20.0/touchpad-jumping-cursors.html for details

Mfg j-e-p