Closed GoogleCodeExporter closed 9 years ago
For reference the get-orig-source that I use reads 2 files (add/remove). The
add file contains:
CMakeLists.txt
bin/docs
bin/GameIndex.dbf
cmake
common
linux_various
locales
pcsx2
plugins/CDVDnull
plugins/CMakeLists.txt
plugins/FWnull
plugins/GSdx
plugins/GSnull
plugins/PadNull
plugins/SPU2null
plugins/USBnull
plugins/dev9null
plugins/onepad
plugins/spu2-x
plugins/zzogl-pg
tools
The remove file contains:
common/src/Utilities/x86/MemcpyFast.cpp
common/vsprops
pcsx2/3rdparty
plugins/GSdx/baseclasses
plugins/GSdx/vtune
plugins/zzogl-pg/build.sh
plugins/zzogl-pg/opengl/Linux/Makefile.am
plugins/zzogl-pg/opengl/Makefile.am
plugins/zzogl-pg/opengl/ZeroGSShaders
plugins/zzogl-pg/opengl/configure.ac
plugins/zzogl-pg/opengl/depcomp
plugins/zzogl-pg/opengl/install-sh
plugins/zzogl-pg/opengl/missing
tools/GSDumpGUI
Also it removes the win32/windows folders.
I guess the old autotools files included in zzogl could be removed from trunk.
There are some too inside the ZeroGSShaders folder but I currently just remove
the directory.
Original comment by debian.m...@gmail.com
on 11 Apr 2012 at 9:43
Note: plugins and pcsx2 are different projects. They're provided in the same
svn as convenience.
Trivial file:
plugins/GSdx/config.h
pcsx2/gui/Resources/rebuild.sh
tools/bin2app.sh
plugins/zzogl-pg/opengl/shaders.sh
Mine :p
linux_various/detect_missing_file_in_cmake.sh: *No copyright* UNKNOWN
The manpage too.
Just miss the header:
pcsx2/MTVU.h: *No copyright* UNKNOWN
plugins/zzogl-pg/opengl/ZZHacks.h: *No copyright* UNKNOWN
plugins/spu2-x/src/DplIIdecoder.cpp: *No copyright* UNKNOWN
Well this one I don't know: In last ressort, you can regenerate the ressource.h
file (outside of compilation). The tool only format image file to an include
file.
tools/bin2cpp/bin2cpp.cpp: *No copyright* UNKNOWN
I think you can remove this directory too:
plugins/GSdx/xbyak
Original comment by gregory....@gmail.com
on 12 Apr 2012 at 6:15
Ok. I clean most of issue. It remains the issue of bin2cpp.cpp...
Can you please send me a patch with the correct license for manpage.
Original comment by gregory....@gmail.com
on 12 Apr 2012 at 6:34
Most manpages just say:
AUTHOR
This manual page was written by XXX <XXX@XXX.com>, for the Debian system (but
may be used by others).
There are rare cases like gzip which throws a bunch of stuff since it's gnu.
Oh a quick question are these symlinks needed?
pcsx2/3rdparty
pcsx2/bin
plugins/zzogl-pg/opengl/compile
I was trying to make get-orig-source make reproducible results and those pesky
symlinks ruin everything with their timestamps :P since svn does not preserve
timestamps from directories or symlinks it seems.
I just ask since I'm probably pushing the envelope on this clause by removing
cruft:
"A repackaged .orig.tar.{gz,bz2,xz}:
<snip>
should, except where impossible for legal reasons, preserve the entire building
and portablility infrastructure provided by the upstream author. For example,
it is not a sufficient reason for omitting a file that it is used only when
building on MS-DOS. Similarly, a Makefile provided by upstream should not be
omitted even if the first thing your debian/rules does is to overwrite it by
running a configure script."
Original comment by debian.m...@gmail.com
on 12 Apr 2012 at 6:58
Well at least
plugins/zzogl-pg/opengl/compile
points to an automake file so it could get removed.
Original comment by debian.m...@gmail.com
on 12 Apr 2012 at 7:00
Don't know if windows use it. But without everything WIN (3rd party and others
...) won't compile anyway
Original comment by gregory....@gmail.com
on 12 Apr 2012 at 7:16
I rewrite bin2cpp, change the manpage to GPLv3.
Except ps2hw.dat and nvidia-cg depency, is it ok for you?
Original comment by gregory....@gmail.com
on 12 Apr 2012 at 5:54
Original comment by gregory....@gmail.com
on 12 Apr 2012 at 6:02
Well the ps2hw.dat and nvidia issue are the only "big" things left. Since there
is an email from ZeroGS then probably the ps2hw.dat thing should not be that
hard at least.
When those 2 issues get fixed I can probably talk to the Debian Games team
again. The first time they seem to not be interested until those issues where
resolved. They will review it and then if that pass Debian ftp-master and their
lawyers will review it since it has to pass through the NEW package process.
They are most likely most strict than I'm so there may be other issues later.
Anyway for reference here is my compete TODO list this time:
* debian/changelog:
- Update to a revision where the copyright issues are resolved and that is a
good release point for the 0.9.9 series. The stable 0.9.8 series can't be
released unless the copyright updates are backported and the debian folder
updated. Basically after all the issues are resolved ask upstream to make a
revision with updated PO files (msgmerge) and that they think it's fit for
release in Debian.
- Set from UNRELEASED to unstable/experimental.
* debian/copyright:
- Run "licensecheck --recursive --copyright *" and check that the copyright
file is complete. Must fix those pesky plugins.
- Verify if whole project is GPL-3 or GPL-3+. http://code.google.com/p/pcsx2/
says Code license "GNU GPL v3" it's most likely GPL-3+.
- zzogl is GPL-2+ but links with non-free nvidia-cg-toolkit.
- ps2hw.dat is distributed as a precompiled shader instead of building it or
loading it on demand.
- A COPYING.GPLv2, COPYING.GPLv3, COPYING.LGPLv2.1, and COPYING.LGPLv3 are
most likely needed in the source root. Not sure if there is another license
used that requires the full original license in the source.
* debian/rules:
- Verify the effects of the hardening flags. They seem harmless but upstream
thinks that they may affect performance. BINDNOW and PIE which truly cause
performance issues are currently disabled. This is in the rules file:
# FIXME: Upstream thinks that hardening may affect performance.
#export DEB_BUILD_MAINT_OPTIONS=hardening=-all,+format,+relro
This would disable only stackprotector and fortify. The code should already
segfault if buffer overflows and stack overwrites occurs. More info in:
http://wiki.debian.org/Hardening
* debian/Readme.source:
- Verify the removed files are all explained and match get-orig-source-remove.
* debian/TODO.Debian
- Delete this file when I'm done.
Curent WIP:
- DEB_BUILD_OPTIONS= nostrip noopt
- Workaround the PO clean issue.
- What to do with pcsx2_ZZReplayLoader and add a manpage I guess.
- I: pcsx2: possible-documentation-but-no-doc-base-registration
- Submit patch for the hundreds of DSO linking by the plugins.
If the program using the plugins actually has functions with those names and
the plugins use those version then this linking is not needed. If the plugins
uses the symbols provided by -lz -lX11 -lgtk-x11-2.0 then this is needed. Since
there is no way of knowing which one is true during compilation only a warning
is given if it's determined that they are plugins. This will introduce a little
overlinking since the cmake scripts adds way more than it's probably needed.
dpkg-shlibdeps: warning:
debian/pcsx2/usr/lib/i386-linux-gnu/games/pcsx2/libFWnull-0.7.0.so contains an
unresolvable reference to symbol gtk_dialog_get_type: it's probably a plugin.
dpkg-shlibdeps: warning: 19 other similar warnings have been skipped (use -v to
see them all).
dpkg-shlibdeps: warning:
debian/pcsx2/usr/lib/i386-linux-gnu/games/pcsx2/libonepad-1.1.0.so contains an
unresolvable reference to symbol gtk_tree_model_get_type: it's probably a
plugin.
dpkg-shlibdeps: warning: 69 other similar warnings have been skipped (use -v to
see them all).
<snip>
Attached is the patch for the unresolved references. This introduces a little
overlinking but some of the files without the patch are already overlinked:
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader debian/pcsx2/usr/games/pcsx2 were
not linked against libatk-1.0.so.0 (they use none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader
debian/pcsx2/usr/lib/i386-linux-gnu/games/pcsx2/libzzogl-0.3.0.so were not
linked against libXext.so.6 (they use none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader debian/pcsx2/usr/games/pcsx2 were
not linked against libfreetype.so.6 (they use none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader
debian/pcsx2/usr/lib/i386-linux-gnu/games/pcsx2/libzzogl-0.3.0.so were not
linked against libICE.so.6 (they use none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader
debian/pcsx2/usr/lib/i386-linux-gnu/games/pcsx2/libzzogl-0.3.0.so were not
linked against libGLU.so.1 (they use none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader debian/pcsx2/usr/games/pcsx2 were
not linked against libglib-2.0.so.0 (they use none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader debian/pcsx2/usr/games/pcsx2 were
not linked against libgdk_pixbuf-2.0.so.0 (they use none of the library's
symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader debian/pcsx2/usr/games/pcsx2 were
not linked against libcairo.so.2 (they use none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader debian/pcsx2/usr/games/pcsx2 were
not linked against libpango-1.0.so.0 (they use none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/pcsx2/usr/games/pcsx2_ZZReplayLoader
debian/pcsx2/usr/lib/i386-linux-gnu/games/pcsx2/libzzogl-0.3.0.so were not
linked against libSM.so.6 (they use none of the library's symbols).
Original comment by debian.m...@gmail.com
on 12 Apr 2012 at 8:57
Attachments:
Ok, I changed the get-orig-source routine to download everything and then
remove non-DFSG-free cruft and anything with a valid reason to be removed. This
will stick with policy and avoid having to fix this later.
That results in the following trivial files as the only ones with missing
information:
bin/launch_pcsx2_linux.sh: *No copyright* UNKNOWN
build.sh: *No copyright* UNKNOWN
pcsx2/bin/launch_pcsx2_linux.sh: *No copyright* UNKNOWN
rebuild.sh: *No copyright* UNKNOWN
The following is the list of all files/directories removed by get-orig-source
as explained in a README.source
+ 3rdparty => Already included in Debian.
+ bin/Langs => Remove the pre-generated language files.
+ common/src/Utilities/x86/MemcpyFast.cpp => AMD copyright/license.
+ debian-unstable-upstream => A debian folder. Remove to avoid confusion.
+ fps2bios => Missing copyright information. Possibly non-DFSG-free.
+ plugins/CDVDiso => Missing copyright information.
+ plugins/CDVDisoEFP => Missing copyright information.
+ plugins/CDVDlinuz => Missing copyright information.
+ plugins/CDVDolio => Missing copyright information.
+ plugins/CDVDpeops => Missing copyright information.
+ plugins/GSdx/baseclasses => Microsoft copyright/license.
+ plugins/GSdx/vtune => Intel copyright/license prohibits distribution.
+ plugins/LilyPad => Missing copyright information.
+ plugins/PeopsSPU2 => Missing copyright information.
+ plugins/SSSPSXPAD => Missing copyright information.
+ plugins/USBqemu => Missing copyright information and not distributable.
+ plugins/cdvdGigaherz => Missing copyright information.
+ plugins/xpad => Missing copyright information.
+ plugins/zerogs => Missing copyright information.
+ plugins/zerospu2 => Missing copyright information.
+ plugins/zzogl-pg/opengl/ZeroGSShaders/zlib => Available in Debian.
+ tools/GSDumpGUI => Missing copyright information.
+ tools/bin2cpp/bin2cpp.cpp => Missing copyright information.
+ win32/Win32/Windows/windows => Missing copyright information.
Everything else seems to have a valid license and I could not find a reason to
remove. "Missing" may imply 1 or many files since xpad had only like 2 files
while GSDumpGUI had a lot. USBqemu and other had files with license that
prohibit distribution so those where easier to remove.
I now have to fix the authors lines in the copyright files which I keep
postponing heh and will continue to do until I can't avoid it anymore. Sigh,
would be a lot easier if everything was with the same license. The copyright
file is kind of impressive right now heh.
Original comment by debian.m...@gmail.com
on 13 Apr 2012 at 3:11
I just finished completing and checking the copyright file.
Found one last issue:
These files were originally LGPL-2.1 (without +) therefore can only be made
LGPL-2.1, GPL-2, GPL-2+, GPL-3 or GPL-3+. Can't go LGPL-3+, LGPL-3 or LGPL-2.1+.
LGPL-3+ [Copyright: 2009 by Olli Parviainen] plugins/spu2-x/src/WavFile.cpp
LGPL-3+ [Copyright: 2009 by Olli Parviainen] plugins/spu2-x/src/WavFile.h
Only this, the 3 files with missing info (4 if counting repetitions) and to
know if the project is globally GPL-3 or GPL-3+ is left for the trivial
copyright stuff.
Original comment by debian.m...@gmail.com
on 13 Apr 2012 at 11:11
Well from soundtouch 1.6, so I see LGPL-2.1+ ?
//
// SoundTouch audio processing library
// Copyright (c) Olli Parviainen
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 2.1 of the License, or (at your option) any later version.
Otherwise, I suggest to drop pcsx2 0.9.8 and to fix svn first. It would reduce
a little the burden.
Original comment by gregory....@gmail.com
on 13 Apr 2012 at 3:49
Oh I specifically asked the soundtouch author since I help maintain the package
in Debian. By coincidence I asked and got a reply 5 days ago that is the only
reason I would know. The copyright laws also take into account the authors
intent so I'm not sure if just the fact that he copy/pasted the standard
message into the headers and forgot to remove the "(or at your option)" part
can be used as a loophole.
Yeah I never considered releasing 0.9.8 a viable option. Releasing a fixed
0.9.9 and waiting for the next stable release should be fine.
Original comment by debian.m...@gmail.com
on 13 Apr 2012 at 6:33
I add the necessary bit to build ps2hw.dat from cmake (actually
ps2hw_cmake.dat). I let you handle the proper file installation (the plugin
will open ps2hw.dat).
Original comment by gregory....@gmail.com
on 17 Apr 2012 at 5:11
Ok done it works with the new ps2hw file.
It would be nice if there was an option to only install the ps2hw_cmake.dat
file by either:
- Passing a -DVAR during configuration
OR
- Checking if the ZeroGSShaders directory is detected then do not install
ps2hw.dat and then just rename ps2hw_cmake.dat to ps2hw.dat instead of just
having these two lines as true:
install(FILES ${PROJECT_SOURCE_DIR}/plugins/zzogl-pg/opengl/ps2hw.dat
DESTINATION ${PLUGIN_DIR})
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/ps2hw_cmake.dat DESTINATION
${PLUGIN_DIR})
Only one of those files can be used after all. I just work around it by
patching the filename that the plugin reads and just installing ps2hw_cmake.dat
so it's more of a wishlist kind of thing.
Only issues left are:
* debian/copyright:
- Verify if whole project is GPL-3 or GPL-3+. http://code.google.com/p/pcsx2/
says Code license "GNU GPL v3" it's most likely GPL-3+ but I use GPL-3 to be safe.
- zzogl is GPL-2+ but links with non-free nvidia-cg-toolkit.
+ Add a project wide exception until it gets replaced?
- A COPYING.GPLv2, COPYING.GPLv3, COPYING.LGPLv2.1, and COPYING.LGPLv3 in text
form are most likely needed in the source root. Not sure if there is another
license used that requires the full original license in the source.
GPL-3: http://www.gnu.org/licenses/gpl-3.0.txt
LGPL-3: http://www.gnu.org/licenses/lgpl.txt
LGPL-2.1: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt
GPL-2: http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
trunk/build.sh: *No copyright* UNKNOWN
trunk/rebuild.sh: *No copyright* UNKNOWN
The rest of the issues are trivial on my side.
Original comment by debian.m...@gmail.com
on 18 Apr 2012 at 4:41
Yes it would be best to have a -DREBUILD_SHADER variable. And only install the
good dat file but that not critical for the moment.
When you said "Add a project wide exception until it gets replaced", you mean
all project or only zzogl ? For zzogl, you will need to contact Zeydlitz.
The 2 others files was developed by Arcum ;)
Original comment by gregory....@gmail.com
on 18 Apr 2012 at 10:23
Well as the GNU FAQ said: "It depends on how the program invokes its plug-ins."
Exception only needed to the plugin if this happened: "If the program uses fork
and exec to invoke plug-ins, then the plug-ins are separate programs, so the
license for the main program makes no requirements for them."
Exception to all the project (PITA) if this happens: "If the program
dynamically links plug-ins, and they make function calls to each other and
share data structures, we believe they form a single program, which must be
treated as an extension of both the main program and the plug-ins."
I asked earlier in Debian Games and they thought it was probably the whole
project. It just depends on how "independent" is zzogl. I'm not entirely which
of the two apply.
For reference, I only found 1 program in Debian licensed as GPL that depends on
Nvidia-cg-toolkit (http://packages.debian.org/source/sid/pycg).
The upstream author just added this to a README file and it was accepted into
Debian:
LICENSE
-------
Although a little confused with licensing for the software, I did
re-write most of it, yet a good portion of the media comes from
NVIDIA. So as per nvidia's request, this statement must be included:
* THE NVIDIA SOFTWARE IS BEING PROVIDED ON AN "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING
* WITHOUT LIMITATION, WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR ITS USE AND OPERATION
* EITHER ALONE OR IN COMBINATION WITH OTHER PRODUCTS.
*
*
*
* IN NO EVENT SHALL NVIDIA BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL,
* EXEMPLARY, CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, LOST
* PROFITS; PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) OR ARISING IN ANY WAY OUT OF THE USE,
* REPRODUCTION, MODIFICATION AND/OR DISTRIBUTION OF THE NVIDIA SOFTWARE,
* HOWEVER CAUSED AND WHETHER UNDER THEORY OF CONTRACT, TORT (INCLUDING
* NEGLIGENCE), STRICT LIABILITY OR OTHERWISE, EVEN IF NVIDIA HAS BEEN ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
From that, this software is licensed under the GPL version 2. See
LICENSE for more information. In addition, as a special exception, the
copyright holders of PyCg allows linking to NVIDIA's Cg.
Oh yeah I noticed that those file are arcum's but he did not put the copyright
header so I'm not sure if the usual LGPL-3+ PCSX2 dev Team applies.
Original comment by debian.m...@gmail.com
on 18 Apr 2012 at 10:41
Well, PCSX2 dynamically links plugins. And make functions call. However plugins
are independents. Only PCSX2 communicates directly with the plugins. Anyway I'm
afraid that the whole project is impacted.
Original comment by gregory....@gmail.com
on 18 Apr 2012 at 11:22
Well on the bright side at least there is only 2 things left and one is an easy
1 sentence answer.
* debian/copyright:
- Verify if whole project is GPL-3 or GPL-3+. http://code.google.com/p/pcsx2/
says Code license "GNU GPL v3" and the FAQ pdf says GPL-3. Confirm this is
correct:
Files: *
Copyright:
2002-2012 PCSX2 Dev Team
License: GPL-3
or if it should be:
License: GPL-3+
- zzogl is GPL-2+ but links with non-free nvidia-cg-toolkit. Seems like that
to the FSF all the plug-ins form 1 big program with the PCSX2 program due to
some technicalities. Permission from the copyright owners via a GPL exception
is needed for anyone other than the PCSX2 team to link against the
nvidia-cg-toolkit AND distribute the resulting "tainted" binaries. FSF goal
is a complete free system therefore they make it hard to use non-free stuff.
Well the zzogl thing will take a while since it's a pain and I'm not sure how
the PCSX2 team wants to go about it. Most possible solutions (exception,
replacement, etc) are fairly time consuming so I might as well just contact the
FSF to get a definitive answer of how an exception would work in this case and
to help you guys make an educated decision.
Original comment by debian.m...@gmail.com
on 18 Apr 2012 at 10:51
I will work toward the removal of cg. I will merge both GS branches. you will
get 3 plugins:
gsdx SW opengl: require an ogl3 gpu.
zzogl cg: the current plugin
zzogl : with a GLSL backend. Work only for AMD. the goal is to fix GL for
nvidia GPU.
The exception won't be possible if every coders of PCSX2/plugins need to be
contacted!
Original comment by gregory....@gmail.com
on 19 Apr 2012 at 7:36
Oh yeah I realize it won't be possible if every coder must be contacted
hopefully that is not the case.
Oh ok, "gsdx SW opengl" is basically the current gsdx plugin too?
Original comment by debian.m...@gmail.com
on 19 Apr 2012 at 7:43
Oh nvm I just remebered the gsdx-ogl branch.
Original comment by debian.m...@gmail.com
on 19 Apr 2012 at 7:54
Let me see if I get this before I try to make a list and some patches of the
current issues. Tell me if anything of this is wrong.
The desired behavior in general is:
- cmake should be able to compile the legacy zzogl-cg even if GLSL_API=true. (I
think currently it does not if GLSL_API=true, have not tried)
- The new zzogl with GLSL_API=false would try to make what basically is
zzogl-cg but with updated code. This one only works with AMD (not sure if only
the GLSL backend is affected or both are)?
- The new zzogl with GLSL_API=true would try to compile zzogl using the GLSL
backend. This one has confirmed issues with NVIDIA GPUs.
- Compiling both versions of the new zzogl at the same time (2 .so files: one
with GLSL and one with CG) is not possible and not desired.
I have been all day in windows and have not really tried the merged branch.
Original comment by debian.m...@gmail.com
on 20 Apr 2012 at 8:48
1/ Normally it must work. I change it in my latest commit. I'm just afraid of
conflict with ps2hw.dat (minus you're previous bug report)
2/ Yes. Actually only GLSL is limited to AMD GPU otherwise it must be ok. CG
must work nicely.
3/ Yes. Unfortunately it won't work on nvidia (black screen). The goal is to
fix it.
4/ The new zzogl can be either CG or GLSL not the 2 as the same times. You can
still build the new with GLSL and the old with CG. Or you can build it 2 times
and rename the so. Anyway I don't thinks it is useful. The emulation part of GS
and the GPU's submission command are quite separated.
Original comment by gregory....@gmail.com
on 20 Apr 2012 at 9:37
Here are some patches to fix the MSVS2010 windows build:
- 2010_zzogl-cg.patch: updates build system for zzogl-cg.
- 2010_new_zzogl.patch: updates build system for the new zzogl.
- fix_ZZGl_h_for_windows.patch: FTBFS due to 6 undefined declarations. Moved
only the 6 externs that declared the undefined above where they are first used
to fix this.
- fix-plugin-name-and-ini-name.patch: Update the displayed name of zzogl-cg and
use a different ini since they may not be compatible in the future.
Here are some patches to fix the MSVS2008 windows build:
- 2008_zzogl-cg.patch: updates build system for zzogl-cg.
- 2008_new_zzogl.patch: updates build system for the new zzogl.
- 2008_build1_old-problems.patch: fix old compilation problems and remove a
non-existant file.
- 2008_build2_no_immintrin.patch: Revert to using emmintrin.h for SSE2. Using
immintrin.h is overkill and only works with MSVS2010 (It may need SP1 too).
- Note: The zerogsogl_2008.sln (zzogl folder) and zerogsogl-cg_2008.sln
(zzogl-cg folder) files should probably be deleted and I did not update them.
They have not been updated in 2 years and the sln file at the root folder does
the same.
Since the patches are created with svn 1.7 and in windows they most likely need
to be applied with "patch -N -p0 --binary < $PATH_TO_PATCH" or something
similar due to the eol style. Debian based distros don't have svn 1.7.0+ which
I guess would make them apply cleanly with "svn patch $PATH_TO_PATCH". Applying
them in the order listed should work.
Tested in Debug and Release mode. The new zzogl library was left in CG mode for
compatibility with NVIDIA GPU.
Also I just confirmed that the two remaining symlinks are not needed in windows
and probably can get deleted. They become plain text files (at least in NTFS)
like:
- /trunk/pcsx2/3rdparty contains the string "link ../3rdparty/"
- /trunk/pcsx2/bin contains the string "link ../bin"
The only issue I found was:
- start a game with 0.3.0 or 0.4.0
- close the game but not the emulator
- switch to the other plugin 0.3->0.4 or 0.4->0.3
- Emulator complains that the window can't be opened. And the message about
incompatible HW is shown.
- Close emulator and reopen it.
- Everything works until I try to switch plugins again. Both plugins works if
they are started 1st.
I also have at least one for linux but I can't access it from Windows so I will
send it later.
Original comment by debian.m...@gmail.com
on 21 Apr 2012 at 2:25
Attachments:
Thanks you very much for your help. I will review the patch and integrate them.
Well the idea of the 2 plugins is to help the debug. In the end I would like to
drop zzogl 3.0 and keep only the version 4.0.
Original comment by gregory....@gmail.com
on 21 Apr 2012 at 3:32
Oh ok.
Here is the last patch for now.
Tested in MSVS2010, MSVS2008, Linux with internal SDL, Linux with external SDL
1.3 from experimental.
It basically strips the hardcoding of the 3rdparty folder and uses
vsprops/props files in windows. This makes it compile with an external SDL
1.3/2.0 if available in Linux.
It currently needs an include_directories(/usr/include/directfb) at least with
SDL-1.3 in Debian since the FindSDL.cmake does not currently looks for the
include paths of the dependencies of SDL.
Original comment by debian.m...@gmail.com
on 21 Apr 2012 at 4:01
Attachments:
I commit your previous patches (I will look later at the latest patch). However
the dependency of SDL will be dropped in a couple of weeks. Actually when I
find some time to merge my OGL branches.
For your information, I slightly modify your patch.
1/I move SSE header inside Util.h so it would be easier to change it in the
future.
2/I move all GL define at the top.
Original comment by gregory....@gmail.com
on 21 Apr 2012 at 4:21
Oh ok.
Also I just noticed that the patch did not delete just made these files 0bytes:
Modify /trunk/plugins/zzogl-pg-cg/opengl/Win32/zerogsogl.vcxproj
Modify /trunk/plugins/zzogl-pg-cg/opengl/Win32/zerogsogl.vcxproj.filters
Modify /trunk/plugins/zzogl-pg-cg/opengl/Win32/zerogsogl_2008.sln
Modify /trunk/plugins/zzogl-pg-cg/opengl/Win32/zerogsogl_2008.vcproj
These one got renamed since they could not have the the same name as other
files even if they are in different directories. Visual Studio throws a tantrum
otherwise.
Original comment by debian.m...@gmail.com
on 21 Apr 2012 at 4:42
Oh I just received an email from the soundtouch author. He is going to update
the documentation to say the license is LGPL-2.1+ to match the headers. Well I
guess it could have stayed LGPL-3+ if I did not mention it and waited.
Original comment by debian.m...@gmail.com
on 21 Apr 2012 at 5:30
Oh I received a reply from the FSF and I just asked them back for confirmation
just to be sure.
The short version is that everyone already gave their consent to link with the
nvidia-cg-toolkit except the authors in the GPL-2+ files.
Basically those files are in
tools/dynacrchack/: Avi Halachmi
plugins/zzogl-pg/: GSsoft Team, Zeydlitz, zerofrog, Gabest, Gregory
Hainaut,arcum42
plugins/spu2-x/: zerofrog, gigaherz
plugins/spu2-x/src/iconvert.cpp: 2001 Edmund Grimley Evans <edmundo@rano.org>
plugins/SPU2null/*: 2002-2010 SPU2null Team
plugins/onepad/*: arcum42, zerofrog
plugins/GSnull/Registers.h: Gabest, PCSX2 Dev Team, Terratron Technologies Inc.
plugins/GSdx/: GSsoft Team, Gabest,
plugins/GSdx/GS.h: Gabest, Terratron Technologies Inc.
pcsx2/IPU/mpeg2lib/*: Michel Lespinasse, Aaron Holtzman
and a few files with "2002-2012 PCSX2 Dev Team" which only need approval by the
team leader or whoever represents the DEV team.
Most of the names are repetitions of the same people only one that could cause
issues are:
plugins/spu2-x/src/iconvert.cpp
pcsx2/IPU/mpeg2lib/*
The two files with Terratron Technologies Inc but those files originally where
not GPL-2+ and I'm not sure derivative work base on it's distributable to begin
with based on the original license but that is another issue.
Anyway the files that are COMPILED AND ARE GPL-2+ are the only ones that need
to be either removed, changed to LGPL-3+ or add an exception if zzogl-cg is to
be distributed.
Not sure about the sps2dev files from Terratron those could cause issue
regardless of nvidia-cg-toolkit situation.
Original comment by debian.m...@gmail.com
on 25 Apr 2012 at 9:29
Also could the 0001-portable-GSdx.patch be applied even if GSdx-ogl will be
merged in the future? It's more sane and every other header from the 3rdparty
folder has their path in the props file except those 3 hardcoded paths which
only 1 is used in windows and 3 in linux.
Original comment by debian.m...@gmail.com
on 25 Apr 2012 at 9:46
Hum seem fair. If I don't have time this weekend to merge my branch (and remove
SDL) I will apply it.
Original comment by gregory....@gmail.com
on 27 Apr 2012 at 8:33
Oh I see now I thought gsdx-ogl was going to be a different plugin in it's own
directory like zzogl/zzogl-cg.
Here are some patches this time for Linux (I lost the 1st message by hitting F5
so I will just copy/paste the headers):
1) 0000_REBUILD_SHADER.patch
For zzogl-pg:
- Only build shader if REBUILD_SHADER=TRUE and GLSL_API=FALSE
- Only install the precompiled ps2hw.dat if REBUILD_SHADER=FALSE
- If REBUILD_SHADER=TRUE install ps2hw_cmake.dat as ps2hw.dat since that is the
filename ZZoglCreate.cpp expects.
For zzogl-pg-cg:
- Only build shader if REBUILD_SHADER=TRUE
- Fix the paths from "plugins/zzogl-pg" to "plugins/zzogl-pg-cg". Next patch
fixes the one I missed here.
- If REBUILD_SHADER=FALSE install ps2hw.dat as ps2hw-cg.dat to avoid collision.
- Change all the instances of ps2hw.dat to ps2hw-cg.dat in ZZoglCreate.cpp.
- If REBUILD_SHADER=TRUE install ps2hw_cmake.dat as ps2hw-cg.dat since that is
the filename ZZoglCreate.cpp expects.
In BuildParameters.cmake:
- Use the precompiled shader file by default to keep the current behavior.
2) 0001_fix_remaining_paths.patch
Fix the paths from "plugins/zzogl-pg" to "plugins/zzogl-pg-cg".
Missed these three in the previous patch.
3) 0002_BUILD_REPLAYERS.patch
Add -DBUILD_REPLAY_LOADERS=TRUE|FALSE and set the default to TRUE.
.
This is only useful in debug/devel builds and probably the default should even
be false. Since the current behavior is to install them I set the default as
TRUE but I really wanted to set is as false.
4) 0003_DO_NOT_INSTALL_SHADER_BUILDER.patch
Internal program and not needed by the user.
Enough stuff gets installed already.
5) 0004_MINOR_GSDX.patch
"pcsx2 SDL" is not needed anymore in a default compilation.
I tested each patch in Linux and verified the sha1sum of the shaders file to
confirm that everything worked as expected with the different -DVAR set.
On a random note I can't get the gsdx plugin to run on Debian or Ubuntu
Precise. I always get an assertion.
Ubuntu:
/tmp/buildd/pcsx2-0.9.9~svn5187+dfsg/common/src/Utilities/Linux/LnxHostSys.cpp(6
4) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: MTGS
Condition: false
Message: Unhandled page fault @ 0x00000008
[00] GSDeviceOGL::IASetVertexState(GSVertexBufferStateOGL*)
[01] GSRendererOGL::SetupIA()
[02] GSRendererOGL::DrawPrims(GSTexture*, GSTexture*, GSTextureCache::Source*)
[03] GSRendererHW::Draw()
[04] GSState::FlushPrim()
[05] void GSState::GIFRegHandlerTEST<0>(GIFReg const*)
[06] void GSState::Transfer<3>(unsigned char const*, unsigned int)
[07] GSgifTransfer
Trace/breakpoint trap (core dumped)
Debian:
/tmp/buildd/pcsx2-0.9.9~svn5187+dfsg/common/src/Utilities/Linux/LnxHostSys.cpp(6
4) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: MTGS
Condition: false
Message: Unhandled page fault @ 0x00000000
Stacktrace:
[00] GSDeviceOGL::IAMapVertexBuffer(void**, unsigned int, unsigned int)
[01] GSRendererOGL::SetupIA()
[02] GSRendererOGL::DrawPrims(GSTexture*, GSTexture*, GSTextureCache::Source*)
[03] GSRendererHW::Draw()
[04] GSState::FlushPrim()
[05] void GSState::GIFRegHandlerTEST<0>(GIFReg const*)
[06] void GSState::Transfer<3>(unsigned char const*, unsigned int)
[07] GSgifTransfer
For Reference in Debian I tried with catalyst 12.4 and my card is a mobility
HD4650 with Dx 10.1, etc. If GSdx is broken like zzogl-GLSL forget the last
part but not the patches heh.
Original comment by debian.m...@gmail.com
on 30 Apr 2012 at 2:08
Attachments:
Thanks I will look at your patch. They seem good :) However I want to keep the
same shader ps2hw.dat for both zz plugins. The more difference between the
plugins the more difficult to find a regression with the version 0.4.
Is was on GSdx HW? Code is a bit buggy on AMD but this segmentation fault is
not normal. Could you try to attach a debugger and give me more inner details.
I will write a gdb mini-doc later anyway ;)
Do you feel Ok it I take some idea/improvement from your ppa package? What is
the best way to give you some credit? Copyright, Maintainer field?
Note: I'm still trying to find the good license :p
Original comment by gregory....@gmail.com
on 30 Apr 2012 at 7:01
Oh ok, I just renamed the ps2hw.dat to ps2hw-cg.dat in case that you changed
the rebuilt shader code in the new zzogl-pg so that it could be compared with
the old version since currently old shaders overwrite the new ones. If you
really want to use the same shader for both then I guess you would only update
the code in the new zzogl-pg. The problem I noticed was that currently the
shaders from zzogl-pg-cg get installed last and overwrite the ones from
zzogl-pg so any new changes would get lost unless the files are renamed or the
order is swapped so zzogl-pg-cg is compiled/installed 1st and the new ones
overwrites those. It would not matter if you are sure that you will never
change the shaders or the code to compile the shaders but that is hard to tell.
If they are not renamed at the very least I would change the order of them so
that you always get the shaders from the new zzogl-pg instead of legacy
zzogl-pg-cg. The 1st patch also updates the paths for zzogl-pg-cg since it
would have undesired behavior if the zzogl-pg folder did not exist.
Oh nevermind the GSdx thing, I was half asleep last night and did not check the
settings. It was on SDL software (deprecated) and I thought it defaulted to
OpenGL SW or at least that the SDL option was not there if it was not compiled
with SDL. Anyway the 1st time I packaged the new GSdx I forgot to copy the
*.glsl file and the plugin does not complain like zzogl (with ps2hw.dat) if
they are not found it just shows a white screen and works as if it was GSnull
heh. Fairly minor issue looking at the big picture.
Oh it's fine the original idea of the ppa was just to backup some packages that
I locally compile and let you know about improvements to the debian folder but
people started using it so I tried to be nice and maintain it a little. On
second thought, I should have just put it on github or something since I
already have it on git. Anyway I have 3 branches the lucid-oneiric (not
multi-arch), precise branch (transitional multiarch to preserve upgrade path),
and the Debian/Quantal which is full multiarch without the transitional
packages. The last one is not on the ppa and it's probably the best since it
the only one that takes into account the new gsdx/zzogl-pg/zzogl-pg-cg.
Since you mentioned license it reminded me of one question. Should I just drop
the nvidia-cg-toolkit dependency and move the package from contrib->main or is
the last license issue a work in progress? Not sure how feasible is to
workaround only the GPL-2+ files but at least it's less than ALL the authors
:P. I just ask to see if there was a slim chance of it making it into Wheezy
before the Debian freeze since it needs at least one stable video plugin that
works with nvidia/amd/intel.
Original comment by debian.m...@gmail.com
on 30 Apr 2012 at 3:20
I don't think anybody will update the shaders for the moment. Anyway, I will
use the shader of zzogl in zzogl-cg (ie zzogl-cg will depends on zzogl). Well I
will see that not critical for the moment.
Ok for GSdx it is on my TODO list.
My suggestion, drop CG and both zzogl for the moment. Just puts somewhere that
you can download extra plugins from us. I'm working to fix GLSL[0], then you
will be able to also add zzogl inside debian too.
[0] Strangely it won't work anymore on my AMD system. Actually I found it
strange that it worked on the past because I fixed a critical errors on the
shader compilation. Fortunately I will be able to debug it on my AMD system and
maybe it would work on Nvidia too.
Original comment by gregory....@gmail.com
on 30 Apr 2012 at 3:50
If you want I can update the 1st patch with the behavior that you desire so you
can focus on other stuff.
Also there is a FTBFS if I drop the nvidia-cg-toolkit dependency AND use
"-DGLSL_API=TRUE", since it still tries to use the nvidia stuff and compile
zzogl-pg-cg. I went to sleep and left the patch halfway done. I can submit in a
couple of hours when it's done if you want.
Oh ok, since the freeze last for a fairly long time I guess after it the
plugins should be in better shape :). It could get uploaded to experimental
later too.
Original comment by debian.m...@gmail.com
on 30 Apr 2012 at 4:18
Ok. Yes your patch is welcome. The idea is
1/ completely drop ps2hw.dat from zzogl-pg-cg
2/ And only build zzogl-pg-cg when zzogl-pg is built (with CG).
Note for the FTBFS on debian, remove zzogl-pg-cg
Original comment by gregory....@gmail.com
on 30 Apr 2012 at 4:27
Oh the thing is I really can't delete upstream stuff in the get-orig-source
routine unless it's 3rdparty files or Invalid licenses. I could do it in the
PPA but not in a Debian release since I have to stay as close as the original
as possible. Therefore I was making a patch so it just won't compile if it was
not found.
The idea is that if the user want to recompile the source with less or more
features they can do it. In this case they can always install nvidia-cg-toolkit
later and just compile it one their own and it's still legal.
Ok I will update the patches with those 2 points in mind.
Original comment by debian.m...@gmail.com
on 30 Apr 2012 at 4:41
Ok here are the updated patches. The explanation is in the header of the
patches so I will not paste that here.
Test Done (with REBUILD_SHADER=TRUE and BUILD_REPLAY_LOADERS=FALSE):
CG_FOUND=TRUE AND GLSL_API=TRUE => Only compiles libzzogl-0.4.0.so and
installs ps2hw.glsl.
CG_FOUND=TRUE AND GLSL_API=FALSE => Both compile and only the rebuilt
ps2hw.dat from zzogl-pg is installed.
CG_FOUND=FALSE AND GLSL_API=TRUE => Only compiles libzzogl-0.4.0.so and
installs ps2hw.glsl. Message about no CG for ZeroGS.
CG_FOUND=FALSE AND GLSL_API=FALSE => Both do not compile. ZeroGS and ZZogl
complain about missing CG. Everything else compiles.
I tested REBUILD_SHADER and BUILD_REPLAY_LOADERS individually before but I did
this extra test to ensure I did not break it.
Test Done (with REBUILD_SHADER=FALSE and BUILD_REPLAY_LOADERS=TRUE):
Got the same results but the Replay loaders are built and the precompiled
shader is used when CG_FOUND=TRUE and GLSL_API=FALSE.
I think this covers the points from before. Also the FTBFS was caused by a typo
"GLSP_API" which it took me a fair amount of time to see since it was easy to
miss. I fixed the 5 appearances of it in the 1st patch.
Original comment by debian.m...@gmail.com
on 30 Apr 2012 at 10:18
Attachments:
Good jobs.
Original comment by gregory....@gmail.com
on 1 May 2012 at 10:55
Oh thanks. I'm almost running out of patches now :) only 2 left.
Here is one that fixes issue 1233. As usual patch header has a rather verbose
explanation.
The idea was to not touch the code and get the same behavior as without the
patch but with the bug fixed. Since the change is at the preprocessor level it
should accomplish this.
As usual there are other ways that this could be solved but this is a fairly
simple and conservative way of doing it.
Original comment by debian.m...@gmail.com
on 1 May 2012 at 8:18
Attachments:
Ok here are the other patches that I had.
- The 0000 series removes the hacks for multiarch in Debian-based distributions.
At the very least applying 0000a would be nice because it would help the
porters of hurd and kfreebsd. The file FindGTK2_pcsx2.cmake is
not needed anymore and does not help these ports.
- The 0001 patch removes duplicates messages and the missing dependency messages
when the directory does not exist.
- The 0002 patch adds a -DGLSL_SHADER_DIR and -DCG_SHADER_DIR so they can be
moved independently from the -DPLUGIN_DIR.
After these and the stringify.patch I don't have more patches unless there is
interest for the hurd-i386 and kfreebsd-i386 portability patches. It compiled on
kfreebsd but I did not test it in hurd. It should also compile on MacOS but I
don't have a MacOS PC, a Hackintosh or like apple stuff heh.
Original comment by debian.m...@gmail.com
on 5 May 2012 at 8:31
Attachments:
0001_stringify_macros.patch would be better in the good bug report ;) Anyway
that a clever trick.
I didn't apply 000c because I want to test carefully cross compilation on amd64
first. It doesn't hurt for the moment.
I keep PLUGIN_DIR for CG to avoid multiplication of build option. CG will be
removed in the future anyway, it won't never be in debian/multiarch. I'm not
sure source can be provided. CG code path is not so complex so I will be able
to port it to glsl, I need to improve Apitrace in parallel too.
For PCSX2 license, we will go to GPLv3+. Docs need to be updated accordingly.
Original comment by gregory....@gmail.com
on 7 May 2012 at 6:10
Oh ok sure I will put it in the other one.
Why not use GLSL_SHADER_DIR for ps2hw.glsl too? Not sure if the omission was
intentional or if it was dropped by mistake when deleting the CG_SHADER_DIR
part.
Original comment by debian.m...@gmail.com
on 7 May 2012 at 7:05
no that normal. I need to commit a big chunk of zzogl change ;) It was too
difficult to seperate the 2 but I would like to review my change a bit more.
Original comment by gregory....@gmail.com
on 7 May 2012 at 7:09
Oh ok sure. I will bug you later about it if I don't see it after you commit a
lot of zzogl changes. :P
Just a quick question. Since AMD basically killed support for R600/R700 graphic
cards in their 12-5 catalyst driver I switched to the open source driver in
Debian and moved to Precise as my main Linux Desktop since they ship 12-4. I
took this opportunity to try and write a small readme for Debian with the
requirements of each one (even the CG one although it won't be shipped but they
can compile it if they want).
I noticed:
- zzogl-cg and the new zzogl with CG API works with the open source "radeon"
driver and mesa 8.0.2 so I would assume the requirement for that is OGL 2.1 if
any.
- GsDX works with an OGL 3.3 card and a catalyst driver reporting support for
OpenGL 3.3.11627. It gets a message saying "GL_ARB_shading_language_420pack is
not supported" but I don't see any ill effects. It fails as expected with the
"radeon" driver.
- GLSL zzogl shows a black screen and works as GSnull with catalyst so when it
get fixed it should work. In radeon/mesa it fails badly heh.
The question which took a long time to ask is based on:
http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
at what level would the GLSL/GSdx would work assuming that the plug-ins worked
already. I remember you mentioned OGL 4.2 drivers for GSdx which sounds awfully
high since my catalyst driver reports only 3.3 and it seemed to work. I have
not looked at all the GL code but I remember glGetStringi and I remember
something about profiles so I was not sure if it was OGL 3.0/GLSL 1.3 or OGL
3.2/GLSL 1.5 that is needed.
I just wanted to put something like "when the GL3.txt file reaches OGL XXX,
GLSL XXX or reaches feature XXX this plugin should work" for each of the
plug-ins. Better than getting 1000 bugs saying it does not work with XXX driver.
Original comment by debian.m...@gmail.com
on 7 May 2012 at 7:49
Well it is a bit more complicated.
For zzogl cg, we need 2.1 + some GL3 extensions. But nvidia uses special
extensions to be more efficient, I don't know the exact requirement. Honestly
going to real GL3 will probably help a lots. And the only OGL2.1 card supported
are geforce6 and geforce7. Nvidia will drop them one day. Note I don't count
Intel...
For GSdx ogl, we need OGL3.3 (again 3.0 + extensions but 3.3 is better and
nearly supported by opensource driver) + two OGL4
extensions:GL_ARB_separate_shader_objects and GL_ARB_shading_language_420pack.
Note that 2 others extensions would be useful GL_ARB_map_buffer_alignment
(because I want the guarantee that code is properly aligned for sse2 operation)
and GL_ARB_texture_storage (but was buggier last time on my AMD GPU...). For
information
For GLSL zzogl, the first target is the same as GSdx. First goal is to make it
works
Original comment by gregory....@gmail.com
on 7 May 2012 at 8:02
Mesa 8.1 is due in August and should have OGL 3.0
Jan/2003 is the target for OGL 3.1 in mesa 8.2.
Hopefully they can solve the patent issue with ARB_texture_float since SGI owns
and enforces that patent and there will not be full OpenGL 3.0+ compliance
without it.
Mmmm 1 OGL4.1 and 3 OGL4.2 extensions. Oh well at least glxinfo reports that I
have them with catalyst in my OGL 3.3 card. Even if GSdx says
"GL_ARB_shading_language_420pack is not supported". Hopefully after mesa has
them the drivers actually implement them since MESA is almost done but the
drivers are lagging a bit.
Anyway thanks for the info. I will try to make a list later of the things
missing for Debian. From the top of my head the only important thing missing is
to check the 2 files from sps2dev (Terratron) since the custom license they use
basically says can't modify or distribute the content and I'm no sure how it
applies in this case (it was hard to find the original source tarball). The
rest is for you to work your magic and stabilize the 2 video plug-ins. When you
are "happy" with them just tell me and I will just finish the little that is
left of the packaging (just the copyright file is left but I hate copyright
files when there are so many different licenses)and poke the Debian Games
people.
Original comment by debian.m...@gmail.com
on 7 May 2012 at 8:42
Original issue reported on code.google.com by
debian.m...@gmail.com
on 11 Apr 2012 at 9:17Attachments: