search

cai567890 / pcsx2

Automatically exported from code.google.com/p/pcsx2
1 stars 0 forks source link

General copyright Issues and those related to Debian. #1257

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hello:

I was going to submit a minor patch to fix some typos on the copyright headers 
so I might as well make the summary/subject generic and move the copyright talk 
here.

The patch fixes minor typos like "te" -> "the", "the the" -> "the", "20011" -> 
"2011", and 3 issues in plugins/zzogl-pg/opengl/common.h (copyright line order, 
"ffmepeg" -> "ffmpeg", and GPL-2.1 issue).

This make parsing program detect the license correctly and easier to make a 
script to parse the output and generate the copyright information.

Information already mentioned in r5152

* debian/copyright:
  - Run "licensecheck --recursive --copyright *" and check that the copyright
    file is complete. Submit patch that is already done to fix various headers
    with typos that make licensecheck give wrong info.
  - Verify if whole project is GPL-3 or 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.
  - pcsx2.man is GFDL. Not sure if DFSG.
    http://wiki.debian.org/DFSGLicenses#GNU_Free_Documentation_License_.28GFDL.29
    Safer to GPL-2/GPL-2+/GPL-3/GPL-3+ or just do like most other man pages.

Files that need headers or be removed when making source DFSG (9 files):

linux_various/detect_missing_file_in_cmake.sh: *No copyright* UNKNOWN
pcsx2/MTVU.h: *No copyright* UNKNOWN
pcsx2/gui/Resources/rebuild.sh: *No copyright* UNKNOWN
plugins/GSdx/config.h: *No copyright* UNKNOWN
plugins/zzogl-pg/opengl/ZZHacks.h: *No copyright* UNKNOWN
plugins/zzogl-pg/opengl/shaders.sh: *No copyright* UNKNOWN
plugins/spu2-x/src/DplIIdecoder.cpp: *No copyright* UNKNOWN
tools/bin2app.sh: *No copyright* UNKNOWN
tools/bin2cpp/bin2cpp.cpp: *No copyright* UNKNOWN

Missing Headers (files are 2 years old there are new versions out too)(4 files):

Files: 
 plugins/GSdx/xbyak/*
Copyright: 2007-2012 MITSUNARI Shigeo <herumi@nifty.com>
License: BSD-3-Clause
    plugins/GSdx/xbyak/xbyak_mnemonic.h: *No copyright* UNKNOWN
    plugins/GSdx/xbyak/xbyak_bin2hex.h: *No copyright* UNKNOWN
    plugins/GSdx/xbyak/xbyak_util.h: *No copyright* UNKNOWN
    plugins/GSdx/xbyak/xbyak.h: *No copyright* UNKNOWN

There are some files like  those in Gsdx/zzogl that have individuals and not 
the team "PCSX2 Dev Team" so I have to put those individually and that is a 
work in progress.

Finally there are various files with LGPL-2.1+/GPL-2+/LGPL-3+/etc but only the 
full license of the GPL-3 is included with the source. I would think that the 
source has also to distribute the full thing for each of the other ones used in 
individual files (well the ones that requires this).

Original issue reported on code.google.com by debian.m...@gmail.com on 11 Apr 2012 at 9:17

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago

Original comment by gregory....@gmail.com on 12 Apr 2012 at 6:02

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
Oh nvm I just remebered  the gsdx-ogl branch.

Original comment by debian.m...@gmail.com on 19 Apr 2012 at 7:54

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
Good jobs.

Original comment by gregory....@gmail.com on 1 May 2012 at 10:55

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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