With the help of nVidia, I was able to get to the bottom of what's going
on with WINE 1.3.11+. In fact, it has nothing to do with WINE. Any
application that attempts to call glXSwapIntervalSGI() with a Pbuffer
current will cause nVidia GLX to trip a BadWindow error. This has been
the case at
@lists.sourceforge.net
Sent: Tuesday, March 1, 2011 12:47:14 AM
Subject: Re: [VirtualGL-Users] VirtualGL Linux wine crash in versions
newer than 1.3.10
On 2/28/11 6:20 PM, Nathan Kidd wrote:
On 11-02-28 07:04 PM, DRC wrote:
I'm not following how you ascertained that the issue was between WINE
On 11-03-02 05:14 PM, DRC wrote:
Bingo.
Apparently nVidia is trying to outsmart us yet again and is somehow
making a determination in the underlying GLX library that it needs to
send glXSwapIntervalSGI() over the wire rather than to the display on
which the GLX context has been established
On 3/3/11 11:21 AM, Nathan Kidd wrote:
Another approach to deal with this could be to remove
GLX_SGI_swap_control from the extension list. At least this way
(well-behaved) apps would *know* they can't control the update speed.
(Although in wine's case it will simply warn and carry on, so the
-Users] VirtualGL Linux wine crash in versions
newer than 1.3.10
I did some more testing based on comments here - hopefully there's some
useful information since I know the methods were unorthodox to say the
least.
First, perhaps not helpful, but the error is reproduceable using a
Cygwin
I'm not following how you ascertained that the issue was between WINE
and the 3D X server.
On 2/28/11 5:11 PM, Nathan Kidd wrote:
I was finally able to reproduce.
a) I had to update my NVIDIA driver from a pretty old 185 to 260.
b) Used Wine 1.3.14 (from ubuntu-wine/ppa karmic) and
On 11-02-28 07:04 PM, DRC wrote:
I'm not following how you ascertained that the issue was between WINE
and the 3D X server.
Sorry, I didn't mention that part. I ran against an in-house X server
with tracing enabled and examined the trace. No GLX, and more
importantly, no X errors returned at
On 2/28/11 6:20 PM, Nathan Kidd wrote:
On 11-02-28 07:04 PM, DRC wrote:
I'm not following how you ascertained that the issue was between WINE
and the 3D X server.
Sorry, I didn't mention that part. I ran against an in-house X server
with tracing enabled and examined the trace. No GLX, and
crash in versions newer
than 1.3.10
On 11-02-25 06:19 PM, DRC wrote:
If we're getting a BadWindow error it had to be issued by the 2D X
server. Therefore, force an indirect context and grab a wireshark
trace. The actual VendorPrivate call has to be there. Once we know
which vop
PM
Subject: Re: [VirtualGL-Users] VirtualGL Linux wine crash in versions newer
than 1.3.10
On 11-02-25 06:19 PM, DRC wrote:
If we're getting a BadWindow error it had to be issued by the 2D X
server. Therefore, force an indirect context and grab a wireshark
trace. The actual
] VirtualGL Linux wine crash in versions
newer than 1.3.10
I can't reproduce the failure with WINE 1.3.13. Can you give more
specific information-- what graphics hardware you are using, the
specific driver version, what O/S, etc.?
After looking at the WINE source, the only scenario I can come up
If we're getting a BadWindow error it had to be issued by the 2D X
server. Therefore, force an indirect context and grab a wireshark
trace. The actual VendorPrivate call has to be there. Once we know
which vop it is then the grepping will be easier.
If you or someone else has the time
On 11-02-25 06:19 PM, DRC wrote:
If we're getting a BadWindow error it had to be issued by the 2D X
server. Therefore, force an indirect context and grab a wireshark
trace. The actual VendorPrivate call has to be there. Once we know
which vop it is then the grepping will be easier.
If you
Hello List,
I'm finding that VirtualGL has been working well with most graphics
applications I've tried under Linux, and even with pretty decent performance.
I have been running several Windows applications using wine and VirtualGL
(Games and other graphic applications) with decent success
On 11-02-24 10:32 AM, calvin.mor...@comcast.net wrote:
Hello List,
I'm finding that VirtualGL has been working well with most graphics
applications I've tried under Linux, and even with pretty decent
performance.
I have been running several Windows applications using wine and
VirtualGL
: Nathan Kidd nathan...@spicycrypto.ca
To: VirtualGL Users virtualgl-users@lists.sourceforge.net
Sent: Thursday, February 24, 2011 8:50:48 AM
Subject: Re: [VirtualGL-Users] VirtualGL Linux wine crash in versions
newer than 1.3.10
On 11-02-24 10:32 AM, calvin.mor...@comcast.net wrote:
Hello List
On 11-02-24 01:24 PM, Nathan Kidd wrote:
VGL doesn't hook
any vendor private calls, so ...
Correction: VGL doesn't appear to hook this vendor private function.
--
Free Software Download: Index, Search Analyze Logs
I can't reproduce the failure with WINE 1.3.13. Can you give more
specific information-- what graphics hardware you are using, the
specific driver version, what O/S, etc.?
After looking at the WINE source, the only scenario I can come up with
is that it's trying to use glXBindTexImageATI(),
, 2011 11:24:36 AM
Subject: Re: [VirtualGL-Users] VirtualGL Linux wine crash in versions newer
than 1.3.10
On 11-02-24 12:15 PM, calvin.mor...@comcast.net wrote:
xscope 1.3 reports to have beginning support for GLX, so I've attempted
to use that. This is my first time using xscope, so hopefully
19 matches
Mail list logo
