Posts by chewitt

    In some forums that would be handled by signatures. We used to have signatures active, but it's one of the primary targets for spammers to add link-farming spam to. We also have too many users that think text in distracting weird colours and abnormally large font sizes is great visual design, and a small number harbouring a beef with other forum users and long-term project members who like to add messages that are basically offensive. So signatures have been turned off. Anything that provides a Google scrape-able alternative would likely suffer from the same issues, so I appreciate the idea but we aren't likely to do anything like that.

    NB: Anything that's of general benefit to our user audience can (and should) be put in the wiki, which is open for anyone to send changes to through a GitHub pull request.

    There are no "apps" but there are "add-ons" for a range of useful LE related things in the LE repo, including Docker which opens the door to more unusual things. There are no browser add-ons for ARM devices.

    The work to support WireGuard was done by me (not the worlds best script/coder) and with a single use-case in mind: routing all traffic to my home network so I can watch content from home or bypass geoblocking to stream content as if at home (not the hotel in a foreign country I'm often at). I originally used a simplified homebrew version of wg-quick which worked but had lots of logic holes and was hacky. Then I had a chat with Daniel Wagner (ConnMan dev) and that encouraged ConnMan to gain support for WireGuard in the VPN module. This continues to support my use-case and has the added benefit of making connections on/off controllable through the LE settings add-on.

    I've no issues with people enhancing the current arrangement, but a) nobody has ever proposed any alternative (via pull request on GitHub), and b) it would need to be a well tested and robust arrangement not the usual "look mum, I made the lights blink" level of beginner script mess that we typically see in the forums. The best approach would be submitting code to ConnMan to address whatever missing feature or bug exist because then ConnMan owns the maintenance of the feature, not LE, where things often get overlooked.

    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.