Package Details: rtl8814au-dkms-git 5.8.5.1.r182.g8105736-1

Git Clone URL: https://aur.archlinux.org/rtl8814au-dkms-git.git (read-only, click to copy)
Package Base: rtl8814au-dkms-git
Description: RTL8814AU and RTL8813AU chipset driver with firmware v5.8.5.1
Upstream URL: https://github.com/morrownr/8814au
Licenses: GPL2
Conflicts: rtl8814au
Submitter: zebulon
Maintainer: zebulon (Frost)
Last Packager: zebulon
Votes: 25
Popularity: 0.006637
First Submitted: 2017-09-18 20:21 (UTC)
Last Updated: 2024-05-23 13:15 (UTC)

Dependencies (3)

Required by (0)

Sources (3)

Pinned Comments

zebulon commented on 2019-10-01 06:19 (UTC) (edited on 2025-02-12 07:25 (UTC) by zebulon)

To all having an issue with this driver: please try these alternate packages: https://aur.archlinux.org/packages/rtw88-dkms-git or https://aur.archlinux.org/packages/rtl88xxau-aircrack-dkms-git.

Latest Comments

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 14 Next › Last »

zebulon commented on 2018-07-16 08:42 (UTC)

@erkexzcx: I think the best way would be for you to create a Github account and put the file structure of your zip archive in a project. Then we can start diff between your archive and gordboy's one, to see what changes were required for ARM. Then we can see how we can incorporate these changes as a branch in my copy of gordboy's code. I am not familiar with the handling PKGBUILD for several platforms, but I will look into it. Either the platform detection will be made directly in the source (a bit like for the various linux kernel version), or maybe we can make the PKGBUILD download the specific branch according to the platform. I need to read how this is usually done. Thanks anyway for your contribution and I am glad this is on good tracks.

erkexzcx commented on 2018-07-13 16:47 (UTC)

@zebulon I am not very familiar with makefile structure, but my proposed package https://drive.google.com/open?id=1rKsYlV7_8UUDLDsQzk6kxKtb0jbPXulu works just perfectly on 2 of my arm devices. Any suggestions of how this could be implemented? Instructions are here: https://edimax.freshdesk.com/support/solutions/articles/14000063861-how-to-install-ew-7833uac-adapter-on-raspberry-pi (this is exactly what my proposed package does for ARM architecture)

zebulon commented on 2018-07-03 14:05 (UTC)

@francoism90: this is ok and I accept this argument. However we need to have a way to follow the code changes from the vendor's base code. Since my code is in Github, I would suggest to add arm as a patch set.

francoism90 commented on 2018-07-03 13:57 (UTC)

@zebulon It doesn't matter what architect your package supports. Not saying you can do anything in AUR, but other platforms such as ARM and x86 are fine to include if supported by upstream.

zebulon commented on 2018-07-03 09:37 (UTC) (edited on 2018-07-03 13:17 (UTC) by zebulon)

@erkexzcx: EDIT: I would like to amend my initial answer: I received some information and indeed AUR can be used to host various architectures, so I am completely happy to have you helping with the arm version of the package. Please note I do not own arm hardware, so you will be the one doing the patching and the testing.

That said, there is another thing to address here. Can you please propose your arm patches as a Github fork of my repository? A bit of history: the rtl8814au code I have on Github is based on vanilla with patches to compile on recent kernels (see the other related projects (8812au and 8821au), we have repositories on Github that show exactly this). Or do you prefer another solution? If I understand correctly, the PKGBUILD src will point to the same repository, hence we need a code that support both x86_64 and arm, using conditionals (as for the various kernel versions).

erkexzcx commented on 2018-07-02 16:38 (UTC)

Therefore I am asking you to add me as a maintainer, so I can test this driver on ARM architecture as well as on x86_64 (because I can). This way we can avoid creating another package as identical as this, just extra support for ARM.

erkexzcx commented on 2018-07-02 13:54 (UTC)

@zebulon I have no idea why you are focusing so much on arm community and not saying a word about i686 architecture in this AUR package. Please go to https://wiki.archlinux.org/index.php/PKGBUILD#arch and see what architectures are available for AUR. Also, if you really feel that AUR is not a place for ARM architecture, then please drop i686 as well. I do not see why you should support i686 if you resist to support arm architectures.

zebulon commented on 2018-07-02 09:02 (UTC)

@erkexzcx: unfortunately I am not a maintainer for ARM, or even have any affiliation with the people from archlinuxarm. You may want to contact them directly on their IRC or forum to propose your PKGBUILD (see https://archlinuxarm.org/forum/viewforum.php?f=4 for user-submitted packages). But the AUR, as far as I know, is not designed to host ARM PKGBUILDs. Hope this helps.

erkexzcx commented on 2018-06-30 13:10 (UTC)

@zebulon Could you please add me as a maintainer or at least - update this AUR archive with this one? https://drive.google.com/open?id=1rKsYlV7_8UUDLDsQzk6kxKtb0jbPXulu

I have 2 ARM based SBC and this driver is a MUST to have. I am more than happy to test it for you. My provided AUR archive works just fine on my laptop as well as on my boards.

zebulon commented on 2018-06-29 05:21 (UTC)

@erkexzcx: thanks for your work and comments. However please note I do not maintain packages for ARM. Arm is not supported here, this repository is for x86_64 only (i686 having now been dropped). There is however a separate Archlinux project for ARM at https://archlinuxarm.org and this is where an ARM package should be developed. Note this is not bad will, just that I would not be able to test it. Thus it would be better to leave it to the Archlinuxarm developers who have the hardware.