Xpra: Ticket #565: opengl errors after upgrade to trusty and xpra 0.12.5

Hi, after upgrading my ubuntu machines (client and server to trusty) and after upgrading xpra too from 0.12.4 to 0.12.5, I am getting the following

2014-05-04 11:32:30,985 do_paint_rgb32 error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/client/window_backing_base.py", line 235, in do_paint_rgb32
    success = self._do_paint_rgb32(img_data, x, y, width, height, rowstride, options, callbacks)
  File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_window_backing.py", line 427, in _do_paint_rgb32
    return self._do_paint_rgb(32, img_data, x, y, width, height, rowstride, options, callbacks)
  File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_window_backing.py", line 492, in _do_paint_rgb
    self.present_fbo(drawable)
  File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_window_backing.py", line 376, in present_fbo
    glEnablei(GL_BLEND, self.textures[TEX_FBO])
  File "/usr/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", line 384, in __call__
    self.__name__, self.__name__,
NullFunctionError: Attempt to call an undefined function glEnablei, check for bool(glEnablei) before calling
2014-05-04 11:32:35,043 do_paint_rgb32 error

with this xpra does not paint its windows. Disabling opengl in the client makes xpra work.

The setup is as follows. opengl appears to be only available in the client (the server uses xdummy, but has nvidia graphics with the legacy driver and I haven't succeeded in getting opengl working with xdummy here).



Sun, 04 May 2014 09:42:25 GMT - Antoine Martin: owner, description changed

That's very strange as there was not a single update to the client code, let alone the opengl code.

Are you sure that there weren't other system updates from Ubuntu or nvidia? It looks to me like OpenGL is not working on your setup. glEnablei should always be available.


Sun, 04 May 2014 09:48:47 GMT - Antoine Martin:

Can you try running the client with:

XPRA_ALPHA=0 xpra attach ...

Does it help?


Sun, 04 May 2014 10:00:30 GMT - Antoine Martin:

Please also post the output of xpra/client/gl/gl_check.py


Sun, 04 May 2014 14:07:13 GMT - Antoine Martin:

r6343 disables alpha when glEnablei is missing. I still don't understand why it would go missing, but this should workaround it.

Please let me know if that helps and I'll backport it.


Sun, 04 May 2014 14:52:27 GMT - Antoine Martin: owner changed

afarr / smo: do you guys have trusty installed with opengl drivers somewhere? callegar: please let us know your graphics card and drivers.


Sun, 04 May 2014 20:58:24 GMT - callegar:

Hi, unfortunately I will not be on that trusty machine for some days. As soon as I'm on it I'll make the test.

In the meantime, some answers.

Are you sure that there weren't other system updates from Ubuntu or nvidia?

Yes, they were, tons of them, since I moved from ubuntu saucy to trusty and at the same time I upgraded xpra.

glxinfo and glxgears appeared to work on the machine. So KDE effects. So opengl seemed fine.

The xpra info windows, finds the python opengl module and can correctly identify the opengl version (2.1, if I remember correctly).

The machine has an integrated NVIDIA Geoforce 7025 chipset and is using the proprietary NVIDIA driver.

From memory this is the best that I can do.


Mon, 05 May 2014 06:03:33 GMT - Antoine Martin: owner changed

From memory this is the best that I can do.


Thanks, let's wait for the rest of the info. I think r6343 is the right fix for this, I just want to understand why glEnablei is missing before I apply it.


Fri, 09 May 2014 13:32:53 GMT - Antoine Martin:

Did you have a chance to test it? Can I close this ticket? r6343 makes sense, so I have applied it to v0.12.x in r6430.


Fri, 09 May 2014 14:30:48 GMT - callegar:

Sorry, no way to test on that machine yet, since I'm away. I hope I'll be able to try shortly, though.


Sat, 10 May 2014 07:57:51 GMT - tsaarni:

I get the same NullFunctionError on my machine as callegar reported.

Client is ubuntu 14.04 with Intel HD Graphics (i915).

$ python /usr/lib/python2.7/dist-packages/xpra/client/gl/gl_check.py
2014-05-10 10:38:02,858 PyOpenGL warning: missing accelerate module
2014-05-10 10:38:02,858 PyOpenGL warning: missing array format handlers: numeric, vbo, vbooffset
2014-05-10 10:38:02,858 OpenGL Version: 2.1 Mesa 10.1.0
2014-05-10 10:38:02,862
2014-05-10 10:38:02,862
2014-05-10 10:38:02,862 OpenGL properties:
2014-05-10 10:38:02,863   pygdkglext_version       : (1, 1, 0)
2014-05-10 10:38:02,863   has_alpha                : True
2014-05-10 10:38:02,863   vendor                   : Intel Open Source Technology Center
2014-05-10 10:38:02,863   gdkgl_version            : (1, 4)
2014-05-10 10:38:02,863   shading language version : 1.20
2014-05-10 10:38:02,863   opengl                   : (2, 1)
2014-05-10 10:38:02,863   GLU extensions           : GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
2014-05-10 10:38:02,864   renderer                 : Mesa DRI Intel(R) Ironlake Mobile
2014-05-10 10:38:02,864   rgba                     : True
2014-05-10 10:38:02,864   display_mode             : ['ALPHA', 'SINGLE']
2014-05-10 10:38:02,864   pyopengl                 : 3.0.2
2014-05-10 10:38:02,864   GLU version              : 1.3

So GL 2.1 here too. Isn't glEnablei() GL 3.0?

I'm using xpra for the first time now, so I don't know if it worked before trustu release.


Sat, 10 May 2014 09:58:46 GMT - tsaarni:

I fetched the trunk but it still has the bug.

The code that is conditionally calling glEnablei() uses HAS_ALPHA value that originates from GTKWindowBacking class instead of the global variable set in gl_check.py. See constructor of ClientWindowBase?. It uses GTKWindowBacking.HAS_ALPHA which does not consider, nor is updated according to the gl_check variant of the HAS_ALPHA.

I see from SVN log that some refactoring has been done in recent days but this problem remains.


Sat, 10 May 2014 12:33:10 GMT - Antoine Martin:

Isn't glEnablei() GL 3.0?


You're right, it is: GLAPI: glEnable

The code that is conditionally calling glEnablei() uses HAS_ALPHA...


You're right again. Does r6437 fix this properly this time? (and r6438 for v0.12.x)

If so, I'll try to make new 0.12.x release next week.


Sat, 10 May 2014 19:57:50 GMT - tsaarni:

Thanks for your response,

Unfortunately it still did not fix the bug. I found two remaining problems:

1) In r6437 copy of HAS_ALPHA is made from the global variable before call to gl_check.check_GL_support() has been made. Therefore GLPixmapBacking.HAS_ALPHA is set to True which is the default value for gl_check.HAS_ALPHA.

