Tochpad deaktivieren

H

hokuspokus

Well-Known Member
Hallo Leute

Mich stört das Tochpad auf meinem Dell Notebook. Beim Surfen oder Spielen drück ich oft ungewollt mit dem Handballen auf das Pad.
Ich benutzte natürlich nur die Maus, Tochpad hab ich noch nie benutzt.
Kann man das irgendwie deaktivieren . Bios oder sogar über X server ?
 
im Grunde genommen solltest du ja wissen, wie du es überhaupt eingerichtet und zum Laufen gebracht hattest. Es gibt da mehrere Möglichkeiten.
Hauptsächlich sind Mausgeräte unter X eingerichtet, wenn sie auch auf der Konsole funktionieren, wird das nicht unbedingt an X weitergereicht und es sollte in deinem Falle genügen, es in X zu deaktivieren.
Es kann in einer xorg.conf eingerichtet sein (von dir selbst oder durch einen Automagismus) oder es kann von Hal und Dbus an X weitergeleitet werden. Dann gelten die Policities zu dem Gerät.
Du musst deinen Weg finden, also wie du es bei dir eingerichtet hast und dann entsprechend einfach den Eintrag für das gerät löschen oder auskommentieren.
Das sollte genügen.
 
Das Touchpad ist bei mir intern noch über PS2 angebunden. Wenn du sysmouse verwendest musst du einfach nur moused_enable in der rc.conf abschalten. Auf USB hat das, glaube ich, keinen Einfluss.
 
hokuspokus schrieb:
Ja aber leider braucht ja xorg keine xorg.conf mehr. Sonst könnte man sowas hier probieren
http://www.heise.de/ct/hotline/Touchpad-unter-X11-abschalten-323014.html

Was nun?
Zum Vergrößern anklicken....

es braucht keine xorg.conf mehr, aber du kannst ja trotzdem eine benutzen, wenn du das möchtest. Ich selbst habe das immer so gemacht, irgendwann wollte ich etwas, das ich einfach in der xorg.conf machen konnte, ohne lange suchen zu müssen.
Für dich ist nun interessant, es tatsächlich über die Polycities zu versuchen.
Du kannst hier zahlreiche Beiträge finden, die dich sinngemäß weiter bringen (also nicht genau dein Thema treffen, aber den Weg weisen). Ich glaube sogar, dass im Handbuch dazu etwas beschrieben steht.

Derzeit habe ich keinen FreeBSD-Rechner dabei und kann das nicht einfach nachsehen, wie diese Policies heißen und wo sie stehen.
Sieh mal hier:
http://www.freebsd.org/doc/de/books/handbook/x-config.html
 
hokuspokus schrieb:
Was stört dich denn an hald ?
Zum Vergrößern anklicken....

vielleicht kann ich da vorgreifen, weil ich gerade diese Frage lese.

Für mich sieht es etwa so aus: warum denn noch einen Dienst?
Als ich zum allerersten Mal auf dem damals benutzten GNU/Linux und einem KDE nach dem Einstecken eines USB-Sticks ein Icon auf dem Desktop erscheinen sah, das den automatisch gemounteten Stick symbolisierte, da war ich total begeistert. Das war damals durch Scripts realisiert worden. Ausgewertet wurden Meldungen im /proc und von dmesg, nicht aber aus der /dev Struktur, zumindest nicht primär. Das alles hatte ich damals nicht recht verstanden und bilde mir auch nicht ein, es heute zu verstehen, aber Tatsache ist wohl, dass Linux seinem /dev nicht ganz trauen konnte, es war zu sehr mit diversen Ideen überladen.
Deshalb ersannen einige Leute eine Lösung, die unabhängig von der Plattform immer Geräte und ihre Eigenschaften zuverlässig erkennen könnte und diese Daten an weitere Helfer leiten, um dann benutzt werden zu können. HAL und DBUS sind hier zu nennen. Das ganze sollte auch einfach zu konfigurieren sein und die Idee hat durchaus was für sich, so dass schließlich Anwendungen außerhalb von Linux darauf setzten, etwa der X-Server.
FreeBSD hatte wohl nie die Probleme von Linux und statt dessen ein brauchbares devfs und somit wäre da kein solcher Dienst notwendig gewesen, aber er wird uns so natürlich quasi aufgedrückt. Allerdings geht es bislang in FreeBSD auch noch ohne HAL und das ist auch gut so, denn auf mancher HW produziert HAL ganz große Konfusion und führt deshalb mitunter zu Hängern.
Linux hat wohl (ich nutze es nicht und gebe das nur weiter) die Probleme inzwischen auch im Griff und mit udev eine Alternative, so dass es ebenfalls auf HAL verzichten kann.

