Re: [...] D-Link DWA-192 - Realtek RTL8814AU WiFi USB 3.0

2017-02-02 Thread Stephen Morris

On 2/2/17 7:56 am, Rick Stevens wrote:

On 02/01/2017 01:07 PM, Stephen Morris wrote:

On 1/2/17 8:27 am, Rick Stevens wrote:

On 01/31/2017 01:47 PM, Stephen Morris wrote:

$ rfkill unblock wifi
OR
$ nmcli radio wifi on
IF
$ systemctl is-active NetworkManager
active
AND
subsequently
$ nmcli device wifi list
to show the APs within the range.

$ rpm -qi NetworkManager-wifi | grep Summary
Summary : Wifi plugin for NetworkManager

It is installed, right?


One question I have, in the 8814 instructions above you mentioned:

// Adds missing Vendor/Product ID
$ sed -i '/0xA834/ a\\t{USB_DEVICE(0x7392, 0xA833), .driver_info =
RTL8814A}, /* Edimax - Edimax */' os_dep/linux/usb_intf.c

Should the values inside the USB_DEVICE brackets be the idVendor and
idProduct numbers mentioned in the dmesg output above?


It is not for for D-Link DWA-192 - VID/PID 2001:331a is already there
https://github.com/diederikdehaas/rtl8814AU/blob/driver-4.3.21/os_dep/linux/usb_intf.c#L208





I've isolated one problem I have with this. Device wlp4s6 is still there
and it is an old pci wireless device that I thought was dead. It looks
like it wasn't and all the time that I thought I was using the DWA192 I
was actually using the pci device, so I need to provide an apology to
everyone who provided help on this, I was working under a false
impression.

But having compiled the 8814au driver that I downloaded from the web
site you provided it seems to be using working now on the 5GHz channel,
but the device has a blue light around the middle of it that the driver
seems to be flashing all the time. When the device is active the light
should be permanently on and goes out when connection to the net is
lost. I could switch the light off but that defeats the purpose of what
it is for. Under windows that process works correctly.

In network manager the device it is talking to shows this: wlp3s0u2
(0E:13:3D:F9:D2:A4). I thought the information within the brackets was
the mac address of the device, but if I am correct it has determined the
mac address incorrectly.

Yes, that should be the MAC address of the device. The newer kernels
number the network devices in the order they're discovered on the bus
and name them according to their position in the bus (e.g. "p4s0"
meaning PCI device 4, subdevice 0). Typically hardwired stuff starts
off with "en", wireless with "wl". Toss in USB and I'm not sure what
they'd be.

In your case, the PCI device is probably found first and would be, by
default, the one NM tries to use. Your USB dongle would probably be
discovered last and you'll need to tell NM to use it in place of the
PCI card.

Again, "ip link show" will show you the various network devices you
have, along with their names and in the "link/ether" line for each
device, the MAC address of the device. You can then use "ethtool -i
" to see which driver that device is using. Make note of
the MAC address of your new device and make sure it's using the driver
you expect it to use.

If you really want to start from scratch, then in NM, I would delete
any existing configurations you have, then click "Add", then select
"Wi-Fi" in the "Connection Type" window. In the "Wi-Fi" tab, fill in
the SSID of your wireless network, select "Client" (or "Managed") in
the "Mode" field, then use the drop-down in "Device" and select the MAC
of the new device.

Click the "Wi-Fi Security" tab, fill in the appropriate data. Finally,
click the "General" tab and tick the "Automatically connect to this
network when it is available" option, then click "Save". Hopefully,
it'll come right up with a DHCP address. If not, right-click on the NM
applet, disable networking, then re-enable it.

Yesterday, after sending this message, I changed the contents within the
brackets to the correct mac address, because as well as the entry in the
list for the old pci card there was an entry with no device but had the
correct the correct mac address within brackets.
This morning I tried to compile a beta driver that from the website I
got the impression was designed to support the rtl8812au, rtl8814au and
rtl8821au chipsets but when compiled it produced and 8812.ko kernel
module which when activated Fedora would not use for the device as the
device could not be activated by networkmanager.
Consequently I have just gone back to the rtl8814au driver and activated
that which has then immediately enable the device. When I look at
networkmanager at the existing definitions I was looking at yesterday
that had the 3 devices in the 'Restrict to Device' list, that drop down
list now only has one entry which is the entry for the usb device with
the correct mac address (wlp3s0u2 (6C:72:20:00:AC:C4)). I'm not sure
what the u2 in the device name means, but I have 9 usb ports which are a
mixture of usb 2 and usb 3 ports for 8 of the ports, and a 9th port that
is self booting to allow updating of the motherboard bios from a usb stick.
My ethernet device has device name enp7s0.