I know this isn't nice thing to do, but following works around this problem:

--- xpra/client/gl/gl_check.py  (revision 6438)
+++ xpra/client/gl/gl_check.py  (working copy)
@@ -216,6 +216,8 @@
             log.warn("OpenGL glEnablei is not available, disabling transparency")
             global HAS_ALPHA
             HAS_ALPHA = False
+            from gl_window_backing import GLPixmapBacking
+            GLPixmapBacking.HAS_ALPHA = False
         #check for framebuffer functions we need:
         from OpenGL.GL.ARB.framebuffer_object import GL_FRAMEBUFFER, \

2) Second remaining problem is that the _has_alpha value is still overwritten in call ClientWindowBase.set_metadata(metadata) since metadata["has-alpha"] is true. It will change the value back to True.


Sun, 11 May 2014 04:59:36 GMT - Antoine Martin:

Oh, dear, that's embarrassing. You're right again!

I remember thinking when I did the refactoring, that there were too many attributes carrying almost the same information, and that this led to confusion and probably also bugs:

So... it's messy and I need to take a good look at this. Renaming some of these variables might help. For 0.12.x backport, something more simple will have to do.


Sun, 11 May 2014 05:50:06 GMT - tsaarni:

Thanks,

For a simple temporary fix, would something like following make sense:

