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.wine...@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