If I recall correctly, "wlp3s0

Re: [...] D-Link DWA-192 - Realtek RTL8814AU WiFi USB 3.0

2017-02-02 Thread poma
On 01.02.2017 22:12, Stephen Morris wrote:
[...]
> I'm about to try to interface the source code for this driver to dkms so 
> that it will get compiled every time I boot from a new kernel, but at 
> the moment I'm not sure how to tell dkms where to find the source code, 
> so I'll have to try to investigate that.
> 

"dkms.conf" of rtl8812AU is working example
https://github.com/diederikdehaas/rtl8812AU

# journalctl -o cat -b -u dkms
Starting Builds and install new kernel modules through DKMS...
Kernel preparation unnecessary for this kernel.  Skipping...
Building module:
cleaning build area...
'make'..
cleaning build area...
DKMS: build completed.
8812au.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
Adding any weak-modules
depmod..
DKMS: install completed.
Kernel preparation unnecessary for this kernel.  Skipping...
Building module:
cleaning build area...
'make'
cleaning build area...
DKMS: build completed.
8814au.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
Adding any weak-modules
depmod
DKMS: install completed.
Started Builds and install new kernel modules through DKMS.

# modinfo -k $(uname -r) -n 8812au 8814au
/lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko
/lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko

# modprobe -v 8812au ; modprobe -v 8814au
insmod /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/rfkill/rfkill.ko.xz 
insmod /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/wireless/cfg80211.ko.xz 
insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko 
insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko 

# dmesg -t
...
RTL871X: module init start
RTL871X: rtl8821au v4.3.14
RTL871X: rtl8821au BT-Coex version = BTCOEX20150128-51
usbcore: registered new interface driver rtl8821au
RTL871X: module init ret=0
RTL871X: module init start
RTL871X: rtl8814au v4.3.21_17997.20160531
usbcore: registered new interface driver rtl8814au
RTL871X: module init ret=0

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: Los efectos de compiz no funcionan en fedora 25 mate compiz

2017-02-02 Thread Mike Wright

On 01/30/2017 01:49 PM, Snaker Mota wrote:

Hola a todos desde ASE dos meses instale fedora 25 con él escritorio
mate compiz para poder usar los efectos pero no e podido usarlos por
la razón de que no e podido instalar los drivers de mi targeta
gráfica al pareser no hay manera de aserlo? Es que no es estable
?


Hola Snaker Mota,

¿Encontró la solución?  Pienso que no sea un problema de los drivers 
sino que los efectos no están habilitados.


Según los documentos 
https://docs.fedoraproject.org/en-US/Fedora/14/html/User_Guide/sect-User_Guide-Customizing_the_desktop-Compiz_Fusion_.html 
fedora no viene con los efectos activados.  Vaya aquí
"System → Preferences → Desktop Effects en GNOME o Kickoff Application 
Launcher → Applications → Settings → Compiz Switcher en KDE" para 
prenderlos.


Espero que le ayuda

--

Did you find a solution?  I think it's not a driver problem but that the 
effects haven't been activated.


According to the documentation fedora doesn't come with the effects 
enabled.  Go to [see above] in order to turn them on.


HTH
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Lost kde task bar

2017-02-02 Thread Fulko Hew
I've been fighting with F24 (gosh I  miss the good old days) but today it's
totally disconnected on me.

My laptop has developed an intermittent  backlight problem so i have it
driving my TV instead. While trying to resolve resolution issues between
and driving both the onboard LCD and the TV my KDE task bar has gone away.

Logging out and in doesn't restore it, and neither does a reboot. I also
tried starting Gnome,  which does, but the Wi-fi doesn't start.

Can annyone suggest what to try next?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: Lost kde task bar (resolved)

2017-02-02 Thread Fulko Hew
On Thu, Feb 2, 2017 at 9:48 AM, Fulko Hew  wrote:

