Posts by SupervisedThinking

Quote from Ramalama

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

Display More

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 Ramalama

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

Display More

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

Ramalama

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

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

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.

Ramalama both come with plenty of additional options and configuration opts but if they are not mandatatory it's fine too!

About the flags check out either

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

or

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

depending on what flags you actually want to change/pass.

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.

rockpro64:/run/kernel-overlays/modules/5.10.29/kernel/drivers/hid # modinfo hid-xpadneo.ko
filename:       /usr/lib/modules/5.10.29/kernel/drivers/hid/hid-xpadneo.ko
version:        5
description:    Linux kernel driver for Xbox ONE S+ gamepads (BT), incl. FF
author:         Kai Krakow <[email protected]>
author:         Florian Dollinger <[email protected]>
license:        GPL
srcversion:     B216E9B30524DE39E09E711
alias:          hid:b0005g*v0000045Ep00000B13
alias:          hid:b0005g*v0000045Ep00000B05
alias:          hid:b0005g*v0000045Ep000002E0
alias:          hid:b0005g*v0000045Ep000002FD
depends:        
name:           hid_xpadneo
vermagic:       5.10.29 SMP mod_unload aarch64
parm:           trigger_rumble_mode:(u8) Trigger rumble mode. 0: pressure, 1: directional (deprecated), 2: disable. (byte)
parm:           rumble_attenuation:(u8) Attenuate the rumble strength: all[,triggers] 0 (none, full rumble) to 100 (max, no rumble). (array of byte)
parm:           ff_connect_notify:(bool) Connection notification using force feedback. 1: enable, 0: disable. (bool)
parm:           gamepad_compliance:(bool) Adhere to Linux Gamepad Specification by using signed axis values. 1: enable, 0: disable. (bool)
parm:           disable_deadzones:(bool) Disable dead zone handling for raw processing by Wine/Proton, confuses joydev. 0: disable, 1: enable. (bool)
parm:           quirks:(string) Override device quirks, specify as: "MAC1:quirks1[,...16]", MAC format = 11:22:33:44:55:66, no pulse parameters = 1, no trigger rumble = 2, no motor masking = 4, hardware profile switch = 8, use Linux button mappings = 16, use Nintendo mappings = 32, use Share button mappings = 64 (array of charp)

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

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.

Quote from Ramalama

Is it possible to integrate xow?

GitHub - medusalix/xow: Linux driver for the Xbox One wireless dongle

This would be actually amazing to play with the Elite Controller over the dongle.

Here are some guys, that made a Build recipe for xpadneo, maybe it helps for xow xD

Thread

Implementing xpadneo drivers for future releases ?

Hello Folks

First of all: xpadneo is the device driver for the Xbox One S Gamepad (with Bluetooth builtin) (But only for bluetooth connection - on USB connection directly xpad driver is still needed).

Now while Kodi / Libreelec supporting retro Gaming and the Xbox One Gamepads has a wide range of users - I think it would be REALLY great to get the bluetooth connection also working

Source code: xpadneo Linux Drivers

I am also available for pretesting and debugging (got one Xbox One S Gamepad) - But…

MisterT

February 8, 2019 at 2:04 AM

Actually having both would be awesome too. xpadneo provides rumble and everything else for bluetooth controllers and xow has adapter support. The normal libreelec xbox one controller support is pretty dissapointing, no rumble etc...

If thats possible, it would be actually amazing for a lot of people that uses emulators or especially moonlight

Thank you

Display More

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.

If it works with my standalone Retroarch implementation then I'm pretty sure the quirks are related to Retroplayer which you IMHO already proved since the slowdown occurs on various versions & OS. SNES should literally run on a toaster nowadays btw.

