Bug#898810: wine: revert_opengl46.patch applied to wine why no upstream bug.
Since I do support with wine I went and questioned on the IRC channel
with wine graphics developer I know.
>From everything they looked at the change should be fairly neutral as
those ID numbers behind those values should be the same. That why
they are not interested in fixing it at this time. Key words "at this
time". Does not mean they will not change it with a future commit if
this causes issue on android or other platform builds.
I had forgot when somethings move from EXT to ARB in opengl that they
keep the same ID values just end up with double entry in headers.
I was correct that it looks suspect most code I do that just uses the
opengl header files not using the xml file to generate own so able to
play with the rules. Basically a patch like in almost any other
program that is not wine would have been a defect. It was correct
for me to sense trouble just wine happens to be exception to rule in
this case.
So correct is update khronos-api in debian. Also wine project are
not going to take a patch for something caused by not using the latest
khronos files this is why wine source was set up to get them directly
to make the opengl files wine needs.
Having old versions of khronos xml files is likely to cause other
problems in future with wine builds. This does bring up the horrible
question if part of wine packaging if the khronos files should be
packaged as like wine arch neutral deb due to with wine likely that
these will need to be out of sync with the complete system every so
often due to wine implementing support ahead of graphical stack.
On Sat, May 19, 2018 at 7:27 AM, Jens Reyer <jre.winesim@gmail.com> wrote:
> control: block 898810 by 869233
>
>
> On 16.05.2018 02:40, oiaohm wrote:
>> I was looking over patches that are being added to wine.
>
> Again, thanks for doing that.
>
>
>> I stumbled on the
>> https://sources.debian.org/patches/wine/3.0-1/revert_opengl46.patch/ and when I
>> look at it is in the fact of not right.
>>
>> Is this caused because you are not using the current khronos files
>> https://raw.github.com/KhronosGroup/OpenGL-Registry/master/xml/gl.xml
>> https://raw.github.com/KhronosGroup/OpenGL-Registry/master/xml/wgl.xml
>
> Yes, we need a newer version of the package khronos-api in Debian. I
> set the related bug as blocking bug.
>
>
>> There is a possiblity that the opengl46 patch is wrong to start off with.
>> {"GL_EXT_texture_filter_anisotropic", ARB_TEXTURE_FILTER_ANISOTROPIC}
>> This line in the patch makes me smell a possible issue that someone might have
>> done a straight find and replace incorrectly. If that is the case
>> EXT_TEXTURE_FILTER_ANISOTROPIC and ARB_TEXTURE_FILTER_ANISOTROPIC handling
>> need to be implemented next to each other. As in try
>> ARB_TEXTURE_FILTER_ANISOTROPIC if that don't exist try
>> EXT_TEXTURE_FILTER_ANISOTROPIC and after that fail. If this is the case there
>> need to be a wine bug opened and a patch submitted upstream.
>>
>> Please note I do serousally think this is a bug in wine source code. From the
>> gl.xml file from kronous
>> extension name="GL_ARB_texture_filter_anisotropic" supported="gl|glcore"
>> extension name="GL_EXT_texture_filter_anisotropic" supported="gl|gles1|gles2"
>>
>> Note the supported. Running on android with glex1 or gles2 not seeing
>> ARB_TEXTURE_FILTER_ANISOTROPIC and only seeing EXT_TEXTURE_FILTER_ANISOTROPIC
>> would be normal. Please remember wine is adding android support so has to
>> support gles1 and gles2 as you even get new android devices today missing
>> Opengl ES 3.0
>>
>> If what I suspect is the case and not caused somehow by what you have done with
>> the khronos files please open upstream bug report in wine.
>
> I created the opengl46 patch simply by reverting the related upstream
> commits. You might be right with your suspicion, but I currently don't
> have enough time to really look into it, and argue the case or propose a
> fix to upstream. If you're sure with your theoretical analysis please
> submit a bug at http://bugs.winehq.org/ and then tell us here about it.
>
> Personally I'm more interested in getting khronos-api in Debian updated,
> and thus getting rid of this patch here.
>
> Greets
> jre
Reply to: