Re: Updated: xorg-server-1.9.2-1
On 09/11/2010 09:02, Fergus wrote:
Fatal server error:
Can't read lock file /tmp/.X0-lock
Does /tmp/.X0-lock exists? Is it readable by you?
Yes.
Hmm. It's strange that the Xserver should choose to lie about that, then.
The code in question really does just say...
lfd = open(LockFile, O_RDONLY);
if (lfd 0) {
unlink(tmp);
FatalError(Can't read lock file %s\n, LockFile);
}
... so I can't see much room for unpredictability.
It would be helpful if you could strace XWin to see why it gets this wrong.
Have you tried manually removing the lock file /tmp/.X0-lock?
Are you sure /tmp is getting mounted successfully
where you expect it to be?
Yes.
Have you tried '-nolock', as suggested by [1]
I hadn't then.
But I have now and as a consequence everything is working perfectly.
Thank you.
(Over time I have occasionally had to moderate the syntax of both XWin and
xterm command lines to go from working to failing and back again to working.
This is just another example. On an earlier occasion, the recommended use of
-nolock failed. I am just happy when the current usage works. Thanks again.)
Well, I can't deny this might be your experience, but that's not how things
are supposed to work :-)
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: xorg-server-1.9.2-1
Fatal server error: Can't read lock file /tmp/.X0-lock Does /tmp/.X0-lock exists? Is it readable by you? Yes. Are you sure /tmp is getting mounted successfully where you expect it to be? Yes. Have you tried '-nolock', as suggested by [1] I hadn't then. But I have now and as a consequence everything is working perfectly. Thank you. (Over time I have occasionally had to moderate the syntax of both XWin and xterm command lines to go from working to failing and back again to working. This is just another example. On an earlier occasion, the recommended use of -nolock failed. I am just happy when the current usage works. Thanks again.) Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: xorg-server-1.9.2-1
Dear Jon, Since the update I have been unable to start XWin under [1.7]. Following my usual sequence at a bash prompt: mount n:/tmp /tmp # drive n: is NTFS as required run XWin -multiwindow Normally these two would be followed by a command line for xterm, but I am not getting that far! The second line repeatedly generates a Cygwin/X error message box, where the reason given is very familiar: Can't read lock file /tmp/.X0-lock I used to get this when /tmp was FAT32 but as you see from line 1 I am making an explicit mount to a NTFS drive, and in the recent past this step has been all that is necessary to make progress. When I open /var/log/xwin/XWin.0.log for more information I read ~ cat /var/log/xwin/XWin.0.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.9.2.0 (10902000) Build Date: 2010-11-03 XWin was started with the following command line: /usr/bin/XWin -multiwindow ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1280 h 1024 winInitializeDefaultScreens - native DPI x 96 y 96 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/mandible:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 Fatal server error: Can't read lock file /tmp/.X0-lock [1]+ Donerun XWin -multiwindow Can anything be determined from the 3 lines in this file beginning _XSERV (Unable .. failed .. failed)? Do I need to change my command sequence? BTW it's interesting (is it?) that the error message refers to 1.9.2.0 not 1.9.2-1. I'm surprised that there are no other anguished reports to you following the update, but I guess that's because the fault/ problem/ difficulty is mine rather than general. ?? Any insights much appreciated. Thank you, Fergus PS It kills me not to copy this to cygwin at cygwin dot com which I feel will have a much wider readership and skill set amongst that readership, but anybody sinning in this regard is always referred straight to Cygwin-X. A strange separation of reporting. Not that I am doubting your specific capability, just the potential for Me Too amongst readers. (Or even Not Me, but I Know What's Going Wrong.) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: xorg-server-1.9.2-1
On 08/11/2010 11:48, Fergus wrote:
Since the update I have been unable to start XWin under [1.7].
Following my usual sequence at a bash prompt:
mount n:/tmp /tmp # drive n: is NTFS as required
run XWin -multiwindow
Normally these two would be followed by a command line for xterm, but I am not
getting that far! The second line repeatedly generates a Cygwin/X error
message box, where the reason given is very familiar:
Can't read lock file /tmp/.X0-lock
I used to get this when /tmp was FAT32 but as you see from line 1 I am making
an explicit mount to a NTFS drive, and in the recent past this step has been
all that is necessary to make progress. When I open /var/log/xwin/XWin.0.log
for more information I read
~ cat /var/log/xwin/XWin.0.log
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.9.2.0 (10902000)
Build Date: 2010-11-03
XWin was started with the following command line:
/usr/bin/XWin -multiwindow
ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1280 h 1024
winInitializeDefaultScreens - native DPI x 96 y 96
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/mandible:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
Fatal server error:
Can't read lock file /tmp/.X0-lock
I don't think there have been any significant changes in the lockfile code
since the previous version, so this is mysterious.
Does /tmp/.X0-lock exists? Is it readable by you? ('ls -al /tmp/.X0-lock' )
Are you sure /tmp is getting mounted successfully where you expect it to be?
Have you tried '-nolock', as suggested by [1]
Can anything be determined from the 3 lines in this file beginning _XSERV
(Unable .. failed .. failed)? Do I need to change my command sequence?
The lines about inet6 are expected if you don't have IPv6 installed. If they
have just started appearing with 1.9.2, that would be odd.
BTW it's interesting (is it?) that the error message refers to 1.9.2.0 not
1.9.2-1.
XWin only reports the upstream version (1.9.2.0), not our packaging version
(the -1), for various uninteresting reasons.
I'm surprised that there are no other anguished reports to you following the
update, but I guess that's because the fault/ problem/ difficulty is mine
rather than general. ?? Any insights much appreciated.
Either that or you are the only person who uses XWin :-) I never hear from
anyone saying it just works fine, so I assume they don't exist :-)
[1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: xorg-server-1.9.2-1
On 11/8/2010 6:48 AM, Fergus wrote: PS It kills me not to copy this to cygwin at cygwin dot com which I feel will have a much wider readership and skill set amongst that readership, but anybody sinning in this regard is always referred straight to Cygwin-X. Because this is where those interested in Cygwin-X will be hanging out and looking for answers. For issues that are clearly X-related (or suspected to be so), it makes sense to query the list that supports that functionality, even if the readership is smaller than the main list. From the perspective of those with a problem, I would think there would be a preference for quality (of responses from this list) vs quantity (of eyes on some other list). And I'm sure those on the main list who aren't interested in X issues much prefer the lack of X traffic (and vice-versa). If you look in the email archives for discussions about merging the lists, you'll see these two points were well represented in the feedback, if my memory serves. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.9.2-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.9.2-1 *** xorg-server-dmx-1.9.2-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes, this contains the following cygwin-specific changes since 1.9.0-2: * Rewrite of the way clipboard thread is started, which should improve clipboard robustness in XDMCP session (thanks to Michel Hummel) * Fix clipboard interaction with nxproxy (and possibly other X clients) (thanks to Roland Cassard) * Fix WM_DISPLAYCHANGE handling in windowed mode to not resize the X screen * Don't write list email address into log * Fix random DPI after resize * Implement WGL AIGLX for non-toplevel X windows WGL AIGLX = The experimental WGL AIGLX mode (activated by the XWin command line option '-wgl') which enables hardware accelerated OpenGL rendering in the X server using the native WGL OpenGL interface, should now be working well enough to be useful. I'd very much like to hear reports of success or failure with specific OpenGL applications. For remote clients, you must 'export LIBGL_ALWAYS_INDIRECT=1' before starting the client application to force indirect rendering. For local clients, the recent update of libGL1 to 7.8.2-1 makes indirect rendering the default, so no special steps are needed. Please ensure you are using the latest display drivers for your graphics hardware before reporting any visual issues with WGL. Known problems: - OpenGL windows with static contents aren't re-drawn when occluded by a native Window and then exposed. Workaround: force the window to redraw, e.g. by resizing it. - When an OpenGL window is behind a native application window which uses layered windows for translucency e.g mintty, the OpenGL rendering is drawn over the top, flickering. Apparently, if we want to avoid this, we need to do the OpenGL rendering offscreen, then transfer it our window, so this becomes most of the 'use native compositing in multiwindow mode' todo list item. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
