Re: Maus wird erkannt - aber funktioniert nicht

On Mon, Feb 18, 2019 at 08:35:39AM +0100, Harold Gutch wrote:
> Hi,
>
> On Sun, Feb 17, 2019 at 04:15:23PM +0100, Polytropon wrote:
> > Natürlich kenne ich auch Geräte, wo erst ein ugen-Gerät auf-
> > taucht, es dann aber "konkret" wird, wie Du in Deinem Beispiel
> > gut belegt hast:
>
> Ich will jetzt nicht meine Hand dafür ins Feuer legen, aber von dem
> was ich in dmesg sehe scheint genau das der Normalfall zu sein, ich
> meine mich aber auch zu erinnern dass früher[tm] Geräte direkt ein
> spezifisches Device (z.B. umassX) zugewiesen bekamen ohne dass der
> "Umweg" über ugen(4) gegangen wurde. Möglicherweise ist letzteres der
> Fall wenn der Kernel schon das konkrete USB-Gerät unterstützt, sei es
> dass die Unterstützung statisch im Kernel ist oder als bereits
> geladenes Modul - nur wenn keines davon der Fall ist, dann wird eben
> erst ein ugen(4) Gerät zugewiesen, und das konkrete Device kommt dann
> wenn devd das entsprechende Modul nachlädt. Oder ich hab das
> schlichtweg falsch in Erinnerung.

Das war früher so, dass ugen nur dann binden konnte, wenn kein
anderer Treiber auf dem Gerät unterwegs war.
Mit dem derzeitigem USB-Stack ist die Hürde vorbei und es gibt immer
ein ugen, ähnlich wie pass bei SCSI Devices.

>
> > 1. Kann moused auch mit einem ugen-Gerät arbeiten, oder ist ein
> > ums-Gerät _zwingend_ notwendig? War jedenfalls bisher so mein
> > Eindruck.
>
> Letzteres - es ist nicht so dass das Gerät einfach nur an ums(4)
> "übergeben" wird, der Treiber verarbeitet die einkommenden Daten auch
> noch ein wenig bevor sie (z.B. an moused) weitergegeben werden, siehe
> auch usr/src/sys/dev/usb/input/ums.c .

Also normalerweise würde ich vermuten, dass die Maus einfach so mit
ums(4) läuft, vor allem weil es der Kennung nach eine einfache Maus ist.
Neben der Möglichkeit, dass die Maus einfach inkompatibel ist, gibt
es noch andere mögliche Ursachen.
So kann es z.B. sein, dass die Maus für den Betrieb mehr Strom will,
als der USB-Port liefern darf.
In dem Fall kann der Treiber das "Maus"-Interface nicht aktivieren.
Es ist auch denkbar, dass die Maus mehrere Betriebsarten hat, die man
ggfs. explizit mit "usbconfig set_config" aktivieren muss.
Einen solchen Befehl kann man per devd triggern.
Ist mir aber ehrlich gesagt alles 3 bislang noch nicht bei einer Maus
begegnet.

Wenn alle Stricke reissen kannst du es mit webcamd aus den Ports versuchen.
Das sind Linux-Kerneltreiber, die in einer Emulation im Userland laufen.
Lass dich nicht vom Namen irritieren, der macht inzwischen mehr als Kameras.
Leider kann die Latenz manchmal für bestimmte Geräte zu schlecht sein.
Für X muss das dabei erzeugte evdev Device dann allerdings meines Wissens
leider noch fix konfiguriert werden und vor dem Start existieren.
Section "InputDevice"
        Identifier "MS-Voodoo-Maus"
        Driver "evdev"
        Option "Device" "/dev/input/event0"
EndSection

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message