Alex Kholodkov Posted April 3, 2017 Posted April 3, 2017 Hello, I had succeeded install last version of Armbian on Odroid XU4. I have WiFi USB dongle Realtek RTL8812AU chipset (ID = 0bda:8812) I see it $ lsusb Bus 003 Device 003: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter $ dmesg | grep -i usb [ 9.630704] [c5] RTL871X: rtl8812au v4.2.5_10143.20140103_ASUS [ 9.887562] [c5] usbcore: registered new interface driver rtl8812au [18812.680134] [c2] RTL871X: nolinked power save leave but no Wifi interface Could anyone please help solve it
BigG2017 Posted April 9, 2017 Posted April 9, 2017 Did you figure out this issue? I have been considering buying this dongle since my current Realtek N dongle intermittently drops the signal on Armbian Ubuntu zenial mainline...not sure if the OS is actually the problem.
Igor Posted April 10, 2017 Posted April 10, 2017 6 hours ago, BigG2017 said: not sure if the OS is actually the problem. In most cases, problems are drivers and WiFi drivers are among most critical ones. It's actually hard to find a good working one. RTL8812AU was working fine on my brief testing ... but don't actually use it. Not with build in driver, but with this one: https://github.com/gnab/rtl8812au It's easy to compile within armbian, just blacklist the on which is build in if necessary. And make sure you have good - original power supply, USB3 powering is a must.
tkaiser Posted April 15, 2017 Posted April 15, 2017 This should work in both Debian Jessie and Ubuntu Xenial: git clone https://github.com/gnab/rtl8812au sed -i -e 's/CONFIG_PLATFORM_I386_PC = y/CONFIG_PLATFORM_I386_PC = n/' \ -e 's/CONFIG_PLATFORM_ARM_RPI = n/CONFIG_PLATFORM_ARM_RPI = y/' rtl8812au/Makefile sudo apt install build-essential dkms sudo mv rtl8812au /usr/src/8812au-4.2.2 sudo dkms add -m 8812au -v 4.2.2 sudo dkms build -m 8812au -v 4.2.2 sudo dkms install -m 8812au -v 4.2.2 And this is the result: root@clearfogpro:~# iwconfig wlan0 wlan0 IEEE 802.11an ESSID:"Snort-Honeynet 5GHz" Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency:5.2 GHz Access Point: BC:05:43:BE:C1:E3 Bit Rate:300 Mb/s Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:****-****-****-****-****-****-****-**** Security mode:open Power Management:off Link Quality=100/100 Signal level=68/100 Noise level=0/100 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
BigG2017 Posted April 16, 2017 Posted April 16, 2017 Thanks again. On a separate but related note, I'm having issues maintaining wifi connectivity using the latest Armbian mainline (zenial based) with the Airlink101 Wireless N 150 Mini USB Adapter. It worked fine with my Raspberry Pi3, but it frequently disconnects, and I have to manual reconnect frequently. 'lsusb' identifies it as "Realtek RTL8188CUS". Any ideas on how to fix this issue?
BigG2017 Posted April 23, 2017 Posted April 23, 2017 Well, I couldn't determine the cause of signal dropping with the Airlink (RTL 8188CUS), so I took the somewhat easier way out and purchased a similar USB wifi adapter used on this thread with the RTL8812AU. So far, I haven't experience any drops. @tkaiserThanks for the command line help!
vitaly Posted November 22, 2017 Posted November 22, 2017 I did not tested myself yet, but RTL8811AU is more cheap alternative to RTL8812AU. My devices are listed as "0bda:a811 Realtek Semiconductor Corp.", this id already exists in driver, discussed in this thread.
Igor Posted November 22, 2017 Posted November 22, 2017 With Hardkernel driver, 8811AU is not working, while it works with ours. In Odroid 4.9 kernel it was added 10 days ago and is only present in automated nightly builds. 1
AlexisTM Posted February 2, 2018 Posted February 2, 2018 @Igor Does that means this issue https://github.com/gordboy/rtl8812au/issues/1 is not present on armbian with the rtl8814AU driver? Is there any other way to obtain the used rtl8814AU driver than applying the patch to the Odroid kernel? I have both rtl8811au and rtl8821au devices having a glitch.
Igor Posted February 2, 2018 Posted February 2, 2018 3 minutes ago, AlexisTM said: is not present on armbian with the rtl8814AU driver? I haven't noticed anything like that but this doesn't mean it is not present. There is only one way - to test closely but I can do that fastest once next week. Odroid kernel doesn't have support for 8814au either IIRC, only 8812au.
AlexisTM Posted February 2, 2018 Posted February 2, 2018 Thanks I just installed one armbian image on one of the odroids and will test the dongles. NOTE: I use DKMS to install the modules missing.
AlexisTM Posted February 2, 2018 Posted February 2, 2018 @Igor Sad news. Same glitch on the armbian image. :/ TP-Link Archer T4U AC1200 (RTL8821au) on armbian: https://pastebin.com/6erHF6wY Odroid Module 4 (RT5572N) has horrible bad results on both images, this sample is on armbian: https://pastebin.com/Rp64npD2 This glitch is not happening on the Odroid Module 3 (RTL8188CUS) on Kernel 4.15.103.
Igor Posted February 2, 2018 Posted February 2, 2018 Thanks. We are using those sources: https://github.com/aircrack-ng/rtl8812au ... check if its already fixed, then we can bring them into the kernel and push an update.
Igor Posted February 12, 2018 Posted February 12, 2018 @AlexisTM Odroid XU4 4.9.y Spoiler 64 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=1.23 ms 64 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=1.35 ms 64 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=1.47 ms 64 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=1.55 ms 64 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=1.24 ms 64 bytes from 172.16.100.1: icmp_seq=6 ttl=64 time=1.25 ms 64 bytes from 172.16.100.1: icmp_seq=7 ttl=64 time=1.25 ms 64 bytes from 172.16.100.1: icmp_seq=8 ttl=64 time=1.47 ms 64 bytes from 172.16.100.1: icmp_seq=9 ttl=64 time=1.60 ms 64 bytes from 172.16.100.1: icmp_seq=10 ttl=64 time=1.21 ms 64 bytes from 172.16.100.1: icmp_seq=11 ttl=64 time=1.94 ms 64 bytes from 172.16.100.1: icmp_seq=12 ttl=64 time=1.28 ms 64 bytes from 172.16.100.1: icmp_seq=13 ttl=64 time=1.41 ms 64 bytes from 172.16.100.1: icmp_seq=14 ttl=64 time=1.16 ms 64 bytes from 172.16.100.1: icmp_seq=15 ttl=64 time=1.52 ms 64 bytes from 172.16.100.1: icmp_seq=16 ttl=64 time=1.18 ms 64 bytes from 172.16.100.1: icmp_seq=17 ttl=64 time=1.18 ms 64 bytes from 172.16.100.1: icmp_seq=18 ttl=64 time=1.25 ms 64 bytes from 172.16.100.1: icmp_seq=19 ttl=64 time=1.21 ms 64 bytes from 172.16.100.1: icmp_seq=20 ttl=64 time=1.17 ms 64 bytes from 172.16.100.1: icmp_seq=21 ttl=64 time=1.18 ms 64 bytes from 172.16.100.1: icmp_seq=22 ttl=64 time=2.20 ms 64 bytes from 172.16.100.1: icmp_seq=23 ttl=64 time=1.25 ms 64 bytes from 172.16.100.1: icmp_seq=24 ttl=64 time=1.24 ms 64 bytes from 172.16.100.1: icmp_seq=25 ttl=64 time=1.15 ms 64 bytes from 172.16.100.1: icmp_seq=26 ttl=64 time=1.19 ms 64 bytes from 172.16.100.1: icmp_seq=27 ttl=64 time=1.34 ms Cubox 4.14.18 Spoiler 64 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=2.34 ms 64 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=2.47 ms 64 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=2.70 ms 64 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=2.27 ms 64 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=2.55 ms 64 bytes from 172.16.100.1: icmp_seq=6 ttl=64 time=2.41 ms 64 bytes from 172.16.100.1: icmp_seq=7 ttl=64 time=2.63 ms 64 bytes from 172.16.100.1: icmp_seq=8 ttl=64 time=4.95 ms 64 bytes from 172.16.100.1: icmp_seq=9 ttl=64 time=2.57 ms 64 bytes from 172.16.100.1: icmp_seq=10 ttl=64 time=2.70 ms 64 bytes from 172.16.100.1: icmp_seq=11 ttl=64 time=2.89 ms 64 bytes from 172.16.100.1: icmp_seq=12 ttl=64 time=2.47 ms 64 bytes from 172.16.100.1: icmp_seq=13 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=14 ttl=64 time=2.33 ms 64 bytes from 172.16.100.1: icmp_seq=15 ttl=64 time=2.32 ms 64 bytes from 172.16.100.1: icmp_seq=16 ttl=64 time=2.54 ms 64 bytes from 172.16.100.1: icmp_seq=17 ttl=64 time=2.55 ms 64 bytes from 172.16.100.1: icmp_seq=18 ttl=64 time=2.58 ms 64 bytes from 172.16.100.1: icmp_seq=19 ttl=64 time=2.57 ms 64 bytes from 172.16.100.1: icmp_seq=20 ttl=64 time=2.40 ms 64 bytes from 172.16.100.1: icmp_seq=21 ttl=64 time=2.55 ms 64 bytes from 172.16.100.1: icmp_seq=22 ttl=64 time=2.54 ms 64 bytes from 172.16.100.1: icmp_seq=23 ttl=64 time=2.67 ms 64 bytes from 172.16.100.1: icmp_seq=24 ttl=64 time=2.38 ms 64 bytes from 172.16.100.1: icmp_seq=25 ttl=64 time=2.41 ms 64 bytes from 172.16.100.1: icmp_seq=26 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=27 ttl=64 time=2.43 ms 64 bytes from 172.16.100.1: icmp_seq=28 ttl=64 time=2.28 ms 64 bytes from 172.16.100.1: icmp_seq=29 ttl=64 time=2.54 ms 64 bytes from 172.16.100.1: icmp_seq=30 ttl=64 time=2.30 ms 64 bytes from 172.16.100.1: icmp_seq=31 ttl=64 time=2.41 ms 64 bytes from 172.16.100.1: icmp_seq=32 ttl=64 time=2.72 ms 64 bytes from 172.16.100.1: icmp_seq=33 ttl=64 time=5.14 ms 64 bytes from 172.16.100.1: icmp_seq=34 ttl=64 time=2.32 ms 64 bytes from 172.16.100.1: icmp_seq=35 ttl=64 time=2.51 ms 64 bytes from 172.16.100.1: icmp_seq=36 ttl=64 time=2.46 ms 64 bytes from 172.16.100.1: icmp_seq=37 ttl=64 time=4.58 ms 64 bytes from 172.16.100.1: icmp_seq=38 ttl=64 time=2.47 ms 64 bytes from 172.16.100.1: icmp_seq=39 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=40 ttl=64 time=2.30 ms 64 bytes from 172.16.100.1: icmp_seq=41 ttl=64 time=2.44 ms 64 bytes from 172.16.100.1: icmp_seq=42 ttl=64 time=2.38 ms 64 bytes from 172.16.100.1: icmp_seq=43 ttl=64 time=2.55 ms 64 bytes from 172.16.100.1: icmp_seq=44 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=45 ttl=64 time=2.30 ms 64 bytes from 172.16.100.1: icmp_seq=46 ttl=64 time=2.53 ms 64 bytes from 172.16.100.1: icmp_seq=47 ttl=64 time=2.43 ms 64 bytes from 172.16.100.1: icmp_seq=48 ttl=64 time=2.44 ms 64 bytes from 172.16.100.1: icmp_seq=49 ttl=64 time=2.41 ms 64 bytes from 172.16.100.1: icmp_seq=50 ttl=64 time=2.28 ms 64 bytes from 172.16.100.1: icmp_seq=51 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=52 ttl=64 time=2.40 ms 64 bytes from 172.16.100.1: icmp_seq=53 ttl=64 time=2.61 ms 64 bytes from 172.16.100.1: icmp_seq=54 ttl=64 time=2.51 ms 64 bytes from 172.16.100.1: icmp_seq=55 ttl=64 time=2.41 ms 64 bytes from 172.16.100.1: icmp_seq=56 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=57 ttl=64 time=2.39 ms 64 bytes from 172.16.100.1: icmp_seq=58 ttl=64 time=2.43 ms 64 bytes from 172.16.100.1: icmp_seq=59 ttl=64 time=5.81 ms 64 bytes from 172.16.100.1: icmp_seq=60 ttl=64 time=2.30 ms 64 bytes from 172.16.100.1: icmp_seq=61 ttl=64 time=2.54 ms 64 bytes from 172.16.100.1: icmp_seq=62 ttl=64 time=2.71 ms 64 bytes from 172.16.100.1: icmp_seq=63 ttl=64 time=3.32 ms 64 bytes from 172.16.100.1: icmp_seq=64 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=65 ttl=64 time=2.57 ms 64 bytes from 172.16.100.1: icmp_seq=66 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=67 ttl=64 time=2.45 ms 64 bytes from 172.16.100.1: icmp_seq=68 ttl=64 time=2.45 ms 64 bytes from 172.16.100.1: icmp_seq=69 ttl=64 time=2.57 ms 64 bytes from 172.16.100.1: icmp_seq=70 ttl=64 time=2.65 ms 64 bytes from 172.16.100.1: icmp_seq=71 ttl=64 time=2.45 ms 64 bytes from 172.16.100.1: icmp_seq=72 ttl=64 time=2.52 ms 64 bytes from 172.16.100.1: icmp_seq=73 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=74 ttl=64 time=2.45 ms 64 bytes from 172.16.100.1: icmp_seq=75 ttl=64 time=2.80 ms 64 bytes from 172.16.100.1: icmp_seq=76 ttl=64 time=2.72 ms 64 bytes from 172.16.100.1: icmp_seq=77 ttl=64 time=2.66 ms 64 bytes from 172.16.100.1: icmp_seq=78 ttl=64 time=2.31 ms 64 bytes from 172.16.100.1: icmp_seq=79 ttl=64 time=2.65 ms 64 bytes from 172.16.100.1: icmp_seq=80 ttl=64 time=2.54 ms 64 bytes from 172.16.100.1: icmp_seq=81 ttl=64 time=2.38 ms 64 bytes from 172.16.100.1: icmp_seq=82 ttl=64 time=2.29 ms 64 bytes from 172.16.100.1: icmp_seq=83 ttl=64 time=2.55 ms 64 bytes from 172.16.100.1: icmp_seq=84 ttl=64 time=2.27 ms 64 bytes from 172.16.100.1: icmp_seq=85 ttl=64 time=7.72 ms 64 bytes from 172.16.100.1: icmp_seq=86 ttl=64 time=2.31 ms 64 bytes from 172.16.100.1: icmp_seq=87 ttl=64 time=2.58 ms 64 bytes from 172.16.100.1: icmp_seq=88 ttl=64 time=2.29 ms 64 bytes from 172.16.100.1: icmp_seq=89 ttl=64 time=2.30 ms 64 bytes from 172.16.100.1: icmp_seq=90 ttl=64 time=4.36 ms 64 bytes from 172.16.100.1: icmp_seq=91 ttl=64 time=2.73 ms 64 bytes from 172.16.100.1: icmp_seq=92 ttl=64 time=2.42 ms 64 bytes from 172.16.100.1: icmp_seq=93 ttl=64 time=2.30 ms 64 bytes from 172.16.100.1: icmp_seq=94 ttl=64 time=2.55 ms It looks normal, no glitch. This driver update was already pushed into most kernels. Same results with 8814 or 8812, both test were made on 2.4 band.
AlexisTM Posted February 12, 2018 Posted February 12, 2018 @Igor Yours has no issue so far Could you provide me with the details of the USB adapter you are using so that I can buy the same ones
Igor Posted February 12, 2018 Posted February 12, 2018 Bus 001 Device 010: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter Bus 001 Device 008: ID 0bda:a811 Realtek Semiconductor Corp. Bus 001 Device 012: ID 0bda:8813 Realtek Semiconductor Corp. Serial # [ 1560.988790] usb 1-1.4.4.2: Product: 802.11ac NIC [ 1560.988802] usb 1-1.4.4.2: Manufacturer: Realtek [ 1560.988813] usb 1-1.4.4.2: SerialNumber: 123456 8814 https://www.gearbest.com/network-cards/pp_625323.html 8811 https://www.gearbest.com/network-cards/pp_613225.html 8812 is no name from eBay. It looks like this one. Try again building from sources, Odroid XU4 NEXT ... I just pushed patches up. Those are tested.
funkypunkskunk Posted January 11, 2019 Posted January 11, 2019 On 4/15/2017 at 12:50 PM, tkaiser said: This should work in both Debian Jessie and Ubuntu Xenial: git clone https://github.com/gnab/rtl8812au sed -i -e 's/CONFIG_PLATFORM_I386_PC = y/CONFIG_PLATFORM_I386_PC = n/' \ -e 's/CONFIG_PLATFORM_ARM_RPI = n/CONFIG_PLATFORM_ARM_RPI = y/' rtl8812au/Makefile sudo apt install build-essential dkms sudo mv rtl8812au /usr/src/8812au-4.2.2 sudo dkms add -m 8812au -v 4.2.2 sudo dkms build -m 8812au -v 4.2.2 sudo dkms install -m 8812au -v 4.2.2 And this is the result: root@clearfogpro:~# iwconfig wlan0 wlan0 IEEE 802.11an ESSID:"Snort-Honeynet 5GHz" Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency:5.2 GHz Access Point: BC:05:43:BE:C1:E3 Bit Rate:300 Mb/s Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:****-****-****-****-****-****-****-**** Security mode:open Power Management:off Link Quality=100/100 Signal level=68/100 Noise level=0/100 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Sorry if i'm an idiot but I can't compile that driver on my system. Relevant armbianmonitor -U https://pastebin.com/6Q9Rhjay And this is the error log: KMS make.log for 8812au-4.2.2 for kernel 4.4.167-rockchip64 (aarch64) Fri Jan 11 10:06:21 UTC 2019 make ARCH=arm CROSS_COMPILE= -C /lib/modules/4.4.167-rockchip64/build M=/var/lib/dkms/8812au/4.2.2/build modules make[1]: Entering directory '/usr/src/linux-headers-4.4.167-rockchip64' CC [M] /var/lib/dkms/8812au/4.2.2/build/core/rtw_cmd.o gcc: error: unrecognized argument in option ‘-mabi=apcs-gnu’ gcc: note: valid arguments to ‘-mabi=’ are: ilp32 lp64 gcc: error: unrecognized command line option ‘-mapcs’; did you mean ‘--specs’? gcc: error: unrecognized command line option ‘-mno-sched-prolog’; did you mean ‘-Wno-sign-promo’? gcc: error: unrecognized command line option ‘-msoft-float’ scripts/Makefile.build:277: recipe for target '/var/lib/dkms/8812au/4.2.2/build/core/rtw_cmd.o' failed make[2]: *** [/var/lib/dkms/8812au/4.2.2/build/core/rtw_cmd.o] Error 1 Makefile:1493: recipe for target '_module_/var/lib/dkms/8812au/4.2.2/build' failed make[1]: *** [_module_/var/lib/dkms/8812au/4.2.2/build] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-4.4.167-rockchip64' Makefile:1064: recipe for target 'modules' failed make: *** [modules] Error 2 Is this related to settings in gcc? I can't seem to find a google answer to the error message either. Any clue as where to begin reading?
Igor Posted January 11, 2019 Posted January 11, 2019 14 minutes ago, funkypunkskunk said: Sorry if i'm an idiot but I can't compile that driver on my system. No, it's a known problem - driver compilation breaks on aarch64 kernel version 4.4.y only. We pack this driver (a better version of it) inside all kernels but 4.4.y since we don't have resources to fix 3rd party wireless drivers. Sometimes yes, but generally no.
funkypunkskunk Posted January 11, 2019 Posted January 11, 2019 2 hours ago, Igor said: No, it's a known problem - driver compilation breaks on aarch64 kernel version 4.4.y only. We pack this driver (a better version of it) inside all kernels but 4.4.y since we don't have resources to fix 3rd party wireless drivers. Sometimes yes, but generally no. Thanks Igor for the answer. I've been reading a lot of other forum replies by you and tkaiser and you are generally helpful despite the overwhelming amount of questions you get on this forum. I have a tinkerboard and my usb wifi works great there (with armbian) and i've been trying to figure out what the problem could be. Is there a roadmap to up the kernel version or should i just go for another distro, or check if I can resolve it myself?
Igor Posted January 11, 2019 Posted January 11, 2019 12 minutes ago, funkypunkskunk said: Is there a roadmap to up the kernel version or should i just go for another distro Other distros are far behind and they surely weren't able to solve such problems. Just to save you time lost on "distro hopping". If you want to run this wireless chip OOB - all you need to do is to upgrade a kernel to 4.19.y. armbian-config -> beta repository (reboot and once again) -> alternative kernels -> DEV. But it is beta ... no need to search around. This is the best possible atm. We will perhaps create roadmaps, when projects costs will not be almost fully on our private cash.
funkypunkskunk Posted January 11, 2019 Posted January 11, 2019 6 minutes ago, Igor said: Other distros are far behind and they surely weren't able to solve such problems. Just to save you time lost on "distro hopping". If you want to run this wireless chip OOB - all you need to do is to upgrade a kernel to 4.14.y or to 4.19.y (in a few days). armbian-config -> alternative kernels -> DEV. But it is beta ... We will perhaps create roadmaps, when projects costs will not be almost fully on our private cash. Thanks! I've made a small donation for the effort you are doing. I'll be sure to try the devel-kernel in a few days. 1
Igor Posted February 7, 2019 Posted February 7, 2019 On 1/11/2019 at 1:35 PM, funkypunkskunk said: but I can't compile that driver on my system. New driver is coming: https://github.com/armbian/build/commit/9758711ed42e345453eddc4b3314f8eaf81d01b5 Also working fine on 4.4.y kernels.
funkypunkskunk Posted May 10, 2019 Posted May 10, 2019 On 2/7/2019 at 3:36 PM, Igor said: New driver is coming: https://github.com/armbian/build/commit/9758711ed42e345453eddc4b3314f8eaf81d01b5 Also working fine on 4.4.y kernels. I tried the tinkerboard and starting an access point via USB Wifi works just fine there. I've experienced no problems with different computers and phones. Using the same dongle for Wifi to create an access point with the rock64 isn't really as stable.. don't know what the problem might be. Connections are broken for some devices, and sometimes it's impossible to log on to the access point. So for the tinkerboard it works just fine, not so much for the rock64. If the drivers are fine then it's probably some other software related problems. Thanks for the update Igor!
Recommended Posts