Open beaumanvienna opened 10 years ago
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.
Are you sure you're not a genius? ^__^
On October 2, 2014 5:44:17 PM EDT, Jens-Christian notifications@github.com 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/getPosIt'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 callgetpos
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: https://github.com/ProfessorKaos64/RetroRig/issues/126#issuecomment-57714807
Sent from my Android device with K-9 Mail. Please excuse my brevity.
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!
Multi monitor support for xbmc has been fixed in upstream/master, see https://github.com/FernetMenta/xbmc/issues/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.
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.
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:
retrorig-setup.0.9.5.deb
or git clone https://github.com/ProfessorKaos64/RetroRig
ROMs
, BIOS
and Savestates
and RetroRig system filesapt-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?
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!!!
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
.
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 :)
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" notifications@github.com An: "ProfessorKaos64/RetroRig" RetroRig@noreply.github.com Cc: "Jens-Christian" jc.lache@gmail.com 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"}}
I've done the packaging for retrorig-setup
, see https://github.com/beaumanvienna/RetroRig/commit/a09621ab85fb976579d8f18dec70aa8bf9842f14
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!
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 notifications@github.com wrote:
I've done the packaging for retrorig-setup, see beaumanvienna@a09621a https://github.com/beaumanvienna/RetroRig/commit/a09621ab85fb976579d8f18dec70aa8bf9842f14
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 https://github.com/ProfessorKaos64/RetroRig/issues/126#issuecomment-58570400 .
Michael DeGuzis Email: mdeguzis@gmail.com Website: http://www.libregeek.org Linked In Resume/Profile http://www.linkedin.com/profile/view?id=124915388&trk=nav_responsive_tab_profile
Added some comments for Ubuntu-Gnome, see above.
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)
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!
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 notifications@github.com 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: https://github.com/ProfessorKaos64/RetroRig/issues/126#issuecomment-60554409
Sent from my Android device with K-9 Mail. Please excuse my brevity.
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-basedgetpos
helper] pcsx2 (xrandr) [ok] [EDIT 20141003: in combination with Qt-basedgetpos
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 functionCWinSystemX11::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.