On my Beelink Mini MX (Beelink Mini MX Ver 1.0 TV Box 2G/16G Amlogic S905) wifi does not work any more in build 8.2.2.3.
Wifi did work in 8.2.2.2.
kszaq want me to provide a log?
Yes, please.
On my Beelink Mini MX (Beelink Mini MX Ver 1.0 TV Box 2G/16G Amlogic S905) wifi does not work any more in build 8.2.2.3.
Wifi did work in 8.2.2.2.
kszaq want me to provide a log?
Yes, please.
8.2.2.3 build is now available to download. Due to updated WiFi drivers - unlikely possibility of network loss - automatic update is currently disabled.
If no new WiFi issues are reported, I will enable automatic update for all boxes on Monday.
Edit: auto-update enabled.
8.2.2.3 build is now available to download. Due to updated WiFi drivers - unlikely possibility of network loss - automatic update is now active only for C2 and LePotato builds as these boards don't have built-in WiFi.
If no new WiFi issues are reported, I will enable automatic update for all boxes on Monday.
Let us all test the drivers, auto-update enabled. I haven't faced any issues on all my S905(X) devices.
Your box might have fake RAM.
Here's an easy way to check: if you have Android 7.1 installed on internal memory of your box, simply delete dtb.img from SD card that you run LE from and boot into LibreELEC. That way LibreELEC will use the very same device tree Android uses and you will see what is the real RAM capacity Android uses.
4kfreak E.g. add this to /storage/.config/autostart.sh:
I am sorry GDPR-2 if I sounded a bit harsh, no offence taken and I hope it's mutual.
It was not an accusation it was more of an observation because it is not the first time link.
GPL doesn't oblige you to push the code every time you publish something, it requires you to make code available on demand. It is a courtesy that we all push our code to GitHub. I don't want to argue, it's just sometimes there's too much side work and we forget about things.
As for the fork it is a community fork which is in the process of being upstreamed, so I would hope you contribute further work there to benefit everybody moving forward.
I have explained in personal conversation that I have no time to work on Leia, at least not now and I won't push anything I can't test.
The above goes for you as well kszaq
It's really nice to hear personal accusations after issuing a general statement, isn't it?
I would like to see some of your work being pushed upstream rather than me having to follow your changes every week, cherry pick and then push, it is very time consuming and also somewhat frustrating
There is no "upstream" for my work. There's LE master where the code was pushed by you and you stepped up to maintain it. And if you speak about your personal fork, you shouldn't expect the original author to maintain a fork.
I've already pushed all my Kodi patches upstream.
even more so when you forget to push your changes at all and one of us has to poke you to remind you.
I guess forgetting once (on New Year's Eve) to push 4 commits relevant to the very popular Le Potato board hurt many people? Especially that I pushed them a few hours later.
Instead we have bunch of different builds from different people. Which is very bad and totally unnecessary.
Actually we have Krypton builds from me and Leia builds here. I think there is acceptance to have Amlogic support in master LE branch, the thing that really requires work is getting rid of the hackfest (I'm mostly responsible for it...) as much as possible.
It depends on you (you, adamg, raybuntu...), or basically it has to be done on baylibre side?
It requires the whole vdec part to be rewritten almost from the scratch to properly support V4L2. I don't think Adam, Ray or me have that deep knowledge to do this, it certainly requires involvement from Amlogic (and perhaps BayLibre if they're contracted to do this part).
Whats's the issue which is causing that delay in support hw decoding in the ml kernel? Can you give us any clue?
It needs to be implemented, which is anything but trivial task.
Given that Amlogic devices do not conform to the above and it is unlikely that they will, it basically means we are working with devices with a limited lifespan in terms of Kodi support.
It would take me far too long to explain the full details of absolutely everything but it appears S912 may survive, S905 and S905X there is uncertainty and S8XX will be guaranteed to be dropped.
Not precisely. It is quite possible that S9xx (i.e. S905, S912 and so on) will get v4l2 in mainline kernel. For now most of S905/912 pieces are already supported in mainline, the main thing that is lacking is hardware decoding support. When this happens, we will finally be able to use mainline kernel on our devices.
What will be dropped are 8726MX, S805, S802 and S812 devices as they're very unlikely to get full mainline support.
I'm on version 8.2.1.1 and auto update doesn't seem to work for me.
In LE setrings i set auto update from manual to auto and restarted. But nothing seems to happen, still on version 8.2.1.1
Any ideas?
Please look at the changelog. Auto update is working since 8.2.1.2, it was disabled for 8.2.1.1.
The command to look up dtb name in my most recent builds is /proc/device-tree/le-dt-id
kszaq I've used your builds on various S905/S905X boxes and haven't had an issue before, but one box (mxq pro 4k) appears to generate a random mac address for wifi every boot. I know that you added some code to correct that, and pull it from the SoC, but even using 8.2.2.2 it has the same issue. What information would be useful for you to help debug?
Thanks!
I developed a fix only for Ethernet, not WiFi. You should at least post dmesg collected after booting to see it there's a chance for fixing this.