Have XBMC and RetroRig running alongside with each other

[beaumanvienna]

An existing install of XBMC shall not be influenced by RetroRig. The installation of RetroRig shall be non-intrusive for an XBMC installation. RetroRig shall run on its own and dedicated settings.

[mdeguzis]

Since I have to remap the keyboard.xml assignments I don't see this happening. I skin things, and remove home buttons. RetroRig is meant to be a standalone options and not for an existing XBMC implementation, let alone an existing system of Ubuntu. It's mean for those who wish to repurpose and old PC, or slice of a partition and run this installer after the Ubuntu install. Splitting things heavily in XBMC in the way you want is not something I intend to do, but I am welcome to pull requests with whatever folks drum up. I could always make an alternative branch, idk. The beta branch will be updated in a few hours if you wish to checkout the beta with git and make code alternations.

[beaumanvienna]

I get your concept. I'm not familiar with XBMC internals, my idea was to have it run off a different set of settings, maybe .retrorig instead of .xbmc. For the time beeing your approach is definitely a good way to get to a stable version. On the other hand, it's quite limiting the scope of your work. Consider the "spouse-approval factor", not everybody is allowed to have an arbitrary amount of computers running ;-) If people have setup XBMC already, maybe for their living room, RetroRig might spoil their existing installation. In my case that is a dedicated gaming/home theater combination, no way I would go back to my old machine for gaming. And, not sure where I read this, there is a project for XBMC integration in SteamOS going on right now, which in turn could benefit from RetroRig. Besides, just targeting Ubuntu, I don't know. Like I said, it's definitely a good approach for the moment to figure out the minimum requirements and get to a decent version. Be that as it may, it's totally up to you to decide on priorities and whether to close this ticket or not.

[mdeguzis]

Trust me, it's quite complex when setting all this internal XML code in XBMC up ahead of time. As far as the spouse approval option, I can't do this at the moment. Yes, maybe in the future I can figure something out, but I do not know how to achieve what you want (changing internals of XBMC without...changing the internals?). This is largely due to keyboard.xml needing to be rewritten due to how it's all setup with controls for emulators and such. If it is limiting, than that is my fate. This project started as a way to backup my configs, and it is a personal project from the start. I can't appease everyone with the skillset I have. I do plan on trying to make this work with SteamOS+XBMC. Again, this is meant for folks re purposing old PCs. For things to be unobtrusive, all you have to realistically do is partition about 10 GB off for a Ubuntu install, and just use the same home directory (if its compatible of course). This is one that requires a great deal of thought. I am not saying no, or not impossible, but something that can only be looked at after many other things stabilize and are implemented.

[beaumanvienna]

I checked the source code of xbmc. As far as I can tell there's no explicit environment variable to set to change ".xbmc" to a different folder: http://pastebin.com/Qs4465jK (from xbmc/Application.cpp, look for "userHome") But it evaluates $HOME. This could be tweaked before xbmc is called.

[mdeguzis]

Interesting. Again, something II am open to looking at.

[mdeguzis]

JC: Ticket reopened for work.

[beaumanvienna]

Right now, the folder destination for .xbmc is hard-coded in RetroRig. It appears in ./scriptmodules/configuration.shinc ./scriptmodules/gamepads.shinc ./scriptmodules/helpers.shinc ./scriptmodules/setup.shinc ./supplimental/update-git-configs.sh

Would you consider changing this to a variable to be too distracting? I could change this with my next pull request.

I still need to find out why our version of XBMC needs XBMC_HOME=/usr/share/xbmc to be set up, while the regular install doesn't need this. Now we put the export command to our launcher, which leaves a regular call of xbmc without the right environment. If nothing helps, we could add the export command to ~/.bashrc. But probably we'll find out, like we always do ;-)

With my latest patching of xbmc if have started to make a handshake between the service rescan and xbmc. I can now easily check upon starting the service, if xbmc is capable of handling the user signal.

In our launch script startXBMC.sh. we need to tweak $HOME to ~/.retrorig (Btw. this should be renamed to startRetroRig.sh.)

I understood you are working on placing a RetroRig starter to the desktop (or panel?).

Well, and that's it, basically, I would they.

[mdeguzis]

Would you consider changing this to a variable to be too distracting? I could change this with my next pull request.

