RetroELEC Kodi+Wayland+Emulationstation+RetroArch (x86/XU4/RPi)

    jaykass

    That depends on what kind of PR's, adding packages for them isn't an issue. I might add them for RPi/Odroid, but the generic images is almost at 512MB already.

    Liquidmercury

    No worries, just explaining that the PCSX2 emulator there is the exact same as I use so I can't really understand that you were able to launch games with your Celeron. Perhaps he made a build with the new "Play" core, I don't know.

    New generic image is out.

    Quote from Liquidmercury

    I think I was pulling the wrong log files, was pulling the last set not second from last. Sorry brain fart on my part hopefully this is what you need.

    Per a response Escalade had earlier to a question of mine, those logs seem to be created when you connect to the share. So, you'll want to boot your system, trigger the error, and then pull the latest logs before rebooting again.

    installed the latest generic build (from the 29th). Installation from scratch worked. Kodi works fine.

    Firefox starts up, but as soon as I play a video from youtube, it crashed within 10 to 30 seconds.

    Sometime the display freezes for seconds. Same stuff I reported a few days ago.

    Those problem seemed to have been fixed about a week ago.

    Logfiles attached. Please let me know, if I can provide any further info.

    Quote from escalade

    mtk1

    Looks like Sway triggers a bug in the i915 kernel driver. Doesn't happen here on the latest image, give it a try.

    slacker666

    I have no idea, so go with generic.

    A slight improvement I would say. But, eventually FF still hangs and eventually crashes.

    This problem was gone (for me) with the -rc6 kernel. More patches went in before the final release.

    So, maybe it's a kernel issue ?

    Or, did you configure FF differently at the time of the -rc6-based builds (10...14 days ago) ?

    dmesg:

    [ 1979.399923] Asynchronous wait on fence i915:sway[1357]:48b0 timed out (hint:intel_atomic_commit_ready+0x0/0x54)

    [ 1983.473520] i915 0000:00:02.0: GPU HANG: ecode 8:1:0x85dffffb, in sway [1357], stopped heartbeat on rcs0

    [ 1983.473524] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.

    [ 1983.473525] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel

    [ 1983.473526] drm/i915 developers can then reassign to the right component if it's not a kernel issue.

    [ 1983.473527] The GPU crash dump is required to analyze GPU hangs, so please always attach it.

    [ 1983.473528] GPU crash dump saved to /sys/class/drm/card0/error

    [ 1983.576026] i915 0000:00:02.0: Resetting rcs0 for stopped heartbeat on rcs0

    [ 2078.791318] perf: interrupt took too long (2520 > 2500), lowering kernel.perf_event_max_sample_rate to 79200

    [ 2287.443598] Asynchronous wait on fence i915:sway[1357]:875a timed out (hint:intel_atomic_commit_ready+0x0/0x54)

    [ 2292.665644] i915 0000:00:02.0: Resetting rcs0 for stopped heartbeat on rcs0

    [ 2303.443252] Asynchronous wait on fence i915:sway[1357]:8764 timed out (hint:intel_atomic_commit_ready+0x0/0x54)

    [ 2307.599778] i915 0000:00:02.0: Resetting rcs0 for stopped heartbeat on rcs0

    [ 2343.643548] docker0: port 1(veth7fa588b) entered disabled state

    [ 2343.643827] veth7ec5664: renamed from eth0

    [ 2343.708970] docker0: port 1(veth7fa588b) entered disabled state

    [ 2343.723557] device veth7fa588b left promiscuous mode

    [ 2343.723565] docker0: port 1(veth7fa588b) entered disabled state

    [ 2346.535583] Asynchronous wait on fence i915:sway[1357]:8cf2 timed out (hint:intel_atomic_commit_ready+0x0/0x54)

    [ 2350.478511] i915 0000:00:02.0: Resetting rcs0 for stopped heartbeat on rcs0

    [ 2366.751954] docker0: port 1(veth687e866) entered blocking state

    [ 2366.751958] docker0: port 1(veth687e866) entered disabled state

    [ 2366.752741] device veth687e866 entered promiscuous mode

    [ 2367.249717] eth0: renamed from veth4daef5d

    [ 2367.263889] IPv6: ADDRCONF(NETDEV_CHANGE): veth687e866: link becomes ready

    [ 2367.264018] docker0: port 1(veth687e866) entered blocking state

    [ 2367.264025] docker0: port 1(veth687e866) entered forwarding state

    [ 2437.514826] i915 0000:00:02.0: Resetting rcs0 for stopped heartbeat on rcs0

    [ 2483.594441] i915 0000:00:02.0: Resetting rcs0 for stopped heartbeat on rcs0

    [ 2507.218543] perf: interrupt took too long (3170 > 3150), lowering kernel.perf_event_max_sample_rate to 63000

    [ 2591.515987] r8169 0000:03:00.0: invalid short VPD tag 00 at offset 1

    I don't configure Firefox at all, it's the upstream Arch package. I updated the container today, go ahead and run the following:

    # docker pull escalade1/arch-browser

    # docker pull escalade1/arch-pcsx2

    The containers run entirely separate from the LibreELEC userland, so has it's own Mesa etc. I should probably redo the launcher scripts to pull the latest container on startup.

    The best thing would be to compile Firefox with the LE toolchain, but that would require way too much work to set up and maintain.

    Quote from escalade

    I don't configure Firefox at all, it's the upstream Arch package. I updated the container today, go ahead and run the following:

    # docker pull escalade1/arch-browser

    # docker pull escalade1/arch-pcsx2

    The containers run entirely separate from the LibreELEC userland, so has it's own Mesa etc. I should probably redo the launcher scripts to pull the latest container on startup.

    The best thing would be to compile Firefox with the LE toolchain, but that would require way too much work to set up and maintain.

    Just did. Problem persists :(

    Checking the upcoming Linux kernel 5.5.1 patch: Nothing related to DRM.

    Would you still have the 5.5-rc6-based image around ? I could try again if FF really worked flawlessly - maybe I was just lucky.

    Quote from escalade

    jaykass

    Could you tell me a bit about how it performs in different cores? Is it powerful enough to use any shaders? I'd be interested to know if it can use the crt-frutbunn shader for example.

    I tested Gameboy, Gameboy color, Gameboy advance, NES, SNES, Genesis, n64, and an assortment of arcades. Everything seemed to run at full speed (and I have my display at 1080p), steady 60fps when applicable. I ran more emulation intensive games (such as Mario World 2 for the SNES) if I am aware of them.

    If you have specific games you are curious about, I can look at them specifically.

    As for the shaders, retroarch doesn't seem to recognize any of the installed shaders. I verified via sftp that they exist (and in the right location) but retroarch just shows empty dirs. Is there an option to have retroarch recognize the slang shaders? I don't generally use shaders so this testing is for others' benefit, not my own.

    mtk1

    Sorry, I don't. I could build it but it's not at the top of my list just this moment. Good news is that I've been hacking away at including the few missing libs needed for running Arch Firefox directly on LibreELEC. Bad news is that I've done so, got the browser up and running but it won't actually load up any sites. I should be able to work it out though, time to get a decent Wayland capable browser running natively in this image :)

    RomMon

    Np :)

    jaykass

    The slang shaders requires either the glcore or vulkan driver. Check that you are using glcore, which should be selected automatically by the retroarch.sh script. With the gl driver only glsl shaders would be visible.

    The latest image under the «test» folder has integrated Firefox 72.0.2 using official binaries, now running natively on LibreELEC / Wayland. The image has crossed over 512MB though so can only be updated to for those who installed LE with my images which have 1024 MB /flash. Works terrific :)


    Some other improvements are fine tuned fontconfig setup with beautiful sub pixeled rendered DejaVu truetype for all GUI apps i.e. Firefox, RPCS3 and PCSX2. I’ve also added Thai fonts (ttlwg).