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

Quote from Bub4

Hi all,

did anyone get 8BitDo Gamepads to work with x86 natively (without dongle) in LibreELEC(-RR)?

I have a ASrock J5005 and tested two intel M.2 cards without success. I get them paired only via bluetoothctl but they lose the connection quite immediately.

.

They work flawlessly on RPi4 and LibreELEC 10.

Does anyone have an idea?

Thanks

Edit: I check in another thread, if bluetooth is working properly - guess there is something wrong with my system: RE: Bluetooth does not find a device ASRock J5005 - Intel Wireless AC 3165

Display More

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.

Quote from SupervisedThinking

Ramalama

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

=================================================================================
 End Configuration for LibreELEC
 =================================================================================



**** This system lacks the following tools needed to build  ****
gdk-pixbuf-pixdata provided by libgdk-pixbuf2.0-bin
**** The system appears to be a ubuntu system ****
Would you like to install the needed tools? (y/n)y
[sudo] password for compiler: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libjbig0 libtiff5 libwebp6
The following NEW packages will be installed:
  libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libjbig0 libtiff5 libwebp6
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 561 kB of archives.
After this operation, 1852 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y

It works now as it should

Perfect, now i just need to test xpadneo out xD

Quote from SupervisedThinking

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:

root@le-compiler:~# sudo apt install libgdk-pixbuf2.0-bin
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libjbig0 libtiff5 libwebp6
The following NEW packages will be installed:
  libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libjbig0 libtiff5 libwebp6
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 561 kB of archives.
After this operation, 1852 kB of additional disk space will be used.
Do you want to continue? [Y/n]

----

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

With libgdk-pixbuf2.0-bin, compilation went perfectly fine

My head was this:

c8fd01496bba529f1f010ee650b09b68c7c66620 (HEAD -> master-rr, origin/master-rr) mesa: drop revert-patch for mesa 21.0.y

Im going to build and test now the RPi4 xD

Quote from SupervisedThinking

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 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 😂

before all the modifications definitively yes 😂😂😂😂😂

but at the current point, i need to rebuild and check 😂

Update xD

Creating symlinks in /home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/install_pkg/adwaita-icon-theme-3.38.0/usr/share/icons/Adwaita/cursors
if test -z "/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/install_pkg/adwaita-icon-theme-3.38.0" && test -n "" ; then \
         -q /home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/install_pkg/adwaita-icon-theme-3.38.0/usr/share/icons/Adwaita; \
fi
make[4]: Leaving directory '/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/build/adwaita-icon-theme-3.38.0/.x86_64-libreelec-linux-gnu'
make[3]: Leaving directory '/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/build/adwaita-icon-theme-3.38.0/.x86_64-libreelec-linux-gnu'
make[2]: Leaving directory '/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/build/adwaita-icon-theme-3.38.0/.x86_64-libreelec-linux-gnu'
make[1]: Leaving directory '/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/build/adwaita-icon-theme-3.38.0/.x86_64-libreelec-linux-gnu'
/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/bin/gtk-update-icon-cache: error while loading shared libraries: libgdk_pixbuf-2.0.so.0: cannot open shared object file: No such file or directory
FAILURE: scripts/build adwaita-icon-theme:target during post_makeinstall_target (package.mk)
*********** FAILED COMMAND ***********
${PKG_ORIG_SYSROOT_PREFIX}/usr/bin/gtk-update-icon-cache ${INSTALL}/usr/share/icons/Adwaita
**************************************
*********** FAILED COMMAND ***********
${SCRIPTS}/build "${1}" "${PARENT_PKG}"
**************************************
FAILURE: scripts/install adwaita-icon-theme:target has failed!

The following log for this failure is available:
  /home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/.threads/logs/515.log

>>> adwaita-icon-theme:target seq 515 >>>
[508/579] [FAIL] install adwaita-icon-theme:target

The following log for this failure is available:
  /home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/.threads/logs/515.log

Parallel build failure - see log for details. Time of failure: Fri Apr 16 22:42:27 UTC 2021
make: *** [Makefile:12: image] Error 1

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

Building xD

See you in 2h 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:

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

FAILED: gtk/gtkresources.c
/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/toolchain/bin/glib-compile-resources gtk/gtk.gresources.xml --sourcedir /home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/build/gtk3-system-3.24.28/>/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/bin/gdk-pixbuf-pixdata: error while loading shared libraries: libgdk_pixbuf-2.0.so.0: cannot open shared object file: >
gtk/gtk.gresources.xml: Child process exited with code 127.
ninja: build stopped: subcommand failed.
^[[1;31mFAILURE: scripts/build gtk3-system:target during make_target (default)^[[0m
*********** FAILED COMMAND ***********
ninja ${NINJA_OPTS} ${PKG_MAKE_OPTS_TARGET}
**************************************
*********** FAILED COMMAND ***********
${SCRIPTS}/build "${1}" "${PARENT_PKG}"
**************************************
^[[1;31mFAILURE: scripts/install gtk3-system:target has failed!^[[0m

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

Quote from SupervisedThinking

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.

#################################################################################
# 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...

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

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

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

Quote from SupervisedThinking

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:

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:

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

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

[79/665] Generating gtkresources_c with a custom command
FAILED: gtk/gtkresources.c 
/home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/toolchain/bin/glib-compile-resources gtk/gtk.gresources.xml --sourcedir /home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/build/gtk3-system-3.24.28/.x86_64-libreelec-linux-gnu/gtk --sourcedir /home/compiler/LibreelecRR/build.LibreELEC-Generic.x86_64-10.0-devel/build/gtk3-system-3.24.28/gtk --sourcedir ../gtk --c-name _gtk --internal --generate --target gtk/gtkresources.c --manual-register --dependency-file gtk/gtkresources.c.d
gtk/gtk.gresources.xml: to-pixdata preprocessing requested, but GDK_PIXBUF_PIXDATA is not set, and gdk-pixbuf-pixdata is not in PATH.
ninja: build stopped: subcommand failed.
FAILURE: scripts/build gtk3-system:target during make_target (default)
*********** FAILED COMMAND ***********
ninja ${NINJA_OPTS} ${PKG_MAKE_OPTS_TARGET}
**************************************
*********** FAILED COMMAND ***********
${SCRIPTS}/build "${1}" "${PARENT_PKG}"
**************************************
FAILURE: scripts/install gtk3-system:target has failed!

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

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

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