Posts by Ramalama

    From my view, nuc's are in every way one of the best minipc's that you can buy. Great any os support, even hackintosh, great updates, pretty much a no brainer.

    And they are all good, no matter which generation since haswell. Just watch out for hdmi 2.0/1 for the long-term.

    But the rpi4 is actually pretty amazing either sure, it's slow compared to a nuc, but it's still perfect for an *elec device.

    Im not into game emulation, so dunno how it performs there, but it has x265 hardware acceleration and is pretty awesome for any video related stuff.

    Cheers

    I have ordered an intel 7260 mpcie card for my x86 build on Monday, it camed today finally.

    And i have readed the other post of your issue.

    Let me say this, while Bluetooth was on linux always a bit of a pain, doesn't matter which distribution. I got it always working.

    With today's testings, with the 7260 card, i have same issues as on the pi4. And this issue is bigger and related to Bluetooth kernel modules or Bluetoothctl or hci.

    To be more precise, the pairing process looks broken, scanning works, but pairing not.

    It says it paired, it connects and disconnects in a loop, but i can't get anything properly paired and connected.

    No matter if on the rpi4 or 7260.

    First i thinked it is probably xpadneo, but it isn't, the module isn't even loaded, even a recompile without it doesn't works.

    On Ubuntu 20.04, Bluetooth is a pain, but after many tryes of pairing/connecting it works. And once you connected it once it works constantly perfect (that one device)

    On libreelec, doesn't matter if RR or not RR it doesn't work, i tryed it almost 100 times.

    Replacing the firmware for the 7260 (bluetooth module) leads nowwhere, since hci says that it's already patched to v57 and doesn't even try to load the "ibt-hw-..." files.

    And there is no documented way or command to load the firmware yourself.

    But those bluetooth firmware files or patchfiles, are for all intel Bluetooth devices, it doesn't matter if it's an ax200 or an super old 7260/7265 module. All the same fw files. That means if bt isn't working on one intel module, the possibility is extremely high that it won't work on all other intel cards too.

    Only the wifi firmware is for every module different.

    So it's a pain, the whole Bluetooth code is crappy on linux anyway if you ask me. Even on macos and windows it's not always perfect.

    The only thing where Bluetooth is a no brainer, is on the phones.

    However, I don't give up yet.

    Cheers.

    Ramalama

    Yeah well I copy pasted & forgot to delete the [] ^^ can you test it again? Or just install 10k packages xD

    It works now as it should ^^

    Perfect, now i just need to test xpadneo out xD

    Well I've turned the half distro inside out to build gdk-pixbuf stuff but in the end I would end up with GTK3 & else as host build which isn't worth the hassle ^^ I've added libgdk-pixbuf2.0-bin as dependency to checkdeps and this should be fine.

    Could you remove the package once you've pulled in the latest commit & see if checkdeps asks for the correct file? Cleaning just gtk3-system & build it again should be fine to see if you run into trouble again.

    Well, that didn't worked well xD

    Check the attached logfile xD

    But if i do it myself:

    ----

    I have tested the pi.

    Compilation works perfectly fine!

    XOW - Works perfectly fine!

    xpadneo - (im have a hard times to pair the controller, still didn't managed)

    But that issue has nothing todo with you or libreelec, i had the same hard times to pair it initially with raspbian too.

    But once it paired at connected once, it works forever, just its hard to get there and still weren't successfull...

    So basically i need more time to test it out xD

    Ramalama

    don't worry... I didn't know this back in the days > three years ago too & I was rebuilding the dumb way over and over and died through the build until everything was fixed...

    Yeah you have to consider that the packages are linked against each other and so if the host config changes or e.g. you bump a single package which was linked agains libexample.1.14 and then the bumped package install libexample.1.15 you also have to recompile the packages which depend on the lib.

    About the wrapper... whatever floats your boat :D usually the project files include everything you need and args like BUILD_PERIODIC=RR or BUILDER_NAME=ST are optional. All you need is PROJECT=Generic ARCH=x86_64 make image, even PROJECT=Generic ARCH=x86_64 are superflous since it's the default, to kick of building an image since the scripts already handle everything else but obviously you have to tell the makefile which project you want to build.

    Exactly, something like that i got, so im compiling everything now πŸ˜‚

    I know that your scripts does already everything, that script is just basically to make it easier for myself, i started something i wanted to finish it, there is really not much more to it πŸ˜‚

    A wiki does the same job πŸ˜‚

    But on a clean new build environment, all i have todo is dumb run the script and it tells me, to install git+make+create an nonroot user to get started, and does everything else, without me having to fiddle in your repo and forgetting changing stuff that i personally want to cchange, like debloating the kernel πŸ˜‚

    But tbh, libreelec made already a file for this, which is pretty amazing already to slim the kernel down.

    However, no one needs to use that script, it's just a dumb way for me if i forget everything in a month or so πŸ˜‚

    --

    Compilation is over 60% already, so far everything looks great with the libgdk package πŸ˜‚

    Using your latest repo changes (1h ago cloned)

    Cheers

    oh god, that would have made it easier πŸ™ˆ

    however, with the libgdk package it seems that it compiles fine.

    i just runned into another error, on another package, but this time i think it comes from, because i installed libgdk and didn't cleaned the build cache or something.

    So let me check, i will reply in 2h πŸ˜‚

    You can could look in the meantime to this here, if you like it or not, it's basically already done, just have to fine tune itπŸ˜‚

    Libreelec-RR-Scripts/libreelec-rr.sh at main Β· Ramalama2/Libreelec-RR-Scripts Β· GitHub

    It's basically just a wrapper for your repo πŸ˜‚

    Will reply in 2h, cheers πŸ˜‚

    Update xD

    gtk3-system looks fine now, but now we have adwaita-icon-theme xD

    cat LibreelecRR/Compilation_Time.txt

    Start: Fri Apr 16 20:55:03 UTC 2021

    Done: Fri Apr 16 22:42:27 UTC 2021

    Takes around 2h from clone till here xD

    But from now on, i will just build, without the cleanup, should be fine to get through all errors. And then i can build from clean again xD

    But i need finally some sleep, see you tomorrow xD

    will tell you after i recompiled it πŸ˜‚

    about xow and the modprobe, it probably just needs a hint in the wiki, that's all.

    no one needs to complain, cause it's the only libreelec/"xdistro"kodi that has working xow/xpadneo at all πŸ˜‚

    About gtk3-system:

    I checked out till here:

    Code
    compiler@le-compiler:~/LibreelecRR$ git log --pretty=oneline
    6ce98bc242bf9f7934d06e38cb8b778f07198fae (HEAD -> master-rr, origin/master-rr) xow: tweaks
    0e65bca8cf47fb4d37b3bc35cd874ed1fc47391f brave-browser: updated to 1.0.3 / added function to set refresh rate

    and i still get the same error xD

    Sorry xD

    EDIT:

    Wait the error is different this time, it complains about libgdk_pixbuf-2.0.so.0 or about gtk/gtk.gresources.xml, not about the binary anymore xD

    Ramalama

    I'm building RPi4 images at the moment but it'll take some time... tomorrow they should be ready.

    The gtk3-system package should be fine, I've renamed the host gdk-pixbuf command and it still worked so fingers crossed. Of course I would appreciate if the image can be compiled on a minimum build system.

    Have a look at the new modprobe.d conf files for xpad then, it would be nice if you could delete your old ones and the new ones shipped by the image, just delete them, apply an update and they will be restored.

    Just did, and i don't understand it.

    Code
    #################################################################################
    # Bind dongle to non-existent module to prevent the mt76x2u driver from loading #
    # https://github.com/medusalix/xow/blob/master/install/modprobe.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

    My modprobe file is gone/deleted, yours is there...

    But the 2 lines are commented out...

    But my controller still works and did worked after boot instantly perfect... =O

    dmesg and the service doesn't report any errors...

    It definitively didn't worked before without the modprobe file...

    Is there some sort like initramfs, where it still uses the "cached" modprobe file?


    EDIT:

    Okay, i think i understand why.

    Just replugged the dongle, while the system is running, and:

    usbfs: interface 0 claimed by mt76x2u while 'xow' sets config

    So it works now only at boot time, if the dongle is already plugged in with boot.

    Seems like the xow service binds the dongle at boot, before "mt76x2u"

    But if you replug/or plugin the dongle after the system is booted, you need the modprobe file xD

    So those 2 lines should be uncommented :D

    I sadly don't have an sse4 supported x86 platform. The D2550 is max SSE3. It was meant to throw away, since i have 2 shields and an raspberry... but well, it found a way to survive xD

    For xpadneo, it will take till tomorrow, i can test it on the RPI4 only, cause the zotac id84 has only bluetooth 3.0, (mpcie replacement card is on the way), but the gamepad is bt 4.0+ (ble), so its incompatible.

    But tomorrow, i can test it properly with the pi4.

    For cabextract/curl, it works, your build scripts asked me if i wanted to install them and did it properly :thumbup:

    For gtk3-system, im compiling already, will take a bit, till i can report back.

    For xow (system service & modprobe file): (Updated to the build from today morning just now)

    Works absolutely perfect now, it is starting perfectly at boot and works inside kodi without any issues.

    So there is nothing todo, except once, initially enable the service.

    My compilation system is an Proxmox Host (Ryzen 5800x/64gb Ecc Ram/ton of ssd storage), but sadly takes around 2h i think, i didn't really paid attention. And i compile in an lxc container (near native performance, its like a sandbox environment, not a virtual machine).

    Ramalama

    1) your forum account should be now approved, I've pinged a mod

    2) could you check if gtk3-system builds fine now on your minimal system?

    3) IF you're in mood and have some time to spare you could also remove curl & cabextract as packages? Then when you start to build an image it should nag & ask to install those missing ones

    = basically all problem you've reported should be hopefully fixed

    Thank you.

    Sure, i will test everything out.

    But it will take a bit, till i get at home + start the compilation.

    i seen that you already included the modprobe and edited the service, today at morning before i left the house. And started compiling already πŸ˜‚

    will update you, when i get at home.

    EDIT: Thank you! im approved πŸ™ˆ

    Cheers

    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.

    ------

    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

    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 πŸ˜‚

    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.

    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

    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

    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 :)