We could set a variable I think in the main setup script, in the same vein $rootdir and $scriptdir are set. You're welcome to test it out. Since we are in fairly different timezones, I won't be making any changes (I think haha) until I would get home in +09:00. Give it a go, pull the latest beta, and try it. I think I finally squashed the annoying bug I had (indirectly) that prevented RCB from starting on the first run only (/#39):

23:49:08 T:140150370654144   DEBUG: ------ Window Deinit (Startup.xml) ------
23:49:08 T:140150370654144   DEBUG: ------ Window Init (Home.xml) ------

After first run, things initialize right, odd. I simple captured that userdata folder after that, and things started to work on first run consistently. Odd I know. I did disable the add on updater, so it had to be some kind of integrity check that I couldn't find in the skin xml at the moment, or XBMC itself. Either way, it seems to be fixed (until further notice).

There was Yea I am not sure how XBMC is called in relation to the xbmc-bin and it's location. It's possible there could be a symlink we could create. Export yes is a dirty workaround, but you're right.

Your improvements in the cpp files highly invaluable JC, that is helping immensely. The shortcut, called "RetroRig.desktop" in the code goes the Unity bar (universal code with gsettings/sed), and the desktop (still needs your fix for all languages with xdg). Realistically, most folks ignore the destkop in Ubuntu, but I think we should keep it if this ever goes to other distros (especially since it probably works fine on Mint like you test sometimes). Good progress!

I am happy too that I have the IRC bot configured from github.com to the IRC channel to show the commits.

[mdeguzis]

I decided this will wait until 0.8.2, since a few quick tests showed that some things don't pick up right. For instance the skin doesn't work, hotplugging doesn't work. Maybe I'm missing some variables. What I did to test was do EXPORT HOME=/home/test/.retrorig and copy the contents of .xbmc into that new dotfile. We'll make these changes for 0.8.2

[mdeguzis]

coming back to this JC to another look. How difficult is it to use our own dotfile (.retrorig) now that some of the improvements have been made? I am thinking we do this at compile time?

[beaumanvienna]

I have tried that yesterday too. I still don't see a reason to re-compile XBMC for that issue.

With

/usr/share/applications/startXBMC.sh: http://slexy.org/view/s2iBO7YdpX /usr/bin/xbmc-retrorig: http://slexy.org/view/s27WM23IE0 (search it for .retrorig) sudo chmod ugo+x /usr/bin/xbmc-retrorig mkdir ~/.retrorig mv ~/.xbmc/ ~/.retrorig/

I checked the files in .xbmc for absolute paths referring to ~/.xbmc, but didn't find anything. The references that you enter to the emulator config files or RCB should be fine, because you use absolute paths (for ~/RetroRig/ROMS etc.). Also the log in ~/.retrorig/.xbmc/temp/xbmc.log looked OK.

[mdeguzis]

OK we can just push this to a later version and focus on refining the rest of the current planned features I have on the wiki.

On July 7, 2014 1:29:20 AM EDT, Jens-Christian notifications@github.com wrote:

I have tried that yesterday too. I still don't see a reason to re-compile XBMC for that issue.

With

/usr/share/applications/startXBMC.sh: http://slexy.org/view/s2iBO7YdpX /usr/bin/xbmc-retrorig: http://slexy.org/view/s27WM23IE0 (search it for .retrorig) sudo chmod ugo+x /usr/bin/xbmc-retrorig mkdir ~/.retrorig mv ~/.xbmc/ ~/.retrorig/

I checked the files in .xbmc for absolute paths referring to ~/.xbmc, but didn't find anything. The references that you enter to the emulator config files or RCB should be fine, because you use absolute paths (for ~/RetroRig/ROMS etc.). Also the log in ~/.retrorig/.xbmc/temp/xbmc.log looked OK.

---

Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/issues/31#issuecomment-48142157

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

[mdeguzis]

By only reason I wanted this before was that we could completely separate our XBMC and their addons and data. No biggie right now.

On July 7, 2014 1:29:20 AM EDT, Jens-Christian notifications@github.com wrote:

I have tried that yesterday too. I still don't see a reason to re-compile XBMC for that issue.

With

/usr/share/applications/startXBMC.sh: http://slexy.org/view/s2iBO7YdpX /usr/bin/xbmc-retrorig: http://slexy.org/view/s27WM23IE0 (search it for .retrorig) sudo chmod ugo+x /usr/bin/xbmc-retrorig mkdir ~/.retrorig mv ~/.xbmc/ ~/.retrorig/

I checked the files in .xbmc for absolute paths referring to ~/.xbmc, but didn't find anything. The references that you enter to the emulator config files or RCB should be fine, because you use absolute paths (for ~/RetroRig/ROMS etc.). Also the log in ~/.retrorig/.xbmc/temp/xbmc.log looked OK.

---

Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/issues/31#issuecomment-48142157

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

[beaumanvienna]

Not sure if you understood that right. I was trying to say it works already :-)

