18.03.16 - Moonlight
-
@substring Worked like a charm Yay. Duplicated the controller mapping file to
customcontrollerdb.txt
, fixed the GUUID and added the following line tomoonlight.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
-
@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
-
@substring Should i open a bugfix at moonlight-embedded github and reference this thread?
-
@nwildner i'd rather review their code first
-
@nwildner So i've dived in the code ... moonlight computes itself the GUID instead of calling SDL2 dedicated methods
-
@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:
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)...
-
@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.
-
@substring It's done.
Let's see if this could make Moonlight better integrated with Recalbox
-
@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.
-
@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 ? -
Will do it, nevermind
-
@substring Thanks.
I was going to do right now(Gitlab is not allowed at my workplace)
-
@substring Sorry for my dumb ess 18.03.30 is Out and installed moonlight still dont realised my Bluetooth controller
-
@gimpi i don't understand
-
@substring the Update said some fixes in the moonlight Installation but my Bluetooth controller will Not Work while streaming any USB plugged Controller worked
-
@gimpi i haven't tried with any bluetooth controller in fact
-
@substring ok in the "christmas" recalbox Patch it worked Like a Charm with an Bluetooth Hmm ok im Just trying now
-
@gimpi because moonlight had to be updated since to be compatible with GFE 3.12. But the pad configuration routines changed. I'll try and see if the dev how this goes. Which pad doesn"t work ? can you provide a support archive ?
-
@substring its an third Party ps3 bluetooth controller from "big ben"
How Do i create an Support archive? Can try it after Work tonight
-
@gimpi start recalbox, go to http://recalbox/help or http://recalbox.local/help if you're on MAC/Linux