> I've been fighting with F24 (gosh I  miss the good old days) but today
> it's totally disconnected on me.
>
> My laptop has developed an intermittent  backlight problem so i have it
> driving my TV instead. While trying to resolve resolution issues between
> and driving both the onboard LCD and the TV my KDE task bar has gone away.
>
> Logging out and in doesn't restore it, and neither does a reboot. I also
> tried starting Gnome,  which does, but the Wi-fi doesn't start.
>
> Can annyone suggest what to try next?
>

​After trying Gnome and XFCE, unplugging the TV, and a number of reboots,
everything has magically reappeared​.  So my problem has magically gone
away, as magically as it appeared.  Sorry for the bother.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: Lost kde task bar

2017-02-02 Thread Martin Bříza

On Thu, 02 Feb 2017 15:48:38 +0100, Fulko Hew  wrote:

I've been fighting with F24 (gosh I  miss the good old days) but today  
it's

totally disconnected on me.

My laptop has developed an intermittent  backlight problem so i have it
driving my TV instead. While trying to resolve resolution issues between
and driving both the onboard LCD and the TV my KDE task bar has gone  
away.


Logging out and in doesn't restore it, and neither does a reboot. I also
tried starting Gnome,  which does, but the Wi-fi doesn't start.

Can annyone suggest what to try next?


You can right-click the desktop in KDE Plasma and add another taskbar.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: Lost kde task bar

2017-02-02 Thread Fulko Hew
On Thu, Feb 2, 2017 at 10:29 AM, Martin Bříza  wrote:

> On Thu, 02 Feb 2017 15:48:38 +0100, Fulko Hew  wrote:
>
> I've been fighting with F24 (gosh I  miss the good old days) but today it's
>> totally disconnected on me.
>>
>> My laptop has developed an intermittent  backlight problem so i have it
>> driving my TV instead. While trying to resolve resolution issues between
>> and driving both the onboard LCD and the TV my KDE task bar has gone away.
>>
>> Logging out and in doesn't restore it, and neither does a reboot. I also
>> tried starting Gnome,  which does, but the Wi-fi doesn't start.
>>
>> Can annyone suggest what to try next?
>>
>
> You can right-click the desktop in KDE Plasma and add another taskbar.
>

​That was about the 2nd thing I tried (without success).
​
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: [...] D-Link DWA-192 - Realtek RTL8814AU WiFi USB 3.0

2017-02-02 Thread poma
On 02.02.2017 14:19, poma wrote:
> On 01.02.2017 22:12, Stephen Morris wrote:
> [...]
>> I'm about to try to interface the source code for this driver to dkms so 
>> that it will get compiled every time I boot from a new kernel, but at 
>> the moment I'm not sure how to tell dkms where to find the source code, 
>> so I'll have to try to investigate that.
>>
> 
> "dkms.conf" of rtl8812AU is working example
> https://github.com/diederikdehaas/rtl8812AU
> 
> # journalctl -o cat -b -u dkms
> Starting Builds and install new kernel modules through DKMS...
> Kernel preparation unnecessary for this kernel.  Skipping...
> Building module:
> cleaning build area...
> 'make'..
> cleaning build area...
> DKMS: build completed.
> 8812au.ko:
> Running module version sanity check.
>  - Original module
>- No original module exists within this kernel
>  - Installation
>- Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
> Adding any weak-modules
> depmod..
> DKMS: install completed.
> Kernel preparation unnecessary for this kernel.  Skipping...
> Building module:
> cleaning build area...
> 'make'
> cleaning build area...
> DKMS: build completed.
> 8814au.ko:
> Running module version sanity check.
>  - Original module
>- No original module exists within this kernel
>  - Installation
>- Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
> Adding any weak-modules
> depmod
> DKMS: install completed.
> Started Builds and install new kernel modules through DKMS.
> 
> # modinfo -k $(uname -r) -n 8812au 8814au
> /lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko
> /lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko
> 
> # modprobe -v 8812au ; modprobe -v 8814au
> insmod /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/rfkill/rfkill.ko.xz 
> insmod /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/wireless/cfg80211.ko.xz 
> insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko 
> insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko 
> 
> # dmesg -t
> ...
> RTL871X: module init start
> RTL871X: rtl8821au v4.3.14
> RTL871X: rtl8821au BT-Coex version = BTCOEX20150128-51
> usbcore: registered new interface driver rtl8821au
> RTL871X: module init ret=0
> RTL871X: module init start
> RTL871X: rtl8814au v4.3.21_17997.20160531
> usbcore: registered new interface driver rtl8814au
> RTL871X: module init ret=0
> 
> 

