Daphne & Basic Auto-Config Failure
-
I first noticed this problem in Daphne, but it would seem to be a problem anywhere the "first" joystick is auto detected. I have a controller that has two analog shoulder buttons that register a button press when they are pressed completely down. The problem is that every time RetroPie tries to detect the first joystick, it assumes the axis of the analog buttons belong to a joystick and try to map them accordingly to movement.
I've determined that this is an unknown problem for many as those who talk of double input for "Lower Left" & "Lower Right" in Emulation Station are also experiencing this as well. They are quick to write it off as a simple bug, but what is happening is that when they are prompted to press the button, ES is reading the axis input in advance of the button that follows. Again, I confirmed this with jstest by observing axis input from axis-2 until it clicks all the way down. At that point, a seperate button input is registered.
Knowing this, I can now map my controller and any other like it with a little forethought. As long as the trigger is pressed all the way down, but just shy of the click when you manually map the entry, it will properly read as a button press every time. This completely eliminates this "mysterious bug" so many youtubers and forum posts refer to.
However, none of this affects when RetroPie tries to auto map the first joystick in an emulator. How might I set RetroPie to de-prioritize or even ignore the analog input, leaving the button input intact? I assume this has to be done at a system level, so am I looking to create a udev rule? If so, what is the syntax? I like to think I'm a quick study on these things, but I am in need of a starting point as this issue has seemingly gone undiagnosed in every corner I have looked.
-
It just occurred to me that I might be coming at this all wrong. For anyone who knows, let me ask you this...
When a controller's joystick is auto-mapped in RetroPie outside of RetroArch cores, does it use an existing controller map to do so? If so, I can simply change "axis-2" to "button-4" and call it a day. However, if it auto-maps it on the fly each time, I imagine some sort of system rule would be necessary.
Thanks
-
Bump.
Any information on how RetroPie Auto-Maps it's joysticks would be most helpful. Again, it's mapping analog shoulder buttons as directional movement that conflicts with the actual joystick which makes anything outside of RetroArch unplayable.
-
This wont help but Daphne doesn't auto detect it has a config file you have to manually edit unless it's stock config maps correct to your controller.
-
That's true except for the joystick. Below is an excerpt from the config file.
"# Each input is mapped to 2 keyboard keys and one joystick button."
"# A joystick's first analog stick is also automatically mapped."So, after the controller is configured manually, Daphne auto-maps what it thinks is a joystick when launched, but somehow includes the axis input of the shoulder buttons. Then the two shoulder buttons fight for control with the joystick for left and right. This same behavior is seen everywhere in RetroPie where a joystick is used with the exception of RetroArch. If I could somehow tell the system to ignore the two shoulder axis inputs, everything would fall into place.
-
For anyone who happens upon this in the future with a similar issue, I have a little time to spare, so I thought I'd document my progress so far. What is happening is that my analog shoulder buttons don't have a preset to where their resting positions should be. Knowing that, I was able to discover that many systems (including parts of RetroPie) read axis values outside of a resting position as being active. So when the software goes to auto-map the joystick, it gets confused and combines the active axis input with that of the actual joystick.
With this information in hand, my next step will be to explore software options that will calibrate the resting positions of the shoulder buttons. When that is done, everything else should fall in line. Two examples are; Daphne should no longer have two input methods fighting for control and ScummVM should no longer lock it's mouse in the upper left when controller input is active.
I'll report back here when I find out which tools do the job, but at first blush it looks like running "jscal" and then configuring a "udev" rule from there might do the job.
-
Well, jscal seems to have done the trick. Now all that is left is to create a udev rule to auto-calibrate the controller and life will be peachy. I haven't tried out Daphne yet, but the joystick cursor in ScummVM is no longer locked and those two issues were symptomatic of the same problem.
Seeing as how I have pieced together the information needed to diagnose and solve this problem from many sources, I plan to write a detailed how-to thread separately to this one. It will mainly cover Gamecube controller adapters and the various DolphinBar modes as primary examples, but it should serve as a decent guide to solving most input issues with finicky controllers, using the included tool set found in RetroPie.
So, among other things, look forward to digging out that Wavebird as well as Wiimote light gun action in mouse supported emulators.
-
I'm curious what controller you are using? I have an XBOX 360 controller and it works fine for both Daphne and ScummVM. I've never had the cursor stuck in the corner in ScummVM. For Daphne I left the default keyboard codes and changed the joystick values to better suit my style but it does work fine with defaults.
Are you saying the the trigger button works as an axis (like 2 and 3) until fully depressed it's a button value (like 6 and 7)? Isn't that how it supposed to work or you want to isolate the two actions?
Daphne by default maps the trigger buttons on an XBOX 360 controller (I believe it's 6 and 7 but you can change that value to whatever you want below. It's the 3rd value on each line). Now that the driver between wired and wireless are standardized for the XBOX you'll need to change 14, 15, 16 & 17 also. Changing the values is just a quick integer modify if the trigger buttons aren't to your liking.
/opt/retropie/configs/daphne/dapinput.ini
[KEYBOARD] KEY_UP = 273 114 5 KEY_DOWN = 274 102 7 KEY_LEFT = 276 100 8 KEY_RIGHT = 275 103 6 KEY_BUTTON1 = 306 97 14 KEY_BUTTON2 = 308 115 15 KEY_BUTTON3 = 32 113 16 KEY_START1 = 49 0 4 KEY_START2 = 50 0 0 KEY_COIN1 = 53 0 1 KEY_COIN2 = 54 0 0 KEY_SKILL1 = 304 119 0 KEY_SKILL2 = 122 105 0 KEY_SKILL3 = 120 107 0 KEY_SERVICE = 57 0 0 KEY_TEST = 283 0 0 KEY_RESET = 284 0 0 KEY_SCREENSHOT = 293 0 0 KEY_QUIT = 27 113 17 END
-
@Riverstorm said in Daphne & Basic Auto-Config Failure:
I'm curious what controller you are using?
I am using a Wavebird Gamecube controller and have tested it with three separate connection methods, all to the same effect. The Raphnet adapter works perfectly out-of-the-box, The Mayflash 4-port adapter was tested in HID PC mode, but ultimately needed ToadKing's driver to work in WiiU mode. Due to the fact that all the RetroArch cores worked perfectly with either connection method and everything outside of those were getting mixed axis inputs, I assumed that the problem was in how the system detects joystick input as opposed to how RetroArch does.
While I still can't explain why RetroArch's detection works so much better here, I have learned that the overall problem has more to do with the Wavebird itself rather than the system detection or even the adapters. Running jstest and jscal showed me that I needed to set a resting position for the analog triggers so that the system knew when they were inactive, but it also showed me that as these triggers are pressed, input data was bleeding into the other axis. I tested this with a few other wired Gamecube controllers as well as a few aftermarket wireless Gamecube controllers and they did not have this same problem.
Again, I must point out that while this is certainly isolated to the Wavebird, RetroArch performes perfectly despite all of this, leading me to believe that it is possible to read this controller's input correctly. My next step is going to involve using xboxdrv to map all input from the Wave bird, while specifically telling it to ignore the axis input from the two shoulder buttons.
Why go through all of this? Well, that's really the true "game" here for me. Having a fully tailored retro arcade system is actually somewhat of a byproduct of the fun I have trying to make a fully tailored retro arcade system.
-
@mediamogul said in Daphne & Basic Auto-Config Failure:
Why go through all of this? Well, that's really the true "game" here for me. Having a fully tailored retro arcade system is actually somewhat of a byproduct of the fun I have trying to make a fully tailored retro arcade system.
Ok, I can appreciate that. I've done several projects where I spent more time building rather than playing but as I get older I would hope to reverse that. ;) I've mostly stuck to a well beaten path with XBOX controllers and I-PAC's that both work flawless out of the box. I do have my eye on the RetroPie ControlBlock which I think would be a very interesting setup.
-
The control block does look nice. If I identify at all as a "Collector" it would be as a video game controller collector. I have some very unique controllers that I have working on all variety of different platforms. Once I first got my Mattel Power Glove to work as a standard USB controller, I was hooked.
My last retro gaming system was a hacked Wii and I have pushed it absolutely as far as it can go, which means a lot of the fun is over for me. It even has full light gun support for all the pertinent systems that supported it back in the day. In moving to RetroPie, one of my main goals is to carry over all the controllers I accumulated for multiplayer from my Wii.
What I've pleasantly found out is that the techniques I'm learning here will carry over to adapting virtually any USB compliant controller to any linux based platform for the foreseeable future. I'm very excited about the possibilities as I have never liked the idea of a single dominant controller for an open platform.
-
@mediamogul said in Daphne & Basic Auto-Config Failure:
What I've pleasantly found out is that the techniques I'm learning here will carry over to adapting virtually any USB compliant controller to any linux based platform for the foreseeable future.
Not sure what you mean here. In the capacity you're writing drivers for the Libretro cores to make USB compliant devices work with Retroarch/RetroPie?
I'm very excited about the possibilities as I have never liked the idea of a single dominant controller for an open platform.
Doesn't every platform open, closed, proprietary, etc. have some dominant controller sort to speak. I would guess the top five controllers probably make up the lion's share of the user population simply because they are widely used and supported. You have to start somewhere when supporting devices why not the #1 best sellers, top used controllers, etc. I do appreciate those that support the one off devices that have potential to be the next best seller or niche usages or simply as it sounds in your case a collector enthusiast.
-
Can anyone please tell me how to run dragons lair 2, I got all the ones that work under raspberry but lair2 can not do it, please help, thanks. I got the files I believe I am doing something wrong with the rom, I got the lair2 but the files are dl2-xxxx.
Thanks in advance.
-
@dalogan72 said in Daphne & Basic Auto-Config Failure:
Can anyone please tell me how to run dragons lair 2
Since you have other Daphne games running you probably know the name, directory structure format and file locations. Do you have a specific error or screenshot of the error when you run DL2?
This thread has a lot of useful information and extras on Daphne too:
-
@dalogan72 said in Daphne & Basic Auto-Config Failure:
Can anyone please tell me how to run dragons lair 2
Thanks in advance.
Dragon's Lair 2 runs exactly the same as the others just make sure you have your frame file and rom in the correct directory. The lair2 rom will use the dl2 file names.
-
@Riverstorm said in Daphne & Basic Auto-Config Failure:
Not sure what you mean here. In the capacity you're writing drivers for the Libretro cores to make USB compliant devices work with Retroarch/RetroPie?
RetroPie has a universal gamepad driver available in it's default installation. It's just that, due to it's name, many people tend to overlook all that it can do. The xboxdrv can be used to adapt any input device that the system can read as an event, which pretty much opens the door to anything. It can also be used in a capacity to map keyboard commands to a gamepad, allowing controller support to those emulators that only support a keyboard. After being setup, the system (in this case RetroPie) assumes the input device is a standard XBox gamepad or basic keyboard.
Doesn't every platform open, closed, proprietary, etc. have some dominant controller sort to speak. I would guess the top five controllers probably make up the lion's share of the user population simply because they are widely used and supported. You have to start somewhere when supporting devices why not the #1 best sellers, top used controllers, etc. I do appreciate those that support the one off devices that have potential to be the next best seller or niche usages or simply as it sounds in your case a collector enthusiast.
It's just a difference in computer philosophy. There's nothing wrong per se with a dominant controller being used by the masses. We should consider ourselves lucky that there is one that works very well and is available to all. But to some, at the heart of running a hobbyist computer is the notion that practically anything is possible with a little imagination and perseverance. It's easy to forget this as we live in a time where the computer is being thought of more and more as an appliance. Which again, isn't necessarily a bad thing for the masses, it's just that notion limits what is possible for the sake of convenience. Thankfully both philosophies are well catered to in the open source world we find ourselves in here. Things can be as simple or advanced as any one of us wishes.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.