XBMC PL 12 / Wii motion controller query after any gamepad type / PPSSPP with SDL2

[beaumanvienna]

XBMC PL 12 : GUI dialog "unmet dependencies / wanna disable yes/no" disabled for #133

Wii motion controller query after any gamepad type: The query to use a Wii motion controller used to show up only for PS3/Bluetooth. Moved it at the end of the gamepad setup, now it shows up no matter what.

PPSSPP with SDL2: The segfaulting was just a packaging issue, ppsspp was expecting certain assets in a predefined place. Fixed and uploaded to https://launchpad.net/~beauman/+archive/ubuntu/retrorig-testing.

[EDIT 14/10/26]: after testing this under Ubuntu and Ubuntu-Gnome, I've copied it to https://launchpad.net/~beauman/+archive/ubuntu/retrorig

The good news is that we are back on upstream/master for this package, after they've merged in my pull requests :-D

I've also pushed retrorig-setup v0:0.9.5.4.1 to my test repository.

When talking to an old friend this morning I noticed you mentioning me on http://www.libregeek.org/2014/10/20/retrorig-0-9-5-happy-retrogaming/

Thanks for that! Awesome!

[beaumanvienna]

Here's some feedback from running RetroRig under Ubuntu-Gnome 14.04.1:

There's something wrong with the figlet/dialog detection. Could you have a look at this?

I had again problems with my PS3 controller. It was mapped to device /dev/input/js1. This time connecting it via USB and then pairing it didn't help as work-around. I changed ps3_set_ctrl_assignments to make it work. I don't want to commit this code, because I'm afraid it might break your multi-controller work. Could you do me a solid and review it? Thanks! http://slexy.org/raw/s25pji6mJP

[EDIT 14/10/26]: GensGS doesn't work :-(

While the controls for XBMC are fixed now if the controller is assigned slot nb. 2, there is still a problem with dolphin: http://slexy.org/view/s213SXdOOk

[mdeguzis]

I'll check this once I get back to my hotel. Thanks!

On October 25, 2014 12:19:19 PM EDT, Jens-Christian notifications@github.com wrote:

Here's some feedback from running RetroRig under Ubuntu-Gnome 14.04.1:

There's something wrong with the figlet/dialog detection. Could you have a look at this?

I had again problems with my PS3 controller. It was mapped to device /dev/input/js1. This time connecting it via USB and then pairing it didn't help as work-around. I changed ps3_set_ctrl_assignments to make it work. I don't want to commit this code, because I'm afraid it might break your multi-controller work. Could you do me a solid and review it? Thanks! http://slexy.org/raw/s25pji6mJP

---

Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/pull/138#issuecomment-60487976

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[beaumanvienna]

I fixed rrs_prereq() and rrs_reboot(). It was one fi too much in rrs_done() and missing instructions in rrs_kernel_check(). So the complete file setup.shinc was corrupted.

[mdeguzis]