DKMS - RTL8814AU,
as explained for RTL8812AU here:
https://github.com/diederikdehaas/rtl8812AU

$ git clone https://github.com/diederikdehaas/rtl8814AU.git
$ cd rtl8814AU/
...
// eventual steps, previously mentioned
...
$ curl -JLO 
https://raw.githubusercontent.com/diederikdehaas/rtl8812AU/driver-4.3.14/dkms.conf
$ sed -i 's/12/14/g' dkms.conf 
$ git add .
$ git commit -m "Added dkms.conf"
$ git tag 4.3.21_17997.20160531

$ su
# DRV_NAME=rtl8814AU
# DRV_VERSION=4.3.21_17997.20160531
# mkdir /usr/src/${DRV_NAME}-${DRV_VERSION}
# git archive ${DRV_VERSION} | tar -x -C /usr/src/${DRV_NAME}-${DRV_VERSION}

# dkms add -m ${DRV_NAME} -v ${DRV_VERSION}
# dkms build -m ${DRV_NAME} -v ${DRV_VERSION}
# dkms install -m ${DRV_NAME} -v ${DRV_VERSION}

# modinfo 8814au -F version
# modprobe -v 8814au

'modprobe' goes if the device is already plugged in,
otherwise re-plug USB device, and if VID/PID of device and driver match - auto 
loading kicks in.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: [...] D-Link DWA-192 - Realtek RTL8814AU WiFi USB 3.0

2017-02-02 Thread Stephen Morris

On 3/2/17 4:28 am, poma wrote:

On 02.02.2017 14:19, poma wrote:

On 01.02.2017 22:12, Stephen Morris wrote:
[...]

I'm about to try to interface the source code for this driver to dkms so
that it will get compiled every time I boot from a new kernel, but at
the moment I'm not sure how to tell dkms where to find the source code,
so I'll have to try to investigate that.


"dkms.conf" of rtl8812AU is working example
https://github.com/diederikdehaas/rtl8812AU

# journalctl -o cat -b -u dkms
Starting Builds and install new kernel modules through DKMS...
Kernel preparation unnecessary for this kernel.  Skipping...
Building module:
cleaning build area...
'make'..
cleaning build area...
DKMS: build completed.
8812au.ko:
Running module version sanity check.
  - Original module
- No original module exists within this kernel
  - Installation
- Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
Adding any weak-modules
depmod..
DKMS: install completed.
Kernel preparation unnecessary for this kernel.  Skipping...
Building module:
cleaning build area...
'make'
cleaning build area...
DKMS: build completed.
8814au.ko:
Running module version sanity check.
  - Original module
- No original module exists within this kernel
  - Installation
- Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
Adding any weak-modules
depmod
DKMS: install completed.
Started Builds and install new kernel modules through DKMS.

# modinfo -k $(uname -r) -n 8812au 8814au
/lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko
/lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko

# modprobe -v 8812au ; modprobe -v 8814au
insmod /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/rfkill/rfkill.ko.xz
insmod /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/wireless/cfg80211.ko.xz
insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko
insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko

# dmesg -t
...
RTL871X: module init start
RTL871X: rtl8821au v4.3.14
RTL871X: rtl8821au BT-Coex version = BTCOEX20150128-51
usbcore: registered new interface driver rtl8821au
RTL871X: module init ret=0
RTL871X: module init start
RTL871X: rtl8814au v4.3.21_17997.20160531
usbcore: registered new interface driver rtl8814au
RTL871X: module init ret=0



DKMS - RTL8814AU,
as explained for RTL8812AU here:
https://github.com/diederikdehaas/rtl8812AU

$ git clone https://github.com/diederikdehaas/rtl8814AU.git
$ cd rtl8814AU/
...
// eventual steps, previously mentioned
...
$ curl -JLO 
https://raw.githubusercontent.com/diederikdehaas/rtl8812AU/driver-4.3.14/dkms.conf
$ sed -i 's/12/14/g' dkms.conf
$ git add .
$ git commit -m "Added dkms.conf"
$ git tag 4.3.21_17997.20160531

