Infinity ErgoDox wird nicht korrekt erkannt/eingebunden.

Wasp

Insektenspray-Gegner
Hey ihr,
habe mir ein Infinity ErgoDox von Massdrop gegönnt. Da ich anno dazumal Probleme mit einem USB-Microsoft-Keyboard hatte, diese aber seit längerem seitens FreeBSD behoben sind, habe ich mir keine großen Gedanken gemacht JEDOCH wird das Infinity ErgoDox nicht richtig erkannt. Um genau zu sein, wird es als alles gleichzeitig [strike](nacheinander?)[/strike] erkannt: Keyboard, Modem, Maus, Joystick und Media Keys; und FreeBSD 10.2-release (amd64) findet das gar nicht lustig. Nach der ersten Tasteneingabe sind alle anderen Eingabegeräte "tot".

/var/log/messages:
Code:
Oct  9 06:57:43 beteigeuze kernel: kbd3 at ukbd1
Oct  9 06:57:43 beteigeuze kernel: ukbd2: <NKRO Keyboard> on usbus1
Oct  9 06:57:43 beteigeuze kernel: kbd4 at ukbd2
Oct  9 06:57:43 beteigeuze kernel: umodem0: <Virtual Serial Port - Status> on usbus1
Oct  9 06:57:43 beteigeuze kernel: umodem0: data interface 3, has no CM over data, has break
Oct  9 06:57:43 beteigeuze kernel: ums2: <Mouse> on usbus1
Oct  9 06:57:43 beteigeuze kernel: ums2: 5 buttons and [XYZT] coordinates ID=0
Oct  9 06:57:43 beteigeuze devd: Executing '/etc/rc.d/moused quietstart ums2'
Oct  9 06:57:43 beteigeuze kernel: uhid3: <Joystick> on usbus1
Oct  9 06:57:43 beteigeuze kernel: uhid4: <Media Keys> on usbus1

`usbconfig` list ist überraschenderweise glücklich:
Code:
(...)
ugen1.8: <Keyboard - MDErgo1 PartialMap pjrcUSB full Kiibohd> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)

Für Ratschläge dankbar
Wasp

PS: Unter Windoof und Linux Mint läufts fehlerfrei. Unter Gentoo von Prinzip auch, "verschwindet" hier aber einfach nach einer gewissen Zeit und/oder untätigkeit.


Nachtrag:
Gesehen, daß moused(8) respektive devd(8) das erzeugte (Maus-)Gerät (ums2) einbindet. Habe entsprechenden moused getötet und jetzt wird es zumindest irgendwie erkannt. Jedoch erhalte ich komplett falsche Key-Codes (=Zeichen) von den Tasten zurück. Irgendetwas ist da noch immer kaputt...
 
Hmm... Das könnte eine amklaufende N-Key Rollover Emulation für USB-Keyboards sein. Ich habe einen Quirk (wird in die /boot/loader.conf eingetragen) für mein Filco Majestouch 2, der ähnliches Verhalten abstellt. Leider komme ich gerade nicht ran, daher muss es bis heute Abend warten. :(
 
<F5>, <F5> .... <F5> ... ? :ugly:

PS: Schon einmal besten Dank im Voraus für Deine Mühe.
 
Code:
# Filco Keyboard Quirk
hw.usb.quirk.0="0x04d9 0x1818 0x0000 0xffff UQ_UMS_IGNORE"

Das wird in der Manpage zu "usb_quirk" ziemlich detailiert erklärt. 0x04d9 und 0x1818 sind VendorID und ProductID, man kommt irgendwie per usbconfig an sie heran. 0x0000 bis 0xffff sind die Revisionen des Geräts, auf die der Quirk angewandt werden soll. Hier einfach stumpf alle. UQ_UMS_IGNORE ist dann der Quirk, die Manpage hat eine Liste aller. Das sind verdammt viele. Dieser sagt dem Kernel "Hey, das hier ist keine Maus. Egal, was das Gerät selbst sagt".
 
Mit "usbconfig dump_device_desc" kommt man relativ einfach an die IDs.

Mich wundert wirklich, das den Herstellern so was selber nicht auffaellt und die Filco Tastatur sieht wirklich gut und hochwertig aus.
 
Die Hersteller dieser Tastaturen sind wohl eher sehr, sehr kleine Betriebe. Da wird es kaum eine große Kontrolle geben, ob die Geräte überall einwandfrei laufen.
 
Kenne mich mit dem (USB?) Standard nicht aus, aber die Tastastur kann auch als Maus fungieren. Daher klingt es zumindest für mich folgerichtig, daß das Keyboard auch als Maus erkannt wird. Von meinem naiven Standpunkt, hat es für mich in diesem speziellen Fall (und wirklich das erste mal) den Eindruck, daß nicht der Hersteller, sondern FreeBSD das Problem ist. In wie weit dies allerdings irgend einem Standard widerspricht, weiß ich, wie bereits erwähnt, nicht -- aber praktisch ist es (vmtl.) alle mal.

Bereits vor 8-10 Jahren, hatte ich kurzweilig eine ("Gamer") Maus, die als Tastastur erkannt wurde. Habe sie postwendend zurückgebracht und ebenso auf Hardwarehersteller und "neumodisches" Zeug geflucht. Retrospektiv muß ich sagen, habe ich spätestens seit gestern einen etwas differenzierteren Standpunkt; bzw. finde ich, daß man nach ca. 10 Jahren schon mal einen gewachsenen und scheinbar etablierten "Standard", auch wenn er von keiner Kommision beschlossen wurde, akzeptieren kann; zumal wenn er ja durchaus logisch scheint und richtig scheint. Warum sollte mein Regal nicht gleichzeitig eine Sitzbank sein...

OT=OnTopic ;) :
Dank Dir Yamagi! Je nach dem, ob FreeBSD die Quirks nach abziehen des gerätes wieder vergißt oder nicht, ist es jetzt:
UQ_UMS_IGNORE und UQ_HID_IGNORE oder eben nur UQ_HID_IGNORE. Kann man das irgendwo einsehen, welche Quirks gerade aktiv sind?
 
