LibreELEC-RR [ Brave | Spotify | Moonlight | Emulationstation | Retroarch | Pegasus ]

    Quote from Bub4

    played THPS2 yesterday and it runs just fine in ES - it was so much fun to play. So many *pressstart->retries* after the first failed trick. lol

    I did not change the settings in Retroarch anymore. Couldn't this be fixed due to the right sound settings I have now? Anyway....

    I will playground with the settings to get a bit more experienced with the whole thing.

    ...And I guess I have to switch to a more powerful machine sooner or later 8o

    Well only few cores have proper vulkan renderer support so I would stick to GL unless it's absolutely necessary to switch. I thought you're have had trouble with PSX games but if it works fine never touch a running system.

    tl:dr xpad - yes / xow - no

    I've already created a xpadneo package & all upcoming builds should contain at least the Linux kernel driver module. Since I don't own Xbox controllers I can't test them & so I need some feedback what's working, if they are working, and what not. Technically I could add a xow package but I can't distribute it due to retarded licenses: Microsoft Terms of Use | Intellectual Property

    Unless otherwise specified, the Services are for your personal and non-commercial use. You may not modify, copy, distribute, transmit, display, perform, reproduce, publish, license, create derivative works from, transfer, or sell any information, software, products or services obtained from the Services.

    So even if I add a package you would still have to compile the image on your own after you've enabled non-free packages. Unless xow changes it's build process and loads the firmware at runtime I'm not allowed to ship the firmware in my packages.

    Quote from SupervisedThinking

    Well only few cores have proper vulkan renderer support so I would stick to GL unless it's absolutely necessary to switch. I thought you're have had trouble with PSX games but if it works fine never touch a running system.

    tl:dr xpad - yes / xow - no

    I've already created a xpadneo package & all upcoming builds should contain at least the Linux kernel driver module. Since I don't own Xbox controllers I can't test them & so I need some feedback what's working, if they are working, and what not. Technically I could add a xow package but I can't distribute it due to retarded licenses: Microsoft Terms of Use | Intellectual Property

    Unless otherwise specified, the Services are for your personal and non-commercial use. You may not modify, copy, distribute, transmit, display, perform, reproduce, publish, license, create derivative works from, transfer, or sell any information, software, products or services obtained from the Services.

    So even if I add a package you would still have to compile the image on your own after you've enabled non-free packages. Unless xow changes it's build process and loads the firmware at runtime I'm not allowed to ship the firmware in my packages.

    Makes absolutely sense.

    I knew about the driver and absolutely forgot about it. Thanks for the recherche.

    The wiki is already very well documented about compiling myself, will try that out now. And in general rr sse2 version runs amazingly well on an super old super crappy zotac id84 at fhd.

    I try to make the build receipt and compile it today with xow.

    Thanks for the reply 👍

    Quote from Ramalama

    Makes absolutely sense.

    I knew about the driver and absolutely forgot about it. Thanks for the recherche.

    The wiki is already very well documented about compiling myself, will try that out now. And in general rr sse2 version runs amazingly well on an super old super crappy zotac id84 at fhd.

    I try to make the build receipt and compile it today with xow.

    Thanks for the reply 👍

    If you clone the repo you have to switch to master-rr as branch & change the linked line from no to yes:

    LibreELEC-RR/options at master-rr · SupervisedThinking/LibreELEC-RR · GitHub

    then it should compile a generic image including xpadneo & xow. Based on your feedback & experiences I can add additional settings etc. to "upstream" then. You would still have to build the image on your own if you really need xow but this is basically a no-brainer & one-liner. It just needs some time & space to set up a build host.

    Didn't camed today sadly to build. The environment is a no brainer, just need to setup an vm/lxc on proxmox.

    Will do this tomorrow and report 🙈

    About xpadneo/xow, xpadneo is just a kernel module as far i understand, xow is pretty much just a systemd service, that maps raw inputs over libusb as far i understand.

    i used both already, there is nothing to configure. Or nothing i know of at least 🙈

    just that on one the service runs and on the other that the module is loaded. So it's both basically just compile and no gui etc is needed.

    Thank you very much for your effort!

    i think the only hint i probably need is just to know if i can somewhere define O3 and march flags, but i guess that goes into PROJECT_CFLAGS=""

    Just didn't seen it in the wiki 🙈

    Thank you for the hint with the nonfree packages!

    Wish me luck, i will definitively reply how it goes tomorrow 🙈

    Cheers

    The first one is amazing.

    But:

    LibreELEC-RR/arch.x86_64 at master-rr · SupervisedThinking/LibreELEC-RR · GitHub

    will get overwritten by:

    LibreELEC-RR/options at master-rr · SupervisedThinking/LibreELEC-RR · GitHub

    However, the default flags with sse2 etc will get applied anyway, as you made them default.

    So basically the Atom D2550 has full support, as the highlight of that processor is anyway only sse2 xD


    However, im using (my old compiler VM) which is a debian hirsute (+experimental repo), as it provides gcc 11... (need that vm for another compiling project...)

    But i think it's too new for this task, will try ubuntu 20.04 as the wiki recommends (elec wiki).

    Just don't want to go with Mint, cause there are no LXC containers available.

    Because i get already errors, but this error is looking like not an compiler fault:

    Code
    ../coreconf/config.mk:138: CPU_ARCH is not x86_64, disabling -mavx2
