Hallo ihr Lieben,

erstmal vielen vielen Dank für die stetige Arbeit an Verbesserungen.

Leider gibt's ja subjektiv irgendwie immer was zu meckern und ich möchte hier mal den Focus auf WLAN-Treiber und Treiber allgemein ziehen. Mein TP-Link Archer T3U Plus läuft auch mit 6.5 nicht. Ich will aber nicht meckern sondern konstruktiv sein - soweit ich es kann. Eine eigene Station zur Neuentwicklung und Crosscompiling hab ich aktuell nicht, kann aber schon mal Aspekte geben, die auch viele viele andere (WLAN-)Treiber in sich haben und die meiner Meinung nach helfen könnten.

Um genau zu sein geht es um die beiden ID's welche einem Kernel die Zuordnung erlauben. Da kann man im meinem Fall die 88x2bu.ko editieren - bringt nichts. Auch die Editierung der USB-Dateien bringt genauso viel. Die in meinem Fall im BB File vorhandene rtl8822bu-driver-1.0.0.9-20180511a.zip beinhaltet unter os_dep\linux die usb_intfc.c. Meines Erachtens die hauptschuldige Datei.

Schau ich in diese mal rein, so kann mein Archer gar nicht laufen, da hier die Geäte explizit aufgeführt werden (müssen?) und der Archer trotz identischem Chipsatz die 2357:012d hat:

#ifdef CONFIG_RTL8822B
/*=== Realtek demoboard ===*/
{USB_DEVICE(0x0B05, 0x1812), .driver_info = RTL8812}, /* ASUS - Edimax */
{USB_DEVICE(0x7392, 0xB822), .driver_info = RTL8822B}, /* Edimax - EW-7822ULC */
{USB_DEVICE(0x0b05, 0x184c), .driver_info = RTL8822B}, /* ASUS USB AC53 Nano */
{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALT EK, 0xB82C, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, /* Default ID for USB multi-function */
{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALT EK, 0xB812, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, /* Default ID for USB Single-function, WiFi only */
{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_EDIMA X, 0xB822, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, //EDX
{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_EDIMA X, 0xC822, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, //EDX

Lösungsansatz 1 meinerseits - wohl das unwahrscheinliche Masterpiece: ID Spoofing noch weit vor USB-Init setzen. Damit könnte Hinz und Kunz in einer Datei Werte setzen, und jeder Stick - egal aus welchem Bereich - läuft mit dem Treiber eines bekannten Gerätes mit gleichem Chipsatz

Lösungsansatz 2: (häufigeres) Updaten der Dateien, welche im BB als Source liegen. Vielleicht mit Request-Plattform für lsusb -v Screens


Danke im Voraus