I got the distro-agnostic syscall abstraction mainly done/pre-tested tonight after getting back (#126). This pull request will be a primary focus for tomorrow.

[mdeguzis]

There's something wrong with the figlet/dialog detection. Could you have a look at this?

This should be fixed during my syscall abstraction work. There was a syntax error before even that.

I had again problems with my PS3 controller. It was mapped to device /dev/input/js1. This time connecting it via USB and then pairing it didn't help as work-around. I changed ps3_set_ctrl_assignments to make it work. I don't want to commit this code, because I'm afraid it might break your multi-controller work. Could you do me a solid and review it? Thanks! http://slexy.org/raw/s25pji6mJP

Is this code meant to replace the below snippet? Can you please link the entire function?

# Set PS3 Blu MAC value with the "joydetect" C program
# Credit for this goes entirely to http://www.reddit.com/user/ElFeesho
PS3_MAC_BLU=$(joydetect /dev/input/js0 | awk -F'[^:[a-zA-Z0-9]*' '{print $6}')
echo -e "\nController ID/MAC Address applied to XBMC controls was:\n$PS3_MAC_BLU \n"
sleep 2s

The problem with the way you have written things, vs. how I have them and intended them, is ps3_set_ctrl_assignments() is only called during the first case statements of gp_ps3_blu_main(). This is intentional to set the first LED controller / Player 1 slot to XBMC control. I will retest the pairing again tonight, but had no issue with the laptop / internal BT before I left for Ohio. I need to find out where the breakdown occurs for you. Review:

        # call pairing function to set current bluetooth MAC to Player 1
        n="1"
        ps3_pair_blu
        # Set up control assignments for emulators and XBMC control
        clear
        ps3_set_ctrl_assignments
        ps3_set_emulator_ids
        dialog --msgbox "Pairing of Player 1 Controller complete" 5 43 
        sleep 5s

No matter how many BT controllers you select, this above code fires off, setting P1 to the XBMC controls, and the emulator ID's that match. Dolphin and Stella have placeholders that are handled in ps3_set_emulator_ids() appropriately. If the MAC address isn't captured in ps3_set_ctrl_assignments() correctly, that it won't work in the subsequent ps3_set_emulator_ids(). The case statements (seen above) are ordered so that the assignents only affect a certain controller ID.

This begs the question of why your controller is detecting /dev/input/js1 and not js0? What is occupying js0? That would be important to know. If we need to do checks on if something is occupying that slot, then we can. That would be the most concrete reason why mine works just fine. When you are asked to pair Player1 / js0, and you have js1, of course that is going to mess things up. Hmmmmmm. You don't happen to be plugging in BOTH controllers via USB before you pair them via the BT dialog do you? The dialog instructs you to only plug in the first controller. In practice, I pair both my controllers with one cable. Maybe clarification is needed on my part. If there is a technical saftey net we can build into clean_gamepads(), maybe that will help as well.

While the controls for XBMC are fixed now if the controller is assigned slot nb. 2, there is still a problem with dolphin: http://slexy.org/view/s213SXdOOk

My intention was always to just have Player 1 be the primary control for XBMC. If player 1 is still being assinged player 2 / player 2 LED, then that's an issue still. I haven't had an issue, but I will retest.

We could continue to chat here before you rebase and submit a new PR, or skype/IRC whenever you want since we have a few things going on here.

[mdeguzis]

The USB-based function counterparts to Xbox/PS3 controllers do a rename of the js devices (noted here). That may have explained how your workaround seemed to work. In any case, review the above and let me know your thoughts. Things work fine for me, so it has to be some precedural issue, device occupying js0 already, or my crappy code :)

[beaumanvienna]

There's something wrong with the figlet/dialog detection. Could you have a look at this?

This should be fixed during my syscall abstraction work. There was a syntax error before even that.

It's fixed in this PR already. There was one "fi" too much and function "rrs_kernel_check()" was empty, which is apparently not allowed.

Is this code meant to replace the below snippet? Can you please link the entire function?

Yes. The code I'm suggesting is just a cure of symptoms. If the bug does not occur, my code will assign it to slot 0, same as yours did. It's just a fall back method. You can safely pull this in.

I will retest the pairing again tonight, but had no issue with the laptop / internal BT before I left for Ohio

I totally understand that. I never had that problem on my main rig either. Except for two month ago, when I tried to pair the newly bought controller. Your PS3/USB code did solve this issue back then. Thanks for linking https://github.com/ProfessorKaos64/RetroRig/blob/beta/init-scripts/ps3_usb_controller/xboxdrv, I'll study your code ASAP, to see what's going on. Professor, I'm on this now, you can forget this for a while. I'll see if I can either use some of the xboxdrv code to fix this, or to extend sixpair to state explicitly a slot. In general, I think it's good that we can sort out these kinds of bugs among the two of us, rather then scaring of new users.

You don't happen to be plugging in BOTH controllers via USB before you pair them via the BT dialog do you? The dialog instructs you to only plug in the first controller. [..]

No second controller, everything according to the setup instructions. From my side you don't have to retest anything right now. I got this.

[mdeguzis]

