Posts by chewitt

    The 3.5mm Jack output should work *but* you'll need to fiddle with OS level mixer settings to route the audio correctly and get output. I'm not sure if some alsa conf fu can be used to route to both Jack and HDMI at the same time (maybe)? but alsa configuration is one of Linux's "dark arts" so it's not something I've done much experimenting with.

    The main difference with CE is the lack of 4K/VP9/HEVC support on G12A/B and SM1 hardware and overall playback with HEVC on all hardware due to lack of development on the upstream hardware codecs. However if you only need 1080p it's possible to software decode everything comfortably with nice results on hardware like N2 with a huge heatsink to keep things cool. LE also supports (with caveats) older hardware which CE has now dropped support for and the state of hardware decoding on older hardware is better than new; as the current upstream code was developed for older hardware and there are fewer newer-hardware features missing (not the best reason, but still a valid reason).

    After upgrading to the kernel 5.18.3, the USB stack of my S912 was not working properly. Reversing the commit: 6c64a664e1cff339ec698d803fa8cbb9af5d95ce "xhci: Set HCD flag to defer primary roothub registration" of the kernel fixes the issue.

    Confirmed on another S912 device (VIM2) although I see no issues on an older S905 (WP2) and newer S922X (N2+) device. I reported it to the linux-usb mailing list - let's see what maintainers say. If no eureka moment in a couple of days I'll push a revert patch to nightlies.

    Testing with 5.19-rc1 flagged some patches I'd had picked from one of the mailing lists, and after dropping those USB works, so I've pushed an updated patchset to LE main repo. It should get merged for next nightlies.

    The project has a long-standing and well documented hatred of Realtek WiFi chips that require out-of-tree drivers that break (or require new patches) with every kernel bump we make (often). So we stopped adding drivers on user request several years ago; the exception being when it's a simple patch to add a device ID or such to an existing in-kernel driver which we can send upstream.

    There are two ways forwards. You can either self-compile an LE image with the driver you found included - all Realtek drivers follow the same build recipe so it's never that complicated to clone/adapt the recipe for an existing card with the required details to get something to build. Or you swap to use a different USB WiFi device which is supported in the upstream kernel and doesn't need drivers. However don't ask for a list of supported devices as there isn't one; because creating one and then maintaining it would be even more work than supporting the ever-growning list of shitty realtek drivers in the first place.

    From Linux 5.19 there is a native driver for several types of VFD display in the kernel which allows the config to be set in device-tree and sent upstream. I have the driver in current LE images but some effort will need to be made on figuring out the configs (CE confs will be useful but they are not copy/paste the same) and right now I have almost zero time for the effort. LE dropped OpenVFD when the author relicensed the driver module as GPLv3. This has no functional impact on the driver, but makes the module license incompatible with a GPLv2 kerrnel, and LE cares about that kind of thing.

    1. No. S905X is quite well supported. The issue with most W/Y boxes is they are super low-spec with 1GB RAM which means forget 4K.

    2. Yes, because the blobs are firmware and old vendor kernels and moder kernels use the same firmwares. Drivers are something different.

    3. The current upstream drivers were written for GXL/GXM; they don't work as well on newer G12/SM1 hardware as this neeeds updates to some of the codec drivers (which nobody made) and older S905 devices don't support HDR and VP9. Newer boxes have more CPU grunt so most of the time you can disable hardware decoding and software decode (1080p is great, forget 4K).

    4. Allwinner and Rockchip are both well quite supported with older chipsets and there is considerable active development on support for newer chips. LE contributors are heavily involved in the kernel V4L2 stateless decoding efforts.

    The S905 chip requires magic boot code in the first sector of emmc which is the same location for partition records, so in theory you can't have modern u-boot on emmc and then boot an OS that needs to read partition data from the same location; they are mutually exclusive. SD cards boot from a different offset which isn't an issue. So the box must boot from SD card and the only way to force that is to erase vendor u-boot from eMMC (else it's detected and used). NB: The Odroid C2 has some special boot firmware that solves this, but the firmware is packaged to hide how it's done and nobody ever figured it out.

    As the WP2 is going to boot LE11 from SD card in all scenarios there's not much difference between using the "box" image via vendor u-boot and the upstream u-boot image. See if the "box" image fits your needs first before doing anything more.