Exporting X display with X-Win32

[aaearon]

How would I go about? I am unable to find any guides that help me, so if you find one or want to post how you got it to work, please feel free :)

[arantius]

Hmm..... x0rfbserver .....

[aaearon]

So would I compile that on my linux box?

[grimjack]

If you mean that you want to run showeq and have the gui come up on a machine that is runing Xwin32 all you have to do is run Xwin32 on your windows machine and set up your DISPLAY. Then run showeq. export DISPLAY=ip.of.xwin32.machine:0.0


Thanks
GrimJack

[LordCrush]

I use VNC for that, cause X-Servers on win32 are very expensive ...

Perhaps s.o. has a tip for a low cost X-Server i would like to try :)

[grimjack]

Cygwin comes with an X-Server for free.

Thanks
Grimjack

[LordCrush]

Thnx :)

http://cygwin.com/xfree/

[aaearon]

Originally posted by grimjack
If you mean that you want to run showeq and have the gui come up on a machine that is runing Xwin32 all you have to do is run Xwin32 on your windows machine and set up your DISPLAY. Then run showeq. export DISPLAY=ip.of.xwin32.machine:0.0


Thanks
GrimJack

How do I set up DISPLAY?

[Spook]

I've used X-Win32 and the current version of it which is named WinaXe+ (+ for nfs). What you want to know is in their help files. They also have several tutotials - even online walkthroughs. Also, they support ssh2 when you log in via their telnet/ssh2 client which passes display information when you start X clients from the shell that way. I use that one because it is relatively cheap and has support for GLX extensions (which is important to me as I test the updated 3D mapping).

I would love to use the XFree86 port with the cygwin environment but have had a lot of trouble which is why I bought WinaXe...

GL

[quester]

I use VNC to simply log into my XSession on my linux box, and it works very well for me. I have a dual monitor Windows machien for EQ.. EQW on the main monitor, and VNC showing SEQ on the second monitor. Works awesome, and since I use EQW, I can tab over to VNC to make changes in SEQ as needed.

[Jonn]

Another option is to use X11 forwarding in the ssh protocol. If you are using, example, Cygwin, fire the old boy up to X windows (usually you go to your cygwin command line and type startx, myself I use a shortcut right to the .bat file that starts the Cygwin X server when I want an X server). In the X windows interface that comes up, type:

ssh -l root -X remotehost

the -l option says "log in as user..." and the -X option says "enable X11 forwarding." Then when you get the ssh connection established, start up showeq like normal. Voila, your windows come up in your current X session, and the X communications are encrypted for that added warm-fuzzy feeling.

Of course, this comes with a performance hit to the linux box and the Windows box, so mileage may varry.

[grimjack]

Originally posted by aaearon


How do I set up DISPLAY?

At the prompt you run showeq from you would do this.

export DISPLAY=ip.of.windows.machine:0.0
or
DISPLAY=ip.of.windows.machine:0.0;export DISPLAY


This tells the system that any X apps should have the display redirected to the server runing Xwin32. Keep in mind that this is not perminant. You will either have to run this every time you log in or add it to your .profile. Also I assume you use bash as your shell.

As stated in a previous post, another option is to use ssh to log into the showeq machine and use the X forwarding option. In this case, your DISPLAY should be set up to properly forward through SSH automatically.

Thanks
GrimJack

[HanzO]

I tried X-Win - I found it cluttered the network stream.

I just use VMWare on a windows box - works like a charm.

[Zor]

For me X-Win32 is much faster than X on VMWare, even running from the same computer. Very odd.

[Jonn]

VMWare has a fairly large overhead associated with it, both memory wise and processor wise. Even though graphics are accelerated if you use the VMWare tools, they're frequently still pretty laggy, as your client OS makes graphics calls that are interpreted to system calls that VMWare interprets to graphics calls that are interpreted to system calls.

There's also a large overhead of context switching that has to occur for every cycle that is incurred on the client OS. Context switching is where an OS swaps out the active registers from one application to allow another application to control the processor for a while. A context switch occurs every "quantum" (in fact, it defines the edges of a quantum). The way that process threading works, at least under the x86 architecture, I'm not sure about other architectures, is each process exists in its own virtual memory space. "System calls" are actual binary operations passed directly to the processor through "registers" which are *ultra* high speed, but very small capacity memory spaces actually physically located within the processor. Only one program at a time can control the registers in the processor, so the OS lets a particular program control the processor for a few thousand cycles. All operations are halted, outside of that process' control, and the application is copied back to its original location in ram, the next process which should hold control of the CPU is then swapped in. No "productive" work is done during this time, and it can often significantly reduce the efficiency of a system if the length of a quantum is set too high or too low (the higher the length of the quantum, the less time you spend on context switches, but the less simultaneous program execution is). Context switching is *very* heavy on system performance. Running two long-duration processor intensive operations simultaneously is far less efficient than running them consecutively (keep that in mind next time you're doing a kernel build, you probably don't want to also be using GIMP to update graphics for your website unless you feel like both things taking too long)

So what happens in VMWare is that the client OS has to do this context switching as well as the host OS, so depending on the length of the quantums (in both host and client OS), you can easily use up your entire host OS quantum taking care of client OS context switching, meaning that that entire cycle through controlling the processor, your client OS has accomplished nothing "productive" such as drawing your graphics or decoding spawns. This gets especially bad if you have something else that is processor-intensive going on [read: running Everquest in windowed mode], as EQ, like all games, assumes that nothing else will be vying for the processor very frequently, so it just consumes as much processor as it can at all times.

Context switching occurs fairly frequently with ShowEQ running in the client OS, as graphics are handled by one process (X11), and computations by another (ShowEQ), both of which are fairly processor intensive, it's not like running a single command line processor intensive program, it's like running two command line processor intensive programs, which we've already discussed increases the overhead of context switching.

That leaves the execution of your client OS within VMWare hurting badly, it can only have half the original processor at best, and it shaves another 1/3 or so off of that off to handle context switches that are unusually high overhead due to the dual nature of client OS context switching. So if you have a 2 GHz machine running EQ and VMWare simultaneously, you're probably looking at a 600 MHz-ish client machine, and a 1 GHz machine to run EQ.

If all you have is one machine, then there really isn't a better option, but if you have a second machine that you can have a dedicated Linux install on, then unless you have like a parallel cable network between the two, or a null modem connection, or infrared, I can absolutely guarantee that running ShowEQ on the dedicated machine, with X11 tunneling will have far better performance. And if you have a monitor for the second machine, then your best performance overall will be running ShowEQ on it in its own native X11R6 server, perhaps even better performance than that with a lighter weight native X server.

Sorry if that was a little technical, if so, then please don't have already read it.