Moin.
Mein liebstes Eingabeinstrument, der Trackpoint, hat mich lange damit
genervt, dass er - bei ansonsten tadellos praeziser Funktion - alle 10
oder 20 Betaetigungen mit einer willkuerlichen Nachbewegung des Cursors
quittierte.
Langsam ein paar Millimeter nach links oder nach rechts.
Hat wirklich genervt, wenn gerade irgendwas praezis irgendwo hingebracht
werden sollte, z.B. in Inkscape oder Kicad.
Das Problem vermutete ich lange bei dem libinput-treiber, dessen
verschiedene Defaultwerte u.a. fuer adaptive Beschleunigung absolut
jenseits der Benutzbarkeit lagen.
Doch wo sich dies fixxen liess, blieben die willkuerlichen Bewegungen.
Dort wo ich den Fix fuer die Defaultwerte fand, war auch das
unerwuenschte Verhalten der Nachbewegungen erwaehnt - bin also nicht der
Einzige mit dem Problem - niemand hatte jedoch eine Loesung.
Nachdem ich nun nochmal nachgegraben habe, fand sich das Problem in
Gestalt einer scheinbar regelmaessig vorgenommenen Rekalibrierung des
Trackpoints, festgelegt durch einen Parameter in
Die Datei hat zwar ziemlich herumgezickt bei meinen Aenderungsversuchen,
sudo -> keine Schreibrechte, selbst als root hatte ich angeblich keine
Schreibrechte..?!
Liess sich dann aber trotzdem mit der Aenderung als root in nano
sichern, wo
ebenfalls als root noch fehlschlug.
So.
Anpassung des Wertes von '5' auf '15' und hoeher hat das laestige
Problem jetzt endlich eliminiert und die Nachbewegungen gehoeren der
Vergangenheit an.
Aber wie bekomme ich die Aenderung des Parameters in der Systemdatei
persistent?
/sys ist kein echtes Filesystem mit "Systemdateien", sondern ähnlich wie
/dev eine Schnittstelle zwischen Kernel und Userland, siehe sysfs(5).
Du musst den zu setzenden Wert in einem Startup-Script (z.B. mit echo)
dorthin schreiben:
echo 50 > /sys/devices/platform/i8042/serio1/serio/drift_time
Hmmm schrieb:> /sys ist kein echtes Filesystem mit "Systemdateien", sondern ähnlich wie> /dev eine Schnittstelle zwischen Kernel und Userland, siehe sysfs(5).
Soweit klar.
> Du musst den zu setzenden Wert in einem Startup-Script (z.B. mit echo)> dorthin schreiben:>> echo 50 > /sys/devices/platform/i8042/serio1/serio/drift_time
Hab' mir jetzt mal eine /etc/rc.local angelegt - existiert auf lmde4
nicht serienmaessig - den Befehl reingeschrieben und ausfuehrbar
gemacht.
Mal schauen, ob das ausgereicht hat.
Johannes U. schrieb:> Aber wie bekomme ich die Aenderung des Parameters in der Systemdatei> persistent?
Das setzen per Skript ist nur ein Workaround.
Die Änderung gehört zusammen mit der Geräte-ID (z.B. USB:ID, PCI:ID)
eigentlich direkt in den Treiber. Da kann man dann eine If Bedingung für
genau diese Geräte-ID einbauen und dann bleibst du in zukünftigen
Kernelgenerationen davon verschont.
Ich würde mich an deiner Stelle daher an den Treiberentwickler wenden
und ihm deine entsprechende Geräte ID mitteilen, damit der das einbauen
kann.
Falls du selber programmieren kannst, könntest du die Änderung am
Treiber auch selber vornehmen und dann einen Diff Patch dem
Treiberentwickler schicken.
Das erhöht deine Chancen, dass die Korrektur in den Treiber kommt,
sofern der Code okay ist, da es den Treiberentwickler von der Arbeit
entsprechende Änderungen vorzunehmen entlastet und er das dann nur noch
abnicken muss.
Nano schrieb:> Falls du selber programmieren kannst,
Leider nur rudimentaer ;(
> könntest du die Änderung am> Treiber auch selber vornehmen und dann einen Diff Patch dem> Treiberentwickler schicken.
Das waere fuer mich Koenigsklasse und uebersteigt leider meine
Moeglichkeiten.
Wie gesagt ich schau nun erstmal, ob die angelegte rc.local brav
jedesmal beim Start von systemctl bearbeitet wird.
Falls es da hakt, muss ich ja sowieso wieder ran.
Johannes U. schrieb:> /sys/devices/platform/i8042/serio1/serio2/drift_time>> Die Datei hat zwar ziemlich herumgezickt bei meinen Aenderungsversuchen,> sudo -> keine Schreibrechte, selbst als root hatte ich angeblich keine> Schreibrechte..?!
Interessant wäre da gewesen, welchem Benutzer/Gruppe die Datei gehört.
> Liess sich dann aber trotzdem mit der Aenderung als root in nano> sichern, wo> echo $parameter > /sys/devices/platform/i8042/serio1/serio/drift_time> ebenfalls als root noch fehlschlug.
Dann hast du da was falsch gemacht, denn das sollte in dem Fall genauso
gehen.
Nano schrieb:> Johannes U. schrieb:>> Aber wie bekomme ich die Aenderung des Parameters in der Systemdatei>> persistent?>> Das setzen per Skript ist nur ein Workaround.
Skript ist schon ok, aber ich würde es in die udev-Konfiguration für
dieses Gerät stecken und nicht als Teil des Bootvorgangs.
> Die Änderung gehört zusammen mit der Geräte-ID (z.B. USB:ID, PCI:ID)> eigentlich direkt in den Treiber. Da kann man dann eine If Bedingung für> genau diese Geräte-ID einbauen und dann bleibst du in zukünftigen> Kernelgenerationen davon verschont.>> Ich würde mich an deiner Stelle daher an den Treiberentwickler wenden> und ihm deine entsprechende Geräte ID mitteilen, damit der das einbauen> kann.
Ja, das wäre schon besser. Das Gerät sollte bei Default-Einstellung
brauchbar sein. Aber das wird ein Weilchen dauern, bis der Treiber
gepatcht ist, der Patch in den nächsten Kernel kommt und dieser dann
noch in der verwendeten Distribution angekommen ist.
Rolf M. schrieb:> Johannes U. schrieb:>> /sys/devices/platform/i8042/serio1/serio2/drift_time>>>> Die Datei hat zwar ziemlich herumgezickt bei meinen Aenderungsversuchen,>> sudo -> keine Schreibrechte, selbst als root hatte ich angeblich keine>> Schreibrechte..?!>> Interessant wäre da gewesen, welchem Benutzer/Gruppe die Datei gehört.
Nichts leichter als das:
$ bash: /sys/devices/platform/i8042/serio1/serio2/drift_time: Keine Berechtigung
1
$ su root
... und siehe da, nun KANN root den Befehl mit echo schreiben..
Keine Ahnung, was da gestern Abend falsch war, wo es jetzt als root wie
erwartet problemlos klappt, kam gestern diegleiche Fehlermeldung wie mit
sudo.
Merkwuerdig.
>> Liess sich dann aber trotzdem mit der Aenderung als root in nano>> sichern, wo>> echo $parameter > /sys/devices/platform/i8042/serio1/serio/drift_time>> ebenfalls als root noch fehlschlug.>> Dann hast du da was falsch gemacht, denn das sollte in dem Fall genauso> gehen.
Schon klar, das ist am wahrscheinlichsten.
Gestern war es sogar so, dass ich als root in nano gesagt bekam: 'Keine
Schreibberechtigung' und dann das Sichern dennoch klappte..
> Nano schrieb:>> Johannes U. schrieb:>>> Aber wie bekomme ich die Aenderung des Parameters in der Systemdatei>>> persistent?>>>> Das setzen per Skript ist nur ein Workaround.>> Skript ist schon ok, aber ich würde es in die udev-Konfiguration für> dieses Gerät stecken und nicht als Teil des Bootvorgangs.>>> Die Änderung gehört zusammen mit der Geräte-ID (z.B. USB:ID, PCI:ID)>> eigentlich direkt in den Treiber. Da kann man dann eine If Bedingung für>> genau diese Geräte-ID einbauen und dann bleibst du in zukünftigen>> Kernelgenerationen davon verschont.>>>> Ich würde mich an deiner Stelle daher an den Treiberentwickler wenden>> und ihm deine entsprechende Geräte ID mitteilen, damit der das einbauen>> kann.>> Ja, das wäre schon besser. Das Gerät sollte bei Default-Einstellung> brauchbar sein. Aber das wird ein Weilchen dauern, bis der Treiber> gepatcht ist, der Patch in den nächsten Kernel kommt und dieser dann> noch in der verwendeten Distribution angekommen ist.
Zunaechst ist mir nachwievor nicht klar, ob dieser Parameter nun zu
libinput gehoert oder Bestandteil anderer Pakete ist.
Einstellungen an libinput nehme ich ja sonst persistent in
1
/usr/share/X11/xorg.conf.d/40-libinput.conf
vor oder on the fly mit xinput.
Jedenfalls war die unerwuenschte Trackpointbewegung nicht bereits immer
ein Problem mit Linux.
Die Systeme, die ich auf meinem T61 oder W500 hatte, zeigten soetwas
nie.
Auch mein Erstes x201 mit imho erst LMDE2 dann LMDE3 hatte diese
Probleme nicht.
Da ich nun allerdings auch nicht adhoc sagen kann, ob dort auch bereits
libinput fuer die Eingabehardware zustaendig war oder ob es nicht
synaptics oder evdev war, nuetzt es erstmal nicht viel.
Hauptsache ich habe nun einen Fix und bekomme den moeglichst elegant
persistent gemacht :)
Edit:
Werde mal den udev-Fix von hier
>https://www.reddit.com/r/thinkpad/comments/i9dd2f/trackpoint_moving_on_its_own_solved/
ausprobieren, ist wahrscheinlich das Eleganteste.
Johannes U. schrieb:> Aber wie bekomme ich die Aenderung des Parameters in der Systemdatei> persistent?
als Parameter dort wo die 'input-devices' üblicherweise angegeben
werden.
variiert ggf. je nach system
xinitrc, xorg.conf; unter /xorg.conf.d
udev rule, systemd.path unit, ...
https://wiki.archlinux.org/title/TrackPoint
Als einzigem Nutzer tut es nat. auch dein scriptlet
Johannes U. schrieb:> Rolf M. schrieb:>>> Johannes U. schrieb:>>>>> /sys/devices/platform/i8042/serio1/serio2/drift_time>>> Die Datei hat zwar ziemlich herumgezickt bei meinen Aenderungsversuchen,>>> sudo -> keine Schreibrechte, selbst als root hatte ich angeblich keine>>> Schreibrechte..?!>>>> Interessant wäre da gewesen, welchem Benutzer/Gruppe die Datei gehört.>> Nichts leichter als das:> $ -rw-r--r-- 1 root root 4,0K Apr 29 22:38> /sys/devices/platform/i8042/serio1/serio2/drift_time>> $ sudo echo 15 > /sys/devices/platform/i8042/serio1/serio2/drift_time>> $ bash: /sys/devices/platform/i8042/serio1/serio2/drift_time: Keine> Berechtigung>> $ su root>> ... und siehe da, nun KANN root den Befehl mit echo schreiben..> Keine Ahnung, was da gestern Abend falsch war, wo es jetzt als root wie> erwartet problemlos klappt, kam gestern diegleiche Fehlermeldung wie mit> sudo.> Merkwuerdig.>>> Liess sich dann aber trotzdem mit der Aenderung als root in nano>>> sichern, wo>>> echo $parameter > /sys/devices/platform/i8042/serio1/serio/drift_time>>> ebenfalls als root noch fehlschlug.>>>> Dann hast du da was falsch gemacht, denn das sollte in dem Fall genauso>> gehen.>> Schon klar, das ist am wahrscheinlichsten.> Gestern war es sogar so, dass ich als root in nano gesagt bekam: 'Keine> Schreibberechtigung' und dann das Sichern dennoch klappte..
Das ist etwas gemein, aber es gibt eine einfache Erklärung wieso das
nicht geklappt hat - geschrieben wurde hier nämlich nie als Root.
> $ sudo echo 15 > /sys/devices/platform/i8042/serio1/serio2/drift_time
Das sudo führt das echo mit Root Rechten aus. Das interessiert dich aber
gar nicht, du willst ja nur als Root schreiben. Das sudo steht somit
schlichtweg an der falschen Stelle.
echo 15 > sudo tee -a
/sys/devices/platform/i8042/serio1/serio2/drift_time
> Edit:> Werde mal den udev-Fix von hier>>> https://www.reddit.com/r/thinkpad/comments/i9dd2f/trackpoint_moving_on_its_own_solved/>> ausprobieren, ist wahrscheinlich das Eleganteste.
udev ist quasi die Musterlösung für derartige Aufgaben.
Johannes U. schrieb:> Nano schrieb:>> Falls du selber programmieren kannst,>> Leider nur rudimentaer ;(>>> könntest du die Änderung am>> Treiber auch selber vornehmen und dann einen Diff Patch dem>> Treiberentwickler schicken.>> Das waere fuer mich Koenigsklasse und uebersteigt leider meine> Moeglichkeiten.>> Wie gesagt ich schau nun erstmal, ob die angelegte rc.local brav> jedesmal beim Start von systemctl bearbeitet wird.> Falls es da hakt, muss ich ja sowieso wieder ran.
Kein Problem.
Es gibt für Nutzer im Prinzip zwei Möglichkeiten sich direkt an die
Kernelentwickler zu wenden.
Einmal über die Mailingliste des entsprechenden Kernel Subsystems und
das andere über das Bugreport System:
https://bugzilla.kernel.org/
Lies dazu am besten mal folgenden Artikel für weitere Details durch:
https://kernelnewbies.org/FoundBug
Es genügt im Prinzip, wenn du als Nutzer die Treiberentwickler
informierst, gesetzt den Fall es ist wirklich ein Treiberproblem im
Kernel, was die dir aber schnell sagen werden können.
Es direkt am Ursprung reparieren zu lassen hat zwei wesentliche
Vorteile:
1. Du wirst von dem Bug, sofern es keinen Rückfall gibt, in zukünftigen
Kernelversionen verschont bleiben. Bis das in den Distris ankommt,
dauert das natürlich etwas, wie Rolf M. bereits richtig anmerkte, bis
dahin kannst du aber deine Skriptlösung als Workaround verwenden.
2. Andere werden von einem gefixten Treiber auch profitieren. Manche
Nutzer können sich nämlich auch nicht mit einem einfachen Skript
aushelfen, die sind darauf angewiesen, das das einfach funktioniert.
Eine andere Möglichkeit wäre, wenn du dich erst einmal an das Bug Report
System deiner Distribution wendest.
Da wird das gegebenenfalls nach oben weitergereicht. Anderseits ist es
dort aber auch möglich, dass sich keiner darum kümmert und es untergeht.
Der Vorteil ist aber, dass hier das Problem schon im Vorfeld dem
entsprechenden Stück Software (Kernel, Lib usw.), das dafür
verantwortlich ist, zugewiesen werden dürfte und somit eine
Vorsortierung stattfindet. Vielleicht hat diesen Bug schon jemand
gemeldet, dann könntest du dich an den alten Bugreport anhängen.
Manchmal stehen da nützliche Tipps.
Johannes U. schrieb:> Nichts leichter als das:$ -rw-r--r-- 1 root root 4,0K Apr 29 22:38> /sys/devices/platform/i8042/serio1/serio2/drift_time> $ sudo echo 15 > /sys/devices/platform/i8042/serio1/serio2/drift_time> $ bash: /sys/devices/platform/i8042/serio1/serio2/drift_time: Keine> Berechtigung
Hier wird "echo 15" als root ausgeführt. Die Umleitung der Ausgabe in
das File wird aber nicht durch echo, sondern durch die Shell ausgeführt
und damit nicht als root. Deswegen startet die Fehlermeldung auch mit
"bash:".
> $ su root>> ... und siehe da, nun KANN root den Befehl mit echo schreiben..
In dem Fall wird die Shell von root ausgeführt und damit auch die
Umleitung.
Grundsätzlich hat 'pong' glaub ich recht, es sollten solche
Parametrierung über die X11-config für das input-device gemacht werden,
anstatt über die Filesystem-Schnittstelle den Geräte-Treiber zu
verändern.
Kann nämlich auch sein, dass dein rc.local vielleicht ausgeführt wird,
danach aber beim Start von X bzw welchem
WindowManager/DesktopEnvironment auch immer das dann wieder überbügelt
wird.
https://www.thinkwiki.org/wiki/How_to_configure_the_TrackPoint
Ansonsten wäre glaube ich der richtige Weg, Treiber zu parametrieren,
beim Booten mit Grub die Kernel-Commandline anzupassen und den Parameter
da mit reinzugeben:
https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html
Nano schrieb:> Johannes U. schrieb:>> Nano schrieb:>>> Falls du selber programmieren kannst,>>>> Leider nur rudimentaer ;(>>>>> könntest du die Änderung am>>> Treiber auch selber vornehmen und dann einen Diff Patch dem>>> Treiberentwickler schicken.>>>> Das waere fuer mich Koenigsklasse und uebersteigt leider meine>> Moeglichkeiten.>>>> Wie gesagt ich schau nun erstmal, ob die angelegte rc.local brav>> jedesmal beim Start von systemctl bearbeitet wird.>> Falls es da hakt, muss ich ja sowieso wieder ran.>> Kein Problem.>> Es gibt für Nutzer im Prinzip zwei Möglichkeiten sich direkt an die> Kernelentwickler zu wenden.> Einmal über die Mailingliste des entsprechenden Kernel Subsystems und> das andere über das Bugreport System:> https://bugzilla.kernel.org/>> Lies dazu am besten mal folgenden Artikel für weitere Details durch:> https://kernelnewbies.org/FoundBug
Werde ich mir mal bei Gelegenheit zu Gemuete fuehren, danke.
> Es genügt im Prinzip, wenn du als Nutzer die Treiberentwickler> informierst, gesetzt den Fall es ist wirklich ein Treiberproblem im> Kernel, was die dir aber schnell sagen werden können.
Naja, wenn die nix besseres zu tun haben, vermute ich mal so.
Ich finde es immer problematisch, wenn ich nur sagen kann: 'Da ist ein
Problem' ich habe aber nicht das Wissen es an einer bestimmten
Komponente festzunageln.
Ich wuerde eigentlich stets von mir selber verlangen, so wie ich es als
gute Praxis aus diversen Foren kenne, erstmal zu demonstrieren, dass ich
unternommen habe was moeglich ist, um der Sache auf den Grund zu kommen.
> Es direkt am Ursprung reparieren zu lassen hat zwei wesentliche> Vorteile:> 1. Du wirst von dem Bug, sofern es keinen Rückfall gibt, in zukünftigen> Kernelversionen verschont bleiben. Bis das in den Distris ankommt,> dauert das natürlich etwas, wie Rolf M. bereits richtig anmerkte, bis> dahin kannst du aber deine Skriptlösung als Workaround verwenden.>> 2. Andere werden von einem gefixten Treiber auch profitieren. Manche> Nutzer können sich nämlich auch nicht mit einem einfachen Skript> aushelfen, die sind darauf angewiesen, das das einfach funktioniert.
Latuernich.
Am Ursprung fixxen ist stets die praeferierte Vorgehensweise.
Es ist aber auch so, dass ich natuerlich nicht weiss, ob diese
Einstellung nicht fuer die grosse Mehrzahl von Trackpoints (andere
Thinkpadmodelle, Dell-Geraete) ok ist...
Dann waere es kein generelles 'kaputt' sondern einfach nur ein Problem
das einen Teil der Trackpoints betrifft.
Ausgesprochen viel finde ich zu der Sache ja auch nicht im Netz, da ist
dieser von mir verlinkte 2 Jahre alte Redditthread und die Beschreibung
im archwiki, wobei der TO von Reddit mit Sicherheit auch das archwiki
dahingehend bearbeitet hat.
Viel mehr gibt es dazu jedoch nicht.
Im Gegensatz dazu fanden sich schon deutlich mehr Beschwerden zu den
auch von mir erwaehnten Defaultbeschleunigungswerten von libinput, die
aber auch nicht nur den Trackpoint betreffen, sondern auch das Touchpad.
Nun ist das Touchpad bei mir abgeschaltet, denn seit ich Trackpoints
habe bekomme ich bei Touchpads ne Krise, nicht so schlimm wie bei
Maeusen, aber ich mag beides nicht benutzen.
Bei Vielen ist es nicht so, das habe ich immer wieder erlebt.
So mag es sein, dass durchaus viel mehr Trackpoints von der Einstellung
in
betroffen sind, die Nutzer der Geraete dies aber nie feststellen, weil
der Trackpoint nicht verwendet wird..
Das jemand mit Linux den Trackpoint benutzen moechte, den dann aufgrund
der willkuerlichen Bewegungen unbenutzbar findet, dann einfach sang- und
klanglos zu Maus oder Touchpad wechselt und den Trackpoint links liegen
laesst, kann ich mir eher nicht vorstellen.
Aber wer weiss?
Ja, ich kenne auch Linuxnutzer, die an den einfachsten Problemen
scheitern und auch offensichtlich nicht willens oder in der Lage sind,
sich in den Weiten des Netzes schlau zu machen, das gibts auch.
> Eine andere Möglichkeit wäre, wenn du dich erst einmal an das Bug Report> System deiner Distribution wendest.> Da wird das gegebenenfalls nach oben weitergereicht. Anderseits ist es> dort aber auch möglich, dass sich keiner darum kümmert und es untergeht.> Der Vorteil ist aber, dass hier das Problem schon im Vorfeld dem> entsprechenden Stück Software (Kernel, Lib usw.), das dafür> verantwortlich ist, zugewiesen werden dürfte und somit eine> Vorsortierung stattfindet. Vielleicht hat diesen Bug schon jemand> gemeldet, dann könntest du dich an den alten Bugreport anhängen.> Manchmal stehen da nützliche Tipps.
Wie geschrieben:
Bis jetzt habe ich lediglich die Fundstelle bei Reddit und jene vom
gleichen Autor im Archwiki, wahrscheinlich beides 2 Jahre alt.
Nix in irgendeiner Debianquelle oder bei Mint oder in irgendwelchen
Ubuntuforen...
Andererseits sehe ich auch immer wieder bezueglich anderer
Treiberprobleme, dass diesbezueglich Bugreports uralt sind, die dort
beschriebenen Fehler aber nachwievor vorhanden sind..
So zuletzt imho bei einem WLAN Problem bei der Authentifizierung.
Aus dem Gedaechtnis (war nicht meine Hardware und ich hatte das Problem
auch nicht, habs nur fuer jemanden, der das selber nicht konnte gefixxt)
hatte es mit einer Aenderung in NetworkManager bezueglich randomisierter
MAC-Adressen zu tun.
Man bekam einmal kurz Verbindung, es kam aber kein Traffic und dann gabs
ein Disconnect, also: Kein Netzwerk fuer Dich!
Da gab es eine sehr sehr grosse Schar von Nutzern, die darueber klagten
und dies ueber einen langen Zeitraum, soweit ich es in Erinnerung habe,
wurde es jedoch nie an der Quelle gefixxt..
Naja, den kann ich mir jetzt irgendwie nicht richtig verkneifen, den der
NetworkManager hat mich lange Jahre bei meinem UMTS-Stick zur Weissglut
getrieben:
Der Networkmanager kommt von Poettering, da darf man einfach nicht
erwarten, das Bugreports, wenn ueberhaupt, zeitnah auch nur zur Kenntnis
genommen werden.
Johannes U. schrieb:>> Es genügt im Prinzip, wenn du als Nutzer die Treiberentwickler>> informierst, gesetzt den Fall es ist wirklich ein Treiberproblem im>> Kernel, was die dir aber schnell sagen werden können.>> Naja, wenn die nix besseres zu tun haben, vermute ich mal so.
Jeder Kernelentwickler hat sein Zuständigkeitsgebiet. Der eine kümmert
sich um den Netzwerkstack, der andere um dieses oder jenes Dateisystem
und wiederum andere haben sich auf bestimmte Treiber spezialisiert.
> Ich finde es immer problematisch, wenn ich nur sagen kann: 'Da ist ein> Problem' ich habe aber nicht das Wissen es an einer bestimmten> Komponente festzunageln.
Wenn du aber weißt, wie du das Problem auf Userebene entschärfst, siehe
dein Eingangsposting, dann ist schon einmal mehr als genug.
Bedenke bitte, dass die Treiberentwickler nicht alle HW zur Verfügung
haben und daher auf solche Rückmeldungen angewiesen sind.
Viele Treiber orientieren sich bspw. am Chipsatz, also werden für einen
bestimmten Chipsatz geschrieben. Dieser Chipsatz wird dann von mehreren
Hardwarehersteller verwendet und daraus verschiedene Produkte (a, b, c,
d, e usw.).
Und ein Produkt kann mehr Macken haben als ein anderes und ein
Treiberentwickler hat daraus vielleicht nur ein einziges Produkt (z.b.
c), den Treiber kann er darauf optimieren. Ob die anderen Produkte (a,
b, e) oder deines (z.B. d) mit diesem Treiber dann gut funktionieren
kann sein, muss aber nicht, er weiß es aber nicht. Daher ist er auf
deine Rückmeldung angewiesen, da du bspw. Produkt d hast.
Dann kann man mit der USB ID oder PCI ID, je nachdem ob das ein USB oder
PCI Gerät ist im Treiber Anpassungen machen, die den Bug in deinem
Produkt d dann speziell behandeln.
> Ich wuerde eigentlich stets von mir selber verlangen, so wie ich es als> gute Praxis aus diversen Foren kenne, erstmal zu demonstrieren, dass ich> unternommen habe was moeglich ist, um der Sache auf den Grund zu kommen.
Klar. Es ist natürlich immer besser, wenn du das Problem selber
möglichst gut eingrenzen kannst.
> Es ist aber auch so, dass ich natuerlich nicht weiss, ob diese> Einstellung nicht fuer die grosse Mehrzahl von Trackpoints (andere> Thinkpadmodelle, Dell-Geraete) ok ist...
Deswegen gibt es ja die PCI ID bzw. USB ID.
Jeder Hersteller hat da eine eigene zugewiesen und der wiederum kann
eine Sub ID dann für ein bestimmtes Produkt verwenden.
Deswegen kann man einen Treiber so anpassen, dass er genau für dieses
Produkt sich speziell verhält und bei den anderen wiederum nicht.
Insofern wird diese Einstellung bzw. Codeanpassung die große Mehrzahl
anderer Trackpoints, Thinkpadmodelle usw. nicht beeinflussen, da sie
durch die PCI ID bzw. USB ID modellspezifisch ist.
Siehe:
https://pci-ids.ucw.cz/> Dann waere es kein generelles 'kaputt' sondern einfach nur ein Problem> das einen Teil der Trackpoints betrifft.
Das ist wie schon gesagt kein Problem.
Probleme entstehen erst, wenn verschiedene Geräte die gleiche ID
verwenden.
Das kommt gelegentlich bei China Produkten vor, ist bei gescheiter
Hardware aber eher unüblich.
> Nun ist das Touchpad bei mir abgeschaltet, denn seit ich Trackpoints> habe bekomme ich bei Touchpads ne Krise, nicht so schlimm wie bei> Maeusen, aber ich mag beides nicht benutzen.
Ich kann dich gut verstehen. Ich habe an meinem NB immer eine Maus
angeschlossen und das Touchpad schalte ich dann ab, da ich beim Tippen
ansonst immer mit dem Handballen auf das Touchpad kommen würde und das
sehr nervig sein kann.
Das Touchpad nutze ich nur im absoluten Notfall, wenn ich gerade keine
Zeit habe eine Maus anzuschließen und ich das NB nur mal kurz brauche.
> Andererseits sehe ich auch immer wieder bezueglich anderer> Treiberprobleme, dass diesbezueglich Bugreports uralt sind, die dort> beschriebenen Fehler aber nachwievor vorhanden sind..
Das passiert, wenn die Fehler nicht direkt an der Quelle behoben werden
und die Kernelentwickler nichts von den Bugreports in den Distris
erfahren oder schlichtweg die Zeit fehlt, dass sich einer darum kümmert.
Thread beobachten
Seitenaufteilung abschalten