Thanks for reading my mountain of confusing text :) I'll check for the updated PR today if it shows up in my inbox. Thank you for your help JC

On October 27, 2014 10:42:19 AM EDT, Jens-Christian notifications@github.com wrote:

There's something wrong with the figlet/dialog detection. Could you have a look at this?

This should be fixed during my syscall abstraction work. There was a syntax error before even that.

It's fixed in this PR already.

Is this code meant to replace the below snippet? Can you please link the entire function?

Yes. The code I'm suggesting is just a cure of symptoms. If the bug does not occur, my code will assign it to slot 0, same as yours did. It's just a fall back method. You can safely pull this in.

I will retest the pairing again tonight, but had no issue with the laptop / internal BT before I left for Ohio

I totally understand that. I never had that problem on my main rig either. Except for two month ago, when I tried to pair the newly bought controller. Your PS3/USB code did solve this issue back then. Thanks for linking https://github.com/ProfessorKaos64/RetroRig/blob/beta/init-scripts/ps3_usb_controller/xboxdrv, I'll study your code ASAP, to see what's going on. Professor, I'm on this now, you can forget this for a while. I'll see if I can either use some of the xboxdrv code to fix this, or to extend sixpair to state explicitly a slot. In general, I think it's good that we can sort out these kinds of bugs among the two of us, rather then scaring of new users.

You don't happen to be plugging in BOTH controllers via USB before you pair them via the BT dialog do you? The dialog instructs you to only plug in the first controller. [..]

No second controller, everything according to the setup instructions. From my side you don't have to retest anything right now. I got this.

---

Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/pull/138#issuecomment-60603408

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[beaumanvienna]

Things work fine for me, so it has to be some precedural issue, device occupying js0 already, or my crappy code :)

This code is not crappy at all. It's actually pretty advanced. With that fancy test operator you use there. And rename 's/js4/js0/;s/js5/js1/;s/js6/js2/;s/js7/js3/' /dev. I can guess what it does but I had never imagined such code. Respect.

Thanks for reading my mountain of confusing text :) I'll check for the updated PR today if it shows up in my inbox. Thank you for your help JC

Roger that. I'll rebase my stuff tonight, you'll then be able to pull it in automatically.

[beaumanvienna]

Do we copy xboxdrv during the installation to /etc/init.d? If so we should have it installed right away by the Debian install package. Could you do a review of the files copied to sys-locations vs. the rules file?

[mdeguzis]

Ha I only wrote some of that init script lol. Well have yo work in some detection if there is systemd or not. I can check on that tonight. It probably should go in the distro detection function.

On October 27, 2014 10:58:11 AM EDT, Jens-Christian notifications@github.com wrote:

Things work fine for me, so it has to be some precedural issue, device occupying js0 already, or my crappy code :)

This code is not crappy at all. It's actually pretty advanced. With that fancy test operator you use there. And rename 's/js4/js0/;s/js5/js1/;s/js6/js2/;s/js7/js3/' /dev. I can guess what it does but I had never imagined such code. Respect.

Thanks for reading my mountain of confusing text :) I'll check for the updated PR today if it shows up in my inbox. Thank you for your help JC

Roger that. I'll rebase my stuff tonight, you'll then be able to pull it in automatically.

---

Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/pull/138#issuecomment-60606279

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[mdeguzis]

Yep its copied during install with the script. I can test the deb pkg after the PR due to all the changes and need to rebuild the pkg

On October 27, 2014 11:02:34 AM EDT, Jens-Christian notifications@github.com wrote:

Do we copy xboxdrv during the installation to /etc/init.d? If so we should have it installed right away by the Debian install package. Could you do a review of the files copied to sys-locations vs. the rules file?

---

Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/pull/138#issuecomment-60607053

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[beaumanvienna]

My branch is rebased, it can be pulled in automatically.

I looked into the PS3 controller issue tonight, without much success.

I added some debug lines to /usr/bin/sixad and started it manually. The output is exactly the same on both my desktop and my laptop. I've manually updated my laptop to kernel 3.14 (the one we had used before). On my main rig it always works, while on my laptop it always gets slot nb. 2 assigned. Only when I first had two controller configured for USB in RetroRig, it worked on my laptop to pair the very same controller for slot nb 1.

