Moin zusammen, ich habe ein Problem unter Linux und finde keine passende Lösung: Ich habe ein K8055 von Vellemann und möchte das unter Linux verwenden. Das Problem ist, daß ich das Board als HID-Gerät ansprechen möchte. (WebHID in Chrome) Leider wird das Board unter Linux mit dem Treiber vmk80xx.ko betrieben und im HID-Treiber explizit rausgefiltert. Gibt es trotzdem eine Möglichkeit das Board mit dem HID-Treiber zu verwenden? Gruß, SIGINT
Sigint 1. schrieb: > Moin zusammen, > ich habe ein Problem unter Linux und finde keine passende Lösung: > Ich habe ein K8055 von Vellemann und möchte das unter Linux verwenden. > Das Problem ist, daß ich das Board als HID-Gerät ansprechen möchte. > (WebHID in Chrome) Leider wird das Board unter Linux mit dem Treiber > vmk80xx.ko betrieben und im HID-Treiber explizit rausgefiltert. Gibt es > trotzdem eine Möglichkeit das Board mit dem HID-Treiber zu verwenden? > > Gruß, > SIGINT Das K8055 Universum ist leider total Windows-lastik ( also woke ) Was Du mit HID Treibern willst, verstehe ich nicht. Aber: Es gibt doch libraries für Linux - zb wenn Du mit Python arbeiten willst: https://github.com/rm-hull/k8055
Naja: Das K8055 Board ist halt ein HID-Device! Die Programmierer vom Kernel meinen aber, daß es kein HID-Device ist und blacklisten es im HID-Treiber. Dabei wird es im Descriptor eindeutig als Custom-HID deklariert. Das Problem ist jetzt, daß Chrome das Board natürlich nicht per WebHID findet. Man kann zwar den HID-Treiber modifizieren, dann wird das Gerät als HID erkannt... das ist aber keine Lösung, die man einem Linux-Neuling zumuten möchte. Ich hatte gehofft, es gibt eine andere Lösung. :-(
Moin, Im LFS Book gibt's folgendes Rezept gegen "unwanted modules": Vielleicht klappt das ja bei deiner Distribution auch so oder aehnlich.
1 | 9.3.3.3. Udev Loads Some Unwanted Module |
2 | |
3 | Either don't build the module, or blacklist it in a /etc/modprobe.d/blacklist.conf file as done with the forte module in the example below: |
4 | |
5 | blacklist forte |
6 | |
7 | Blacklisted modules can still be loaded manually with the explicit modprobe command. |
Gruss WK
Nee, das ist nicht das Problem. Das K8055 wird vom HID-Treiber selbst in einer blacklist geführt. Deshalb kann der Treiber nicht verwendet werden, sondern nur der vmk80xx. Ich hatte gehofft, daß man das irgendwie forcieren könnte... scheinbar geht das nicht. Also muss ich den HID-Treiber von Hand anpassen und neu übersetzten. Das ist bei Windows eindeutig besser gelöst.
Sigint 1. schrieb: > Das ist bei > Windows eindeutig besser gelöst. Mimimimi. Dann nimm halt Windows unn fertsch. Gruss WK
> Also muss ich den HID-Treiber von Hand anpassen und neu übersetzten. > Das ist bei Windows eindeutig besser gelöst. Ich verstehe nicht wie du auf diese absurde Schlussfolgerung kommst. Du kannst bei Linux einfach den Kernel nehmen, ihn von Hand auf das anpassen was immer du moechtest und neu uebersetzen. Bei Windows hast du die Moeglichkeit nicht. Du musst das hinnehmen was dir der Hersteller gibt und fertig. Du machst den Fehler zu glauben das Windows den Standard setzt dem alle zu folgen haben, taetsaechlich ist es aber nur eines von vielen Betriebsystemen und noch dazu ein schlechtes weil es dir relativ wenig Einflussnahme erlaubt. Vanye
Vanye R. schrieb: >> Also muss ich den HID-Treiber von Hand anpassen und neu übersetzten. >> Das ist bei Windows eindeutig besser gelöst. > > Du kannst bei Linux einfach den Kernel nehmen, ihn von Hand auf das > anpassen was immer du moechtest und neu uebersetzen. > > Bei Windows hast du die Moeglichkeit nicht. Du musst das hinnehmen > was dir der Hersteller gibt und fertig. > Was ist für Anwender wohl besser: Selber am Linux-Kernel was anpassen und neu compilieren zu müssen oder einfach einen Windows-Treiber vom Hersteller installieren zu können?
Sigint 1. schrieb: > Nee, das ist nicht das Problem. Das K8055 wird vom HID-Treiber selbst in > einer blacklist geführt. Deshalb kann der Treiber nicht verwendet > werden, sondern nur der vmk80xx. Ich hatte gehofft, daß man das > irgendwie forcieren könnte... scheinbar geht das nicht. Also muss ich > den HID-Treiber von Hand anpassen und neu übersetzten. Das ist bei > Windows eindeutig besser gelöst. Das muss ja irgend einen Grund haben, warum das Teil in der Blacklist gelandet ist. Alternativ kannst Du auch den PIC auf dem Board gegen einen mit eigener Firmware austauschen, der eben richtig funktioniert und nicht geblockt wird. fchk
Vanye R. schrieb: > Ich verstehe nicht wie du auf diese absurde Schlussfolgerung kommst. > Du kannst bei Linux einfach den Kernel nehmen, ihn von Hand auf das > anpassen was immer du moechtest und neu uebersetzen. > [...] > taetsaechlich ist es aber nur eines von vielen > Betriebsystemen und noch dazu ein schlechtes weil es dir relativ > wenig Einflussnahme erlaubt. Nenn mich verwöhnt, aber im Jahr 2023 habe ich schon den Anspruch an mein Desktop-OS dass ich einem Gerät einen Treiber zuweisen kann ohne am Kernel rumkompileren zu müssen.
Wenn er wirklich in einer blacklist ist, dann nimm ihn da halt wieder raus. Ich verstehe dein Problem nicht wirklich.
Daniel A. schrieb: > Wenn er wirklich in einer blacklist ist, dann nimm ihn da halt wieder > raus. Ich verstehe dein Problem nicht wirklich. Das Problem ist, dass es nicht um eine blacklist geht. Dieses spezifische Gerät ist im C-Code des Treibers selbst explizit ausgenommen. Man muss also den Code ändern und neu compilieren, damit sich der Treiber für das Gerät zuständig fühlt.
:
Bearbeitet durch User
Kannst du versuchen per WebUSB auf das Gerät zuzugreifen? Dann musst du das HID-Protokoll halt selbst implementieren. Der Knackpunkt ist, ob das geht obwohl dieser vmk80xx.ko Treiber geladen ist. Notfalls könnte man den eventuell deaktivieren/löschen ohne den Kernel neu kompilieren zu müssen. Libusb hat dafür libusb_detach_kernel_driver. Chrome implementiert das leider nicht: https://bugs.chromium.org/p/chromium/issues/detail?id=679314 Das wäre aber in einem gewöhnlichen C/C++/Java/Python... -Programm auf Basis von libusb problemlos möglich, nur eben nicht aus Chrome. Allerdings braucht libusb_detach_kernel_driver anscheinend root-Rechte. Chrome mit root-Rechten starten ist wohl sowieso keine besonders gute Idee.
Nur zur Info, unter Windows kämpfe ich regelmäßig mit "falschen" Treibern... Scheinbar bin ich damit auch nicht alleine... sonst würde es dieses Zadig Tool nicht geben. Wie dem auch sei, anscheinend sind es keine richtigen HID devices. Zumindest sehen das die Kernel developer so: https://patchwork.kernel.org/project/linux-input/patch/1360761765-20142-1-git-send-email-abbotti@mev.co.uk/ Dank Open Source kannst du dir aber ansehen, was es mit diesem blacklisting auf sich hat...
1 | bool hid_ignore(struct hid_device *hdev) |
2 | {
|
3 | int i; |
4 | |
5 | if (hdev->quirks & HID_QUIRK_NO_IGNORE) |
6 | return false; |
7 | if (hdev->quirks & HID_QUIRK_IGNORE) |
8 | return true; |
9 | ... |
10 | case USB_VENDOR_ID_VELLEMAN: |
11 | /* These are not HID devices. They are handled by comedi. */ |
12 | if ((hdev->product >= USB_DEVICE_ID_VELLEMAN_K8055_FIRST && |
13 | hdev->product <= USB_DEVICE_ID_VELLEMAN_K8055_LAST) || |
14 | (hdev->product >= USB_DEVICE_ID_VELLEMAN_K8061_FIRST && |
15 | hdev->product <= USB_DEVICE_ID_VELLEMAN_K8061_LAST)) |
16 | return true; |
17 | break; |
Aus diesem kurzen Snippet sollte klar sein, dass du nur das NO_IGNORE Flag setzen musst. Kann sein, dass du das Device auch für den Comedi Treiber blacklisten bzw. per uDev den HID Treiber für diese IDs festlegen musst. Ein kurzes Beispiel, wie du das Flag setzt habe ich hier gefunden: https://gist.github.com/jayme-github/fb129cb3777c7c357ecc5a6ac00f0aae Zugegebenermaßen habe ich das noch nie gebraucht.... WebHID wäre mir persönlich aber zu krass... lieber eine virtuelle Taste definieren und diese per Javascript "Drücken"... aber gut, es ging ja nur um ein Kernel "Problem"... 73
Le X. schrieb: > Nenn mich verwöhnt, aber im Jahr 2023 habe ich schon den Anspruch an > mein Desktop-OS dass ich einem Gerät einen Treiber zuweisen kann ohne am > Kernel rumkompileren zu müssen. Nix für ungut, aber genau das passiert ja. Es ist sogar der Treiber, der ausdrücklich für das vorliegende Device geschrieben wurde, und nicht nur ein generischer Klassentreiber. Der TE möchte aber nicht den zu dem Gerät gehörenden Treiber geladen haben, sondern eben den generischen Klassentreiber – und nenn’ mich von mir aus wieder Fanboy, aber die Möglichkeit hättest du bei MS’ Betriebssystem gar nicht erst.
Jack V. schrieb: > und nenn’ mich von mir aus wieder Fanboy, aber die Möglichkeit hättest > du bei MS’ Betriebssystem gar nicht erst. Das geht schon, über den Gerätemanager oder Tools wie Zadig. Besonders toll ist das aber nicht. Das kann man z.B. nutzen um den WinUSB Treiber statt des FTDI Treibers für einen FT2232 zu laden, um den dann per OpenOCD zum JTAG-debuggen zu nutzen.
Man kann den USB-Treibern zur Laufzeit neue Geräte bekannt machen. Ich benutze z.B.
1 | echo "0403 d4f2" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id |
Evt. kann man mit new_id oder/und remove_id etwas ausrichten. Versuch macht kluch und kostet nichts.
Kann mal ein Mod den Beitrag schließen? Hier kommt wohl nicht mehr viel sachdienliches. Die Idee mit dem NO_IGNORE Flag schaue ich mir an, vielen Dank. Mit WebUSB werden ich das auch mal testen.
Nachtrag: Hans W. hatte den richtigen Riecher! Man muss folgendes in die Kernel-Bootoptionen eintagen: "usbhid.quirks=0x10cf:0x5500:0x40000000", dann wird der richtige Treiber für das K8055 geladen, nämlich der HID-Treiber. Dann findet Chrome das Device, wenn man noch eine UDEV-Regel anlegt für die Zugriffsrechte.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.