I have no problems in connecting to my remote x86 workstation using the X forwarding, and thus running Blender remotely, from apple's X11 or YellowDog Linux 4.0.1 (XFree 6.8). But in both kubuntu breezy and dapper I can't do that (Xorg 6.8 and 7.0.0) Over the remote connection, the xclock opens just fine, and so does a remote konqueror, but glxgears doesn't, nor does blender. The error that pops for glxgears and glxinfo (and the same for blender): -bash-2.05b$ glxgears X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 128 (XFree86-DRI) Minor opcode of failed request: 1 () Serial number of failed request: 11 Current serial number in output stream: 11 -bash-2.05b$ glxinfo name of display: localhost:10.0 X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 128 (XFree86-DRI) Minor opcode of failed request: 1 () Serial number of failed request: 11 Current serial number in output stream: 11 -bash-2.05b$ I have tried to set /etc/ssh/ssh_config "XForwardingTrusted yes", and also run "xhosts +", to no avail. I have also tried to set the DISPLAY var to my kubuntu machine IP plus 0.0 (i.e. 192.168.0.3:0.0 ), but didn't work either, actually didn't even let me open xclock. Both blender and glxgears work just fine in the local kubuntu, but not over a remote connection. I cannot understand why at all, thus this bug report. Some endianness may be at play: I can confirm this beastie for ssh from i386 to powerpc or powerpc to i386. But powerpc to localhost is fine and i386 to i386 is fine.
(In reply to comment #0) > > -bash-2.05b$ glxgears > X Error of failed request: BadRequest (invalid request code or no such > operation) > Major opcode of failed request: 128 (XFree86-DRI) > Minor opcode of failed request: 1 () > Serial number of failed request: 11 > Current serial number in output stream: 11 Something fails to realize it's not a local connection. Setting LIBGL_ALWAYS_INDIRECT=1 goes further but still fails here in a similar scenario. > I have also tried to set the DISPLAY var to my kubuntu machine IP plus 0.0 > (i.e. 192.168.0.3:0.0 ), but didn't work either, > actually didn't even let me open xclock. Probably because the server runs with -nolisten tcp or an authentication issue. > I can confirm this beastie for ssh from i386 to powerpc or powerpc to i386. > But powerpc to localhost is fine and i386 to i386 is fine. By 'i386 to i386', do you mean an ssh connection between to i386 boxes?
> > I can confirm this beastie for ssh from i386 to powerpc or powerpc to i386. > > But powerpc to localhost is fine and i386 to i386 is fine. > > By 'i386 to i386', do you mean an ssh connection between to i386 boxes? Yes, ssh -X connection between two kubuntu x86 boxes is fine, and between two kubuntu powerpc boxes is fine as well. Only when the client is a powerpc and the server is an x86, or viceversa, opengl apps fail.
It looks like the problem is in xf86dri.c. It should probably also support the X_XF86DRIQueryDirectRenderingCapable request in the byte-swapped case, as the client side relies on that to find out whether direct rendering is possible. However, my experiments with LIBGL_ALWAYS_INDIRECT=1 indicate that there are more problems down the road...
Thank you so much Michel for having a look at this. I'm most impressed that you have spotted the most likely source of the problem! Our whole lab here is a mixture of powerpc and x86 machines, and for ease of use all machines run debian or [k]ubuntu. It is a current disaster that we can't run Blender remotely on many ocasions.
Fixed in xserver git.
> Fixed in xserver git. Michel, what does 'git' means? Where and how can one get a snapshot of the CVS code or whatever stable release this fix is in? Thank you for fixing it! Now if only I could test it myself!
(In reply to comment #6) > > Michel, what does 'git' means? > Where and how can one get a snapshot of the CVS code xserver development has moved from CVS to git, see http://gitweb.freedesktop.org/?p=xorg-xserver;a=commitdiff;h=4426215a6e99f84550aaac23ac9c2018668bfbc1;hp=a195a3debca02572d9f7d7a9976b5bf67acc5d08 > or whatever stable release this fix is in? It's not in any release yet. > Thank you for fixing it! Now if only I could test it myself! If you can't work it out from the above, I can attach a patch against the xserver 1.0 codebase.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.