Both systems start with device js0 in /dev/inputs, while only on my laptop device js1 gets created for the BT connection. I'm puzzled.

Got to keep on searching...

[mdeguzis]

OK I'll merge this tonight. That's odd though. You shouldn't have devices populated.

On October 27, 2014 5:03:03 PM EDT, Jens-Christian notifications@github.com wrote:

My branch is rebased, in can be pulled in automatically.

I looked into the PS3 controller issue tonight, without much success.

I added some debug lines to /usr/bin/sixad and started it manually. The output is exactly the same on both my desktop and my laptop. I've manually updated my laptop to kernel 3.14 (the one we had used before). On my main rig it always works, while on my laptop it always gets slot nb. 2 assigned. Only when I first had two controller configured for USB in RetroRig, it worked on my laptop to pair the very same controller for slot nb 1.

Both systems start with only device js0 in /dev/inputs, while only on my laptop device js1 gets created for the BT connection. I'm puzzled.

Got to keep on searching...

---

Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/pull/138#issuecomment-60668750

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[beaumanvienna]

I've debugged sixad a bit (https://github.com/beaumanvienna/qtsixa/commit/2e4e98a44456b8201f075716fbb031d9f3bc0ac3), and found one occurrence of the LED number. It determines the number by scanning through /dev/input/js[0-9] counting only valid devices:

int get_joystick_number()
{
    int i, js;
    char jspath[16];

    js = 1;
    for (i=0; i < 10; i++) {
        snprintf(jspath, sizeof(jspath), "/dev/input/js%i", i);
        if (open(jspath, O_RDONLY) > 0) {
            js = i+1;
        }
    }

    return js;
}

Somehow I've got the impression that sixad has nothing to do with this. Maybe something in the kernel.

[mdeguzis]

Good work, i'm always impressed by those debuggers you insert into the programs, awesome job. Gotta eat something then i'll review and merge. Thank you JC

[beaumanvienna]

I think we have two options now: We can either live with the fact that for some reason the devices not always start with js0. When I pair two PS3 controller on my laptop, it will use js1 and js2. For the first controller we can easily determine which device it's using. That's already contained in this PR. Starting with this index we can increment the device number for each additional controller. This means the LEDs are not 100% OK, but people can probably figure it out if one controller has LED 2 lid, and the other LED 3, that this maps to player 1 and 2.

Or we'll fix the kernel driver. From the learning standpoint that would be pretty cool as well.

I would say alternative 1. That's the low hanging fruit.

Thank you JC

You are welcome! That's an interesting issue.

[mdeguzis]

Alternative 1 is more likely the option, yes. So strange I never ran into this. Must be unique situations, and the only way we will know is by people using it. We'll adjust accordingly. AWESOME job on the additions to building retrorig-setup. I will only trim the version number prefix and it's good to go. I like the way you added a section for essentially the maintainer, and the contributor/other users. Good idea.

[beaumanvienna]

Also, check out the new ppsspp version. State saves finally work!

Thanks for pulling this in!

[mdeguzis]

No problem, as always, your help is vital to the growth of this once-small project.

[mdeguzis]

....somehow your beta I merged in removed all my abstraction for the deb syscalls and the separated rrs_discover_distro. Did you rebase your branch from master?

I will manually merge in your changes tomorrow, unless you get to it first. Try not to submit anything until tomorrow, and if there is disagreement on any function, just let me know. For things like your controller fixes for Bluetooth PS3 detection, that is of course fine.

[beaumanvienna]

Darn it! I've wondered for a while why merging shows these funny effects. Do you remember last time when we just had merged the day before and for the second merge it showed this huge list of commits? That was strange too.

Like always, I use these lines to merge.

The lines I merged were this and this.

I did get your system abstraction code from version 0.9.7, that is only contained in beta, but not in master. So I don't think I merged with master. Also, on Github it said "this can be merged automatically".

