18.03.16 - Moonlight

[nwildner]

@substring I had no problems with Big Picture and older GFE(2.x series), cause you needed to map manually the controllers. Once you did that, worked all the time.

I've tested with the following Steam and Non-steam games

• Tera Online(non-Steam)
• Minecraft Windows 10 Edition(non-Steam, Windows UWP software)
• Steam App
• Lego The Lord of The Rings(steam, launched directly through ES).

None of them had the controller mapped. I'll try to update GFE to 3.13 later today.

If there is any log i can post here, just let me know

[Substring]

@nwildner a support archive is always welcome. Haven't tried wth PS3 pads, i'll try to give it a go asap

[nwildner]

@substring There you go. recalbox-support file created

Link: https://we.tl/yF0U8b2a1v

File: recalbox-support-20180318150341.tar

[Substring]

@nwildner can you try to reconfigure your pad in ES ? Moonlight doesn't find you pad because of its SDL2 GUUID which doesn't fit. It should be 050000004c0500006802000000000000 whereas it got 05000000504c415953544154494f4e00

[nwildner]

Hi @substring . Reconfigured controller inside ES, but it generates the gamecontrollerdb.txt inside /recalbox/share/system/configs/moonlight with the same string. Deleted the file before running Moonlight, but it creates the file with the same wrong GUUID.

 # cat gamecontrollerdb.txt
05000000504c415953544154494f4e00,PLAYSTATION(R)3 Controller,platform:Linux,b:b13,righty:a3,rightx:a2,a:b14,x:b15,righttrigger:b9,rightstick:b2,leftshoulder:b10,dpup:b4,start:b3,dpdown:b6,rightshoulder:b11,dpright:b5,lefttrigger:b8,leftstick:b1,guide:b16,y:b12,lefty:a1,leftx:a0,back:b0,dpleft:b7,# 

Further testing, if i try to put 050000004c0500006802000000000000 GUUID string manually, but it will get replaced. If i change the file to immutable to prevent writes with chattr +i gamecontrollerdb.txt, Moonlight will fail to bring the game to the screen.

Don't know if it is relevant, but my controller is a Shanwan type of those PS3 clone pads.

[Substring]

@nwildner this is how I could make it work ... 1st of all, moonlight is wrong with the device GUID, i'll try to look why if i ever have some time

Now:

• duplicate the gamecontrollerdb.txt to the same folder with a different name, say fixedgcdb.txt
• edit ~/configs/moonlight/moonlight.conf (if you're un yolo mode when pairing) and add/uncomment mapping = fixedgcdb.txt
• no need to reboot, just launch a game

[nwildner]

@substring Worked like a charm Yay. Duplicated the controller mapping file to customcontrollerdb.txt, fixed the GUUID and added the following line to moonlight.conf

mapping = /recalbox/share/system/configs/moonlight/customcontrollerdb.txt

And it also worked with a second controller that i bought on the same batch from China. Guess i can play Lego LOTR with my wife now

Thanks again Subs, on helping me with my Moonlight issues.

Also, i think Moonlight isn't the one to blame here. sdl2-test reports me the incorrect GUUID

# sdl2-jstest -l
Found 1 joystick(s)

Joystick Name:     'PLAYSTATION(R)3 Controller'
Joystick Path:     '/dev/input/event0'
Joystick GUID:     05000000504c415953544154494f4e00
Joystick Number:    0
Number of Axes:     4

[Substring]

@nwildner the guid is reported by SDL2 itself ! Recalbox and sdl2-jstest report the same so ... I also trued sdl2-jstest to make sure the guid was right

[nwildner]

@substring Should i open a bugfix at moonlight-embedded github and reference this thread?

[Substring]

@nwildner i'd rather review their code first

[Substring]

@nwildner So i've dived in the code ... moonlight computes itself the GUID instead of calling SDL2 dedicated methods

[nwildner]

@substring Yeah. I'm browsing through Recalbox-EmulationStation source and it's pretty clean C++ SDL call, while moonlight gets it by computing with the following code:

evdev.c(tag 2.4.6)

struct libevdev *evdev = libevdev_new();
libevdev_set_fd(evdev, fd);
const char* name = libevdev_get_name(evdev);

int16_t guid[8] = {0};
guid[0] = int16_to_le(libevdev_get_id_bustype(evdev));
guid[2] = int16_to_le(libevdev_get_id_vendor(evdev));
guid[4] = int16_to_le(libevdev_get_id_product(evdev));
guid[6] = int16_to_le(libevdev_get_id_version(evdev));

char str_guid[33];
char* buf = str_guid;
for (int i = 0; i < 16; i++)
    buf += sprintf(buf, "%02x", ((unsigned char*) guid)[i]);

Maybe i should open an issue on moonlight-embedded Github after all? (and link this thread)...

[Substring]

@nwildner Why not ... But I think he computed it himself simply because he may not have found how to link an input and its guid. Anyway, I know SDL changed their way of computing the GUID over time, SDL 2.0.8 uses the mthod he chose, i don't know since when. This also means that when we b*mp to SDL 2.0.7 we should hopefully fit. Stupid me, i do have a SDL 2.0.7 pi3 build, i will try to find some time to test with my shanwan.

Final word : he should rely on SDL2 to get the GUID, period.

[nwildner]

@substring It's done.

Let's see if this could make Moonlight better integrated with Recalbox

https://github.com/irtimmer/moonlight-embedded/issues/644

[nwildner]

@substring Hey Subs! Is it possible to cherry-pick commit dcda1a5, and try the irtimmer fix on your SDL build?

It seems that devices with no vendor or product id are handled different, by copying the first 11 Characters(PLAYSTATION) to GUID.

[Substring]

@nwildner yep easy
Just need to add a .patch to the commit url, add it to the package and it should be good to go. Can you open an issue and assign it to me please ?

[Substring]

Will do it, nevermind

[nwildner]

@substring Thanks.

I was going to do right now(Gitlab is not allowed at my workplace)

[Gimpi]

@substring Sorry for my dumb ess 18.03.30 is Out and installed moonlight still dont realised my Bluetooth controller

[Substring]

@gimpi i don't understand