FYI: after mesa upgrade 20.3.5 -> 21.0.2, AMD Kabini vaapi H264 hw. decode stopped working (#4605) · Issues · Mesa / mesa · GitLab

Quote from Deach

Oh nice! I'll have a play around with some and see how it copes.

Thanks

As long as you don't go crazy with resolutions if you use the IGP then it should work quite well.

Quote from Deach

Thank you for this! Everything I've tried upto the N64 era has worked great on my i3-9100 HTPC!

An i3-9100 should run GC/Wii, PS2 and even some PS3 games too

Quote from Bub4

Sorry for the late reply.

Yes - Retroarch is still on Vulkan. Will follow your recommendation and use standalone Dolphin.

Thank you for your support!

NP - check out duckstation with opengl again, the core was rebased on master and was ~700 commits behind. So maybe it'll fix your issues

Quote from Bub4

Oh I read that.

Thought you meant that I have to change the Kodi settings to Pulseaudio. Sorry for my misunderstanding.

It works now with ALSA in Kodi and Pulseaudio as Backend in RR-Config. Thats even better (brilliant) from my perspective.

Gamecube games hang when started from Retroarch. When started via ES it is working. Configured my gamepad with Dolphin as well and currently enjoy some Gamecube Tenn!s.

I've tested Mario Kart for GC & it work's flawless with the libretro core, did you still use Vulkan as RA video driver? Anyway I would highly recommend standalone Dolphin since it's up-to-date.

Well that's the intention - at least the basic functionality should be configurable without cli hassle, my setup functions should cover the usual usecases and load & unload PA modules when you're using the gaming extensions, so Kodi & it's settings are completely untouched. Technically you can switch Kodi over to PulseAudio if you want to use Bluetooth audio, then my scripts still set up all emulators for PA usage and it should also work fine, at least when I tested it with some BT headsets & speakers.

Then have fun playing some GC games!

Bub4 well you should probably read the wiki I've linked in the first post. The audio configuration is explained there & you don't have to use any command line stuff for that

Quote from DDuck007

... just compiled with mesa 21.0.2 - but no good news from my side ...

You should probably check the Mesa issue page Issues · Mesa / mesa · GitLab and create a new one if there is nothing similar. 🤔

Quote from Bub4

Hi SupervisedThinking I followed the route of chewitt and restored only the addon-data and some sources.xml files and installed the needed addons afterwards from repos. Games are running but I need to spend more time on tweaking the (core) settings I guess. My J5005 has issues with some games like THPS2 on psx. Mario Tenn!s on Gamecube is not playing smooth in native resolution whereas Mario Kart runs just fine in 2x resolution. Guess I need to investigate a little more on what are the best cores in Retroarch.

TVheadend runs just fine as well - so do YouTube, Netflix etc. VERY NICE.

So far I couldn't figure out a stable sound setting for Retroarch / Emulationstation. Kodi sound works normal as intended. I am using an AVR, so I chose ALSA in RR settings. I found the right ALSA card as well, but the sound appears only sporadically and is not very smooth at e.g. Gamecube and psx.

I will play around further with your beautiful build! Once more - I appreciate your efforts SOOO MUCH

1. You should try a more recent build which includes more recent duckstation builds for psx games or just try out beetle-psx, pcsx_rearmed

2. The J5005 isn't exactly a highend system & from my personally experience with my J3455-ITX some simpler GC/Wii games will run but don't have high expectations especially if it's a passiv cooled system. You should also focus on dolphin standalone which ES starts, the dolphin libretro core is pretty dated.

3. You should use PulseAudio as audioserver, Kodi only relies on ALSA for passthrough usage. If sound is stuttering or else it's most likely because your system does not emulate the games fast enough which leads to audio quirks.

Quote from chcore

Although using the standalone Retroarch application instead, to play the same ROM, is perfectly smooth as I expected. I still really want to use Kodi retroplayer where possible, for that seamless media center > gaming experience.

Well then it's most likely related to Retroplayer itself. Have you checked your refresh rate in display settings before you've started games? Could you set it to matching PAL/NTSC rates so 50Hz/60Hz?

CvH snes games should run on a toaster, I can't imagine a single compile option screws it all over

I'm pretty sure this is related to some quirky UEFI/BIOS setting. In general Snes9x would even run on a toaster & I would guess for whatever reason your system does not clock up and increase it's speed.

It would be interesting what result you get when you would use my fork, check out the link in my signature & give it a try. I'm curious if it works with Retroarch on LE base.