Wir haben somit einen Dienst, der uns durch Unzulänglichkeiten von Linux aufgezwungen wurde und den nun eigentlich niemand mehr braucht.

Es ist ein unglaublich unverhältnismäßiger Aufwand betrieben, um ein minimales Ergebnis zu erzielen, denn bloß um eine Maus oder ein Keyboard zu konfigurieren oder gesteckte USB-Sticks zu erkennen, ist dieser Dienst vollkommen überdimensioniert. Er kann oder könnte die komplette HW des Systems abstrahieren und darstellen und aktualisieren. Das macht natürlich der Kernel schon selbst, aber HAL kann das eben auf Linux oder FreeBSD oder Solaris und unabhängig vom Kernel.

Nun haben wohl einige der großen DesktopEnvironments inzwischen auch eigene Mechanismen an Bord und verlassen sich nicht mehr ausschließlich auf HAL und lauschen auch nicht mehr nur auf die Kernel-Meldungen. Dann haben wir also sogar noch mehr Dienste, die alle eigentlich gar keinen Sinn machen und kaum was bringen. Deshalb möchte ich selbst auch nicht mehr mit KDE4, weil ich das alles für zu sehr aufgeblasen halte.

Natürlich kann jemand fragen, na und?
Mein PC hat doch ausreichend Ressourcen und kann doch getrost mehrere Dienste laufen lassen, auch, wenn sie sich um die gleichen Dinge kümmern.
Wenn das so ist, dann ist das nur eine Frage des persönlichen Geschmacks und meinem Geschmack entspricht es nicht, unnötige und überflüssige Dinge auf meinem PC laufen zu lassen.
Es kann aber auch sein, dass solch eine Flut von Diensten zu argen Problemen führt, was Sicherheit und Stabilität anbelangt und wie schon erwähnt, gerade HAL und dbus sind dafür bekannt, dass sie nicht immer gut laufen.

Ich will das mal anders versuchen auszudrücken.
Wenn ich Hal und dbus nur dazu brauche, um meinen X-Server automatisch beim Systemstart jedes mal einzurichten und dann und wann einen eingesteckten Stick automatisch zum Mounten zu bringen, dann sind das Dinge, die ich mit wenigen Zeilen manueller Befehle einfach erledigen kann. Die GraKa wird nicht dauernd wechseln, ich kann also auch mit einer festen xorg.conf komfortabel leben und ein Stick, nunja, der ist ja auch mit drei Zeilen eingebunden. Lasse ich das von Hal und Konsorten erledigen, dann habe ich tausende Zeilen von Code aktiv, nur um die paar Kinkerlitzchen zu erledigen.
Wie gesagt: HAL ist größer angelegt, der könnte viel mehr, aber das, wofür wir ihn meist benutzen, ist einfach und klein.
Für mich macht das wenig Sinn.

Zumindest kann darüber nachgedacht werden, ob man das wirklich möchte.
 
hokuspokus schrieb:
Was stört dich denn an hald ?
Zum Vergrößern anklicken....
Da muss ich jetzt einfach auch mal meinen Senf verteilen.

Erst mal historisch, die Einführung von hald hat bei FreeBSD bei vielen Leuten zu allerlei bizarren Problemen geführt. Zum Beispiel, dass X vollkommen einfriert, es sei denn die Maus ist in Bewegung. Stell dir vor du müsstest immer mit der Maus wackeln, damit deine Programme reagieren. Das war auf allen meinen Rechnern so. Mag sein, dass das inzwischen alles geht und hald zuverlässig funktioniert.

