Re: Maus wird erkannt - aber funktioniert nicht

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.


> 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 .


> 2. Wie bewegt man, bei Erkennung eines ugen-Gerätes, das System
>    dazu, den ums-Treiber "zwangsweise" für dieses Gerät zu laden
>    bzw. zu laden versuchen - also quasi das, was sonst automatisch
>    erfolgt?

Naja, prinzipiell ist die Antwort "indem man die probe-Routine im
Treiber patcht". Für jedes neu angeschlossene USB-Gerät fragt der
Kernel alle USB-Treiber (umass(4), uhub(4), ums(4), ... - egal ob die
statisch im Kernel sind oder als Modul nachgeladen wurden), ob sie das
Gerät unterstützen. Bei PCI-Geräten ist das dann meistens so etwas wie
"ist die ID des Geräts in dieser Liste", bei USB so etwas wie "sagt
das Gerät von sich dass es eine Maus ist", also "sind die 3 Integers
Klasse/Subklasse/Protokoll so wie sie bei einer Maus sein sollen").
Wenn das nicht der Fall ist, sagt der Treiber eben "nö, ist nicht
meins". Siehe dazu auch die ums_probe()-Funktion in ums.c.

Aber die "normale" Antwort ist eher "das geht nicht" [ohne am
Quellcode herumzudoktorn]. Du kannst zwar devd sagen dass er (z.B.)
ums(4) laden soll wenn ein Scanner angeschlossen wird (das lässt sich
mit einem Editieren von /etc/devd/usb.conf erledigen), aber ums(4)
wird deshalb trotzdem nicht sich um das Gerät kümmern (wollen).


> Die Rechtfertigung für das Fragekonstrukt ist wieder eine
> individuelle Erkenntnis, bezogen auf Scanner: Da war einer,
> der erst einen ugen-, dann einen uscanner-Eintrag erzeugte,
> und dann einer, der _nur_ einen ugen-Eintrag erzeugte, aber
> beide liefen dann mit SANE. Bei Scannern scheint also beides
> möglich zu sein.

Es ist nicht komplett von der Hand zu weisen dass SANE im Prinzip die
Funktionalität des uscanner-Treibers auch mitliefert - zumindest in
dem Maße wie es zum Betrieb des Scanners nötig ist. Ich weiß jetzt
nicht sicher ob SANE das so macht, aber das ist für mich gerade die
beste Erklärung für das verhalten.


> > Wenn die Maus bei Heino nicht funktioniert, muss das andere Gründe
> > haben.
> 
> Richtig, so _sollte_ es sein, aber beim ugen-Eintrag "hängt"
> es. Ob es was bringt, einen anderen USB-Anschluß zu verwenden?
> Kann ich mir zwar nicht vorstellen, aber man kann ja nie so
> doof denken... ;-)

Naja, es würde vielleicht schon mal ein wenig helfen zu erfahren ob
der Kernel (nach Anstecken der Maus) ums(4) unterstützt und als was
die Maus sich meldet (ausgabe von "usbconfig", s. andere Mail).


Gruß,
  Harold


To Unsubscribe: send mail to [email protected]
with "unsubscribe de-bsd-questions" in the body of the message