Fix for Wayland

[matterhorn103]

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

[matterhorn103]

See this issue at the GLEW repo.

Fixes #567.

As discussed on the forum, the current proposal is that this be a temporary fix for 1.99 and that for 2.0 Avogadro moves away to another bindings library.

Note that my commit message is wrong, GLEW needs to be from 2022 or newer in order to have glewContextInit defined. Presumably using the current state of the GitHub master branch would do the trick; I used the "recent snapshot" (Apr 2022) found in the repo's readme which is here and works.

The URL in cmake/projects.cmake needs to be changed appropriately in order for it to compile correctly, and obviously use of system GLEW needs to be disabled.

It seems GLEW is a while away from any 2.2.1 release still, so I guess that means not only compiling the AppImage and flatpak with the snapshot, but also packaging our own GLEW for 1.99, unless distros have backported the fixes since the 2.2.0 release.

[ghutchis]

I mentioned on the forum, but is there something in the snapshot header that indicates that glewContextInit() is available?

[ghutchis]

Okay, here's what I think we need to do - create a #define GLEW_CONTEXT_INIT using cmake. That is, we try to compile a small test program with the new glewContextInit() call. If it works, then cmake will create the #define.

For example:
https://stackoverflow.com/a/25732622/131896

[matterhorn103]

I mentioned on the forum, but is there something in the snapshot header that indicates that glewContextInit() is available?

Well it builds correctly without complaining, whereas when I use the 2.2.0 release it tells me that glewContextInit() is undefined within this scope at compile time.

src/glew.c contains:

GLenum GLEWAPIENTRY glewContextInit (void)
{
  PFNGLGETSTRINGPROC getString;
  const GLubyte* s;
  GLuint dot;
  GLint major, minor;
...

And there are other entries in the code, for example the above is also in auto/src/glew_init_gl.c and the following can be found in both auto/src/glew_tail.h and include/GL/glew.h:

/* API */
GLEWAPI GLenum GLEWAPIENTRY glewInit (void);
GLEWAPI GLenum GLEWAPIENTRY glewContextInit (void);
GLEWAPI GLboolean GLEWAPIENTRY glewIsSupported (const char *name);

[matterhorn103]

Okay, here's what I think we need to do - create a #define GLEW_CONTEXT_INIT using cmake. That is, we try to compile a small test program with the new glewContextInit() call. If it works, then cmake will create the #define.

For example: https://stackoverflow.com/a/25732622/131896

I'm not sure I quite follow. Is your suggestion that glewInit() continues to be used normally and glewContextInit() is only used if its availability is detected? And only use it on Linux?

Is it a bad idea to just use the snapshot and glewContextInit() for building on all platforms then?

[ghutchis]

Consider a package maintainer. GLEW is at 2.2.0 release, which does not have this function. They want to compile avogadro2 packages against released packages. If we switch to glewContextInit() completely, they don't have many options.

Unfortunately, GLEW doesn't provide its own #define to indicate the method is present. Worse, both the release and the snapshot declare they are version 2.2.0.

If we have a cmake test to see if glewContextInit() compiles, and create our own #define we can do something like:

#ifdef GLEW_HAS_CONTEXT_INIT
   glewContextInit(…)
#else
   glewInit(…)
#endif

[ghutchis]

What GLEW did is really annoying:

• new method rather than fixing glewInit()
• no release yet, only a snapshot
• no #define in the snapshot to indicate the new method is present

So for now, we'll need to do a workaround until we can remove GLEW for good.

[matterhorn103]

Ok I had another look at projects that had linked to the GLEW issue to see how they had handled maintenance, and I discovered that actually it does work on Wayland (at least in many cases), it's just that an error gets raised on initiation, but if this is error is caught and ignored then it's not an issue.

This means there's actually a different, simpler fix possible: if the fact that on Wayland the result of glewInit() is GLEW_ERROR_NO_GLX_DISPLAY is accounted for then the rendering seems to work fine. I've changed the code to do exactly this.

Happily this works even with the released 2.2.0, which means no need for the snapshot, no need for glewContextInit(), no need to avoid system GLEW.

[github-actions]

Here are the build results
macOS.dmg
Avogadro2.AppImage
Win64.exe
Artifacts will only be retained for 90 days.

[github-actions]

Here are the build results
Avogadro2.AppImage
macOS.dmg
Win64.exe
Artifacts will only be retained for 90 days.