This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CygwinX at MS Terminalserver?

On 16/08/2010 07:35, Steffen Sledz wrote:
Am 13.08.2010 13:09, schrieb Jon TURNEY:
Now testuser0002 tries to start another server in parallel.
This gives this error:

/usr/bin/startxwin: Resource temporarily unavailable (errno 11): Another X server instance is running on DISPLAY :0

This is expected. As I said, each X server instance must have a unique display number.

This can't possibly work any other way.  If two users both
have an X server with display number 0, to which server should
a client started with DISPLAY=:0.0 connect?

That's clear. I thought (or hoped) that starting X server using the "XWin Server" menu item automatically searches for an unused display number and uses it. I think that would be a good default behaviour.

I agree it would be useful, and it is on the todo list [1], but there's a non-trivial problem to solve first:

How is the display number which the server has allocated communicated to other processes, so that the users clients appear on the right display?

If you start the X server first and then launch everything from the traymenu, everything would works fine, as the X server places a correct DISPLAY variable into the environment inherited by the child process.

But if you start the X server via xinit/startx/startxwin, the display number needs to be communicated back to xinit, so that the correct display number is used for clients which are subsequently started by xinit.

Fedora ships with a patch [2] which adds the -displayfd option, which allocates a display number and writes it to the specified fd. But to be useful to us, xinit would needs some code to use that flag (under some circumstances) and read that display number and use it for the clients it creates.

There's also the case where the user explicitly sets DISPLAY programmatically or manually before starting clients. I think with some suitable shell scripting, -displayfd probably can be used for that also.


A fatal error has occured and Cygwin/X will now exit.

Cannot open log file "/var/log/XWin.0.log"

This is interesting. On my systems, /var/log has mode 777, rather than 1777.

Having the restricted deletion flag set on /var/log prevents
other users from deleting the logfile from a previous run.

However, checking the source for setup.exe, I see that it does
create /var/log with 1777 permissions, so how I got into this
state I don't know...

I'm not sure that is right, but assuming it is intentional, I
guess we need to create a /var/log/xwin with mode 777 and arrange
for that to be the default logfile location

mkdir /var/log/xwin
chmod 777 /var/log/xwin
adding '-logfile /var/log/xwin/XWin.%s.log' to your xwin command line.

I tested this with success. :)

It would be very helpfully too if this can become the default behaviour of the "XWin Server" menu item (or XWin).

Well, it's not clear here how this should be fixed.

I *think* that this is just a setup bug, and we can simply create /var/log with mode 777.

Volunteer Cygwin/X X Server maintainer

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]