Mupen64plus badly interacting with WiringPi API ? (solved-ish)

[Aryetis]

Hello,

It is gonna be a very specific issue but interesting (I hope so ...) issue.
Ok so here's the basics. I'm using a fan to cool down my pie, I regulate its spinning speed using a npn transistor wired to the pwm pin (like in this tutorial for instance : https://hackernoon.com/how-to-control-a-fan-to-cool-the-cpu-of-your-raspberrypi-3313b6e7f92c#.k6qc5ibix ), and I'm using my own little C program to control the speed ( https://github.com/Aryetis/PiPwmIncrementalFanController ). It works perfectly fine for 99% of the time

Except when I run Mupen64plus .... As soon as I run Mupen64plus the fan goes fullspeed, even thought the speed is still correctly updated in the "temperature file". So there is some low level shenanigans hapenning there between Mugen64plus and wiringPI library. Also it happens only with Mupen64Plus-Glide/Rice core, it does not happen with the libretro version. And once the emulator is started the is no turning back, the fan will go fullspeed forever, killing the emulator won't resolve the bug. I have to restart the pie to get back to normal fan speed. (Obviously I checked, the fan is not going fullspeed because of temperature)

I'm pretty sure I'm "barking" at the wrong tree here. But does anyone here had some similar issues before ? I haven't read about similar issues yet (still googling it thought). Should I tell pass the bug to retropie, to Mupen64Plus, to wiringPI, to my poorly english written fanControl program ?

Thanks for reading, hopefully I picked your interest enough to get an answer ^^

Specs : Raspberry Pi3 , overclocked
RetroPie Version : 4.1.15
No logs, no errors
Emulator : any non libretro Mupen64Plus core

[Aryetis]

necrobumping my own post because I found a workaround.
I use runcommand-onstart.sh script (docs : https://github.com/RetroPie/RetroPie-Setup/wiki/Runcommand , my script : https://pastebin.com/XunR2bBY) combined with some delay (hard programmed in my fanControl program) to relaunch fanControl after Mupen has done its shenanigans and thus reclaim the GPIO.