Re: Failed to create /tmp/.X0.lock file?
On 28/10/2010 14:09, Chris Fouts wrote: After power up, I log in on a Vista 32 machine on a non-admin account, and start XWin server via power shell by calling the startxwin.exe executable. Sometimes XWin fails to start and I get a pop up that says (paraphrase) "Failed to create /tmp/.X0.lock file" I tried using the -nolock option to no avail. How can I alleviate this? Thanks! Unfortunately, we have some bugs which prevent the X server from shutting down cleaning and removing it's lock file under some circumstances. But that should only causing problems if you are non-admin and the previous run was under a different account, which doesn't seem to be what you are saying here? Are you sure you are supplying the -nolock option correctly? The syntax for adding it to the startmenu shortcut is unfortunately rather obscure, but [1] should explain it. Are you sure you get the same error message with -nolock? Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html If that doesn't help you resolve your problem, can you supply the additional information suggested by the problem report link above? Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ [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: gvim tiny font in 1.7.7 (back again)
Jon, et al -- ...and then Jon TURNEY said... % % On 28/10/2010 02:41, David T-G wrote: % > % >...and then Jon TURNEY said... % >% ... % >% You might compare the appearance of the fonts shown by 'xfd -fa Courier' % >% and 'xfd -fn -*-courier-medium-r-*-*-*-120-*-*-*-*-*-*' to test that. % > % >I'm back with xfd loaded now. Sure enough, the two are distinctly % >different; the former is smaller than the latter, although not so tiny as % >to be invisible as in gvim. This sure sounds like a lead, though! ... % % The fonts aren't supposed to be visually identical, as they are potentially % different fonts being draw by different renderers. But the sizes should be % approximately the same. OK. That makes sense. % % Let me try asking the question a different way: Does 'xfd -fa % "Courier-10:style=Bold"' show a reasonably sized font at the same time as % gvim, with that font set, doesn't? (In which case one might conclude this % is probably a gvim bug) They are quite similar. Interestingly, however, trying Courier-18:style=Bold Courier-24 Courier-48:style=Italic all look exactly identical (and the latter nonetheless shows "Regular" at the top). When I 'select a character' they all show "width: 6" and "(font 7,2)"; the Bolds show "left 0" while the Regulars show "left 1". Could the fonts all be coming from the same source instead of being sized properly, maybe? % % I don't think this is quite the same problem as reported by Frédéric Bron, % as you don't seem to be using -resize. Ah. Definitely not. % % -- % Jon TURNEY % Volunteer Cygwin/X X Server maintainer Thanks again & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt pgpsEE7p8Aj1Z.pgp Description: PGP signature
Re: Windows 7 Aero mode issue again
On 26/10/2010 23:58, Eliot Moss wrote: Ok, here's a first email about *some* symptoms ... If I run the latest installed XWin, or this one: ftp://cygwin.com/pub/cygwinx/XWin.20101026-git-6105a1d4e1e137f0.exe.bz2 without -resize and then "sleep" and unsleep the laptop, X does not paint anything but the cursor and keyboard events do not seem to go to the (invisible) windows. I have to kill the server and all the X jobs. I will now proceed to the other tests you suggested ... Hmmm... I don't think you've mentioned this before. I assume this is a regression from 1.8.0 (before -resize was added), as we used to survive a hibernate cycle? You're probably right about earlier version being sensitive to whether -resize was given. I had forgotten about that dependency of behavior. On 27/10/2010 00:15, Eliot Moss wrote: > Ok ... the 20101026 snapshot works properly with -resize and > -engine 1 set: DWM does not go away or get complained about > if I sleep then unsleep. Yay! Good. Just to point out this isn't specific to the snapshot, though, -engine 1 should workaround the problem in all cases. I guess this confirms that it is a problem with our use of directdraw and a hibernate cycle. (as the workaround forces XWin to use the shadow GDI drawing engine rather than the shadow directdraw drawing engine) However, I can't see what is wrong with XWin's use of ddraw. We never try to draw directly to the primary surface (which is what causes DWM to be shut down), so why it thinks we are during a hibernate or resume is obscure. It would probably be a good idea to test with some other ddraw application over a hibernate, to confirm this is a problem with XWin and not with the intel video drivers, but I'm not sure what other ddraw application is similar enough to make this a valid test (The simple tests in dxdiag probably wouldn't prove anything) > I did notice one little thing: its log file seems to go to > /var/log/XWin.0.log rather than /var/log/xwin/XWin.0.log. I hadn't updated the script I use to build snapshots. Thanks for pointing this out, I've now corrected that. > I include the -logverbose 3 output for you, and the stderr. Sorry, I was a little unclear. If you are still interested in pursing this, a log without -engine 1 and with -logverbose 3 would be most helpful. If you could annotate it to show at approximately what timestamp the suspend and resume occurred, that would be even better. -- 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: Windows 7 Aero mode issue again (follow up)
A little more on the 20101026 snapshot on my Windows 7 64-bit setup ... Previous versions would sometimes cause a repaint of the entire screen, that even earlier versions did not do. (My user reaction was: "That's a weird and unnexessary screen repaint.) These repaints would sometimes end by putting some other, non-X, window on top, such as Adobe Acrobat. The 20101026 snapshot, with it less aggressive use of calls, seems to have eliminated those undesirable behaviors, while also fixing the DWM issue I was having. So, thought you'd want to know; good job! -- Eliot -- 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: gvim tiny font in 1.7.7 (back again)
On 28/10/2010 02:41, David T-G wrote: Jon, et al -- ...and then Jon TURNEY said... % % On 25/10/2010 11:25, David T-G wrote: %> ... %>Any more ideas? :-( % ... % But perhaps you mean that gvim is the only application which shows this % problem? Yup -- so far, anyway. % % You might compare the appearance of the fonts shown by 'xfd -fa Courier' % and 'xfd -fn -*-courier-medium-r-*-*-*-120-*-*-*-*-*-*' to test that. I'm back with xfd loaded now. Sure enough, the two are distinctly different; the former is smaller than the latter, although not so tiny as to be invisible as in gvim. This sure sounds like a lead, though! I am leery of posting attachments to the mailing list, so I haven't attached screen shots of the xfd layouts. In addition, I ran xlsfonts and it generated 2582 lines; that's probably more than I should paste here. Let me know what information I can provide, however. S... What do I do to make my fonts all be happy? The fonts aren't supposed to be visually identical, as they are potentially different fonts being draw by different renderers. But the sizes should be approximately the same. Let me try asking the question a different way: Does 'xfd -fa "Courier-10:style=Bold"' show a reasonably sized font at the same time as gvim, with that font set, doesn't? (In which case one might conclude this is probably a gvim bug) I don't think this is quite the same problem as reported by Frédéric Bron, as you don't seem to be using -resize. -- 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: gvim tiny font in 1.7.7 (back again)
On 28/10/2010 01:53, Frédéric Bron wrote: But perhaps you mean that gvim is the only application which shows this problem? When I have the problem, it is not only gvim but also gv for example. It seems it has to do with screen resolution change (see my previous email). Frédéric Aha. It seems we have a bug causing the DPI to be set to random values after a resize. $ xdpyinfo.exe | grep -A2 'screen #0' screen #0: dimensions:2560x1600 pixels (13107x41779 millimeters) resolution:5x1 dots per inch I've uploaded a snapshot with a fix at [1], perhaps you can test that? [1] ftp://cygwin.com/pub/cygwinx/XWin.20101028-git-edd6452650ede026.exe.bz2 -- 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/
Failed to create /tmp/.X0.lock file?
After power up, I log in on a Vista 32 machine on a non-admin account, and start XWin server via power shell by calling the startxwin.exe executable. Sometimes XWin fails to start and I get a pop up that says (paraphrase) "Failed to create /tmp/.X0.lock file" I tried using the -nolock option to no avail. How can I alleviate this? Thanks! -- 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: "Paste" from clipboard can failed (XWin bug)
2010/10/23 Jon TURNEY wrote: > > For testing purposes, do you have an example of an application which only > offers XA_STRING? I discover this problem with nxproxy.exe (from www.nomachine.com) [...] >> note: the actual timeout is set to 1 second. > > I am actually a bit concerned about the size of the timeout, it's > conceivable a remote X application could take longer than that to respond. > > However, since we are trying to do this conversion synchronously in the > clipboard thread's message pump, I'm not sure we want to block longer. Yes, I agree with you Regards, -- 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/
