RetroRig on Debian derivatives

[beaumanvienna]

Ubuntu 14.10 Utopic Unicorn

Needs six additional libraries. As quick&dirty patch the libraries are going to be copied manually.

Linux Mint 17 Qiana

Works , but multi monitor support breaks for XRand-based programs:
mednafen (SDL2) [ok]
GensGS (SDL2) [ok]
ppsspp (Qt) [ok]
mupen64plus (SDL2) [ok]
dolphin-emu (xrandr) [ok] [EDIT 20141003: in combination with Qt-based getpos helper]
pcsx2 (xrandr) [ok] [EDIT 20141003: in combination with Qt-based getpos helper]
xbmc (Xlib) [ok] [EDIT 20141005: xbmc updated to patch level 9 / 14.0 Helix]

Deepin 2014

Only tested in Virtualbox, everything OK after two small amendments.

Ubuntu-Gnome 14.04.1

GensGS is not working. Other SDL2 games are OK though.

Somehow XBMC gets minimized during gameplay and was not restored afterwards. I added RecreateWindow(); in this line of the new function CWinSystemX11::raiseMainWindow(void) to XBMC. This seems to solve the problem. [EDIT This works only partially.] The recreation takes about half a second after game exit. I hope XBMC doesn't get corrupted while getting controller inputs during this time.

[beaumanvienna]

For dolphin-emu I made the multi-monitor support work today.

I programmed a tiny program called getpos, which converts SD_VIDEO_FULLSCREEN_HEAD into display coordinates, see https://github.com/beaumanvienna/getPos

It's already packaged at https://launchpad.net/~beauman/+archive/ubuntu/retrorig

I switched dolphin back to the libreto version from Hunter-Kaller, which determines the display by coordinates from its ini-file.

In setResolution.sh I call getpos to set the display coordinates in Dolphin.ini dynamically. Works!
This is actually two good news, not only that dolphin-emu works flawless now under Mint, we are also using an unpatched version.

Some weeks ago when I had patched pcsx2, I have use exactly the code that now broke in dolphin-emu. I will strip it out again, and change it to coordinates in a configuration file accordingly.

[mdeguzis]

Are you sure you're not a genius? ^__^

On October 2, 2014 5:44:17 PM EDT, Jens-Christian [email protected] wrote:

For dolphin-emu I made the multi-monitor support work today.

I programmed a tiny program called getpos, which converts
SD_VIDEO_FULLSCREEN_HEAD into display coordinates, see
https://github.com/beaumanvienna/getPos

It's already packaged at
https://launchpad.net/~beauman/+archive/ubuntu/retrorig

I switched dolphin back to the libreto version from Hunter-Kaller,
which determines the display by coordinates from its
ini-file.

In
setResolution.sh
I call getpos and set the display coordinates in Dolphin.ini
dynamically. Works!
This is actually two good news, not only that dolphin-emu works
flawless now under Mint, we are also using an unpatched version.

Some weeks ago when I had patched pcsx2, I have use exactly the code
that now broke in dolphin-emu. I will strip it out again, and change it
to coordinates in a configuration file accordingly.

---

Reply to this email directly or view it on GitHub:
#126 (comment)

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

[beaumanvienna]

Thanks, that's nice! If I were, I had taken this approach directly.

Professor, getpos is an excellent tutorial project for packaging. It's just two lines of code more than a "hello world" program would need. It consists out of four files, next to the readme and license, there's only a project and one source file. Use qmake -o Makefile getpos.pro to generate the Makefile. Look how minimalist the rules files is, debuild has build-in support for qmake. Upload to launchpad in 3s!

[beaumanvienna]

Multi monitor support for xbmc has been fixed in upstream/master, see FernetMenta/xbmc#250.

It's a problem with mutter, the window manager of Cinnamon. It's overwriting the position request of xbmc, partly depending on the mouse position. This issue most likely affects Gnome based Linux distributions as well.

[mdeguzis]

Professor, getpos is an excellent tutorial project for packaging. It's just two lines of code more than a "hello world" program would need.