$ su
# DRV_NAME=rtl8814AU
# DRV_VERSION=4.3.21_17997.20160531
# mkdir /usr/src/${DRV_NAME}-${DRV_VERSION}
# git archive ${DRV_VERSION} | tar -x -C /usr/src/${DRV_NAME}-${DRV_VERSION}

# dkms add -m ${DRV_NAME} -v ${DRV_VERSION}
# dkms build -m ${DRV_NAME} -v ${DRV_VERSION}
# dkms install -m ${DRV_NAME} -v ${DRV_VERSION}

# modinfo 8814au -F version
# modprobe -v 8814au

'modprobe' goes if the device is already plugged in,
otherwise re-plug USB device, and if VID/PID of device and driver match - auto 
loading kicks in.
I think I have worked out the issue with the flashing light on the 
device, it seems to be functioning the same way as the flashing lights 
on ethernet pci cards, which from the functionality of the vendor 
supplied driver under windows, is not the vendor intended mode of operation.


I now have two issues with the device, one is dkms and the other is 
standard networking functionality.


For dkms I have used the rtl8812au dkms.conf as my starting point. My 
file is below.


PACKAGE_NAME="rtl8814AU"
PACKAGE_VERSION="4.3.21"
BUILT_MODULE_NAME[0]="8814au"
MAKE="'make' -j3 KVER=${kernelver}"
CLEAN="'make' clean"
DEST_MODULE_LOCATION[0]="/updates/dkms"
AUTOINSTALL="YES"


The driver source code is stored in directory /usr/src/rtl8814AU-4.3.21, 
does the version number in the directory name and the 'PACKAGE_VERSION' 
in the conf file have to match the internal version number in the driver 
for the boot time compile of the driver to work?
I've added the -j3 in the make to get the multi-threaded compile and 
I've added the KVER parameter as from my search I did on the net I found 
an article relative to an older version of Fedora that said the KVER 
parameter must be added to get the driver compiled against the correct 
kernel version at kernel install time (they said that without that 
parameter the driver would be compiled against the running kernel, not 
the newly installed kernel).

With the setup I have if I issue the commands:
sudo dkms build -c /usr/src/rtl8814AU-4.3.21/dkms.conf -m rtl8814AU 
-v 4.3.21 and
sudo dkms install -c /usr/src/rtl8814AU-4.3.21/dkms.conf -m 
rtl8814AU -v 4.3.21 and

sudo modprobe -v 8814au
they build, install and load the module successfully. I've also found 
th

Re: [...] D-Link DWA-192 - Realtek RTL8814AU WiFi USB 3.0

2017-02-02 Thread Samuel Sieb

On 02/02/2017 01:07 PM, Stephen Morris wrote:

I think I have worked out the issue with the flashing light on the
device, it seems to be functioning the same way as the flashing lights
on ethernet pci cards, which from the functionality of the vendor
supplied driver under windows, is not the vendor intended mode of
operation.

Look in /sys/class/leds/.  There is probably a directory with the name 
phy*.  Mine is called "phy0-led".  In that directory is a "file" called 
trigger.  If you cat it, it will show you a list of possible triggers 
for the LED with the current setting in [].  You can change it by 
writing the name of the trigger you want to the file.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org


Re: [...] D-Link DWA-192 - Realtek RTL8814AU WiFi USB 3.0

2017-02-02 Thread Rick Stevens
On 02/02/2017 01:07 PM, Stephen Morris wrote:
> On 3/2/17 4:28 am, poma wrote:
>> On 02.02.2017 14:19, poma wrote:
>>> On 01.02.2017 22:12, Stephen Morris wrote:
>>> [...]
 I'm about to try to interface the source code for this driver to
 dkms so
 that it will get compiled every time I boot from a new kernel, but at
 the moment I'm not sure how to tell dkms where to find the source code,
 so I'll have to try to investigate that.

