can't open glxgears or blender on a remote ssh -X connection

[Albert Cardona]

I have no problems in connecting remotely to my workstation using the X forwarding, and thus running Blender remotely, from
apple's X11 or YellowDog Linux 4.0.1.
But in both kubuntu hoary and kubuntu breezy I can't do that.
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.

[Jonathan Riddell (jr)]

I can confirm this beastie for ssh from i386 to powerpc or powerpc to i386. powerpc to localhost
is fine and i386 to i386 is fine.

[Albert Cardona (cardona)]

Jonathan,
Is this bug fixed in Dapper already? I need openGL over ssh connections so bad! Thanks for any input. I will try a flight CD 4 (the 2 and 3 didn't boot in the powermac around here).

[Albert Cardona (cardona)]

I have tried the ubuntu (gnome) dapper Flight-5 live CD and the problem persists. The kubuntu iso image for the live CD cannot be burned because it is way too large, even with overburning.

[Albert Cardona (cardona)]

The severity has changed from major to minor. My whole lab here at UCLA has shifted from Ubuntu to MacOSX just because of this "minor" bug. If letting students and technicians grow used to macosx is a "minor" issue, sure. I am powerless as to fix this bug but it corrupts any usage we may give to ubuntu by not letting us use OpenGL applications remotely.

[Rocco Stanzione (trappist)]

Since this bug "Has a severe impact on a small portion of Ubuntu users", I'm setting the severity here to Major per https://wiki.ubuntu.com/Bugs/CommonTasks

[Cardona-ucla (cardona-ucla)]

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.

[Albert Cardona (cardona)]

Since I see that noone is working on this, can at least someone point me to the right direction so that I can perhaps submit a patch myself?

Which configuration files, and Xorg source files, are likely to be involved?

Thanks for any directions.

[Michel-tungstengraphics (michel-tungstengraphics)]

(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?

[Cardona-ucla (cardona-ucla)]

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

[Michel-tungstengraphics (michel-tungstengraphics)]

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

[Cardona-ucla (cardona-ucla)]

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.

[Albert Cardona (cardona)]

I have contacted the Xorg bug tracker directely and a possible source of the bug has been identified already. See it here:
https://bugs.freedesktop.org/show_bug.cgi?id=7213

I can only hope the fix will be integrated and packaged fast enough.

[Michel-tungstengraphics (michel-tungstengraphics)]

Fixed in xserver git.

[Cardona-ucla (cardona-ucla)]

> 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!

[Albert Cardona (cardona)]

Apparently it has been fixed at
https://bugs.freedesktop.org/show_bug.cgi?id=7213
I hope it gets packaged soon ...

[Michel-tungstengraphics (michel-tungstengraphics)]

(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.

[Andrew Mitchell (ajmitch)]

Looking at the upstream bug, it looks like it's fixed in the X.Org version we have in edgy. Can someone please confirm this?

[Rodrigo Novo (rodarvus)]

Confirmed. This is fixed for Edgy.

I also have an updated package for Dapper, and am testing it this weekend. As soon as it is published to the archive, I'll close this bug.

[Albert Cardona (cardona)]

Great guys! We are looking forward to the updated package.
Thank you!

[Rodrigo Novo (rodarvus)]

Fixed package uploaded for Dapper (note that dapper-updates uploads need to be manually approved by an ubuntu-archive member, so this package might take a while to be built & published.

[Colin Watson (cjwatson)]

I've approved Rodrigo's upload to dapper-updates.

[Albert Cardona (cardona)]

Thank you all very much for your efforts. It works! One more time it has been pulled out! Congratulations to everyone, we can resume working on our workstations again as of today.

Albert