I've been changing gamepads.shinc and XBMC-cfg/extras/gp_autodetect_xbmc.sh yesterday.

I hope we can figure out what happened here. Could you please do one thing. The code that got lost on your side can be tracked on github in the history of each file. Could you please link the code itself, and in the history of the file when it got lost? Thanks! One thing we should do is to meet on IRC and do some experimental committing step by step, synchronized over IRC. The steps would be: 1) I would get even with upstream/beta. 2) I'll make a line of test code and commit it in a PR. The result should be "this can be merged automatically" 3) You edit the same file and commit it. The result should be "can't be merged automatically" in my PR. 4) I do git fetch upstream/git merge. I should get your newly entered line of code. I will then merge and commit it back to my repository. The result should be "can be merged automatically". 5) You then pull in the PR. The result should be that you get my code plus keep yours. I think we can figure this out. Sorry for the inconvenience.

[beaumanvienna]

Professor, you are a smart guy. I need your help with two issues I had yesterday. I've programmed a new feature into gp_autodetect_xbmc.sh to start XBMC automatically when activating the first controller. It works OK so far, but there are two things that should be improved. One thing I had difficulties with was to find out the owner of the current X-session. Can you think of a better solution then this? The other thing you can maybe help me with is [the way how I call XBMC](sudo -u $user /usr/share/applications/startXBMC.sh &). This works basically fine, hotplugging and all that stuff is OK. However, the "turn off" option is broke. Any suggestions?

[mdeguzis]

Darn it! I've wondered for a while why merging shows these funny effects. Do you remember last time when we just had merged the day before and for the second merge it showed this huge list of commits? That was strange too.

That long line of commits that one time was due to the clean-git.sh run I did. I am going to heavily evaluate that process again to avoid such things, but this did not affect what code was there, merely commits being rebased or something after old archive data was flushed.

I hope we can figure out what happened here. Could you please do one thing. The code that got lost on your side can be tracked on github in the history of each file. Could you please link the code itself, and in the history of the file when it got lost? Thanks!

I can try to to check this out tonight. My main focus is to merge in your code once I do a final once-over of the changes I committed last night. It was good though, since I missed a few abstracted syscalls. That particular operation (abstraction) will take a little time to get perfectly

One thing we should do is to meet on IRC and do some experimental committing step by step, synchronized over IRC. The steps would be:....

I don't think that's how it happens. "A merge conflict usually occurs when your current branch and the branch you want to merge into the current branch have diverged. That is, you have commits in your current branch which are not in the other branch, and vice versa." See: http://fiji.sc/Git_Conflicts

I also like this explanation on Stack Overflow:

You will have a conflict if you merge:

•branch2 to master (no conflict)
•branch3 to master (conflict): 
That is because:

•The common ancestor would be master (with a second line empty)
•the source content is branch3 (with a second line including "3")
•the destination content is on latest of master (with a second line including "2", from the merge of branch2 to master)
Git will ask you to choose which content to keep ("3", "2", or both).

I could make commits, you pull them, you change a line of code or a bunch, commit changes, and its fine. What you may have done is pulled my commits, and saved over top of the new commit (maybe gedit/nano etc was not reloaded and you saved it). Or...maybe not. The best practice is to fetch and merge, rather than git pull, but I'm guilty of doing pulls (which does resolve in conflicts at times). Once you reload your files, you work from there to add your code in. In that sense, the abstracts should have never been over written.

But yes...we can do some practice this weekend, since I am on-call for my day job and I will be home. Setup a time for Saturday or Sunday, and I'll be around then. What I will do, is clone the beta branch to 'git testing' and we will try some stuff. In the meantime, like I am doing, readup on why merge conflicts happen, and merge / pull / fetch topics on the web.

We will figure it out :P. I mean, so far we have not had an issue.

[mdeguzis]

I will look at your controller comments tonight. Busy day at work.

[beaumanvienna]

Thanks for this elaborate answer! We really got to figure out what happened. I totally dig git, especially over SVN that I use at work, but I still need to learn how to avoid these edges.

