Opened 4 years ago
Last modified 4 years ago
#61959 assigned defect
Issue with XQuartz & legacy X forwarding
Reported by: | mzryz | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.4 |
Keywords: | Cc: | ||
Port: | xorg-server |
Description
The team over at sgi.sh have been trying to get X11 forwarding working on SGI IRIX > MacOS for a while without luck. First was the iglx issue which we worked out, but secondly there seems to be an issue with Xinerama and its interaction with XQuartz. After doing research into this issue, it seems to have been a consistent bug for almost 15 years (I will provide references at the end)
X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 128 (XINERAMA) Minor opcode of failed request: 1 (XINERAMAGetState) Resource id in failed request: 0xa9010000 Serial number of failed request: 760 Current serial number in output stream: 760
This error presents when running 'certain' applications over Xforwarding, notably ones with more complex GLX requirements, like the window manager in Irix that uses vector icons etc. It doesn't seem to be related to indirect rendering, but it does require indirect rendering to be working correctly. We currently have Mac users forced to run Linux VM's on their glorious MacOS in order to use Xforwarding... the horror! :)
I hope this is something the team here might be able to look in to? I do appreciate it may not be specific to Macports but any kind of help is appreciated. Thanks.
Our forum thread on the issues: https://forums.sgi.sh/index.php?threads/x11-forwarding-adventures.383/
Here are a few historical links to this issue constantly cropping up: 2004: http://sunmanagers.cs.toronto.edu/2004/5331.html 2007: https://discussions.apple.com/thread/1101676 2010: https://lists.apple.com/archives/X11-users/2010/May/msg00010.html
Change History (4)
comment:1 Changed 4 years ago by mf2k (Frank Schima)
Cc: | jeremyhu removed |
---|
comment:2 follow-up: 3 Changed 4 years ago by jmroot (Joshua Root)
comment:3 follow-up: 4 Changed 4 years ago by mzryz
Replying to jmroot:
I remember something like this coming up before somewhere, and it turned out that indirect glx is disabled by default due to security concerns. What I'm remembering might not be the same problem at all, but have you checked that indirect glx is enabled? Adding
+iglx
to the server args in your startx script should do it if not.
Yes we did enable +iglx with: defaults write org.macosforge.xquartz.X11 enable_iglx -bool true Also tried all advice in this guide: https://www.visitusers.org/index.php?title=Re-enabling_INdirect_glx_on_your_X_server
comment:4 Changed 4 years ago by jmroot (Joshua Root)
Replying to mzryz:
Yes we did enable +iglx with: defaults write org.macosforge.xquartz.X11 enable_iglx -bool true
I don't believe that will have any effect on xorg-server installed with macports, as it is configured with an org.macports prefix rather than org.macosforge. See X11_PREFS_DOMAIN
in /opt/local/bin/startx
.
I remember something like this coming up before somewhere, and it turned out that indirect glx is disabled by default due to security concerns. What I'm remembering might not be the same problem at all, but have you checked that indirect glx is enabled? Adding
+iglx
to the server args in your startx script should do it if not.