Posts by chewitt

milhouse ^ can we revert the removal or re-add that firmware

Commercial entities posting in our forums are asked (under forum rules) to declare themselves so other users (and forum staff) are aware they are not normal users. So I must ask .. what company is the "we" you are representing?

Current 9.0 releases will ship on ye olde Amlogic 3.14 kernel. At some point between 9.0 and 10.0 we will switch to mainline. Depending on your needs or expectations the current state of things is either awesome or missing major/essential capabilities (grab a balbes150's test images if you like). IMHO there are still some key milestones to achieve before we encourage wider public testing.

If someone wants to PR a working Rockchip 4.4 device tree to Kwiboo on GitHub i'm sure he will merge the PR and we can add it to the current "Alpha" build roster. I wouldn't expect to see mainline images for some time yet.

Playing video doesn't generate much load (as it's hardware decoded) so I would assume it's fine. That's not a promise though

LE plans to drop support for the 3.10 kernel after LE 9.0 ships so even if your efforts succeed the code lifespan will be limited. It would be better to invest in a USB tuner that "just works" today and can be reused on a future replacement device (that should be running a mainline kernel).

Client and server functions will come from different binaries that potentially use different configs depending on how the binaries were compiled. It's unusual, but also not without precedent.

If you can tell us which chip is in the box .. we can advise how it might be supported (or not). Otherwise it's a blind guess. That probably requires you to open up the box.

The odd thing is that the 97-xorg.rules udev file should select the Intel GPU if present, as it evaluates in this order:

LibreELEC.tv/97-xorg.rules at master · LibreELEC/LibreELEC.tv · GitHub

Perhaps blacklist the AMD kernel driver and put a modified version of 97-xorg.rules in /storage/.config/udev.rules.d/ that removes the AMD criteria. In that scenario it cannot then choose the AMD card even if present.

Honestly.. no idea.

I'm not sure if /storage/.config/asound.conf still works as an alsa override, but you can try. That said I doubt we have all the plugins you're looking for to do complex things. You might have more success with a custom pulseaudio connection. Even then that's complicated and there's no HOWTO guide for it. It would be easier on something with Raspbian where you have GUI tools available.

SSL certificates on our repo have a validity period (start date and end date) and until the time is set the system clock has datetime before the start date so the certs are invalid and connections (correctly) fail. In our testing the WiFi performance on 3B+ is reasonable and fully supported. The current beta has newer firmware that should perform better than the first (8.2.5) release. It's also possible that a USB device with a larger antenna may perform better in your environment.

I've read the posts twice and I can see all kinds of connection info and arrows, but it's still unclear to me what you are actually trying to achieve?

There is zero support for S905X2 (and Y2/D2 or S922) and that's not likely to change for some time.

Different hardware running a different OS using different drivers and different apps = different result. Deinterlace isn't configurable without writing new code and it's one of the uglier parts of the current Amlogic kernel codebase.

The open-source group at ARM are actively tracking lima/panfrost and hope to get clearance to contribute. Regardless of if/when that comes, once lima and panfrost are viable on RK and Allwinner hardware we'll switch to them because we want to support open-source development and it will make our distro packaging a lot easier. Tracking mainline kernel and mainline mesa (which we already do) for all three platforms instead of each SoC or board needing a different kernel driver and blob will be a huge bonus. The nice thing for RK support is that we can choose when to dump the blob and switch, whereas S912 has to blaze a trail with early stage development code.

I'm expecting a few disgruntled users when we drop WP1 as it was popular and has a reasonable sized active userbase, but as the gap between the rest of the codebase and 3.10 widens we started to see breakage, and while we can make fixes there are no active team members running WP1 (or WC) as a daily-driver now so it's become a challenge to prove fixes before release. So far we haven't shipped anything untested but the number of near misses where positive confirmation is received hours before release (and after lot of nagging) is increasing. We'd prefer to stop than compromise one of our project promises.

No idea. Some VLC devs occasionally attend Kodi devcon to drink beer and share ideas, but we're not VLC and not party to their ideas. You'll have to ask them directly

Milhouse embeds addons and prefixes with 999 to ensure the embedded ones overrule any existing version the user has installed. As it's embedded in the read-only SYSTEM file it cannot be uninstalled. FYI, the embedded 2.3.11 addon is newer than 2.3.6, so you have the latest version.