Change:
stdenv.mkDerivation rec { pname = "rtl88x2bu"; <del> version = "${kernel.version}-unstable-2021-11-04"; </del> <ins> version = "${kernel.version}-unstable-2022-02-22"; </ins> src = fetchFromGitHub { owner = "morrownr"; <del> repo = "88x2bu"; rev = "745d134080b74b92389ffe59c03dcfd6658f8655"; sha256 = "0f1hsfdw3ar78kqzr4hi04kpp5wnx0hd29f9rm698k0drxaw1g44"; </del> <ins> repo = "88x2bu-20210702"; rev = "6a5b7f005c071ffa179b6183ee034c98ed30db80"; sha256 = "sha256-BqTyJpICW3D4EfHHoN5svasteJnunu2Uz449u/CmNE0="; </ins> }; hardeningDisable = [ "pic" ];

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 5.10.79-unstable-2021-05-18 desired version: unstable-2021-11-22 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: is the new repo for this driver, as stated on the : News: A new version of this driver is now available. Testing has shown the new driver to be a very solid driver in managed and master modes You are invited to help test and break in the new driver: The plan is to discontinue this driver by the end of December 2021. This URL will then be used to provide a link to the new driver so this URL is a good permanent bookmark. Please transition to the new driver as you are able to do so. Regards. Nick
I no longer have a rtl88x2bu device, so I can't test this.
I have the "pleasure" of having to deal with an adapter that needs this driver (Edimax EW-7822UAD). It is supported by neither the original repo nor the updated repo (despite the fact that the README claims support). I guess it's just a matter of adding USB IDs, and I can open the issue on the updated repo. But here's the thing. I see that there are a number of different repos with this driver in different states of maintenance. What made you pick morrownr's repo over others?

I am currently using which claims to support more hardware, and it seems to work well, though I have only tested AP mode and haven't run a benchmark for an extended period of time. Would it make sense to switch repos entirely, or would you prefer to stick to morrownr?
tbh, I created this request based on someone who needed help in configuring their device, and found that notice on the repo the current package references. Another option might be having both (not sure how this would be handled though), but I wouldn't switch repos so drastically to avoid issues for people that currently use this driver (they might not, but rather avoid future complaints).
Yeah, there's that, although AFAIK all the repos have the same origin in a driver that Realtek threw out there and let to rot and I'm not sure whether any functionality was . But there's also the question of trust and continuity. One of the repos that is the top hit on duckduckgo has gone unmaintained and won't build against new kernels. Thus, my question was directed more at as the maintainer; perhaps there was a reason why that particular repo was chosen. Or there wasn't :) . In either case, it would be nice to know. Sent from my Moto X (4) using
At the time it would have been the most actively maintained repo I could find/get working.
I have a AC53 Nano that I can use for testing. But I don't know what I'm supposed to test, just daily use or any particular features? Any test suites?
I was considering a PR to switch to RinCat's repo on the grounds that it supports more hardware. So I've been testing it for a couple of weeks now. However, I see now that morrownr's repo recently expanded HW support. And I agree with that the probability of regressions is lower if we maintain continuity and stick to the same upstream. To wit, I'm now testing with the following overlay: It points to my personal repo where I a USB ID for my particular adaptor. I plan to merge that upstream after testing. As I understand it, these USB adapters are only good for casual use anyway, so I don't think it makes sense to test more than that.

What I do is: use the adaptor with my home wifi network suspend the computer every day to ensure the adaptor wakes up properly test with iperf occasionally (using another machine with a wired interface as the iperf server) to check the bandwidth as I've had bad experiences with other rtl adaptors in the past becoming flaky after a while I would also test with NetworkManager in coffee shops and such to see if network switching works well, but I can't because I use this adapter with my desktop machine.
It seems that after this change the driver no longer builds for aarch64 for all available kernel versions: 5.15, 5.16, 5.17 aarch64 builds fail cc