make[2]: *** No rule to make target 'clean'.  Stop.
make[2]: Leaving directory '/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/build/nss-3.60.1/nss/config'
make[1]: *** [coreconf/rules.mk:44: config] Error

    But you can check yourself, i've added the logfile.

    Im going to setup in the meantime the Ubuntu 20.04 environment.

    Something else, im making a simple small script, for anyone that is interrested in xow, basically it's will be just an dumb execute script that will do in the end everything.

    Atm, there isn't anything helpfull in it, but i will provide the final version once i had success xD

    Here is the Proof of Concept dumb script:

    Cheers

    Ramalama

    well nope you're not the first and not the last but you have overlooked this:

    LibreELEC-RR/arch.x86_64 at master-rr · SupervisedThinking/LibreELEC-RR · GitHub

    which is only a fallback if this is not set:

    LibreELEC-RR/options at master-rr · SupervisedThinking/LibreELEC-RR · GitHub

    About the error... well actually I guess this is related to the host system which is probably bleeding edge at any package. It uses Kernel 5.11.y & GCC11 which is not even released yet?

    Check out the cases of the distribution in:

    LibreELEC-RR/checkdeps at libreelec-10.0-RR · SupervisedThinking/LibreELEC-RR · GitHub

    these are the supported build host systems. Beside that NSS is a LE base package which isn't altered in any way by me so it's highly unlikely that it's failing because of changes I made.

    Exactly, i need GCC 11 for znver3, it will get now backported to GCC 10 too, but i started this already longer ago.

    This means i have to compile with:

    PROJECT=Generic ARCH=x86_64 TARGET_CPU="core2" BUILD_PERIODIC=RR BUILDER_NAME=$LE_Branch make image

    or

    PROJECT=Generic TARGET_CPU="core2" BUILD_PERIODIC=RR BUILDER_NAME=$LE_Branch make image

    Because in my logic, if i set the first with ARCH, TARGET_CPU will get overwritten xD

    I will continue tomorrow, its get's late here and my environment isn't done atm.

    But i made a small repository in the meantime that will get updated with time:

    Libreelec-RR-Scripts/libreelec-rr.sh at main · Ramalama2/Libreelec-RR-Scripts (github.com)

    Thank you very much for help!

    See you tomorrow :thumbup:

    Ramalama

    no you just have to enter the following line if you use the master-rr branch:

    Code
    PROJECT=Generic ARCH=x86_64 BUILD_PERIODIC=RR BUILDER_NAME=Ramalama make image

    And see if it builds. I would recommend to read all stuff https://wiki.libreelec.tv/development-1/build-basics here to get a deeper understanding how the build system works. You don't have to set any external args or envars, you have to set them in each option file for each project it you want to change them LibreELEC-RR/options at master-rr · SupervisedThinking/LibreELEC-RR · GitHub

    Quote from SupervisedThinking

    Ramalama

    no you just have to enter the following line if you use the master-rr branch:

    Code
    PROJECT=Generic ARCH=x86_64 BUILD_PERIODIC=RR BUILDER_NAME=Ramalama make image

    And see if it builds. I would recommend to read all stuff https://wiki.libreelec.tv/development-1/build-basics here to get a deeper understanding how the build system works. You don't have to set any external args or envars, you have to set them in each option file for each project it you want to change them LibreELEC-RR/options at master-rr · SupervisedThinking/LibreELEC-RR · GitHub

    Seems like you've got HEVC working? (Came here from your moonlight tickets). Is there a way I could run moonlight with HEVC but under raspbian at this point? thx

    Quote from bluenote

    Seems like you've got HEVC working? (Came here from your moonlight tickets). Is there a way I could run moonlight with HEVC but under raspbian at this point? thx

    You'll probably need to cherry pick the ffmpeg (& kernel?) patches LibreELEC uses:

    LibreELEC.tv/packages/multimedia/ffmpeg/patches at master · LibreELEC/LibreELEC.tv · GitHub

    LibreELEC.tv/projects/RPi/devices/RPi4 at master · LibreELEC/LibreELEC.tv · GitHub

    I guess it's only ffmpeg which needs patching since LE already uses the RPi custom kernel

    Using ubuntu 20.04 now, which provides gcc-9 by default.

    Everything worked well xD

    Will try later with gcc-10.

    However, i just seen, you have already integrated xow into your source. So i had nothing to do xD

    Means that the script that im doing is absolutely useless xD

    Im going to recompile with gcc-10 and core2 now, and will test on my system with the xbox controllers.

    The first compilation now, was just to test if it compiles fine with default ubuntu 20.04 environment. And well it does xD

    Thanks for all the help!

    Im gonna compile again and test :)

    It does not really matter which gcc the host system uses since it's only used to build the toolchain which then builds the target packages. Vanilla LE uses gcc 10.2 & I updated to gcc 10.3 so no matter what Ubuntu ships every target package will be build by gcc 10.2/3

    Beside that only xpadneo-0.9.1 is integrated in my images, to include xow you need to edit the options file for the generic package and set non-free packages to yes. Then it will integrate xpadneo-0.9.1 + xow & will also include fdk-aac and build Citra with support fdk-aac support.

    The core2 flag is mostly useless and I would got another route and check out x86 Options (Using the GNU Compiler Collection (GCC)) then add flags here LibreELEC-RR/arch.x86_64 at master-rr · SupervisedThinking/LibreELEC-RR · GitHub because this is the least "intrusive way" to change stuff for the packages since if you enter git grep TARGET_CPU you will recognize that a lot of packages depends on this var.

    Quote from SupervisedThinking

    Beside that only xpadneo-0.9.1 is integrated in my images, to include xow you need to edit the options file for the generic package and set non-free packages to yes. Then it will integrate xpadneo-0.9.1 + xow & will also include fdk-aac and build Citra with support fdk-aac support.

    Thats what i meant, just enabling non-free packages and i have xow.

    But i meant that you already include xow as build recipe.

    Which is great, cause only changing non-free to yes is very noob friendly 🙈😂

    Thanks for that!

    Probably you will need to add cabextract and curl as build dependencies too, cause xow compilation needs them. But i handle that with my wrapper too.

    Could you probably add non-free to rpi4 too?

    Cause i think there is even more interest in the pi4 for the most users as for x86. 🙈

    I can test xow/xpadneo tomorrow with the pi4 either after today's test with x86.

    Cheers

    Yes I've already added a xow package otherwhise it wouldn't make any sense to add the non-free option if nothing non-free will be built.

    You mean "cabextract and curl" weren't installed at Ubuntu? Because I also thought about adding them to host deps but it did not complain about that on my Mint system.

    About RPi4 and else, all have the same RR options in the project config files. So you can turn them on for every other project too but you have to look in the device subfolder.

    Quote from SupervisedThinking

    Yes I've already added a xow package otherwhise it wouldn't make any sense to add the non-free option if nothing non-free will be built.

    That option sounded for me initially like activating a repository 😂😂😂

    To be able to build it, not like you have included it already 😂

    But well, it makes now more sense 😂

    Quote from SupervisedThinking

    You mean "cabextract and curl" weren't installed at Ubuntu? Because I also thought about adding them to host deps but it did not complain about that on my Mint system

    Exactly, ubuntu (server) 20.04 doesn't include them by default. Dunno why they don't even include curl 😂

    And there is another package i had to install: libgdk-pixbuf2.0-bin, that provides the gdk-pixbuf-pixdata command.

    I sadly didn't noted where it failed to build, was something xorg related, but if you need to know for what it's needed, i can remove it and compile again, till it errors.

    Quote from SupervisedThinking

    About RPi4 and else, all have the same RR options in the project config files. So you can turn them on for every other project too but you have to look in the device subfolder

    Perfect, i just initially watched if there is a nonfree option in project/ARM/options, like in the corresponding project/Generic/options.

    But yes, i found it in projects/RPi/devices/RPi4/options.

    However, my build is almost compiled.

    Going to test.

    Cheers

    Quote from Ramalama

    And there is another package i had to install: libgdk-pixbuf2.0-bin, that provides the gdk-pixbuf-pixdata command.

    I sadly didn't noted where it failed to build, was something xorg related, but if you need to know for what it's needed, i can remove it and compile again, till it errors.

    Can you provide me the package name that fails? Because gdk-pixbuf is basically used for gtk3 and stuff & should be used by the one compiled for the toolchain & not one provided by the host

    xow doesn't works, because we are missing

    xow/modprobe.conf at master · medusalix/xow (github.com) the binding to that nonexistent driver.

    i get an: usb 1-2: usbfs: interface 0 claimed by mt76x2u while 'xow' sets config

    After adding:

    Code: /etc/modprobe.d/xow-blacklist.conf
    alias usb:v045Ep02E6d*dc*dsc*dp*ic*isc*ip*in* xow_blacklist
