Forum: PC Hard- und Software Linux: Aenderung in Systemdatei persistent machen?


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 Johannes U. (kampfradler)


Lesenswert?

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
1
/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..?!
Liess sich dann aber trotzdem mit der Aenderung als root in nano 
sichern, wo
1
echo $parameter > /sys/devices/platform/i8042/serio1/serio/drift_time
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?

von Hmmm (Gast)


Lesenswert?

/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

von Johannes U. (kampfradler)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Johannes U. (kampfradler)


Lesenswert?

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.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Lesenswert?

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.

: Bearbeitet durch User
von Johannes U. (kampfradler)


Lesenswert?

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:
1
$ -rw-r--r-- 1 root root 4,0K Apr 29 22:38 /sys/devices/platform/i8042/serio1/serio2/drift_time
1
$ sudo echo 15 >  /sys/devices/platform/i8042/serio1/serio2/drift_time
1
$ 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.

: Bearbeitet durch User
von pong (Gast)


Lesenswert?

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

von Fliegender Ziegenpeter (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von tut nix zur Sache (Gast)


Lesenswert?

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

von Norbert (Gast)


Lesenswert?

Welcher Treiber/welches module?
Herausfinden!
Dann:
1
# modinfo module
In den parms nach passendem Eintrag suchen.
In
1
/etc/modprobe.d/
 eine Datei anlegen und die Parameter hinterlegen.
Done.

von Johannes U. (kampfradler)


Lesenswert?

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
1
/sys/devices/platform/i8042/serio1/serio2/drift_time
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.

: Bearbeitet durch User
von usuru (Gast)


Lesenswert?

Johannes U. schrieb:
> Hab' mir jetzt mal eine /etc/rc.local angelegt - existiert auf lmde4
> nicht serienmaessig - den Befehl reingeschrieben und ausfuehrbar
> gemacht.

https://wiki.ubuntuusers.de/rc.local/

von Nano (Gast)


Lesenswert?

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.

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.

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