Open TiZ-HugLife opened 4 years ago
Now this is interesting.
I'll admit my motivation on moltengamepadctl fizzled out since it felt like I was writing an API with no real purpose or users. The current minimal state meant that I could just "print devices" via moltengamepadctl to see what was there.
But now you have an actual use case for querying the devices. I'd like to hear from you in a bit more detail on what information and data format you imagine receiving from this query.
Hey, sorry to have not replied for such a long time.
To tell the truth, I unfortunately had to stop using MoltenGamepad because Spyro Reignited Trilogy and Super Crush KO just couldn't see the controller at all if I didn't. I have no idea why. No other Wine game behaves that weirdly. I had the SDL_GAMECONTROLLERCONFIG env var set, it should have been making an XInput device. But I found that it just worked like normally when I turned off MG, even though the way I connect my DS4--using an adapter--causes it to be seen as a generic PS4 pad and doesn't use the "standard" mappings.
I would like to be able to turn MG back on if I can figure out what exactly is up with that. Want me to create a new issue for that?
Back on topic, now...
If I remember correctly, the main things I would just need to know are the real device(s) backing a given virtual device slot, and what driver is in use on that slot. I think these are the main things that can't be queried if you go poking around for information when controllers are already connected and in use.
I don't think it's anything special for using the socket vs using the FIFO and parsing stdout; the commands for that just don't exist right now.
Hey there, it's been a while. You know when you don't hear from me for a long-ass time, things are good in Linux-based FGC land! And that's definitely been the case. My Clevo P950EF has been the workhorse for our local SoulCalibur VI scene for a long time and everyone's happy with it. I often upload our local scene's matches to YouTube. I gotta catch up on our most recent locals.
I've created a script that monitors MG's state and udev, and saves characteristics of real controllers and sends out desktop notifications when real devices get connected and assigned to a slot. I've made it in preparation for creating other utilities like a controller-based menu for disconnecting BT devices. It works pretty well and does what we need it to, but one way I could definitely improve it and make it more suitable for other usecases is if I could, on the script's startup, ask MG what the real devices are in each slot. Right now the script depends on the fact that it starts before any controllers are actually connected, and I'd like it to be more robust. If we could do that, we could also change the script to a real-ass programming language that wouldn't need to save state in the filesystem; if the script dies it can just re-query the state on restart.