Open teletypo opened 11 months ago
So I'm tempted to assume that this driver doesn't really have many fixes/features that the kernel driver does not have.
You should not make this assumption. The drivers are based on totally different source code. The in-kernel driver meets Linux Wireless Standards or it would not be in the kernel. That does not mean that all possible features are supported, it means that the features that are supported are done in accordance with the existing standards. This out-of-kernel driver is nowhere near compliant with Linux Wireless Standards making it hard to work on.
Or maybe they use different firmware blobs?
They do.
maybe there are some meaningful differences, like support for AP, MU-MIMO, speed, stability etc?
A few months ago, I tested an adapter with a rtl8812bu chipset with the in-kernel driver so as to get an idea of the status. I only had time for testing managed mode. What I found with kernel 6.4:
I have added two adapters with rtl8812bu chipsets to the Plug and Play list. I put some warnings as users that are used to the Mediatek in-kernel drivers will likely be surprised. All Mediatek in-kernel driver are support by Mediatek kernel devs and we have access to them. Realtek did not develop the rtw88 usb support. Let's just say that Mediatek is all in and Realtek is not.
Can somebody please document the differences to e.g. linux 6.7?
I'm willing to help but I do not have the time to take on the project by myself. Wanna help?
@morrownr, thank you! I will test the in-kernel rtw88 for a 0bda:b82c Realtek Semiconductor Corp. 802.11ac NIC
in 5.8GHz AP mode. If that's not happy I will test this driver, and report back either way.
I thought this and the in-kernel drivers had a common ancestry, but apparently that's not the case. Given that, to answer your question, no I don't want to document the differences between these two drivers.
@morrownr Thanks a lot for the comparison. Another difference I found with the rtw88 driver is that it does not support USB mode switching (USB 2.0 to 3.0 or vice versa). Because the device initializes in USB 2.0 mode, it won't switch to USB 3.0 with the in-kernel driver. Neither could I find any userspace tools (such as usb_modeswitch) that can perform the USB mode switch.
@Smackd0wn
I have noticed this issue as well. At times, it will switch to usb3 but I need to take a better look at this. I think it may be a bugin the rtw88 driver.
Neither could I find any userspace tools (such as usb_modeswitch) that can perform the USB mode switch.
You won't find any switches. The modern stack, call it mac80211, is automated in this regard. I heavily use adapters based on the mt7612u and mt7921au chipsets that use in-kernel, mac80211, drivers. If I put an adapter with these usb3 capable chipsets in a port, the port is autodetected and usb is set accordingly. I've never seen it fail. If you want usb3, put the adapter in a usb3 port. and it you want usb2, put the adapter in a usb 2 port.
@morrownr
You won't find any switches. The modern stack, call it mac80211, is automated in this regard. I heavily use adapters based on the mt7612u and mt7921au chipsets that use in-kernel, mac80211, drivers. If I put an adapter with these usb3 capable chipsets in a port, the port is autodetected and usb is set accordingly. I've never seen it fail. If you want usb3, put the adapter in a usb3 port. and it you want usb2, put the adapter in a usb 2 port.
For regular USB 3 devices, such as thumb drives, yes, if you put it in a USB 3 port, it works as a USB 3 device. Probably Mediatek chips work like that as well. (Unfortunately I don't have any of those to test.)
But the Realtek 88x2bu does not work like that. It uses "smart switching" which means it always initializes in USB 2.0 mode when powered on. (At least my dongles do so.) The Realtek driver can let the device switch to USB 3.0 mode (or back to 2.0) by writing some registers:
I tested the 88x2bu driver (from this repository), with rtw_switch_usb_mode=1
. Here is the kernel log:
08:43:53 kernel: usb 3-3: new high-speed USB device number 2 using xhci_hcd
08:43:53 kernel: usb 3-3: New USB device found, idVendor=0bda, idProduct=b812, bcdDevice= 2.10
08:43:53 kernel: usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
08:43:53 kernel: usb 3-3: Product: 802.11ac NIC
08:43:53 kernel: usb 3-3: Manufacturer: Realtek
08:43:53 kernel: usb 3-3: SerialNumber: 123456
08:43:54 kernel: 88x2bu: loading out-of-tree module taints kernel.
08:43:54 kernel: 88x2bu: module verification failed: signature and/or required key missing - tainting kernel
08:43:54 kernel: usb 3-3: USB disconnect, device number 2
08:43:54 kernel: rtl88x2bu 3-3:1.0: Runtime PM usage count underflow!
08:43:54 kernel: usbcore: registered new interface driver rtl88x2bu
08:43:55 kernel: usb 4-3: new SuperSpeed USB device number 2 using xhci_hcd
08:43:55 kernel: usb 4-3: New USB device found, idVendor=0bda, idProduct=b812, bcdDevice= 3.00
08:43:55 kernel: usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
08:43:55 kernel: usb 4-3: Product: 802.11ac NIC
08:43:55 kernel: usb 4-3: Manufacturer: Realtek
08:43:55 kernel: usb 4-3: SerialNumber: 123456
When plugged in, it apparently is a USB 2.0 only device, so the kernel found a new high-speed USB device. After the 88x2bu is loaded, and initialized the device (by uploading firmware, writing registers, etc.), the device "disconnected", then reappeared as a SuperSpeed device. That is the "smart switching".
Apparently the "smart switching" feature of 88x2bu is not very well documented. Some people thought the 88x2bu-based dongles are "fake" USB 3.0 devices because they always appear as USB 2.0 initially. I also found others asking about the mode switching, for example @scorpius2k1 from AUR.
I don't think the in-kernel rtw88 driver even support or attempt USB mode switching. mac80211 won't care either. Hence, with the rtw88 driver, the device will stay at USB 2.0.
I tested one more thing--after the Realtek 88x2bu driver made the device to switch to USB 3.0, I unloaded 88x2bu, and loaded rtw88 instead. Fortunately the device stayed at USB 3.0. and that the in-kernel driver works fine. I am not sure if the rtw88 driver will (or should) care about USB mode switch. I mean, for those dongles with Windows drivers onboard, the USB mode switch from CD-ROM to NIC is not Linux kernel's concern. Maybe a userspace program should make 88x2bu switch from USB 2.0 to 3.0 or vice versa.
Apparently the "smart switching" feature of 88x2bu is not very well documented.
I've tried to help with the documentation. Run sudo sh edit-options.sh
from the driver directory. There is documentation in that file and you will notice that the file also blacklists the in-kernel driver. This file is installed if you use sudo sh install-driver.sh
to do the installation. The remove-driver.sh script will remove the file, including the blacklist.
Now, I'm not so sure I would call what this driver does as smart switching
as it is a manual process.
Apparently the "smart switching" feature of 88x2bu is not very well documented.
I've tried to help with the documentation.
Yes, and thanks for that. But most people would expect a USB 3.0 device to work directly in USB 3.0 mode when they put it in a USB 3.0 port. They would not expect it to always initialize in USB 2.0 mode and USB 3.0 is only activated ("smart" or manually) by the driver. That part is not directly documented.
Now, I'm not so sure I would call what this driver does as smart switching as it is a manual process.
Either way, I have created a userspace program to manually perform the USB mode switching for users of the in-kernel (rtw88) driver: https://github.com/Smackd0wn/rtw88_8822bu-usb3
@morrownr
I made some speed tests with my 8812bu cards (Comfast CF-812AC). All on Arch Linux (kernel 6.6.7), with iperf server running on an OpenWrt router (MT7621A/MT7603E/MT7612E), on channel 153 (5.765 GHz), VHT80. Tested with iperf -r
. TX means USB wireless NIC to AP, while RX means AP to USB. Tests performed for several times, and the best is taken.
rtw88
driver (USB 2.0), TX 39 Mbps, RX 198 Mbpsrtw88
driver (manually switched to USB 3.0), same as 188x2bu-20210702
driver (USB 2.0, rtw_switch_usb_mode=0
), TX 98 Mbps, RX 250 Mbps.88x2bu-20210702
driver (USB 3.0, rtw_switch_usb_mode=1
), same as 3So the transmission from the USB card to AP is quite poor with rtw88
, compared to 88x2bu
.
In comparison, under the same testing condition, my 8821cu cards (Comfast CF-813B, about the same form factor as CF-812AC, both without long or external antennas) performed much better with rtw88
(TX 200Mbps, RX 250Mbps), or 8821cu-20210916
driver (about the same speed as rtw88).
That TX speed sure is disappointing. A 1T1R wifi 4 device can achieve that with 40 MHz channel width.
About the USB3 issue: I think the Windows driver must be autodetecting the type of the port and automatically switching the device. Unless it comes with a program with a systray icon which the user is supposed to click to switch to USB3 mode? Someone should take one for the team and install Windows to find out. :) If the driver is doing everything automatically, Wireshark can be used to capture the USB commands and see how the driver does it.
About the USB3 issue: I think the Windows driver must be autodetecting the type of the port and automatically switching the device. Unless it comes with a program with a systray icon which the user is supposed to click to switch to USB3 mode? Someone should take one for the team and install Windows to find out. :) If the driver is doing everything automatically, Wireshark can be used to capture the USB commands and see how the driver does it.
According to this link, yes, it automatically switches to USB3 only when connected to an 802.11ac network that is above USB2 speed.
I use Windows and had tested the 8812bu dongle on it, and it indeed does that kind of auto-switching. And there are no tray icons and the user is not able to manually switch USB mode.
The USB2 to 3 (or vice versa) switching commands are in the out-of-tree Realtek Linux driver as well. Here are the relevant lines in this repo:
And I have made a simple userspace program that does the switching:
https://github.com/Smackd0wn/rtw88_8822bu-usb3/blob/main/88x2bu3.py
@dubhater @Smackd0wn
FYI: The mt7612u and mt7921u driver automatically detect and select USB3 so there is some code in mt76 that might assist in figuring out how to add the appropriate code to rtw88.
@morrownr Those devices also pretend to be USB2 when you first plug them in?
@dubhater
Those devices also pretend to be USB2 when you first plug them in?
No. They detect and set USB2 or USB3 depending on what is detected. It is very accurate. I have never seen a mistake, It just works.
There is a reason the Plug and Play List here is loaded with usb adapters that are powered by Mediatek chipsets. They are far more trouble free than the Realtek usb adapters that are only supported with out-of-kernel drivers. The code above may help with a solution for the 8812bu but I think we need to look at the code in mt7612u also. Between the two, it should be possible to come up with a patch to test. Keep in mind that usb3 detection and support is only for the 8812bu chip as the 8822bu has to be locked to usb2 because of the bluetooth interference problem between usb3 and bluetooth. 8822bu has bluetooth turned on so has to run in usb2 mode.
I would really like to get rtw88 fully up to speed for the 8822/12bu and 8821/11cu chips so I can shut down the out-of-kernel drivers I maintain here. We have multiple discussions going in different places about working on and testing things on rtw88 but it might help if we could get a central location for this work so that we don't get lost. Ideas?
@morrownr
@Smackd0wn rtw88 switches to USB 3 by itself now. The speeds may have improved/worsened also. Would you test it again? https://github.com/lwfinger/rtw88
I read that the 88x2bu driver is now in the mainline kernel, but apparently there's still some differences. In e.g. #195, @morrownr says
Can somebody please document the differences to e.g. linux 6.7? Looking at the commits in this repo, I see mostly fixes to building and installing, but fewer relating to actual driver code. So I'm tempted to assume that this driver doesn't really have many fixes/features that the kernel driver does not have. But maybe there are some meaningful differences, like support for AP, MU-MIMO, speed, stability etc? Or maybe they use different firmware blobs?
Thanks!