# Merkwürdiges Verhalten des X-Maustreibers

## TheSmallOne

Hallo, mir ist heute etwas merkwürdiges in meinem Xorg.0.log aufgefallen.

Und zwar geht es um folgende Zeilen:

```
(WW) Hauptmaus: No Device specified, looking for one...

(II) Hauptmaus: Setting Device option to "/dev/input/mice"

(--) Hauptmaus: Device: "/dev/input/mice"
```

Der Treiber behaupted also er hätte keinen Wert für das Device gefunden und verwendet deshalb /dev/input/mice.

Aber in der /etc/X11/xorg.conf sieht der betreffende Abschnitt so aus:

```
Section "InputDevice"

        Identifier      "Hauptmaus"

        Driver  "mouse"

        Option  "Device"        "/dev/input/mouse0"

        Option  "Protocol"      "IMPS/2"

        Option  "Emulate3Buttons"       "no"

        Option  "ZAxisMapping"  "4 5"

        Option  "Buttons"       "6"

EndSection
```

Es ist also definitiv eine Option für Device angegeben; die betreffende Gerätedatei ist auch existent.

Was ich jetzt nicht verstehe ist: Wieso diese Fehlermeldung?

Zugegeben der Fehler ist nicht weiter tragisch und ich arbeite vermutlich schon eine ganze Weile ungestört mit diesem Zustand, aber ich würde irgendwie dennoch gerne verstehen, wo hier eigentlich der Fehler liegt. Irgendwelche Ideen?

----------

## Christian99

 *TheSmallOne wrote:*   

> Irgendwelche Ideen?

 

Wie siehts denn aus, wenn du als device "/dev/input/mice" ind die xorg.conf schreibst?

----------

## ChrisJumper

Ich weiß ja nicht welchen X-Server du verwendest. Seit 1.8 gab es diese Hal-Kombination mit den fdi-Files. Seit 1.9 muss man das ganze in Dateien schreiben die in einem Verzeichnis Liegen das so heißt: /etc/X11/xorg.conf.d/

In die normale xorg.conf Datei schaut ein aktueller Xserver nicht mehr rein. Er verwendet dann automatische Einstellungen.

----------

## Josef.95

 *ChrisJumper wrote:*   

> Ich weiß ja nicht welchen X-Server du verwendest. Seit 1.8 gab es diese Hal-Kombination mit den fdi-Files. Seit 1.9 muss man das ganze in Dateien schreiben die in einem Verzeichnis Liegen das so heißt: /etc/X11/xorg.conf.d/
> 
> In die normale xorg.conf Datei schaut ein aktueller Xserver nicht mehr rein. Er verwendet dann automatische Einstellungen.

 

Hi Chris

Sorry, da muss ich ein kleines Veto einlegen... :Wink: 

Die xorg.conf war und ist immer noch die Hauptkonfigurations-Datei für X, und das wird auch hoffentlich immer so bleiben. Der X-Server schaut da mit als erstes nach.

Ab ca. xorg-server-1.5 konnte man ja HAL für die Eingabegeräte nutzen (das war aber optional), hatte man xorg-server mit HAL Unterstützung gebaut dann wurden die Eingabegeräte via hottplugging an HAL weitergereicht und man konnte  sie in den berüchtigten fdi-Files abweichend vom default konfigurieren.

Hatte man keine HAL Unterstützung eingebaut, dann wurden die Eingabegeräte normal in der xorg.conf konfiguriert.

Dann ab xorg-server-1.8 kam die Unterstützung von udev (das ist auch optional) und es gibt die Möglichkeit die Eingabegeräte wie gewohnt  in der xorg.conf zu konfigurieren. Nutzt man nicht das Hotplugging via udev dann wird normal das angewendet was in

Section "InputDevice"

definiert ist.

Nutzt man doch das Hotplugging, dann wird die Konfiguration aus

Section "InputClass"

verwendet, und alles andere aus Section "InputDevice" schlicht ignoriert. (ja auch wenn sie da sind)

Ob man nun die Section "InputClass" in einzelnen Dateien unter /etc/X11/xorg.conf.d/ ablegt ist ebenfalls optional, man kann sie nutzen, man muss aber nicht. Section "InputClass" kann auch direkt in der xorg.conf gesetzt werden.

Nutzt man beides, also /etc/X11/xorg.conf.d/Dateien und eine xorg.conf, dann hat die xorg.conf stets das letzte Wort  :Smile: 

Sprich die gute alte xorg.conf ist noch lange nicht tot!  :Smile:  Die Nutzung von xorg.conf.d/ (unter nutzung von Hotplugging via udev) ist optional.

.....................................................................................

@TheSmallOne

Dein 

```
(WW) Hauptmaus: No Device specified, looking for one... 
```

 stammt vermutlich daher da du Section "InputDevice" gesetzt hast, aber vermutlich doch das Hotplugging über udev nutzt? (was aktuell Standard ist) , wenn ja, dann wird die gesamte Section "InputDevice" schlicht ignoriert.