Awesome, i'll take a look and package this to my PPA tonight. I think in due time, the wiki tutorial will be truly invaluable to me and others intimidated by the more complex packaging scenarios, not to mention how Ubuntu does things :)

As for statically linking libraries, and support of other distros, as you have checked (I have only tested before on Mint 17). Should we continue using seperate branches, or maintain one* branch that detects the distro and applies certain modules/scenarios? Just planning a bit. This of course would be after we get this 0.9.5 release out the door.

[beaumanvienna]

Should we continue using seperate branches, or maintain one* branch that detects the distro and applies certain modules/scenarios?

Probably one branch. I started detecting distros here (until line 322)
https://github.com/beaumanvienna/RetroRig/blob/Ubuntu-14.04-Beta/scriptmodules/setup.shinc#L243

I think we need to move this into a dedicated function, and put it at the very beginning of retrorig_setup.sh

Speaking of packaging, I've started to think about packaging retrorig_setup.

My basic ideas are so far:

• Firstly we should create a team at launchpad, which will serve as PPA for RetroRig
• The RetroRig installation should be possible through both retrorig-setup.0.9.5.deb or git clone https://github.com/ProfessorKaos64/RetroRig
• Nice seperation between User folders ROMs, BIOS and Savestates and RetroRig system files
• Nice deinstallation of RetroRig automatically provided by apt-get. When packaging retrorig_setup we clone the repository as usual, remove the supplemental folder, and move system files like the retrorig icon or startXBMC.sh into the fakeroot environment to fakeroot/usr/icons or fakeroot/usr/share/applications/ respectively. The script shall detect if it is run from /home/user/, which would make copying of the files to the system locations necessary, or if it was called in say /usr/lib/RetroRig.

This will give us a better separation of user and system files, as well as remove the image of RetroRig of being hacky.. Any thoughts?

[mdeguzis]

Probably one branch. I started detecting distros here (until line 322)
https://github.com/beaumanvienna/RetroRig/blob/Ubuntu-14.04-Beta/scriptmodules/setup.shinc#L243

Ok, with that plan on mind, I will return the branches to having just master, so be sure to check tomorrow when doing any pull requests. The easy way to do this is to create a new branch called Beta, created from the Ubuntu 14.04 beta as a base. After tonight, all you will see is Master and Beta. Sounds weird, but is much better than attempting to merge things.

Speaking of packaging, I've started to think about packaging retrorig_setup .

Everything for a package works good. The only thing that held me up from doing this before was the controllers, since that is handled interactively. Also, if we change to a PPA package, I'd assume the .sh setup script would not go totally away, and would be needed for post install settings tasks until a proper way to do that in XBMC is found.

In any case, great ideas!!!

[beaumanvienna]

The only thing that held me up from doing this before was the controllers, since that is handled interactively

I meant to to have apt-get install RetroRig (or what we get when we clone it) into a system folder location. Just the files a user would need, so folder supplemental can be omitted. Some files that we copy to system locations during retrorig_setup.sh can already be installed by apt-get, like the icon at /usr/share/icons, startXBMC.sh in /usr/shareapplications, etc. This way we get a clean remove. Ah, and retrorig_setup.sh should be placed into /usr/bin/retrorig_setup. You would then still have to call sudo retrorig_setup as normal user. It should create a folder RetroRig in the directory where called, but just with ROMs, Saves and BIOS.

[mdeguzis]

retrorig_setup.sh should be placed into /usr/bin/retrorig_setup

I can make that small change tonight. Again, all of this is fine, and great, just worried about the controller setup. So if I understand you correctly, are you then assuming the users would be directed after install or per our readme to run the setup file to get the controller working? I am thinking of changing that underscore in the setup file to a dash, simply out of pure annoyance I get when typing it :)

[beaumanvienna]

I've made a few changes in the script files, maybe we should merge first. I'll create a PR on Saturday, Ok?

Gesendet mit meinem HTC