Bevor X von hald abhängig wurde hat das einfach überall funktioniert. Abstraktionsschichten führt man normalerweise ein um Sachen portabler zu machen. Hald hat aber rundum Portabilität verschlechtert.

Ganz abgesehen davon, dass die Umsetzung schlecht ist, ist das technische Prinzip auf dem hald basiert einfach schlecht für den Anwendungsfall. Hald macht polling, überwacht alle möglichen Stellen deines Systems um zu entdecken ob sich etwas ändert. Das kostet a) Rechenzeit ob etwas passiert oder nicht und b) ist es prinzipiell unzuverlässig (Polling ist meiner Meinung etwas für Echtzeitanwendungen oder Ereignisse ohne serielle Abhängigkeiten, also wenn immer nur der neuste Zustand interessiert und was vorher war egal ist). Denn schnelle Ereignisse verpasst so ein System einfach, oder noch schlimmer, bekommt es nur teilweise mit.

Unter FreeBSD könntest du aber stattdessen einfach an /var/run/devd.pipe lauschen. Dann wirst du vom Kernel zuverlässig, ohne Risiko etwas zu verpassen, in der richtigen Reihenfolge über alle Zustandsänderungen informiert. Und während dein Prozess lauscht schläft der und verbraucht keinerlei Rechenleistung. Erst wenn eine Botschaft anliegt wird Dein Prozess von Scheduler geweckt.
 
Kamikaze schrieb:
Da muss ich jetzt einfach auch mal meinen Senf verteilen.

Erst mal historisch, die Einführung von hald hat bei FreeBSD bei vielen Leuten zu allerlei bizarren Problemen geführt. Zum Beispiel, dass X vollkommen einfriert, es sei denn die Maus ist in Bewegung. Stell dir vor du müsstest immer mit der Maus wackeln, damit deine Programme reagieren. Das war auf allen meinen Rechnern so. Mag sein, dass das inzwischen alles geht und hald zuverlässig funktioniert.

Bevor X von hald abhängig wurde hat das einfach überall funktioniert. Abstraktionsschichten führt man normalerweise ein um Sachen portabler zu machen. Hald hat aber rundum Portabilität verschlechtert.

Ganz abgesehen davon, dass die Umsetzung schlecht ist, ist das technische Prinzip auf dem hald basiert einfach schlecht für den Anwendungsfall. Hald macht polling, überwacht alle möglichen Stellen deines Systems um zu entdecken ob sich etwas ändert. Das kostet a) Rechenzeit ob etwas passiert oder nicht und b) ist es prinzipiell unzuverlässig (Polling ist meiner Meinung etwas für Echtzeitanwendungen oder Ereignisse ohne serielle Abhängigkeiten, also wenn immer nur der neuste Zustand interessiert und was vorher war egal ist). Denn schnelle Ereignisse verpasst so ein System einfach, oder noch schlimmer, bekommt es nur teilweise mit.

Unter FreeBSD könntest du aber stattdessen einfach an /var/run/devd.pipe lauschen. Dann wirst du vom Kernel zuverlässig, ohne Risiko etwas zu verpassen, in der richtigen Reihenfolge über alle Zustandsänderungen informiert. Und während dein Prozess lauscht schläft der und verbraucht keinerlei Rechenleistung. Erst wenn eine Botschaft anliegt wird Dein Prozess von Scheduler geweckt.
Zum Vergrößern anklicken....

und es funktioniert schließlich auf keinem System wirklich umfassend, wie von den Entwicklern vielleicht mal gedacht. Bei allen Systemen, wo ich es mir mal kurz angesehen habe, wird immer nur ganz begrenzt auf HAL gesetzt. Fast immer wird der Dienst extrem beschnitten und kaum eine der vorbelegten Konfigurationen tatsächlich genutzt.
Auf HAL zu setzen, das war ein Schnellschuss aus dem Linux-Lager und der war schon damals im Grunde genommen vollkommen irrsinnig und unverständlich. Einige Distros haben das wohl durchgeboxt.