--- xpra/client/gl/gl_window_backing.py (revision 6438)
+++ xpra/client/gl/gl_window_backing.py (working copy)
@@ -385,7 +385,8 @@
         glBindTexture(GL_TEXTURE_RECTANGLE_ARB, self.textures[TEX_FBO])
         if self._has_alpha:
             # support alpha channel if present:
-            glEnablei(GL_BLEND, self.textures[TEX_FBO])
+            if bool(glEnablei):
+                glEnablei(GL_BLEND, self.textures[TEX_FBO])
             glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
         glBegin(GL_QUADS)
         glTexCoord2i(0, h)

that is, move the PyOpenGL test down to the actual call site.


Sun, 11 May 2014 13:28:39 GMT - Antoine Martin:

For a simple temporary fix


Yes, that would do very nicely for 0.12. Probably makes sense to also indent glBlendFunc.

Note: for trunk, I'll continue with the flag cleanup instead. Why is this important: knowing in advance if you will be able to use alpha makes a huge difference in terms of server encoding performance as none of the video encodings we use support alpha ( well, vp9 and h265 could, but they are far too slow to be relevant at this point) so would be forced to use PNG or WEBP (or even plain RGBA) to send the alpha channel (and all for nothing if the client cannot make use of it)


Mon, 12 May 2014 09:58:50 GMT - callegar:

I guess that my comments are now completely irrelevant since everything is very well diagnosed. However, I checked. And indeed the client where I was having the issue is pre-opengl 3.0. On another client with recent Intel graphics supporting opengl 3.0 everything is fine.


Mon, 12 May 2014 13:00:52 GMT - Antoine Martin:

The fix for v0.12 is in r6439. I hope. This time. For real.

the client where I was having the issue is pre-opengl 3.0


Still good to know.


Mon, 12 May 2014 17:27:08 GMT - tsaarni:

I fetched tags/v0.12.x and it works great!

Funny thing is that now also the self._has_alpha value in GLPixmapBacking is False as it should. So I think previous fix to v0.12.x must have already fixed it and r6439 is not even necessary. Until now, I only tested trunk, where the has_alpha value was True. Sorry for not testing v0.12.x before!


Tue, 13 May 2014 09:42:03 GMT - Antoine Martin:

Sorry for not testing v0.12.x before!


No problem, thanks for testing. The extra check can't do any harm, so I'll just keep it in.


Here's what I did for trunk to try to clean things up (see r6444 and r6445, fixups in r6449 and r6451), it adds a little bit more code but I think it makes sense. Documenting here for lack of a better place:

I have also changed a few warnings to be visible by default, as I think we should now be unable to hit them, and are therefore good candidates for complete removal.

Note: we could probably handle the change in alpha for a window by re-initializing its backing, but I don't think that X11 server side windows can change their alpha without making a new window. (well at least not for the xpra X11 unix server case, which is the main target.. for shadow servers, you will have to re-connect if the bpp is change from 24 to 32)


Where this gets really interesting: in adding BGRX to the list of pixel formats we can upload with GL, I've uncovered two more bugs (will this ever end?):


Thu, 15 May 2014 13:07:21 GMT - Antoine Martin:

Unfortunately this one is bigger but should also be backported to v0.12.x, or newer clients (0.13 onwards) will not work too well with older servers..


I think this ticket can now be closed, feel free to re-open if I've missed anything.


Sat, 17 May 2014 09:06:31 GMT - Antoine Martin: status changed; resolution set

I believe the backported fixes in 0.12.6 (see above + re-stride in r6483, r6460 for adding the intel driver to the blacklist) should prevent all the issues mentioned in this ticket. If not, feel free to re-open it.

Forgot cairo, fixed in r6511.


Tue, 27 May 2014 07:50:42 GMT - Antoine Martin:

Forgot toggling opengl on / off, which broke.. see #578


Wed, 16 Dec 2015 03:39:57 GMT - Antoine Martin:

See wiki/ClientRendering/OpenGL


Sat, 23 Jan 2021 04:59:32 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/565