[mdeguzis]

Well...it was 01:40 when I read all that haha. I want to put that into it's own dotfile if it does infact work.

[mdeguzis]

That worked. So I'll replace the hardcoded paths in the setup script. How on earth did you figure out the contents of http://slexy.org/view/s27WM23IE0 ? Seriously, you're an invaluable asset to my vision on this project with the tougher cpp and XBMC portions that would have taken me a lot longer to figure out on my own. Really appreciate it.

RCB is broken using the .retrorig dot file. Might just have to make some adjustments in the addon's xml. I'll have to look at this later if it's not apparent to you while i'm away at work. It actually might be as easy as re-adding the addon while in the new .retrorig

[mdeguzis]

Also, $home/.retrorig is set as a variable to $xbmc_home, per your suggestion to use a variable. You'll see this in the scripts.

[mdeguzis]

We are in business!!!! see IRC, since I posted so many things in a row of what I did. I can post here later if you can scroll back up (you're still in the channel). I had to push config files to the .retrorig, and made two vars, one for xbmc_home, and one for config_home (the emulator stuff and more).

[mdeguzis]

This one is pretty much solved, but i'll hold the ticket open for testing.

[beaumanvienna]

We then have to add /usr/bin/xbmc-retrorig to the patch level three files, right? We haven't added files to the deb packages so far, only exchanged existing ones, so we need to take a bit more caution. I'm still not that familiar with the Debian package mechanisms, but I my first try would be to just unpack, copy the file to the right location and re-pack it.

For the sake of simplicity I would suggest, that we just use the current debug version of xbmc.bin.

This is probably not the last patch level ;-)

http://slexy.org/view/s21UtCXst8

[mdeguzis]

Yes, more caution on this one. I am using your xbmc-retrorig out of /usr/bin/xbmc-retrorig as you described earlier. hhahah no not the last at all. Yes, let's just use the debug level, so we can testing throughout this week and it will make bug squashing easier. We'll talk about this more in depth soon.

[beaumanvienna]

sorry, must be

http://slexy.org/view/s2KK0YRWdS

Now I'm also posting at 1:40 well almost

And they rejected the SDL2 patch: https://github.com/libretro/mednafen-git/pull/4#event-138975887

time for snack

[mdeguzis]

This repo is just a mirror of the official release tarballs for diff purposes. We don't actually accept pull requests for it.

Maybe this just means you need to submit the pull request to the origin, not that mirror repo. 1:40 is late!

[beaumanvienna]

the origin is not at git hub that's the problem. Have a look at the script, it's still wrong but you get the meaning

[mdeguzis]

Looks ok at first glance. What's wrong with that pl3 script?

[beaumanvienna]

the unpack commands since I changed it from the original to pl2 packages

[mdeguzis]

Yea maybe I have this wrong, but it just seems like you need to rename xbmc-bin_original.deb :

wget "http://www.libregeek.org/RetroRig/xbmc/xbmc-bin_Gotham_V13.1_patched_for_RetroRig_patchlevel_2.deb"

# unpack xbmc-bin
sudo dpkg-deb -x xbmc-bin_original.deb .
sudo dpkg-deb -e xbmc-bin_original.deb

To the actual file xbmc-bin_Gotham_V13.1_patched_for_RetroRig_patchlevel_2.deb ? I'm still new to deb packaging too.

[mdeguzis]

XBMC patch level 3 copied to: http://www.libregeek.org/RetroRig/xbmc/

sha1sum results xbmc-bin_Gotham_V13.1_patched_for_RetroRig_patchlevel_3.deb 13aa9213276104fd200d8e29cb48c65c6e78f922

xbmc_Gotham_V13.1_patched_for_RetroRig_patchlevel_3.deb 3c4a0183dfa877beda3ac73d166009530a745a9d1

build script xbmc_pl3_build.sh commited to supplemental/ beta branch. Once you confirm things are working for you, let me know, so I can move pl2 packages to the old directory. I am in the processes of testing this in beta.

results of build http://slexy.org/view/s21Eo5kR5c

scriptmodules/setup.shinc This has now been upgraded to xbmc patch level 3.

I'll be reviewing my install logs sometime tomorrow.

By the way I am signing up for a free 1 year of Amazon S3 Free-Tier services. At some point we can test out that speed.

