The Windows version of the "octave --version" command exposes an uncommon X network transparency issue for wine
I have been downloading lots of free software packages for Windows that are dependencies of PLplot so that I can add additional components of PLplot for my tests of PLplot under wine. Normally, I do all such testing on an X-terminal, and wine normally works without X transparency issues for everything I have tested up to now on wine. These tests include Windows GUI installers for lots of different free software packages and PLplot device drivers that generate interactive plots for the Windows platform. I have not done any such tests for games.
This just-encountered network-transparency trouble occurred for the Windows version of octave, and the reason I am bringing it up here is to find out if this is a known issue or a new bug that I should report on your bug tracker.
Here are the details. I am running a 32-bit version of wine-1.3.9 that I have built and installed on Debian testing 64-bit hardware.
The GUI installer for octave obtained from "http://prdownloads.sourceforge.net/octave/Octave_Windows%20-%20MinGW/Octave%..." worked fine under wine (on the X-terminal). I chose everything to be default other than the install prefix location.
I am also using the latest version of Windows bash from MSYS and start running it as follows
wineconsole --backend=curses MinGW/msys/1.0/bin/bash.exe
Under that bash if I set the PATH to include the bin directory where octave.exe resides and run
octave --version
directly (i.e., not from an X-terminal) I get a good result which consists of the usual GNU octave version message. If I do the same thing from my X-terminal (where all X applications like the xterm where the wineconsole command is executed are running on a remote machine over the office LAN and a local X server on the X-terminal box transparently handles the X display, keyboard, and mouse), then I get the following errors (subject to rewrapping)
bash.exe-3.1$ octave --version X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow)
Serial number of failed request: 208 Current serial number in output stream: 210
Since a rather large number of wineconsole or wine commands I have been running recently (including the octave installer GUI itself) work without issues for an X-terminal, my working hypothesis is the Windows version of octave (which can know absolutely nothing about X) generates a special version of a normal display request to wine that wine for some reason cannot handle in a network-transparent way when translating that display request to X.
Are there known network transparency issues still remaining for some small subset of the display requests translated into X by wine or is this a new X network transparency bug for wine that I should report?
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
Am 21.12.2010 00:42, schrieb Alan W. Irwin:
I have been downloading lots of free software packages for Windows that are dependencies of PLplot so that I can add additional components of PLplot for my tests of PLplot under wine. Normally, I do all such testing on an X-terminal, and wine normally works without X transparency issues for everything I have tested up to now on wine. These tests include Windows GUI installers for lots of different free software packages and PLplot device drivers that generate interactive plots for the Windows platform. I have not done any such tests for games.
This just-encountered network-transparency trouble occurred for the Windows version of octave, and the reason I am bringing it up here is to find out if this is a known issue or a new bug that I should report on your bug tracker.
I'm not sure, but have a look at: http://bugs.winehq.org/show_bug.cgi?id=7416 http://bugs.winehq.org/show_bug.cgi?id=23952
On 2010-12-21 14:33+0100 André Hentschel wrote:
Am 21.12.2010 00:42, schrieb Alan W. Irwin:
This just-encountered network-transparency trouble occurred for the Windows version of octave, and the reason I am bringing it up here is to find out if this is a known issue or a new bug that I should report on your bug tracker.
I'm not sure, but have a look at:
http://bugs.winehq.org/show_bug.cgi?id=7416 http://bugs.winehq.org/show_bug.cgi?id=23952
Thanks, André, for those suggestions.
When I looked at 7416 it refers to support for multiple monitors which is quite different from the X network transparency which allows X terminals (a.k.a. boxes with a minimal Linux distribution that includes an X server but no desktop software like KDE) to use the local X server to display results and handle keyboard and mouse events so that X clients (e.g., KDE desktop, etc.) running on other machines accessible via a network look and feel like they are running on the local machine.
23952 looked more interesting since the quoted error message is very close to what I got. That one was due to a regression (apparently still not fixed) between 1.1.30 and 1.2.0 in how DRI was handled, and one workaround for the reporter was to disable DRI. In my case, "octave --version" worked when run directly on an box with integrated (g33) Intel graphics with DRI enabled, but my X-terminal where the failure occurred has DRI disabled because the graphics chip is SiS with no DRI support. So in essence I am getting reverse behavior to 23952; for a box with DRI turned on, octave --version succeeds, but for a box with DRI turned off it fails. Once I can get access to the Intel box again, I will try taking the network transparency out of the mix by turning off DRI on the intel (direct) box to see if that generates the issue. If octave --version works on that box regardless of whether DRI is on or off, then that would be an even stronger case that it is the (lack of) network transparency for this particular (and rather uncommon) case that is the culprit.
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
Alan W. Irwin wrote: <snipped>
wineconsole --backend=curses MinGW/msys/1.0/bin/bash.exe
Under that bash if I set the PATH to include the bin directory where octave.exe resides and run
octave --version
directly (i.e., not from an X-terminal) I get a good result which consists of the usual GNU octave version message. If I do the same thing from my X-terminal (where all X applications like the xterm where the wineconsole command is executed are running on a remote machine over the office LAN and a local X server on the X-terminal box transparently handles the X display, keyboard, and mouse), then I get the following errors (subject to rewrapping)
bash.exe-3.1$ octave --version X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow)
Serial number of failed request: 208 Current serial number in output stream: 210
<snipped>
I am still not quite sure about the two different execution environments you have, but if it is DRI-related, you could try also running Xvfb and setting DISPLAY to the Xvfb virtual display to see if either of your execution environments continue to work. AFAIK Xvfb is totally software-based and since "octave --version" doesn't use X display at all, using Xvfb should be no effect what so ever.
-
Alan W. Irwin -
André Hentschel -
Hin-Tak Leung