>>> "dkms.conf" of rtl8812AU is working example
>>> https://github.com/diederikdehaas/rtl8812AU
>>>
>>> # journalctl -o cat -b -u dkms
>>> Starting Builds and install new kernel modules through DKMS...
>>> Kernel preparation unnecessary for this kernel.  Skipping...
>>> Building module:
>>> cleaning build area...
>>> 'make'..
>>> cleaning build area...
>>> DKMS: build completed.
>>> 8812au.ko:
>>> Running module version sanity check.
>>>   - Original module
>>> - No original module exists within this kernel
>>>   - Installation
>>> - Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
>>> Adding any weak-modules
>>> depmod..
>>> DKMS: install completed.
>>> Kernel preparation unnecessary for this kernel.  Skipping...
>>> Building module:
>>> cleaning build area...
>>> 'make'
>>> cleaning build area...
>>> DKMS: build completed.
>>> 8814au.ko:
>>> Running module version sanity check.
>>>   - Original module
>>> - No original module exists within this kernel
>>>   - Installation
>>> - Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
>>> Adding any weak-modules
>>> depmod
>>> DKMS: install completed.
>>> Started Builds and install new kernel modules through DKMS.
>>>
>>> # modinfo -k $(uname -r) -n 8812au 8814au
>>> /lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko
>>> /lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko
>>>
>>> # modprobe -v 8812au ; modprobe -v 8814au
>>> insmod /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/rfkill/rfkill.ko.xz
>>> insmod
>>> /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/wireless/cfg80211.ko.xz
>>> insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko
>>> insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko
>>>
>>> # dmesg -t
>>> ...
>>> RTL871X: module init start
>>> RTL871X: rtl8821au v4.3.14
>>> RTL871X: rtl8821au BT-Coex version = BTCOEX20150128-51
>>> usbcore: registered new interface driver rtl8821au
>>> RTL871X: module init ret=0
>>> RTL871X: module init start
>>> RTL871X: rtl8814au v4.3.21_17997.20160531
>>> usbcore: registered new interface driver rtl8814au
>>> RTL871X: module init ret=0
>>>
>>>
>> DKMS - RTL8814AU,
>> as explained for RTL8812AU here:
>> https://github.com/diederikdehaas/rtl8812AU
>>
>> $ git clone https://github.com/diederikdehaas/rtl8814AU.git
>> $ cd rtl8814AU/
>> ...
>> // eventual steps, previously mentioned
>> ...
>> $ curl -JLO
>> https://raw.githubusercontent.com/diederikdehaas/rtl8812AU/driver-4.3.14/dkms.conf
>>
>> $ sed -i 's/12/14/g' dkms.conf
>> $ git add .
>> $ git commit -m "Added dkms.conf"
>> $ git tag 4.3.21_17997.20160531
>>
>> $ su
>> # DRV_NAME=rtl8814AU
>> # DRV_VERSION=4.3.21_17997.20160531
>> # mkdir /usr/src/${DRV_NAME}-${DRV_VERSION}
>> # git archive ${DRV_VERSION} | tar -x -C
>> /usr/src/${DRV_NAME}-${DRV_VERSION}
>>
>> # dkms add -m ${DRV_NAME} -v ${DRV_VERSION}
>> # dkms build -m ${DRV_NAME} -v ${DRV_VERSION}
>> # dkms install -m ${DRV_NAME} -v ${DRV_VERSION}
>>
>> # modinfo 8814au -F version
>> # modprobe -v 8814au
>>
>> 'modprobe' goes if the device is already plugged in,
>> otherwise re-plug USB device, and if VID/PID of device and driver
>> match - auto loading kicks in.
> I think I have worked out the issue with the flashing light on the
> device, it seems to be functioning the same way as the flashing lights
> on ethernet pci cards, which from the functionality of the vendor
> supplied driver under windows, is not the vendor intended mode of
> operation.
> 
> I now have two issues with the device, one is dkms and the other is
> standard networking functionality.
> 
> For dkms I have used the rtl8812au dkms.conf as my starting point. My
> file is below.
> 
> PACKAGE_NAME="rtl8814AU"
> PACKAGE_VERSION="4.3.21"
> BUILT_MODULE_NAME[0]="8814au"
> MAKE="'make' -j3 KVER=${kernelver}"
> CLEAN="'make' clean"
> DEST_MODULE_LOCATION[0]="/updates/dkms"
> AUTOINSTALL="YES"
> 
> 
> The driver source code is stored in directory /usr/src/rtl8814AU-4.3.21,
> does the version number in the directory name and the 'PACKAGE_VERSION'
> in the conf file have to match the internal version number in the driver
> for the boot time compile of the driver to work?
> I've added the -j3 in the make to get the multi-threaded compile and
> I've added the KVER parameter as from my search I did on the net I found
> an article relative to an older version of Fedora that said the KVER
> parameter must be added to get the driver compiled against the correct
> kernel version at kernel install ti