It was probably visible under Android. It won't show under Linux (if it did, the WiFi would probably work). You'll need to open the box, take pics and share them so someone can see what wifi chip/module is used. Then if someone has enthusiasm, some device-tree experiments can be done to enable the card or add the missing driver - no idea what the issue is until we know what hardware is involved.
Posts by chewitt
-
-
Out of interest, with the recent release of Steam Link for more systems by Valve, and the changes for the latest Kodi 19 build on the much newer kernel, does that give any better possibility for Steam Link to work on LibreElec on a Pi4 please? Wondering whether I can do away with my separate RetroPie device at some point and just have the one.
No support for the GBM/V4L2 interface now used in RPi4 and Valve continue to package their pre-compiled stuff around the assumption of a desktop distro which makes it unsuitable/impossible to repurpose.
-
I don't see a single good reason why anyone should bother with passthrough.
I run a moderately high-end AVR and speakers arrangement that does a much better job at converting HBR audio into awesome sound than the Kodi PCM output does. So (playing with words) I don't see a good reason, but I frequently hear one.
-
so in other words: Libreelec/the drivers actively cock up the simple task of playing the video "as-is" and rather crop/strech the half of it as if I selected to play it as 2D (there is an option for that)
Your overly simplistic assessment of simple task ignores how Kodi rendering and playback actually work, and an entwined combination of kernel drivers, kodi, and ffmpeg need to all be in sync for 3D to work. This time around neither LE or Kodi (or the Pi Foundation) are going to accept a huge invasive patchset that can never be upstreamed (which is the situation for the current RPi3 code) so it will either be done properly (and upstreamed) or not done at all. I've clarified with the devs that TAB/SBS are reasonable to implement, MVC is not, MVC via ISO is unlikely to ever be done, and 3D support overall is in the priority list for "when we did everything else" .. so I wouldn't hold breath.
-
People keep quoting the "many would like to encrypt their devices" line to us yet these images which support that have existed for an extended period of time and user numbers remain consistently between 20-30 users total. It's much like how people seeking 4K HDR with DolbyVision support insist that everyone needs it, yet stats show 60% of our userbase runs an RPi board that can't run over 1080p. This is niche and there are no plans to add it into the core distro. Yes user numbers would increase if we did bake it in, but from exprience within our userbase I'd expect 2x to 3x the number, not the 1000x increase that would justify making the change. I'm sure these images will continue to exist and support the limited numbere who do care about encrypting data.
-
I have no memory of users raising issues with 3D in the Generic/PC image but that probably means support doesn't exist (and thus nothing to have a problem with) rather that it works problem free. We don't have a bounty system, and development for 3D things will be done by the Pi Foundation devs so donations to LE are always welcome but won't influence the people who need to write the code. It's on their list, but other things have priority.
-
One of our devs is considering writing a proper PipeWire audio sink for Kodi, but that's only the first step in a long journey.
-
LE master switched curl from building against gnutls to openssl so add-ons will need to be rebuilt.
-
I replied to the other thread you created. Don't cross post please.
-
LE is dependent upon upstream sources to write/merge code for that kind of thing. Pulse recently merged some initial LDAC support, but reading the merge requests on their GitLab instance this appears to be written entirely around gstreamer which we currently don't use or package - and wouldn't really want to add. So "support" for LDAC probably needs to percolate through the software ecosystem around pulse a bit more before we'd be able to do much about it - we have no current plans and it's not really on anyone's radar (AFAIK).
-
LE will package whatever support is available in the upstream kernel, backported if necessary, but we're not going to write kernel audio driver code to add support. So best to ask that Q to Intel audio devs - who will write the code.
-
You have banned add-ons installed. There will be no support until you come back with a clean system.
-
Best to ask bite_your_idols who creates/maintains the Gamestarter repo.
-
Kodi already has lots of great skins for people to choose from, and a small army of skinners who slave away at their creations; it's not a small task to create and then maintain a skin over time. LE staff are not skinners .. so best we don't take on that task.
-
No change. I'm sure 3D will get done (one of the Pi Devs has a compatible TV and likes it) but it's not the highest priority.
-
IIRC the RPi3B/3B+ are the only Pi models with fully functional 3D support. There are IP differences in the RPi4 video pipeline which were never fully accounted for under the legacy codebase (LE 9.2) and 3D is not yet implemented under the new GBM/V4L2 pipeline (LE 10.0): there are plans to add support but things like 4K60 playback, HDR, and hardware deinterlacing which have a broad audience appeal (3D is quite niche these days) have a higher priority with the Pi Foundation devs doing the work.
-
IIRC the waipu.pvr add-on is a recent addition to the Kodi repo and has been developed against Kodi Matrix so there is no Leia version.
-
To clarify "not possible" .. the OMX and MMAL decoders no longer exist in Kodi, hence you cannot use them
See drop omxplayer by Rechi · Pull Request #16080 · xbmc/xbmc · GitHub and RPi: remove platform by lrusak · Pull Request #16321 · xbmc/xbmc · GitHub
Developing GBM/V4L2 without gutting the old methods first would be a) more complicated, b) take several years longer because experience shows quite clearly that developers never invest the huge time/effort required to implement new methods when the old ones are still around.