Ich würde vorschlagen Section "InputClass" draus zu machen und statt des "mouse" Treibers besser den "evdev" Treiber zu verwenden.

Schau zb auch noch mal im Xorg-server 1.8 Upgrade Guide

und auch in der "man xorg.conf"

Section "InputDevice" wird nur dann verwendet wenn man kein Hotplugging via udev nutzt, sprich die Eingabegeräte wirklich vom xorg-server selbst verwalten lässt.

----------

## TheSmallOne

 *Josef.95 wrote:*   

> @TheSmallOne
> 
> Dein 
> 
> ```
> ...

 

Da bin ich mir nicht so sicher. Wie kann man das prüfen?

Ich habe jedenfalls kein /etc/X11/xorg.conf.d/ Verzeichniss und in der xorg.conf steht nirgends was von "InputClass".

Zudem habe ich die Option 	"AutoAddDevices" "off" bei den Server Flags gesetzt und im Logfile Meldungen wie diese hier:

```
(II) config/udev: Adding input device Logitech USB-PS/2 Optical Mouse (/dev/input/mouse0)

(II) AutoAddDevices is off - not adding device.
```

Hinzu kommt, dass die Option "Device" scheinbar als einziges aus der betreffenden "InputDevice"-Section ignoriert wird; die ebenfalls vorhandenen Werte für "ZAxisMapping", "Emulate3Buttons" usw. werden offenbar korrekt verarbeitet.

 *Quote:*   

> Ich würde vorschlagen Section "InputClass" draus zu machen und statt des "mouse" Treibers besser den "evdev" Treiber zu verwenden.
> 
> Schau zb auch noch mal im Xorg-server 1.8 Upgrade Guide
> 
> und auch in der "man xorg.conf"

 

Ich habe mal Testweise aus "InputDevice" ein "InputClass" gemacht, mit dem Resultat, dass der X-Server nicht mehr starten wollte, weil das Eingabegerät angeblich nicht definiert war.

----------

## Max Steel

Wenn du die InputClass verwendest musst du AutoAddDevices auf on schalten.

----------

## Josef.95

 *Max Steel wrote:*   

> Wenn du die InputClass verwendest musst du AutoAddDevices auf on schalten.

 

Das muss man normal nicht explizit setzen wenn man Xorg mit udev verwendet, es wird schon als default verwendet.

Sprich man müsste es nur setzen wenn man es explizit deaktivieren möchte.

----------

## Max Steel

 *Josef.95 wrote:*   

> Das muss man normal nicht explizit setzen wenn man Xorg mit udev verwendet, es wird schon als default verwendet.
> 
> Sprich man müsste es nur setzen wenn man es explizit deaktivieren möchte.

 

Richtig, aber TheSmallOne hats explizit abgeschaltet.

Zumindest laut seinen eigenen Beitrag paar Zeilen weiter oben.

----------

## Josef.95

 *Max Steel wrote:*   

>  *Josef.95 wrote:*   Das muss man normal nicht explizit setzen wenn man Xorg mit udev verwendet, es wird schon als default verwendet.
> 
> Sprich man müsste es nur setzen wenn man es explizit deaktivieren möchte. 
> 
> Richtig, aber TheSmallOne hats explizit abgeschaltet.
> ...

 

Ahhrg, ja sorry, ich hatte den in der Zwischenzeit hinzugekommenen Beitrag von TheSmallOne schlicht übersehen...  :Embarassed: 

----------

## Josef.95

 *TheSmallOne wrote:*   

> ......
> 
>  *Quote:*   Ich würde vorschlagen Section "InputClass" draus zu machen und statt des "mouse" Treibers besser den "evdev" Treiber zu verwenden.
> 
> Schau zb auch noch mal im Xorg-server 1.8 Upgrade Guide
> ...

 

Ja das ist schon richtig, beachte das wenn du das hotplugging wieder anschaltest (bzw nicht deaktivierst) und Section "InputClass draus machst, das dann auch die Zeilen  aus der Section "ServerLayout" für das Eingabegerät entfernt oder einkommentiert werden muss.

----------

## ChrisJumper

 *Quote:*   

> Sprich die gute alte xorg.conf ist noch lange nicht tot! :) Die Nutzung von xorg.conf.d/ (unter nutzung von Hotplugging via udev) ist optional.

 

Sehr interessant! Ich hatte das in meinem letzten Post so sicher behauptet weil eben nach dem X-Server update auf 1.9 meine vorhandene xorg.conf komplett ignoriert wurde. Nach dem erstellen der Datein in xorg.conf.d hat es problemlos geklappt.

Anbei: Unter Ubuntu 10.x hatte ich ähnliche Erfahrungen, das eine Section für die Grafikkarte ignoriert wurde. Dort kann es aber auch ein Bug gewesen sein, weil dort alles verfügbare geladen wurde.

----------