initial test results Things install ok, please test as well. I'm sure I might find bugs tomorrow.

[mdeguzis]

Ok JC, tested from scratch this morning on a VM and test-PC, loooks good. But you'll want to verify the deb pkgs contain your debug information. It seems so, but of course you'll want to check. XBMC exits quick, so I am guessing yes haha. I like the debug versions, but if its not meant for users, we should store that away on my server. And I am looking into a CDN like Amazon S3, but it depends what I can afford. For now while the project has a small following, I will keep it on my server I think.

While all this is getting tested, I will start to look at logging, and we'll discuss soon how to shape that up. I want to get these core features from the Development and Features page on the wiki for 0.8.6 (I bumped it up a bit since we are doing a ton of new changes of large size). If something is missing from that list, let me know. I'd like to get a release into master maybe this week, or end of this week.

[beaumanvienna]

Great! I have to watch soccer tonight, cross your fingers for Germany!

I hope I still find a short moment to continue with mednafen today.

In my first approach from yesterday ( https://github.com/beaumanvienna/mednafen-git/tree/mednafen-0.9.36.2-SDL2-dual-head) I have changed the command line interface of mednafen.

I found a better solution here: http://www.maketecheasier.com/run-fullscreen-games-in-linux-with-dual-monitors/ Apparently, SDL programs should evaluate SDL_VIDEO_FULLSCREEN_HEAD. I'll add that to mednafen, then I can set this variable in xbmc, when changing the displays. Do you think this could work? I mean, if xbmc sets an environment variable, would that be seen by mednafen? It's still a sub-process... That would be a simple way to pass the monitor down the path. And breaking all the interfaces... -jc-

2014-07-08 12:44 GMT+02:00 mikeyd notifications@github.com:

Ok JC, tested from scratch this morning on a VM and test-PC, loooks good. But you'll want to verify the deb pkgs contain your debug information. It seems so, but of course you'll want to check. XBMC exits quick, so I am guessing yes haha. I like the debug versions, but if its not meant for users, we should store that away on my server. And I am looking into a CDN like Amazon S3, but it depends what I can afford. For now while the project has a small following, I will keep it on my server I think.

— Reply to this email directly or view it on GitHub https://github.com/ProfessorKaos64/RetroRig/issues/31#issuecomment-48321269 .

[beaumanvienna]

Sorry And not breaking all the interfaces...

2014-07-08 12:56 GMT+02:00 beaumanVienna . jc.lache@gmail.com:

Great! I have to watch soccer tonight, cross your fingers for Germany!

I hope I still find a short moment to continue with mednafen today.

In my first approach from yesterday ( https://github.com/beaumanvienna/mednafen-git/tree/mednafen-0.9.36.2-SDL2-dual-head) I have changed the command line interface of mednafen.

I found a better solution here: http://www.maketecheasier.com/run-fullscreen-games-in-linux-with-dual-monitors/ Apparently, SDL programs should evaluate SDL_VIDEO_FULLSCREEN_HEAD. I'll add that to mednafen, then I can set this variable in xbmc, when changing the displays. Do you think this could work? I mean, if xbmc sets an environment variable, would that be seen by mednafen? It's still a sub-process... That would be a simple way to pass the monitor down the path. And breaking all the interfaces... -jc-

2014-07-08 12:44 GMT+02:00 mikeyd notifications@github.com:

Ok JC, tested from scratch this morning on a VM and test-PC, loooks good.

But you'll want to verify the deb pkgs contain your debug information. It seems so, but of course you'll want to check. XBMC exits quick, so I am guessing yes haha. I like the debug versions, but if its not meant for users, we should store that away on my server. And I am looking into a CDN like Amazon S3, but it depends what I can afford. For now while the project has a small following, I will keep it on my server I think.

— Reply to this email directly or view it on GitHub https://github.com/ProfessorKaos64/RetroRig/issues/31#issuecomment-48321269 .

[mdeguzis]

I heard back from the skin dev on turning off the dark overlay on the home screen (which I had wanted to do to see how I liked that:

mikeyd @N3RD42

@ChrisBevan_Bath Hi Chris, is there a way in the home.xml that I can disable the home screen black overlay? I can make the change myself ok. - 06 Jul

Chris Bevan @ChrisBevan_Bath @N3RD42 You'll need to change 1080i/includes.xml. in "globalBackground" Delete instances of image controls with backgrounds/vignette.png

[mdeguzis]

Confirmed squashed/fixed in beta, 0.9.1-rc1. This will transition to master very soon.