alias usb:v045Ep02FEd*dc*dsc*dp*ic*isc*ip*in* xow_blacklist

    i get:

    Code
    2021-04-15 22:31:06 INFO  - Pairing enabled
2021-04-15 22:31:35 INFO  - Controller '1' connected
2021-04-15 22:31:36 INFO  - Device announced, product id: 02e3
2021-04-15 22:31:36 INFO  - Serial number: 02680005732652
2021-04-15 22:31:36 INFO  - Controller '1' disconnected
2021-04-15 22:31:39 INFO  - Pairing disabled
2021-04-15 22:31:42 INFO  - Controller '1' connected
2021-04-15 22:31:42 INFO  - Device announced, product id: 02e3
2021-04-15 22:31:42 INFO  - Serial number: 02680005732652
2021-04-15 22:32:04 INFO  - Battery level: full

    means it's fully working :love:

    Another thing is, that the xow.service is by default disabled.

    But as you can enable it simply through ssh and don't even need rw access, it's a pretty simple task.

    I only have the problem that it doesn't work anyway at boot automatically, until i replug the dongle and restart the service after the system booted.

    But this can a fault of the super crappy zotac id84 system, dunno if the usb controller can't reset an port or sth.

    So i will play a bit with it and reply.

    Atm, only the blacklist file is needed and the default state of the service should be enabled.

    ------

    Quote from SupervisedThinking

    Can you provide me the package name that fails? Because gdk-pixbuf is basically used for gtk3 and stuff & should be used by the one compiled for the toolchain & not one provided by the host

    I have removed libgdk-pixbuf2.0-bin and rebuilding again, but it will take a while, im at 275/578 (50%), somewhere here it will fail, but need to wait and will tell you, when it finally failed xD

    -----

    EDIT:

    Okay in the meantime, while the moderators approve my post, i found out why it's not automatically starting:

    multi-user.target: Job xow.service/start deleted to break ordering cycle starting with multi-user.target/start

    Because something in systemd (libreelec?) doesn't even start the service, because of ordering boot? I have no clue xD

    EDIT2:

    Oh god, this takes forever, till this gets approved ;(

    The Package that fails is: gtk3-system

    ---> gdk-pixbuf-pixdata is not in PATH

    I have attached the corrisponding log.

    I need to get finally some sleep now, thanks for everything, see ya tomorrow!

    Cheers