I fixed the second issue already, sudo needed to know the group as well. See https://github.com/beaumanvienna/RetroRig/commit/4ae3f74670f641080b311df8f86d85e87742a99b My only question left would be how to detect the owner of a X-session other then my current approach. So if RetroRig is not started already, it can now be launched by activating a game controller.

I would appreciate some test commits very much! On Friday? My boss granted me to take next week off, so I'll try to book the next possible flight down to the Mediterranean Sea ASAP!! (YEAH) I'm heavily thinking about taking my laptop with me or not, can't decide! Maybe I'll take a week off from RetroRig, too...

[mdeguzis]

My only question left would be how to detect the owner of a X-session other then my current approach. So if RetroRig is not started already, it can now be launched by activating a game controller.

Yep, as said above, I will look this over tonight and see what comes to mind. Is activating RetroRig by controller something you think folks will want? It would be useful in case you exit due to issues, or errors, or if a segfault happens and you don't want to reboot, so I can understand your meaning there.

I would appreciate some test commits very much! On Friday? My boss granted me to take next week off, so I'll try to book the next possible flight down to the Mediterranean Sea ASAP!! (YEAH) I'm heavily thinking about taking my laptop with me or not, can't decide! Maybe I'll take a week off from RetroRig, too...

Friday I get home 4:30 EST GMT -4:00. So I could* do that later in the day for me, or Sat or Sun would be best. Yea, take some time off! We've been at this for a while. I can use that time to just sharpen up the wiki. It's not a race. But if you do take your laptop, i'll look at whatever code I can in my allowable time. Thank you JC

[beaumanvienna]

OK, deal! I'll be online 4:30 EST GMT -4:00 (P.M.) or 10:30 P.M. my time.

[mdeguzis]

Ok, almost done checking over your code additions and mine. I'll report back with an update when I think we are ok. I'll do a scratch install and see what I get. After that, Please backup and current work and pull a fresh copy of the beta branch, then inspect it. We'll be fine, don't worry. We've never had an issue merging before, so I think it was just a few missteps, which is why there is version control anyway :)

[beaumanvienna]

I suggest we do this together via xchat. I'm currently 17 commits ahead of your beta, a good practice for tomorrow. I've actually rebased two or so days ago, currently it can be merged automatically anyway.

Your last merge was OK, you got all of my code except one line. I had to fix one or two bugs in your software as well, nothing big. The rest is fine anyway. One thing I like to ask you though. You often times commit untracked files. Would it be OK for you not to use git add -A? It's not a big deal to delete them, but now as some of our scripts have reached more than a 1000 lines, the PR gets bloated. Just a suggestion though.

I'm done with reworking the PS3 controller. Would you like to get the PR now? Or everything synchronized via xchat? Fri 4:30 EST GMT -4:00 (P.M.) still OK for you?

[mdeguzis]

Let's do any PRs or stuff tomorrow. With the untracked files being pushed..I have a bad habit of using 'git add *' ... Is the proper way, as I've seen.. 'Git add .' for the current directory?

On October 30, 2014 6:39:41 PM EDT, Jens-Christian notifications@github.com wrote:

I suggest we do this together via xchat. I'm currently 17 commits ahead of your beta, a good practice for tomorrow. I've actually rebased two or so days ago, currently it can be merged automatically anyway.

Your last merge was OK, you got all of my code except one line. I had to fix one or two bugs in your software as well, nothing big. The rest is fine anyway. One thing I like to ask you though. You often times commit untracked files. Would it be OK for you not to use git add -A? It's not a big deal to delete them, but now as some of our scripts have reached more than a 1000 lines, the PR gets bloated. Just a suggestion though.

I'm done with reworking the PS3 controller. Would you like to get the PR now? Or everything synchronized via xchat? Fri 4:30 EST GMT -4:00 (P.M.) still OK for you?

---

Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/pull/138#issuecomment-61181977

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[beaumanvienna]

Alright, we'll get to the PR tomorrow.

I usually do a git status and copy&paste the files I like to commit into the git add command. It's late, I'm out. See you then!