Naja, so richitg flüssig läuft das ja jetzt nicht. Insg. scheint mir FreeBSD kein großer Fan von USB zu sein, kann das sein?
  • `usbconfig reset`, eigentlich ein Typo, scheint nichts zu machen, aber halt auch nicht auf ^C oder ^D reagieren. Wenigstens geht SIGTERM. Läßt die Konsole aber dennoch traurig zurück. // Nachtrag: s. unten
  • Quirks lassen sich nur entfernen, wenn das Gerät angeschlossen ist. Was etwas Paradox ist, da der Quirk auch ohne das Gerät existiert kann.
  • Andersherum gibt mir `usbconfig -d 1.6 dump_device_quirks` mit oder ohne "-d1.6" 533 Quirks aller Geräte zurück.
  • Was ist z.B. "add_dev_quirk_vplh". Weder usb_quirk(4) noch usbconfig(8) klärt einen darüber auf.

Nachtrag:
Mehr durch Zufall in /var/log/messages gesehen: "pcm3: Waiting for sound application to exit!". Jetzt ehrlich? Sendet denn der Kernel eine Bitte, in meinem Fall an musicpd(8), sich zu beenden bzw. das Gerät freizugeben?
Interessanterweise kam meine Konsole wieder zum Leben nachdem ich musicpd(8) beendet hatte, obwohl usbconfig(8) ja schon lange via SIGTERM getötet (und via ps(1) Tot assistiert).
 
Naja, FreeBSDs Problem bei USB war schon immer, dass es zu standardkonform ist. Windows und Linux sehen über Dinge wie sich mehrfach meldende Geräte einfach hinweg. Irgendwann ist dann mal jemanden die Hutschnur gerissen und er hat den Quirk-Mechanismus in ein Kernelmodul gepackt, damit man nicht bei jedem zickenden Gerät gleich GENERIC verlassen muss. Die Doku ist da auch definitiv ausbaufähig...

Das 'usbconfig reset' schmeißt wohl alle Geräte einmal raus und wieder rein. Damit er Sound-Devices freigebekommt, muss der Kernel alle Prozesse mit File Descriptors darauf eliminieren. Dinge wie einfach das Device wegschießen gehen mit OSS leider nicht wirklich. Er sendet dann wahrscheinlich ein SIGTERM, was musicpd einfach mal ignoriert hat. Oder irgendwie so. Das ist nun etwas ungesund zusammengeraten. ;)

Ansonsten. Tjoa. Ich muss zugeben, dass ich damals einfach einen Quirk auf irgendeiner Mailingliste gesehen und mir nur angepasst habe. Mehr Gedanken habe ich mir darüber nicht gemacht.
 
Ansonsten lohnt es sich auch, auf den entsprechenden FreeBSD-Mailinglisten zu posten. Da bekommt man oft sehr kompetente Hilfe!

Ich hatte vor 2 Jahren ein Problem mit einer externen USB-Audiokarte, die auf einmal nicht mehr mit einer neuen Version dfu-util zusammenspielen wollte. Bald schon mischte sich Hans Petter Selasky in die Diskussion ein und führte mich aus der Ferne durch Patches, Recompiles, GDB usw., so dass nach einigen Wochen ein Quirk für mein Gerät in FreeBSD drin war (HPS ist einer der Hauptentwickler des USB-Stacks auf FreeBSD). Sehr nett. Sehr hilfsbereit... und am Ende sehr erfolgreich!
 
Danke für die vielen Antworten (für das ja doch recht spezielle Thema). Hatte bereits selbst eingesehen, daß das wohl ein Thema für eine Mailingliste ist. Ganz Google findet mit "FreeBSD ErgoDox" nichts sinnvolles zum Thema außer Rekursion. Hey, Platz eins, schon nach nur einem Tag. ;)
Aber Danke auch SolarCatcher für die motivierenden Worte, wenigstens habe ich jetzt wieder etwas Hoffnung FreeBSD und ErgoDox doch noch zusammen zu bekommen und mich in die altehrwürdigen Tiefen der Mailinglisten zu begeben. Wüßte ansonsten nicht, für was ich mich im Ernstfall entscheiden sollte... :zitter:
 
Zurück
Oben