Als Xorg darauf setzte, war ich wirklich enttäuscht.


Das mit dem Pollen solltest du vielleicht genauer erklären.
Oder ich versuche es mal: durch Pollen werden bekannte Teilnehmer an einem bestimmten Daten-Bus angesprochen. Bei Hal ist dbus das Bus-System. Wenn ich die Teilnehmer kenne, kann ich die nach Priorität immer wieder fragen, ob es ihnen gut geht und kann auch sehen, ob es da Aktion gibt, nachdem ich ihre Antwort gesehen und ausgewertet habe. Gibt es tatsächlich mal Aktion, was aller aller meist bei uns nicht der Fall ist, dann kann Hal aus den Polkits lesen, was er da für Maßnahmen durchführen oder einleiten soll.
Ein Problem ist nun, dass dieser Bus nicht wirklich auf die HW sehen kann, sondern vollkommen unterschiedliche System-Meldungen auswertet. Vollkommen unterschiedlich, weil eben Linux und FreeBSD und Solaris und was immer auch vollkommen unterschiedlich sind.
Nun etablier da mal einen Polling-Mechanismus, wenn die HW dir nicht gehört!
Und, wenn du dann auch Änderungen an der HW damit überwachen willst! Stell dir vor, wie viele Stellen du da dauernd abfragen musst, um die komplette HW zu erfassen.
Und, wenn du das nicht nur lesen willst, sondern an vollkommen unterschiedliche Helferlein dein Ergebnis und die benötigte Aktion übermitteln musst.

Das ist von Anfang an Murks gewesen und hätte auch von Linux damals nicht genommen werden sollen. Weil die noch nichts besseres hatten, haben sie es uns allen aufgezwungen. Und weil das einige Jahre der (manchmal unerwünschte) Standard wurde, ist es so unglaublich ausgebaut und erweitert worden, anstatt es gleich als unsinnige Übergangslösung zu kennzeichnen und genau so klein und billig zu nutzen, wie es damals gewesen ist.

Ganz sicher bin ich kein Unix Guru und meine eigenen Gedanken weichen oft von dem ab, was allgemein aus gutem Grund etabliert wurde. So war das auch mit Hal, das ich von Anfang an nicht mochte und stets kritisierte und im Unterschied zu vielem anderen, bin ich über die Jahre meiner Kritik mit gutem Gewissen treu geblieben. Hal ist Mist und die Umsetzung unnötig kompliziert und fast nicht zu durchschauen.
Wenn es funktioniert und läuft, widert es mich trotzdem an und ich mag es nicht. Manchmal nutze ich es, auf meinem derzeitigen (inzwischen veralteten) Haupt-Rechner habe ich es laufen und beobachte es, aber ich mag es nie und kann es nicht leiden. Schlimmer noch: es läuft dauernd und ich nutze es fast nie! Für nix!
Einen Fehler zu finden und zu isolieren und schließlich vielleicht zu beheben ist mehr, als ein abendfüllendes Programm. Es ist sehr viel einfacher, einen Stick manuell zu mounten, als Hal zu so etwas zu überreden (ok, Hal mountet nicht selbst, er leitet nur die Information weiter, aber meist scheitern automatische mounts wegen falscher policies für Hal).

Ich bleibe dabei, dass es gewissermaßen Geschmackssache ist, ob jemand Hal nutzen möchte oder nicht, zumindest dann, wenn seine HW ihn nicht zwingt, darauf zu verzichten. Aber mein Geschmack ist es eindeutig nicht!
 
Die Sache ist doch nicht, dass die Idee hinter hald generell schlecht wäre. Es ist die Umsetzung. Wie Kamikaze schon angedeutet hat, hätte man hald einfach als das implementieren können, was der Name andeutet. Als "Abstraction Layer". In der Praxis dann also ein paar hundert Zeilen C-Code, die epoll (Linux), IOCP (SysV) und kqueue (BSD) auf eine generische API abstarhieren. Aber stattdessen hat man diesen Krampf gebaut, der meint alles selbst machen zu müssen. Aber diese Diskussion ist hinfällig, da hald de facto tot und vergessen ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben