Posts by axel

Yasai-san  Da Flex this is very helpful, thanks!

Quote from chewitt

axel I've spoken to Radxa about the AIC8800 wireless chip a couple of months ago as it's also fitted to one the boards I've been using to test. Radxa have no plans to upstream the driver as this would require a large effort, i.e. complete rewrite as the current quality of driver code would never be accepted into the kernel, and after years of working to rid our codebase of the maintenance burden of downstream (mostly Realtek) drivers we have no desire to add technical dept in the form of another vendor driver that has no plan to be upstreamed. I've shared our surprise/annoyance and position, and have strongly suggested they stick to using Broadcom, Qualcomm, Realtek (now upstream) chips in future iterations of current boards and future board designs so distros can avoid the need for crap drivers. I'm not sure LibreELEC's opinion will carry much commercial weight with them, but from our side, there's no action to be taken.

Thanks for the detailed answer, it's appreciated. I understand and support your position, from a LE project perspective.

From a "how do i get this device to do what i want" perspective, it sounds like i need to learn to build LE and add the driver in my image, to get it to get usable wifi? or add an external wifi adaptor, which is a lot simpler, a bit sad considering it has onboard wifi, and not as fun (probably type-2 fun though, lets' be honest). Or run Armbian / Radxa Debian and make it boot into Kodi.

I was able to get some logs from Radxa Debian: https://paste.debian.net/hidden/8b8084a4

Of note (i think) is: kernel: rwnx_load_firmware :firmware path = /lib/firmware/aic8800_fw/SDIO/aic8800D80/fmacfw_8800d80_u02.bin

This and other similar patches + a config are loaded.

This appears to be https://github.com/radxa-pkg/aic8800/ or https://github.com/shenmintao/aic8800d80

I will try to get a log, I was a bit lazy the other night as there was no immediate way of SSHing into the device.

Or I currently have the Radxa Debian SD inside: with some minimum help I can confirm what firmware and kernel module are being loaded.

I'd edit my previous message, but can't apparently.

I just checked by booting Radxa's official Debian image, and wifi and bluetooth work fine.

Also, i got worried they'd sent me the wrong board as LE was only reporting 4GB of RAM, instead of 8. But no, there are 8 gig, htop and free -m confirm it. So it appears that's another issue with the LE image, it only reports 4GB of RAM out of 8GB.

I just tried out the LibreELEC-RK356X.aarch64-12.90.1-radxa-zero-3.img.gz image on a newly bought Zero 3W, and it booted fine however, no wifi card appears to be detected, nor bluetooth.

Is this to be expected?

I just tried Milhouse's latest LibreELEC build, and there is no OS level NFSv4 support.

But there is Kodi-lever support, which I think is what the logs refer to.

Thanks CvH, great to see NFS kernel support work happening. That would really be a superior option to mounting via Kodi!

Hi. I'd just like to clear this up and check I've got it right:

• there is currently no NFSv4 support in LibreELEC because of limitations with busybox (tested and confirmed in the current latest stable: LibreELEC (official): 8.2.5 (Generic.x86_64))
• there is NFSv4 support in community builds such as Escalade's (along with a wide selection of extras)
• there is NFSv4 support in test builds by Milhouse, such as this Kodi 18 Leia build #0111 (cf. change log)

So my choices are to go with a community build or a test build, to get NFSv4 support.

I also understand that Milhouse's test builds are designed to test features that will be included in LibreELEC official, so does this mean NFSv4 is planned to come to LibreELEC official? This is in contradiction to what Irusak was saying:

Quote from lrusak

possibly in the future. However busybox mount does not support nfsv4 so it would require switching to util-linux and adding nfs-utils which isn't really desired at the moment.

Clarifications welcome Thanks!

Quote from dahmage

I just had this issue after upgrading from fedora 24 to 25. the only difference i know of is that now i am using a Wayland session instead of X? this trick worked, but i wonder if it is a wayland related issue.

Yes, this completely has to do with Wayland, which is now the default graphical server in Fedora 25.
Wayland, by design, does not let another user (root in our case) access what our user is doing in their session on the graphical server. So when root tries to open its window in another user's (ie: our user's) graphical session, Wayland (rightly) denies it.

The fix suggested,

xhost +

allows any and all users to access the current users' graphical session.

If you find this a bit much, you can allow only root to access your current session, with the following:

xhost si:localuser:root

Once you've finished using the app you want as root, you can remove root from the list of allowed users with:

xhost -si:localuser:root

Hope this helps. At the end of the day, a better solution (using the suggestions in this bug: Bug 1274451 – sudo with graphical apps doesn't work on wayland) should probably be used, as this is really just a workaround (and end-users shouldn't have to be doing this).