Re: Dell-Desktop USB-Tastaturproblem

On Mon, Aug 25, 2008 at 02:33:09PM +0200, Oliver Fromme wrote:
> Peter Ross wrote:
> Was passiert eigentlich, wenn Du die Tastatur abziehst und
> wieder ansteckst? Findet er sie dann wieder? Und hast Du
> mal versucht, den Tastaturmultiplexer (kbdmux) zu disablen?
> (Den braucht man eigentlich nur, wenn man mehrere Tastatu-
> ren gleichzeitig verwendet, z.B. eine PS/2 und eine USB.)
>
> > Weiß jemand zufälligerweise, wie weit der usb2_-Import gediehen ist? übers
> > Wochenende gab es wohl einige Zeiten, in denen der Code nicht einmal
> > kompilierte..
>
> Soviel ich weiß, wurde der Import noch nicht durchgeführt
> (es sei denn, ich hab's irgendwie verpasst). Mein letzter
> Stand ist, dass es in letzter Minute noch ein paar kleine
> Fragen bezüglich der Art und Weise des Imports gab. Ich
> gehe aber davon aus, dass es diese Woche über die Bühne
> geht.

Alfred schrieb zuletzt irgendwas von September.
Keine Ahnung derwievielte das war, aber diese Woche jedenfalls nicht
mehr.

> > Ich habe gelesen, daß alle Treiber neugeschrieben werden müssen.
>
> Ganz so ist es nicht, aber beträchtliche Teile müssen
> (bzw. mussten) umgeschrieben werden. Ich stecke im USB-
> Code auch nicht selbst drin, aber mein Eindruck ist, dass
> die meisten "alten" Treiber auch mit dem neuen Stack
> verfügbar sind. Ein paar sind (noch) nicht verfügbar,
> ich glaube in erster Linie ein paar USB-Netzwerk/WLAN-
> Dongles. Dafür gibt werden aber auch einige Geräte
> unterstützt, die mit dem "alten" Code nicht laufen.

Ja - Hans Petter hat so ziemlich alles portiert.
Es gibt natürlich immer wieder das Risiko, dass Geräte nicht mehr
funktionieren, weil das timing anders ist usw...
Nahezu jedes USB Gerät auf dem Markt ist buggy und da kann bereits
eine harmlos wirkende Änderung ein Auslöser sein.
Andererseits funktionieren aber auch Geräte, die vorher nicht liefen.

> Einer der größten Vorteile des neuen USB-Stacks ist, dass
> er nicht mehr unter dem "Giant Lock" steht, d.h. er läuft
> Multithreaded. Man darf also Performance-Verbesserungen
> erwarten.

Das ist auch der wesentliche Grund für die Änderung im Treiberdesign.
Das bisherige Verfahren war für UP vollkommen Ok, aber mit SMP sieht
es anders aus.
Performanceverbesserungen sind auch in anderen Punkten zu erwarten.
USB ist leider mit der Performance nicht unproblematisch - wenn man
ein schnelles umass Gerät will, dann leiden andere Busteilnehmer
darunter.
Beim senden ist es einfach, weil man nur Buszeit für tatsächlich zu
sendende Daten belegt, aber beim empfangen muss man zum pollen der Daten
Buszeit belegen.
Dank der heutigen Rechner mit unzähligen USB-Bussen aber wohl kaum noch
ein ernstes Problem.
Zudem hat der alte USB Stack durch eine Designschwäche maximal jeden
zweiten Frame für ein bestimmtes Gerät genutzt, was zum einen die
Latenz erhöht und zum anderen die maximal mögliche Übertragungsrate
halbiert.

> Außerdem wird der USB-Client-Modus unterstützt, was
> besonders für die Embedded-Fraktion interessant ist.
> Damit könnte eine FreeBSD-Box beispielsweise ein umass-
> Gerät emulieren.

Das ging schon vorher - wenngleich auch nicht per Kernel.
Beispielsweise per (inzwischen nicht mehr produzierten) PDIUSBD11 am
smbus - smbus gibt es notfalls auch am lpt.
Dazu muss man aber auch anmerken, dass die wenigsten Rechner Hardware
für USB-Client Betrieb besitzen.
PCs haben das sowieso nur mit Zusatzkarten und im FreBSD kompatiblen
Embeddedbereich ist das auch eher selten anzutreffen.
Die µC auf meinen ARM Boards besitzen z.B. einen Client Controller, der
auch unterstützt wird, aber ich habe die Anschlüße mangels konkretem
Bedarf nicht rausgeführt, was somit zu entsprechendem Lötaufwand führt.
Ich sehe den potentiellen Nutzen ohnehin als sehr gering an.
Warum sollte man z.B. ein umass Gerät emulieren wollen?

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