----- Reply message -----
Von: "mikeyd" [email protected]
An: "ProfessorKaos64/RetroRig" [email protected]
Cc: "Jens-Christian" [email protected]
Betreff: [RetroRig] RetroRig on Debian derivatives (#126)
Datum: Mi., Okt 8, 2014 14:44

retrorig_setup.sh should be placed into /usr/bin/retrorig_setup

I can make that small change tonight. Again, all of this is fine, and great, just worried about the controller setup. So if I understand you correctly, are you then assuming the users would be directed after install or per our readme to run the setup file to get the controller working? I am thinking of changing that underscore in the setup file to a dash, simply out of pure annoyance I get when typing it :)

—
Reply to this email directly or view it on GitHub.
{"@context":"http://schema.org","@type":"EmailMessage","description":"View this Issue on GitHub","action":{"@type":"ViewAction","url":"https://github.com/ProfessorKaos64/RetroRig/issues/126#issuecomment-58351345","name":"View Issue"}}

[beaumanvienna]

I've done the packaging for retrorig-setup, see beaumanvienna@a09621a

It's a first draft, the setup script now needs to be adopted to the new way of installing. I wouldn't recommend to install it via apt-get, but you could download and decompress the package from
https://launchpad.net/~beauman/+archive/ubuntu/retrorig/+packages

I did this on my new Acer laptop. Looks like I'm now equipped for some serious commissioning work abroad. :-D

Good luck for your test tomorrow!

[mdeguzis]

Thanks! Studying a lot tonight, as always, many thanks for your great work
and making this go far beyond I ever had hoped.

On Thu, Oct 9, 2014 at 4:15 PM, Jens-Christian [email protected]
wrote:

I've done the packaging for retrorig-setup, see beaumanvienna/RetroRig@a09621a
beaumanvienna@a09621a

It's a first draft, the setup script now needs to be adopted to the new
way of installing. I wouldn't recommend to install it via apt-get, but
you could download and decompress the package from
https://launchpad.net/~beauman/+archive/ubuntu/retrorig/+packages
https://launchpad.net/%7Ebeauman/+archive/ubuntu/retrorig/+packages

I did this on my new Acer laptop. Looks like I'm now equipped for some
serious commissioning work abroad. :-D

Good luck for your test tomorrow!

—
Reply to this email directly or view it on GitHub
#126 (comment)
.

Michael DeGuzis
Email: [email protected]
Website: http://www.libregeek.org
Linked In Resume/Profile
http://www.linkedin.com/profile/view?id=124915388&trk=nav_responsive_tab_profile

[beaumanvienna]

Added some comments for Ubuntu-Gnome, see above.

[mdeguzis]

I added some pre-checks so users can determine if they are supported or not on launch. This also ties in with OS/distro detection, and pkg manager detection. See commit 9b43191, 0ed362e, and 6e1f5c3. The script will only pause for 5 seconds if the platorm is not supported. The debian derivitives we support should now have distro-agnostic commands in the scripts, and are sourced based on what distro package manager is the primary default (e.g. apt-get)

[beaumanvienna]

Cool stuff!

The system detection I had started should be moved to the beginning of the install process. Currently we first add some (Debian-specific) repositories and then check for the OS. Maybe move it to your pre-checks?

When it comes to the PR, just let me know when a good time is to pull it in. I will then re-base it, so it can be pulled in automatically. Thanks!

[mdeguzis]

Give the beta another check. The dostro detection fores off first, then prepare folders , then software. At the top of software is the add repos function which contains your code. If we need to move it , not a problem. Just let me know, but it the beginning of the software install function should be fine, correct?

On October 27, 2014 2:26:25 AM EDT, Jens-Christian [email protected] wrote:

Cool stuff!

The system
detection
I had started should be moved to the beginning of the install process.
Currently we first add some (Debian-specific) repositories and then
check for the OS. Maybe move it to your pre-checks?

When it comes to the PR, just let me know when a good time is to pull
it in. I will then re-base it, so it can be pulled in automatically.
Thanks!

---

Reply to this email directly or view it on GitHub:
#126 (comment)

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