Re: Some changed behaviors ...
On 7/2/2015 7:27 PM, Jon TURNEY wrote: On 04/06/2015 02:41, Eliot Moss wrote: I just updated to the latest XWin and got some different behaviors: - In my .XWinrc file I was using MINIMIZE in the STYLES. This now seems to permanently iconize a window. If I click on the icon, it briefly flahses large and then iconizes again. Thanks for reporting this. This regression seems to be a side-effect of the change I made in 1.17.1-5. If you would like to try it, I made a snapshot which hopefully fixes this without breaking anything else, but when working on this code I always get the feeling that something else is going to unravel when I pull on one of the loose ends :) ftp://cygwin.com/pub/cygwinx/x86/XWin.20150702-git-b872b0571855112c.exe.bz2 ftp://cygwin.com/pub/cygwinx/x86_64/XWin.20150702-git-b872b0571855112c.exe.bz2 I run 32-bit, so I tested only that, but MINIMIZE in STYLE now works! Hooray! This is the first time that emacs has properly minimized on startup and properly un-minimized when first clicked! - When using -geometry (with xemacs in particular), the height of the screen seems different, and if I change the geometry height by 1, the height of the window does not change by 1 -- it either doesn't change, or changes by more than one. Hmmm I think that the size of the emacs window is (or at least, should be) constrained so it can only change by a whole character? Can you give a bit more detail e.g. what version you were using previously, the geometry you are requesting and the actual size of the window as reported by xwininfo? Yes, the first two geometry measures for emacs are indeed in terms of characters. Here is output when I request 110x64+0+0 on my laptop xwininfo: Window id: 0xe00054 xemacs Absolute upper-left X: 9 Absolute upper-left Y: 38 Relative upper-left X: 9 Relative upper-left Y: 38 Width: 1103 Height: 983 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +9+38 -808+38 -808-59 +9-59 -geometry 108x64+9+38 This is from requesting 110x65+0+0: xwininfo: Window id: 0xe00054 xemacs Absolute upper-left X: 9 Absolute upper-left Y: 38 Relative upper-left X: 9 Relative upper-left Y: 38 Width: 1103 Height: 983 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +9+38 -808+38 -808-59 +9-59 -geometry 108x64+9+38 And this from 110x66+0+0: xwininfo: Window id: 0xe00054 xemacs Absolute upper-left X: 9 Absolute upper-left Y: 38 Relative upper-left X: 9 Relative upper-left Y: 38 Width: 1103 Height: 983 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +9+38 -808+38 -808-59 +9-59 -geometry 108x64+9+38 I verified that I was changing the right file by adjusting the width to 80 instead of 110, and it changed. If I take that 80x66+0+0 window and drag the bottom down to add a line, we get this: xwininfo: Window id: 0xe00054 xemacs Absolute upper-left X: 9 Absolute upper-left Y: 38 Relative upper-left X: 9 Relative upper-left Y: 38 Width: 803 Height: 998 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +9+38 -1108+38 -1108-44 +9-44 -geometry 78x65+9+38 (Curious that the 80 was not obeyed, huh? There's plenty of room in that dimension.) The vertical dimension may get short- changed because it pushes right up against the icon bar at the bottom of the screen. I guess emacs does its own mystical adjustment of the parameters, given available font sizes, etc. I don't think this is a Cygwin-X specific thing, but if you have any additional thoughts, they're welcome! Thanks, as always, for your work on X for cygwin! 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/
Some changed behaviors ...
Dear Jon (et al.) -- I just updated to the latest XWin and got some different behaviors: - In my .XWinrc file I was using MINIMIZE in the STYLES. This now seems to permanently iconize a window. If I click on the icon, it briefly flahses large and then iconizes again. - When using -geometry (with xemacs in particular), the height of the screen seems different, and if I change the geometry height by 1, the height of the window does not change by 1 -- it either doesn't change, or changes by more than one. In the process of playing with this I solved a long-standing mystery to me: -iconic never worked for me on xemacs. It turns out that it works if I place it *first* among the command line flags, but it does not work when placed last. Maybe -geometry overrides it? Anyway, it strikes me as odd, but at least it works now. My workaround for the MINIMIZE thing was to use -iconic on the particular windows instead -- it does what I want anyway. But I thought you'd want to know about MINIMIZE being weird. Not sure what happened with the height thing ... Regards -- Eliot Moss -- 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: weird xemacs crash
On 2/18/2015 8:14 AM, Jon TURNEY wrote: On 17/02/2015 20:35, Eliot Moss wrote: Dear Cygwin X -- I have a situation where cygwin xemacs, both 21.4.23-1 and the newer -2 crash when trying to open a file with certain content. (I copied the file; opening it under the other name fails too.) It's a relatively small file, some .c source. The characters used are all reasonable ASCII: newline plus space through 175 octal. The length is 2601 bytes. But are you sure this isn't the problem mentioned in [1]? [1] https://cygwin.com/ml/cygwin/2015-02/msg00339.html The work-around suggested there does seem to prevent the crash. I could not tell that that was what it was because it fails so quickly I could not see anything. Looking forward to the fixed 21.4! Thanks! 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/
weird xemacs crash
Dear Cygwin X -- I have a situation where cygwin xemacs, both 21.4.23-1 and the newer -2 crash when trying to open a file with certain content. (I copied the file; opening it under the other name fails too.) It's a relatively small file, some .c source. The characters used are all reasonable ASCII: newline plus space through 175 octal. The length is 2601 bytes. Here is the stackdump: Stack trace: Frame Function Args 002899C4 61030F12 (02E0, EA60, 00A4, 00289A24) 00289AE4 610E468A (6119EE10, , 00289B18, ) What's the next step? Regards -- EM -- 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: Automatic X server startup
On 5/27/2014 8:52 AM, Pavel Fedin wrote: Hello! Recently i have started using Insight (https://sourceware.org/insight/) under Cygwin/X. Everything is quite good except one thing. I remember once upon a time i worked on MacOS X. There, X server starts up automatically if there is some program requesting it. On Cygwin i still have to run it by hands. Is is possible to set up autostart of the X server ? May be i just don't know how to do it ? I use the xlaunch program and have it set to start when I log in. It can start programs for you, if you want anything started from the beginning, but you can have it run no programs and simply wait for any X programs to come along. If you run xlaunch with no arguments it pops up a short interactive GUI for setting up the configuration. And of course man xlaunch will tell you more. Best wishes -- Eliot Moss -- 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: XWin on taskbar
On 8/6/2012 8:04 AM, Jon TURNEY wrote: On 03/08/2012 15:42, Eliot Moss wrote: The patched run.exe seems to work for me as well. Thanks for testing. I am still uncertain if you are seeing the same, similar or a different problem to me, though, so it would be helpful if you could confirm or deny if the extra taskbar button you see with the unpatched run behaves in the same way as I described. Sorry I did not describe more completely, but yes, that's the exact behavior I see also. Regards -- EM -- 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: XWin on taskbar
The patched run.exe seems to work for me as well. Thanks!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: XWin on taskbar
On 7/31/2012 10:16 PM, Ross Boulet wrote: I have a desktop running Windows 7 Professional and a laptop running Windows 7 Home Premium. I have updated Cygwin on both to make sure everything is current. I start X on both the same way using the shortcut installed by Cygwin. On both machines, I have a .startxwinrc that starts two rxvt windows. The difference is, on the desktop, items appear in the Windows taskbar for the two rxvt windows only - as I expect. But on the laptop, another taskbar item for the XWin server appears. It's not a huge deal, but it adds a little clutter to the taskbar I would rather not see. Any thoughts as to why this is happening? I am not sure the reason is known; a race condition has been mentioned as a possibility. I solved this by using xlaunch, and starting that with cygwin's run program. Regards -- Eliot Moss -- 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: AW: possible to run XWin as windows service?
On 7/28/2012 8:15 AM, Paul Maier wrote: Can you recommend me how to start the X Server without getting a task bar entry? The cygwin program run.exe is designed to do just that. It's what I use for this purpose :-) ... Eliot Moss -- 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: AW: possible to run XWin as windows service?
On 7/28/2012 8:57 AM, Eliot Moss wrote: On 7/28/2012 8:15 AM, Paul Maier wrote: Can you recommend me how to start the X Server without getting a task bar entry? The cygwin program run.exe is designed to do just that. It's what I use for this purpose :-) ... ... and I just tried it in the Startup folder and it works fine. Here is the Target of the shortcut: C:\cygwin\bin\run.exe /usr/bin/xlaunch.exe -p /usr/bin -run ***cygwin-path-to***/config.xlaunch I find the -p makes it easier to write the various files, since it allows cygwin programs to be found. The Start in is: C:\cygwin\bin My cygwin installation is in C:\cygwin Regards -- Eliot Moss -- 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: AW: AW: possible to run XWin as windows service?
On 7/28/2012 9:08 AM, Paul Maier wrote: The cygwin program run.exe is designed to do just that. It's what I use for this purpose :-) ... I was using run.exe too. run.exe used to hide the window and the task bar entry. But since my upgrade from Cygwin 1.7.9 to 1.7.15, run.exe only hides the window but not the task bar entry, when invoked from the Startup menu in some cases. This seems buggy, see my thread: http://cygwin.com/ml/cygwin/2012-07/msg00473.html But I don't have the impression that a developer accepted this as bug. Do you have a suggestion how to avoid this situation? I used to have difficulty like that with startxwin, but it does not happen any more for me with xlaunch. It did look like a race condition or something ... 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: Issue with XWin under xlaunch
Ok, I can see that perhaps in some ways I was being foolish and could have figured out more of this myself. But here's something interesting. I tried this: - Pin to Start Menu of the supplied XLaunch short cut - Edit to change the command to: /usr/bin/xlaunch.exe -run /home/Eliot/config.xlaunch (since I want to start things, not build/edit a config file) The full line in the shortcut is: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xlaunch.exe -run /home/Eliot/config.xlaunch This works, without putting in the explicit /usr/bin/ everywhere in the .XWinrc file. BUT: I get the extra icon I don't want, this time for XLaunch rather than for StartXWin. So the extra icon seems to have to do with the bash that run.exe is starting and the fact that the bash is still there as parent to the still-running XLaunch (or StartXWin). Perhaps it is because the bash does not start the program under it in the same way that run.exe does? Regards -- EM -- 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: Issue with XWin under xlaunch
Ok -- by perusing the log I figured it out ... In the past, .XWinrc names of files such as xterm worked just fine. Apparently something changed about the PATH used, and xterm was not being found. When I write /usr/bin/xterm, it starts up. You can see the first case and the second in the attached log file. So, I think xlaunch is ok, but this was a surprising difference :-) ... Regards -- Eliot Moss InitConnectionLimits: MaxClients = 255 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.12.0.0 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Snapshot: 20120423-git-638383315ef51e46 XWin was started with the following command line: XWin :0 -multiwindow -clipboard -nowgl -ac -unixkill -clipboard -resize -engine 1 -emulate3buttons 100 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1280 h 800 winInitializeScreenDefaults - native DPI x 96 y 96 ddxProcessArgument - arg: :0 ddxProcessArgument - arg: -multiwindow ddxProcessArgument - arg: -clipboard ddxProcessArgument - arg: -nowgl ddxProcessArgument - arg: -ac ddxProcessArgument - arg: -unixkill ddxProcessArgument - arg: -clipboard ddxProcessArgument - arg: -resize ddxProcessArgument - arg: -engine ddxProcessArgument - arg: -emulate3buttons [727789.342] (II) xorg.conf is not supported [727789.342] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [727789.342] LoadPreferences: Loading /home/Eliot/.XWinrc [727789.358] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD [727789.358] winDetectSupportedEngines - Windows NT, allowing PrimaryDD [727789.358] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [727789.358] winDetectSupportedEngines - Returning, supported engines 001f [727789.358] winSetEngine - Multi Window or Rootless = ShadowGDI [727789.358] winScreenInit - Using Windows display depth of 32 bits per pixel [727789.389] winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 800 depth: 32 [727789.389] winFinishScreenInitFB - Masks: 00ff ff00 00ff [727789.389] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [727789.389] winInitMultiWindowWM - Calling pthread_mutex_lock () [727789.389] winMultiWindowXMsgProc - Calling pthread_mutex_lock () [727789.389] MIT-SHM extension disabled due to lack of kernel support [727789.405] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [727789.436] (II) AIGLX: Loaded and initialized swrast [727789.436] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [727789.436] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [727789.514] winPositionWindowMultiWindow: (x, y) = (0, 0) [727789.514]immediately return since hWnd is NULL [727789.514] winMapWindowMultiWindow - pWin: 800bb6c0 [727789.514] winUpdateWindowsWindow [727789.529] System: `/usr/bin/xkbcomp -w 1 -R/usr/share/X11/xkb -xkm /cygdrive/c/Users/Eliot/AppData/Local/Temp/xkb_J7a79Q -em1 The XKEYBOARD keymap compiler (xkbcomp) reports: -emp -eml Errors from xkbcomp are not fatal to the X server /var/lib/xkb/server-0.xkm' [727789.670] Loaded XKB keymap /var/lib/xkb/server-0.xkm, defined=0x7f [727789.670] winPointerWarpCursor - Discarding first warp: 640 400 [727789.670] (dix) initialising device 6 [727789.670] (--) 8 mouse buttons found [727789.670] (dix) initialising device 7 [727789.670] (--) Setting autorepeat to delay=500, rate=31 [727789.670] (--) Windows keyboard layout: 0409 (0409) US, type 4 [727789.670] (--) Found matching XKB configuration English (USA) [727789.670] (--) Model = pc105 Layout = us Variant = none Options = none [727789.670] Rules = base Model = pc105 Layout = us Variant = none Options = none [727789.670] (dix) enabling device 6 [727789.670] (dix) enabling device 7 [727789.670] client(0): Reserved pid(1). [727789.670] client(0): Reserved cmdname(XWin) and cmdargs(:0 -multiwindow -clipboard -nowgl -ac -unixkill -clipboard -resize -engine 1 -emulate3buttons 100). [727789.670] winBlockHandler - pthread_mutex_unlock() [727789.670] winInitMultiWindowWM - pthread_mutex_lock () returned. [727789.670] winInitMultiWindowWM - pthread_mutex_unlock () returned. [727789.670] winInitMultiWindowWM - DISPLAY=:0.0 [727789.670] client(20): Reserved pid(-1). [727789.670] client(20): Reserved cmdname(NULL) and cmdargs(NULL). [727789.670] AllocNewConnection: client index = 1, socket fd = 7 [727789.670] winMultiWindowXMsgProc - pthread_mutex_lock () returned. [727789.670] winMultiWindowXMsgProc - pthread_mutex_unlock () returned. [727789.670] winProcEstablishConnection - winInitClipboard returned. [727789.670] winMultiWindowXMsgProc - DISPLAY=:0.0 [727789.670] winClipboardProc - DISPLAY=:0.0 [727789.670] winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. [727789.670] client(40): Reserved pid
Re: Issue with XWin under xlaunch
On 4/23/2012 12:41 PM, Eliot Moss wrote: Ok -- by perusing the log I figured it out ... In the past, .XWinrc names of files such as xterm worked just fine. Apparently something changed about the PATH used, and xterm was not being found. When I write /usr/bin/xterm, it starts up. You can see the first case and the second in the attached log file. So, I think xlaunch is ok, but this was a surprising difference :-) ... Regards -- Eliot Moss PS -- I can confirm that adding /usr/bin solves the problem with the current released XWin.exe as well as with the 20120423 snapshot you asked me to test. E -- 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: Taskbar appearance changes between xorg-server 11 series and 12.0 series (more)
On 4/18/2012 4:13 AM, Eliot Moss wrote: On 4/17/2012 7:51 AM, Jon TURNEY wrote: On 11/04/2012 11:39, Eliot Moss wrote: Thank you for following up, Jon! The title of the window in question is StartXWin. It has no perceivable content - I cannot de-iconize it. Its only real evidence on the screen is the task bar icon. I'm not sure whether I've passed on the sequence of things that happens in terms of what is visible: 1) As StartXWin starts, the screen flashes briefly, a common artifact of run.exe. 2) Then the icon is *not* visible. 3) xorg-server starts and displays its icon, and the StartXWin icon appears. I am not sure whether there is a perceivable ordering here. I'll perhaps try it a few times to see. This suggests that it is something about xorg-server starting and trying to decide which icons to display. IIRC, the StartXWin icon appears before my xterm icons do, but then STartXWin is already running, and the xterms get fired off by the .startxwinrc file. Best -- 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: Taskbar appearance changes between xorg-server 11 series and 12.0 series (more)
On 4/19/2012 6:01 AM, Eliot Moss wrote: On 4/18/2012 4:13 AM, Eliot Moss wrote: On 4/17/2012 7:51 AM, Jon TURNEY wrote: On 11/04/2012 11:39, Eliot Moss wrote: 1) As StartXWin starts, the screen flashes briefly, a common artifact of run.exe. 2) Then the icon is *not* visible. 3) xorg-server starts and displays its icon, and the StartXWin icon appears. I am not sure whether there is a perceivable ordering here. I'll perhaps try it a few times to see. I tried some more: The StartXWin and xorg-server icons come up simultaneously as far as my eye perceives. xterm and xemacs icons, for jobs started by startxwin, come up later. Once those things finish that StartXwin started, the StartXWin icon remains, *until* I right click the xorg-server icon to get its menu -- then the StartXWin icon goes away (presumably xorg-server is just then perceiving the termination of StartXWin). In hope that these various details are helpful in narrowing down the location in the code that may be at issue -- 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: Taskbar appearance changes between xorg-server 11 series and 12.0 series (more)
On 4/17/2012 7:51 AM, Jon TURNEY wrote: On 11/04/2012 11:39, Eliot Moss wrote: I'm still not entirely sure what process in running in this window you complain of. Can you be say what the title and contents of this window are? Thank you for following up, Jon! The title of the window in question is StartXWin. It has no perceivable content - I cannot de-iconize it. Its only real evidence on the screen is the task bar icon. I'm also not sure if this problem is related to he X server at all. Can you try creating a shortcut which runs the following command, for example, and see if the bash window is always successfully hidden? C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c sleep 10 I see no window (well, it flashes for a brief moment) and no icon. The bash runs -- I can see it in the task manager, and then it goes away after the appointed 10 seconds. My StartXWin shortcut has: Shortcut panel: target: C:\cygwin\bin\run.exe /bin/bash -l -c /bin/startxwin -- -unixkill -clipboard -multimonitors -resize -engine 1 -emulate3buttons 100 -wm -auth /home/Eliot/.Xauthority Start in: C:\cygwin\bin Shortcut key: none Run: Normal window Comment: blank Advanced...: Run as admin not checked General panel: nothing interesting Compatibility panel: nothing checked Security panel: nothing adjusted Other panels have nothing adjustable This is starting to look like some kind of race as xorg-server is starting .. Regards -- 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/
Initial xemacs iconization (was Re: Taskbar appearance changes between xorg-server 11 series and 12.0 series)
In the end, I was able to address my xemacs initial window appearance
under cygwin xfree in this way:
1) First, xemacs does not handle -iconic or the iconized resource
properly. I found it best not to set them.
2) The command line -name argument will override all the X resources,
so if not really what I wanted (I'd have to create a whole new
set of settings -- might be useful for some users or under other
circumstances).
3) The window name / title argument was what I ended up using, thus:
xemacs -T xemacs
Since the default class name for xemacs windows is emacs, I can match
all windows in .XWinrc using emacs, and thus minimize them all using:
STYLES { emacs MINIMIZE }
If I want to minimize just the one window created in (3) above, I can
write:
STYLES { xemacs MINIMIZE }
It's all logical in its own idiosyncratic way, I suppose ... 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: Taskbar appearance changes between xorg-server 11 series and 12.0 series (more)
Dear Jon (et al.): Here's an interesting new bit of evidence. When playing around with xlaunch configurations and such, I ran startxwin several times this morning. ONCE, X came up without the iconized StartXWin window (i.e., things displayed as they used to before I upgraded xorg-server). This makes me suspect that there may be some kind of timing-related behavior. Perhaps the relevant code did not change between releases, but other changes affected relative timing of various actions, exposing a latent bug or race condition. I am happy to switch the xlaunch, though, if the separate issue with XWin when started under xlaunch can be resolved. Regards, and thanks again for your efforts in maintaining this complex beast! Eliot Moss -- 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: Taskbar appearance changes between xorg-server 11 series and 12.0 series
All I can really say is that it works for me. If run isn't doing it's job for you, I don't know why. You might like to take a look at using the xlaunch package to start your Xserver and see if that behaves any better. Ok ... Does this suggest to you any other way that might work to get an iconified xemacs from the .startxwinrc file? We seem to be talking past each other here. The .XWinrc you attached does not specify a style for the 'emacs' class. Yes; I changed it, and was reporting on the changed .XWinrc. Adding 'emacs MINIMIZE' seems to work for me (although it does appear that the window is created normal and then minimized, which a bit ugly, but that's a consequence of the order we do things at window creation time) Right, but this affects only windows launched manually from the XWin menu, not ones launched from .startxwinrc. Maybe xlaunch can help with both issues :-) ... I'll look into it ... Thanks!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: [ANNOUNCEMENT] Updated: xorg-server-1.12.0-3 (TEST)
Thank you, Jon. I am having more success in getting my initial windows looking the way I think they should when I use xlaunch. However, at present on my system xlaunch has one show stopper: When I start XWin with it, XWin cannot start any items from the XWin menu (the one set up by .XWinrc). I click and nothing appears to happen. The Exit button (etc.) are active. Regards -- 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: Taskbar appearance changes between xorg-server 11 series and 12.0 series
On 4/7/2012 1:45 PM, Jon TURNEY wrote: On 07/04/2012 17:45, Eliot Moss wrote: I'm not sure if you are labouring under a misapprehension due to poor documentation, or reporting a bug here. The STYLE directive adjusts the window styling of all windows which match the specified class or window name, it shouldn't matter how the application which created that window was started, be it from the XWin menu, from ~/.startxwinrc or from a terminal. If it does matter how the application was started, then that is a bug. I think I was confused. I had tried to apply STYLE MINIMIZE based on a misunderstanding of how xemacs named its windows. When I use STYLE emacs MINIMIZE, it matches the window name and seems to work all the time. Of course this means that manually launched ones also start minimized, which wasn't my intent, but is livable. It does seem that xemacs is deeply confused about this whole how-to-start thing, as its FAQ observes :-) ... Thanks -- E -- 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: Taskbar appearance changes between xorg-server 11 series and 12.0 series
On 4/6/2012 1:01 PM, Jon TURNEY wrote: On 05/04/2012 16:54, Eliot Moss wrote: Something seems to have changed between the last 1.11 release and the 1.12.0 (up through the 1.12.0-2 release made yesterday). The window for StartXWin, which is minimized, did not previously result in an X icon in the taskbar, but now does, and it is distinct from the stack of X icons for my several launched xterms. I feel it is clutter and want to suppress it, but I don't know how at this point. I guess the window you are seeing is the terminal window in which bash is being run? It's the job of the run command to hide that window, and why it should suddenly stop doing so when the XWin at the bottom of the process tree changes, I have no idea. Yes, which is why I, too, was surprised. This might perhaps be related to a bug in cygwin 1.7.12 where cygwin executables were wrongly handled as native, non-cygwin executables? I just installed 1.7.13, and the behavior is still there. It goes away when something completes, which happens when all the windows started by .startxwinrc are gone. If I kill it, then all those initial windows die. Perhaps this is all normal, *except* that the run window is displayed. Separately, going from 1.12.0-1 to 1.12.0-2 changed my xemacs icon, to one that is nearly transparent (there's something there, but very hard to discern). In the past xemacs gave its own icon (which I could never find or override). Thanks for pointing this out. I'd introduced a couple of bugs into the fallback icon conversion code for a bitmap pointed to by WM_HINTS (which is only used when a NET_WM_ICON property isn't present) I've applied a couple of fixes, so hopefully this works better now. I've uploaded a snapshot at [2]. Perhaps you could try that out and see if that improves things for you? Yes! Now the xemacs icon is back to the way it used to be. I suspect that the 'XE' icon from /usr/share/xemacs-21.4.22/etc/xemacs-icon.xpm is baked into the Xemacs executable. If Xemacs itself doesn't provide a way to change it, you could override it for multiwindow mode by using the ICONS directive in XWinrc. Maybe; if I find one I like :-) ... These various commands / files all seem to be seen and used. And by the way, the xemacs1 MINIMIZE does not seem to work -- it always starts maximized and I have to minimize it manually. Hints on that? Using -name to set the xemacs resource name does not set the window class name, apparently by design [1], so this style directive will not match the window title or window class name of your xemacs window. Fortunately, you could probably achieve the same effect by adding the '-iconic' command line option to the xemacs invocation. Actually, -iconic does not work; neither does it work to set the iconic resource to true. Seems to be an xemacs thing. In fact, here is a quote from the FAQ: Ugh, this stuff is such an incredible mess that I've about given up getting it to work. The principal problem is numerous window-manager bugs... However, I find that the .XWinrc MINIMIZE style *does* work ... but of course only for windows I create later. And the class name is emacs, not xemacs, hence a STYLE entry of: emacs MINIMIZE ... Does this suggest to you any other way that might work to get an iconified xemacs from the .startxwinrc file? On 05/04/2012 17:11, Eliot Moss wrote: On xorg-server 1.12.0-2, doing a reload of .XWinrc via the .XWinrc menu cases an exception that kills the X server. I does put up an error window saying what happened (a segmentation fault). This was also related to the icon conversion changes and should be fixed in the latest snapshot. That is indeed now fixed. Thanks for all the fixes! E [1] http://www.nada.kth.se/cgi-bin/info?%28xemacs-faq.info%29Q3.1.7 [2] ftp://cygwin.com/pub/cygwinx/XWin.20120406-git-b309f093d6e90201.exe.bz2 -- 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/
Taskbar appearance changes between xorg-server 11 series and 12.0 series
Dear Jon (et al.) --
Something seems to have changed between the last 1.11 release and
the 1.12.0 (up through the 1.12.0-2 release made yesterday).
The window for StartXWin, which is minimized, did not previously
result in an X icon in the taskbar, but now does, and it is
distinct from the stack of X icons for my several launched
xterms. I feel it is clutter and want to suppress it, but I
don't know how at this point.
Separately, going from 1.12.0-1 to 1.12.0-2 changed my xemacs
icon, to one that is nearly transparent (there's something
there, but very hard to discern). In the past xemacs gave
its own icon (which I could never find or override).
Here are possibly relevant facts about my setup:
1) How I start things: StartWXin is a Windows short cut, set to run as a
Normal Window, started from directory C:\cygwin\bin, with this command
(Target):
C:\cygwin\bin\run.exe /bin/bash -l -c /bin/startxwin -- -unixkill -clipboard
-multimonitors -resize -engine 1 -emulate3buttons 100 -wm -auth
/home/Eliot/.Xauthority
2) My .startxwinrc file contains:
#!/bin/bash
xrdb -merge ${HOME}/.Xdefaults
xmodmap ${HOME}/.Xmodmap
UC=${USER} console
xterm +tb -geometry 110x43+4+0 -T ${USER} -n ${USER} -name ${USER} -bg
rgbi:.0/.2/.2-ls
xterm +tb -geometry 110x43-10+0 -T ${UC} -n ${UC} -name ${UC} -bg
rgbi:.5/.0/.1-ls
xterm +tb -maximized-T task -n task -name task -bg rgbi:.05/.05/.05 -ls
-e rlwrap -a -- task shell
xemacs -T xemacs-n xemacs-name xemacs1
3) My .XWinrc contains:
MENU systray {
elnux1EXEC xterm -display %display% -ls -title elnux1-bg rgbi:.1/.10/.1 -e /usr/bin/ssh
m...@elnux1.cs.umass.edu
elnux7EXEC xterm -display %display% -ls -title elnux7-bg rgbi:.1/.10/.1 -e /usr/bin/ssh
m...@elnux7.cs.umass.edu
roc EXEC xterm -display %display% -ls -title roc -bg rgbi:.2/.20/.0 -e /usr/bin/ssh
m...@roc.cs.umass.edu
swarm EXEC xterm -display %display% -ls -title swarm -bg rgbi:.0/.20/.0 -geometry
120x47+0+0 -e /usr/bin/ssh m...@swarm.cs.umass.edu
deepgreen EXEC xterm -display %display% -ls -title deepgreen -bg rgbi:.0/.03/.0 -e /usr/bin/ssh
m...@deepgreen.cs.umass.edu
balderEXEC xterm -display %display% -ls -title balder-bg rgbi:.2/.00/.0 -e /usr/bin/ssh
m...@balder.cs.umass.edu
SEPARATOR
console EXEC xterm -display %display% +tb -geometry 110x43-10+0 -T 'Eliot console' -n 'Eliot
console' -name 'Eliot console' -bg rgbi:.5/.0/.1 -ls
login EXEC xterm -display %display% +tb -geometry 110x43+4+0 -T 'Eliot' -n 'Eliot'
-name 'Eliot' -bg rgbi:.0/.2/.2 -ls
taskEXEC xterm -display %display% -ls -title task -bg rgbi:.05/.05/.05 -maximized -e rlwrap
-a -- task shell
xterm EXEC xterm -display %display% -ls -title xterm
SEPARATOR
xemacs EXEC xemacs
xpdfEXEC xpdf
SEPARATOR
Reload .XWinrc RELOAD
}
ROOTMENU systray
STYLES {
console MINIMIZE
Eliot MINIMIZE
xemacs1 MINIMIZE
}
==
These various commands / files all seem to be seen and used. And by the way,
the xemacs1 MINIMIZE does not seem to work -- it always starts maximized and I
have to minimize it manually. Hints on that?
Regards -- Eliot Moss
--
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/
Reload .XWinrc kills X server
Dear Jon (et al.) -- On xorg-server 1.12.0-2, doing a reload of .XWinrc via the .XWinrc menu cases an exception that kills the X server. I does put up an error window saying what happened (a segmentation fault). Regards -- Eliot Moss -- 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: Default settings for XTerm
I think that's cutomization: -color (note the dash), but yes :-) ... Eliot Moss -- 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: Default settings for XTerm
On 10/31/2011 3:45 PM, Eliot Moss wrote: I think that's customization: -color (note the dash), but yes :-) ... Eliot Moss Sheesh, I also typed it wrong, corrected above! EM -- 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: A question about program icons ...
Thanks, Jon, for the additional explanations! 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: A question about program icons ...
On 7/29/2011 3:16 AM, Csaba Raduly wrote: Hi Eliot, On Thu, Jul 28, 2011 at 5:47 PM, Eliot Moss wrote: Recently I started using startxwin and .XWinrc and am getting used to -multiwindow mode. Something I have been wondering is where the program icons actually come from. For example, I cannot for the life of me find the icons used for xemacs (has a little red XE in it) or xpdf (black background, stylized red X and stylized white pdf). Right-click, Properties, Change Icon... will bring up a dialog which allows you to change the source of the icon, with the current source filled in. Dear Csaba -- I appreciate your effort to be helpful. In this case I already know how to change an icon that is directly associated with a program file or shortcut. However, these programs do not seem to have an icon associated in the usual way, and even their normal icon is not what cygwin-xfree displays in the toolbar. For example, xemacs from the Windows dialog does not show any icon or offer a way to set one. The shortcut to it that is in the Cygwin X menu does associate an icon and allow you to change it, but the icon that is in the toolbar is not one of the ones offered. The startxwin/.XWinrc mechanisms are looking somewhere else, and I was asking where that is. Even the default files that build the menus and such do not mention the xemacs and xpdf icons that I actually see ... Regards -- 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: A question about program icons ...
Thanks for the tip about .xpm files! -- 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/
A question about program icons ...
Recently I started using startxwin and .XWinrc and am getting used to -multiwindow mode. Something I have been wondering is where the program icons actually come from. For example, I cannot for the life of me find the icons used for xemacs (has a little red XE in it) or xpdf (black background, stylized red X and stylized white pdf). Any hints? I've searched the usual places, and they don't seem to be mentioned in the start menu builder either ... Regards -- Eliot Moss -- 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: how to enable shared memory?
On 7/23/2011 6:25 PM, Ekkard Gerlach wrote: I found some stuff on my own: searching missing cygrunsrv with google leaded me to a not installed package cygrunsrv. I started setup.exe again, selected the Admin - cygrunsrv and installed the package. Now cygserver-config runs, asked me whether to start cygserver as service. I don't know why, I want to enabel shared memory only. While I am not knowledgeable in the details, I can (I hope) clear up that point: cygwin shm support requires a background server to help in the implementation. Regard -- Eliot Moss -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.10.3-1
On 7/20/2011 11:28 AM, Jon TURNEY wrote: On 19/07/2011 18:17, Eliot Moss wrote: On 7/19/2011 10:24 AM, Jon TURNEY wrote: The start menu shortcut for starting XWin in multiwindow mode installed by the xinit package goes to some lengths to avoid lingering unnecessary windows whilst setting up the correct environment, so if you need a custom command line to invoke XWin, you should use that as a template. Obviously, if you are running XWin in windowed mode, you will have one taskbar item corresponding to the XWin window :-) I am wondering if you're referring to the startxdcp.bat file or startxwin.exe (or maybe something else). My .bat file is patterned after a standard one, and my shortcut points to run.exe to run it. I suspect you mean something else :-) ... Thanks for your patience ... 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: [ANNOUNCEMENT] Updated: xorg-server-1.10.3-1
On 7/19/2011 10:24 AM, Jon TURNEY wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-1.10.3-1 *** xorg-server-dmx-1.10.3-1 ... * On Windows 7, use new taskbar APIs so X windows are grouped on the taskbar more correctly (Thanks to Tobias Häußler) I have a wondering about whether this accomplishes something I have been desiring ... apparently not, but perhaps I have simply not set things up right. - I start XWin via run.exe invoking a startxwin.bat file. This avoid a needless console window. - I have created a Windows shortcut for this, and given it the XWin.exe icon by pointing the shortcut's icon selection to XWin.exe. - I get a *separate* instance of the XWin icon when XWin starts up, that is, separate from the run.exe one. What I would *like* is for the running instance of XWin.exe to be considered as having the same icon, so that I don't get two instances, one for the run.exe shortcut and another for the running XWin. Is there another/better way I can arrange this? Regards -- Eliot Moss -- 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: X doesn't start for user without admin rights
I wonder if the issue is that the less privileged user cannot create a log file, socket, or similar thing is one of the usual places. This would look like failure to create a lock file because another user has it open. Either way, creating the lock file fails. Regards -- Eliot Moss Sent via BlackBerry -- 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: R: Emacs silence
In my first e-mail I failed to attached the Xwin log and the cygcheck output. I have just tried that and 209.132.180.131 bounced it as spam. How should I make those available? Nigel The log files have an email address in them. Look for the @ character. Delete the email or rewrite it to read foo at bar instead of f...@bar. I have suggested that the logs output the email that way, but that suggestion has not been taken up yet ... Eliot Moss -- 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: Windows 7 Aero mode issue again
On 10/26/2010 9:09 AM, Jon TURNEY wrote: On 24/10/2010 00:00, Eliot Moss wrote: Dear Jon -- The latest xorg and dlls, posted in the last day, consistently cause my Window 7 64-bit laptop to drop out of Aero mode if I put it in sleep mode and then wake it up. Here are the .log file and the stderr output. Sorry, I'm not quite sure what you are telling me here. It is that you still have the same problem with 1.9.0-2 as with 1.8.2-1? (which is unfortunately unsurprising, as I haven't done anything to fix it) Yes ... but it seems that the problem *had* gone away for a while, with a version I directly downloaded that you had pointed me to ... Regards -- 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: Windows 7 Aero mode issue again
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 ... You're probably right about earlier version being sensitive to whether -resize was given. I had forgotten about that dependency of behavior. Regards -- Eliot Moss -- 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
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! 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 include the -logverbose 3 output for you, and the stderr. Regards, and thanks for continuing to work with me on this! -- Eliot Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.9.0.0 (1090) Snapshot: 20101026-git-6105a1d4e1e137f0 XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -resize -engine 1 -logverbose 3 -auth /home/Eliot/.serverauth.5448 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1280 h 800 winInitializeDefaultScreens - native DPI x 96 y 96 [597661.030] OsVendorInit - Creating default screen 0 [597661.030] winInitializeScreens - 1 [597661.030] winInitializeScreen - 0 [597661.030] winValidateArgs - Returning. [597661.030] (II) xorg.conf is not supported [597661.030] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [597661.030] LoadPreferences: /home/Eliot/.XWinrc not found [597661.030] LoadPreferences: Loading /etc/X11/system.XWinrc [597661.030] LoadPreferences: Done parsing the configuration file... [597661.030] winGetDisplay: DISPLAY=:0.0 [597661.030] winDetectSupportedEngines - Windows NT/2000/XP [597661.062] winDetectSupportedEngines - DirectDraw installed [597661.062] winDetectSupportedEngines - Allowing PrimaryDD [597661.062] winDetectSupportedEngines - DirectDraw4 installed [597661.062] winDetectSupportedEngines - Returning, supported engines 001f [597661.062] winScreenInit - dwWidth: 1280 dwHeight: 800 [597661.062] winSetEngine - Using user's preference: 1 [597661.062] winScreenInit - Using Windows display depth of 32 bits per pixel [597661.062] winCreateBoundingWindowWindowed - User w: 1280 h: 800 [597661.062] winCreateBoundingWindowWindowed - Current w: 1280 h: 800 [597661.062] winGetWorkArea - Original WorkArea: 0 0 770 1280 [597661.062] winGetWorkArea - Virtual screen is 1280 x 800 [597661.062] winGetWorkArea - Virtual screen origin is 0, 0 [597661.062] winGetWorkArea - Primary screen is 1280 x 800 [597661.062] winGetWorkArea - Adjusted WorkArea for multiple monitors: 0 0 770 1280 [597661.062] winAdjustForAutoHide - Original WorkArea: 0 0 770 1280 [597661.062] winAdjustForAutoHide - Adjusted WorkArea: 0 0 770 1280 [597661.062] winCreateBoundingWindowWindowed - WindowClient w 1264 h 732 r 1264 l 0 b 732 t 0 [597661.062] winWindowProc - WM_ACTIVATEAPP [597661.077] winWindowProc - WM_SIZE - new client area w: 1264 h: 732 [597661.077] winCreateBoundingWindowWindowed - Returning [597661.077] winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 800 depth: 32 [597661.077] winAllocateFBShadowGDI - Dibsection width: 1280 height: 800 depth: 32 size image: 4096000 [597661.077] winAllocateFBShadowGDI - Created shadow stride: 1280 [597661.077] winFinishScreenInitFB - Masks: 00ff ff00 00ff [597661.077] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [597661.077] winRandRInit () [597661.077] winCreateDefColormap - Deferring to fbCreateDefColormap () [597661.077] winFinishScreenInitFB - returning [597661.077] Screen 0 added at virtual desktop coordinate (0,0). [597661.077] winScreenInit - returning [597661.077] winGenerateAuthorization - GenerateAuthorization success! AuthDataLen: 16 AuthData: ¥ºFÕ%FU® Û#ññ [597661.077] InitOutput - Returning. [597661.077] MIT-SHM extension disabled due to lack of kernel support [597661.093] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [597661.155] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [597661.155] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [597661.171] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [597661.686] winPointerWarpCursor - Discarding first warp: 640 400 [597661.686] winSendKeyEvent: dwKey: 69, fDown: 1, nEvents 0 [597661.686] winSendKeyEvent: dwKey: 69, fDown: 0, nEvents 0 [597661.686] (--) 8 mouse buttons found [597661.686] (--) Setting autorepeat to delay=500, rate=31 [597661.686] (--) Windows keyboard layout: 0409 (0409) US, type 4 [597661.686] (--) Found matching XKB configuration English (USA) [597661.686] (--) Model = pc105 Layout = us Variant = none Options = none [597661.686] Rules = base Model = pc105 Layout = us Variant = none Options = none [597661.686] winBlockHandler - Releasing pmServerStarted [597661.686] winBlockHandler - pthread_mutex_unlock () returned [597661.701] winProcEstablishConnection - Hello [597661.966] winInitClipboard () [597661.966] winClipboardProc - Hello [597661.966] DetectUnicodeSupport - Windows NT/2000/XP [597661.966] winProcEstablishConnection - winInitClipboard returned.
Windows 7 Aero mode issue again
Dear Jon -- The latest xorg and dlls, posted in the last day, consistently cause my Window 7 64-bit laptop to drop out of Aero mode if I put it in sleep mode and then wake it up. Here are the .log file and the stderr output. Regards -- Eliot Moss Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.9.0.0 (1090) Build Date: 2010-10-12 Contact: cygwin-xfree at cygwin.com XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -resize -auth /home/Eliot/.serverauth.9752 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1280 h 800 winInitializeDefaultScreens - native DPI x 96 y 96 [337692.618] winInitializeScreens - 1 [337692.618] winInitializeScreen - 0 [337692.618] (II) xorg.conf is not supported [337692.618] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [337692.618] LoadPreferences: /home/Eliot/.XWinrc not found [337692.618] LoadPreferences: Loading /etc/X11/system.XWinrc [337692.618] LoadPreferences: Done parsing the configuration file... [337692.618] winGetDisplay: DISPLAY=:0.0 [337692.618] winDetectSupportedEngines - Windows NT/2000/XP [337692.634] winDetectSupportedEngines - DirectDraw installed [337692.634] winDetectSupportedEngines - Allowing PrimaryDD [337692.634] winDetectSupportedEngines - DirectDraw4 installed [337692.649] winDetectSupportedEngines - Returning, supported engines 001f [337692.649] winSetEngine - Using Shadow DirectDraw NonLocking [337692.649] winScreenInit - Using Windows display depth of 32 bits per pixel [337692.665] winWindowProc - WM_SIZE - new client area w: 1264 h: 732 [337692.681] winFinishScreenInitFB - Masks: 00ff ff00 00ff [337692.681] Screen 0 added at virtual desktop coordinate (0,0). [337692.681] MIT-SHM extension disabled due to lack of kernel support [337692.696] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [337692.774] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [337692.774] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [337692.790] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [337693.305] winPointerWarpCursor - Discarding first warp: 640 400 [337693.305] (--) 8 mouse buttons found [337693.305] (--) Setting autorepeat to delay=500, rate=31 [337693.305] (--) Windows keyboard layout: 0409 (0409) US, type 4 [337693.305] (--) Found matching XKB configuration English (USA) [337693.305] (--) Model = pc105 Layout = us Variant = none Options = none [337693.305] Rules = base Model = pc105 Layout = us Variant = none Options = none [337693.320] winProcEstablishConnection - Hello [337693.554] winInitClipboard () [337693.570] winClipboardProc - Hello [337693.570] DetectUnicodeSupport - Windows NT/2000/XP [337693.570] winProcEstablishConnection - winInitClipboard returned. [337693.585] winGetDisplay: DISPLAY=:0.0 [337693.585] winClipboardProc - DISPLAY=:0.0 [337693.585] winClipboardProc - XOpenDisplay () returned and successfully opened the display. [337694.100] winClipboardFlushXEvents - unexpected event type 34 [337698.141] winWindowProc - WM_SIZE - new client area w: 1280 h: 748 [337750.807] winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1 [337762.117] winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1 [337774.316] winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 2 [337774.519] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [337774.628] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [337774.737] winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1 [337774.753] winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 2 [337774.768] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [337775.111] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [337775.345] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [337775.345] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [337780.369] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [337780.369] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 xauth: creating new authority file /home/Eliot/.serverauth.9752 xauth: (stdin):2: unknown command 916c7140476585e790ff94e6621730de xauth: (stdin):3: unknown command 916c7140476585e790ff94e6621730de xauth: (stdin):4: unknown command 916c7140476585e790ff94e6621730de xauth: (stdin):5: unknown command 916c7140476585e790ff94e6621730de 3 [main] XWin 7276
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 9/27/2010 10:53 AM, Jon TURNEY wrote: There is a remaining issue -- which was there before but which I had not posted about. If I Suspend/Resume, then on resumption the driver disables the Aero theme and points its finger at XWin.exe as the culprit, saying it did something incompatible with Aero. You probably know about this stuff, but here's the overall blurb anyway: I can't reproduce this, so again, it seems to be driver-specific. I presume some DirectDraw errors are still emitted over a suspend/resume cycle? Can you attach an XWin.0.log showing them? Yes, it is driver specific and at this point I have gone back to an earlier driver where it tends not to happen. I can try putting in a recent driver and capturing error message for you when I have a little chunk of time to mess with rebooting my system N times :-) .. Thanks, Jon -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
It turned out to be easy to get a log where the Aero mode got turned off after a resume. Here it is (stderr comes after it). Thanks -- Eliot Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.8.2.0 (10802000) Snapshot: 20100923-git-2172af4d1ea713f1 XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -resize -auth /home/Eliot/.serverauth.8420 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - primary monitor w 1280 h 800 winInitializeDefaultScreens - native DPI x 96 y 96 winInitializeDefaultScreens - Returning [ 6203.270] winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 [ 6203.270] (II) xorg.conf is not supported [ 6203.270] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 6203.270] LoadPreferences: /home/Eliot/.XWinrc not found [ 6203.270] LoadPreferences: Loading /etc/X11/system.XWinrc [ 6203.270] LoadPreferences: Done parsing the configuration file... [ 6203.270] winGetDisplay: DISPLAY=:0.0 [ 6203.270] winDetectSupportedEngines - Windows NT/2000/XP [ 6203.286] winDetectSupportedEngines - DirectDraw installed [ 6203.286] winDetectSupportedEngines - Allowing PrimaryDD [ 6203.286] winDetectSupportedEngines - DirectDraw4 installed [ 6203.286] winDetectSupportedEngines - Returning, supported engines 001f [ 6203.286] winSetEngine - Using Shadow DirectDraw NonLocking [ 6203.286] winScreenInit - Using Windows display depth of 32 bits per pixel [ 6203.317] winWindowProc - WM_SIZE - new client area w: 1264 h: 732 [ 6203.332] winFinishScreenInitFB - Masks: 00ff ff00 00ff [ 6203.332] Screen 0 added at virtual desktop coordinate (0,0). [ 6203.332] MIT-SHM extension disabled due to lack of kernel support [ 6203.348] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 6203.364] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [ 6203.364] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 6203.379] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [ 6203.800] winPointerWarpCursor - Discarding first warp: 640 400 [ 6203.800] (--) 8 mouse buttons found [ 6203.800] (--) Setting autorepeat to delay=500, rate=31 [ 6203.800] (--) Windows keyboard layout: 0409 (0409) US, type 4 [ 6203.800] (--) Found matching XKB configuration English (USA) [ 6203.800] (--) Model = pc105 Layout = us Variant = none Options = none [ 6203.800] Rules = base Model = pc105 Layout = us Variant = none Options = none [ 6203.816] winProcEstablishConnection - Hello [ 6203.956] winInitClipboard () [ 6203.956] winClipboardProc - Hello [ 6203.956] DetectUnicodeSupport - Windows NT/2000/XP [ 6203.956] winProcEstablishConnection - winInitClipboard returned. [ 6203.956] winGetDisplay: DISPLAY=:0.0 [ 6203.956] winClipboardProc - DISPLAY=:0.0 [ 6203.956] winClipboardProc - XOpenDisplay () returned and successfully opened the display. [ 6204.409] winClipboardFlushXEvents - unexpected event type 34 [ 6206.952] winWindowProc - WM_SIZE - new client area w: 1280 h: 748 [ 12055.835] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 12055.835] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 13684.064] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 13684.064] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 16856.313] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 16856.313] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 20387.614] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 20387.614] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 21698.584] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 21698.584] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 56138.285] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 56138.285] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 61047.949] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 61047.949] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 66152.832] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 66152.832] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 67952.225] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 67952.225] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 71279.150] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71279.742] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71279.852] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71280.054] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71280.678] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71280.819] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71280.990] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71281.614] winShadowUpdateDDNL -
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
A small suggestion: I have twice been bitten by the fact that I cannot just send an XWin log to the cygwin-xfree list. This is because the log contains an email address, so the cygwin email serve bounces the message. If the format of the email address in the log used at rather than a literal at-sign, then I probably *could* email a log. Something to think about ... Regards -- EM -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 9/23/2010 9:10 AM, Jon TURNEY wrote: On 21/09/2010 23:06, Eliot Moss wrote: [I reported crash on resume after Suspend or Hibernate.] Does the crash also occur if you don't use -resize? Yes. Is there a simple procedure for winding back? If you've installed my snapshot as XWin.exe, the easiest way to get the 1.8.2-1 version back is to reinstall it using setup. Right; sorry I wasn't clear. I was trying the snapshot because 1.8.2-1 fails in the same way. What I meant was: Can I easily go back to a consistent set of X.org files some time *before* that .. Unfortunately, I can't reproduce this on my Win7 system, although it is quite possible that this is specific to the display driver or hardware. I have a Toshiba Portege M750. It has Intel Display drivers. But you know what, that got me thinking: I believe those drivers were updated recently and maybe I should try winding *them* back. If you can use gdb to generate a backtrace for this segfault, that would be most helpful. I understand gdb generally and all. Can you give a bit of guidance about how to start things (edits to startxwn.bat?) with gdb, to get you that back trace? Thanks for the response, Jon ... -- Eliot Moss -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
Thanks for the tips; here's your stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to thread 9084.0x19c8] 0x004158fe in winShadowUpdateDDNL (pScreen=0x19431c8, pBuf=0x1919050) at winshadddnl.c:699 699 winshadddnl.c: No such file or directory. in winshadddnl.c (gdb) i stack #0 0x004158fe in winShadowUpdateDDNL (pScreen=0x19431c8, pBuf=0x1919050) at winshadddnl.c:699 #1 0x00528e94 in shadowRedisplay (pScreen=0x19431c8) at shadow.c:61 #2 0x00528eba in shadowBlockHandler (data=0x19431c8, pTimeout=0x28cc1c, pRead=0x635800) at shadow.c:71 #3 0x00555391 in BlockHandler (pTimeout=0x28cc1c, pReadmask=0x635800) at dixutils.c:373 #4 0x005c731a in WaitForSomething (pClientsReady=0x1cb9cb8) at WaitFor.c:216 #5 0x0054c30f in Dispatch () at dispatch.c:375 #6 0x005464db in main (argc=7, argv=0x6123a6fc, envp=0x18f00f8) at main.c:286 (gdb) c Continuing. Program exited with code 01. Meanwhile I will get Intel driver info and see if reverting that gets around the problem ... Regards -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
So, some (good? but at least interesting) news: The version of the Intel GMA Drivers affects whether the bad behavior happens. These are GMA (Graphics Media Accelerator) drivers for Windows 7 / Vista x64 for the Intel 4 Series Express chipset. The releases are numbers 8.15.10., where is what I will use to distinguish each one. 2202 (most recent) fails 2189 (latest send around by Windows Update) fails 2182 I have not yet tested 2104 works! 2021 probably also works (did before), but not explicitly tested The good thing is that I can now work with less annoyance. The bad thing is that I can't use the latest drivers. Let me know if there is anything I can do to help push XWin forward in handling whatever new it is that the Intel drivers are doing. Regards -- Eliot Moss -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 9/23/2010 11:56 AM, Jon TURNEY wrote: On 23/09/2010 15:54, Eliot Moss wrote: These are GMA (Graphics Media Accelerator) drivers for Windows 7 / Vista x64 for the Intel 4 Series Express chipset. The releases are numbers 8.15.10., where is what I will use to distinguish each one. 2202 (most recent) fails 2189 (latest send around by Windows Update) fails 2182 I have not yet tested 2104 works! 2021 probably also works (did before), but not explicitly tested I've uploaded a new test build at [1] Hopefully this handles this error condition a bit more gracefully. Perhaps you could try it out? [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 Thank you, yes, that no longer causes a SIGSEGV. Thanks! There is a remaining issue -- which was there before but which I had not posted about. If I Suspend/Resume, then on resumption the driver disables the Aero theme and points its finger at XWin.exe as the culprit, saying it did something incompatible with Aero. You probably know about this stuff, but here's the overall blurb anyway: - Why are some visual elements being automatically turned off? If you receive a message that some visual elements, such as window frame transparency, have been turned off, or if you receive a message that the theme has been changed to Basic theme, one of the following might have happened: A program that you're running is incompatible with Aero themes. When this happens, some visual elements are automatically turned off. When the program is no longer running, the visual elements that were turned off are turned on again automatically. Your laptop might be running low on battery power. Windows might turn off Aero themes or window transparency to save battery power. Your computer's hardware configuration or screen resolution was changed. If you changed your screen resolution, video card, or monitor setup, your computer might no longer meet the minimum recommendations for running Aero themes. Your computer does not have enough memory to run all of the programs that you have open and also run an Aero theme. If Windows automatically changed your theme to Basic theme, and you want to change it back to an Aero theme, close some windows to free up memory, and then follow the steps below. To run the Aero troubleshooter To try to get visual elements like transparency running again, use the Aero troubleshooter, which can find and fix problems automatically. Click to open the Aero troubleshooter. If you are prompted for an administrator password or confirmation, type the password or provide confirmation. To use an Aero theme If the troubleshooter doesn't fix the problem, try changing the theme back to an Aero theme. Click to open Personalization. Under Aero Themes, click a theme to apply it to your desktop. As soon as I exit XWin, Aero reasserts and remains if I restart XWin. This is a minor annoyance compared to SIGSEGV. Recently it has happened on *every* Resume; in the past it seemed to me that it happened only *sometimes*, with a pattern I did not figure out. So this is perhaps of lower priority, but would be nice if it were fixed at some point. Thanks again for your quick response! Regards -- Eliot Moss -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 9/23/2010 11:56 AM, Jon TURNEY wrote: [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 Some additional evidence: Using the build above, and *not* using -resize I did not get the Aero theme suppressed on Resume behavior. Recalling that in some earlier version -resize was always on may explain some of my earlier experiences. So turning off -resize gets around that annoyance. But turning off -resize means that if I change screen resolution, e.g., to use a video projector for my class, then the XWin window size gets shrunk and cannot grow back, while with -resize it survives such resolution changes. Perhaps these pieces of information will help you continue to refine this very useful software! Regards -- 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: Cygwin/X bug? suspend-resume issues
Interesting that I just posted a report around the same issue. The latest release available through cygwin, and a later made available by John earlier this month, both SIGSEGV upon resuming after Suspend or Hibernate. This is also on a Win 7 x64 box. As for rebaseall, I've not rebased lately because I have not run into the characteristic symptoms that call for it, so I don't think that's it. Regards -- Eliot Moss -- 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: XFig problems [locale?]
$ export LANG=us_US.UTF-8 I think that should be en_US.UTF-8 Eliot Moss -- 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: Problems Starting Xterm using the System Tray Icon for XWin Server
On 2/18/2010 11:28 AM, Craig Moore wrote:
On Thu, 18 Feb 2010 10:34:56 -0500, Ken Brownkbrown at cornell dot edu wrote:
How do I configure the XWin Server so that it opens xterm correctly?
This happens because xterm doesn't start a login shell, and PS1 gets unset. One
way around this is to set PS1 in your ~/.bashrc file. For example:
PS1='\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
I added this to my ~/.bashrc and the problem went away. Thanks!
Also, is there a way I can add a shortcut on my desktop to open a new
terminal window without having to type 'xterm' in the existing
terminal window or the system tray icon?
I use a shortcut with target
C:\cygwin\bin\run.exe /usr/bin/xterm -ls -display 127.0.0.1:0.0
Perfect, with this I don't even need to bother with the system tray
icon. However, I do get a small error message when I execute it:
-bash: Files/MiKTeX: No such file or directory
cr...@craig-laptop ~
$
I imagine that this has something to do with the way cygwin deals with
the PATH variable? Here is the text in my PATH variable as seen from
Cygwin:
$ echo $PATH
/cygdrive/c/Users/craig/Programming/scripts:/home/craig/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Program
Files/MiKTeX
2.7/miktex/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Program
Files/Common Files/Roxio Shared/10.0/DLLShared/:/cygdrive/c/Program
Files/Common Files/Roxio
Shared/DLLShared/:/cygdrive/c/modeltech_6.5c/win32:/cygdrive/c/Users/craig/Software/ant-1.7.1/apache-ant-1.7.1/bin
Alternatively , this is what it looks like from DOS cmd:
ECHO %PATH%
C:\Program Files\MiKTeX
2.7\miktex\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program
Files\Common Files\Roxio Shared\10.0\DLLShared\;C:\Program Files\Common
Files\Roxio
Shared\DLLShared\;C:\modeltech_6.5c\win32;C:\Users\craig\Software\ant-1.7.1\apache-ant-1.7.1\bin
Its not a big problem, but I thought I would make you all aware of it.
You have spaces in your PATH but probably did not quote it
properly in your scripts when you used it ...
I have things like this in my .bash_profile:
PATH=${HOME}/bin:/c/miktex2.8/miktex/bin:${PATH}:${M2_HOME}/bin
Note the quotes :-)
Since I run MiKTeX from cygwin, I added to PATH within cygwin only,
so that's not my point. My point is always using the quotes when
adjusting PATH, and so forth, if it might have spaces in it.
Cheers -- EM
--
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: [ANNOUNCEMENT] [1.7] Updated: xterm-251-1
Thank you, Yaakov -- this definitely fixed my problem, and ldd shows that it requests ncurses, as desired for the future. Best wishes -- 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: Problem with new xinit - console window doesn't open (but bash starts)
The missing charsets message is symptomatic of not having the patches needed to a couple of X config files concerning UTF-8. If you apply the path, which I think is in the latest Xorg files, then that problem should be fixed. (Assuming you set LANG. You can also try LANG=C as a temporary workaround.) -- Eliot Moss -- 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/
WM_QUIT problem (was twm issue ...)
Since nobody has responded at all, I thought I would try again, a different way ... This is a case where what I believe is normal termination of a window manager (in my case twm) is causing a seg fault in XWin, at least that's what the attached log seems to say. The odd thing is that this happens when I exit twm by typing control-shift-q, where I have the following twm declaration: q = s | c : all : f.quit But I also have a menu with an f.quit item, and when I exit that way, I do not get the seg fault (second attached log). I suppose this is not a huge deal, since I am exiting everything anyway, but a seg fault is kind of scary to a user of an important thing like X :-) ... Best wishes -- Eliot Moss Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-04 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -auth /home/Eliot/.serverauth.5240 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 800 winInitializeDefaultScreens - Returning 2009-11-12 06:56:49 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-11-12 06:56:49 (II) xorg.conf is not supported 2009-11-12 06:56:49 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-11-12 06:56:49 winPrefsLoadPreferences: /etc/X11/system.XWinrc 2009-11-12 06:56:49 LoadPreferences: Done parsing the configuration file... 2009-11-12 06:56:49 winGetDisplay: DISPLAY=:0.0 2009-11-12 06:56:49 winDetectSupportedEngines - Windows NT/2000/XP 2009-11-12 06:56:49 winDetectSupportedEngines - DirectDraw installed 2009-11-12 06:56:49 winDetectSupportedEngines - DirectDraw4 installed 2009-11-12 06:56:49 winDetectSupportedEngines - Returning, supported engines 0007 2009-11-12 06:56:49 winSetEngine - Using Shadow DirectDraw NonLocking 2009-11-12 06:56:49 winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel 2009-11-12 06:56:49 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2009-11-12 06:56:49 Screen 0 added at XINERAMA coordinate (0,0). 2009-11-12 06:56:49 MIT-SHM extension disabled due to lack of kernel support 2009-11-12 06:56:49 XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel 2009-11-12 06:56:49 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so 2009-11-12 06:56:49 (II) GLX: Initialized DRISWRAST GL provider for screen 0 2009-11-12 06:56:49 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! 2009-11-12 06:56:49 winPointerWarpCursor - Discarding first warp: 640 400 2009-11-12 06:56:49 (--) 8 mouse buttons found 2009-11-12 06:56:49 (--) Setting autorepeat to delay=500, rate=31 2009-11-12 06:56:49 (--) winConfigKeyboard - Layout: 0409 (0409) 2009-11-12 06:56:49 (--) Using preset keyboard for English (USA) (409), type 4 2009-11-12 06:56:49 Rules = base Model = pc105 Layout = us Variant = none Options = none 2009-11-12 06:56:50 winProcEstablishConnection - Hello 2009-11-12 06:56:50 winInitClipboard () 2009-11-12 06:56:50 winClipboardProc - Hello 2009-11-12 06:56:50 DetectUnicodeSupport - Windows NT/2000/XP 2009-11-12 06:56:50 winProcEstablishConnection - winInitClipboard returned. 2009-11-12 06:56:50 winGetDisplay: DISPLAY=:0.0 2009-11-12 06:56:50 winClipboardProc - DISPLAY=:0.0 2009-11-12 06:56:50 winClipboardProc - XOpenDisplay () returned and successfully opened the display. 2009-11-12 06:56:50 winClipboardFlushXEvents - unexpected event type 34 2009-11-12 06:57:09 winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. 2009-11-12 06:57:09 winClipboardProc - XDestroyWindow succeeded. 2009-11-12 06:57:09 Segmentation fault at address 0x268 2009-11-12 06:57:09 Fatal server error: 2009-11-12 06:57:09 Caught signal 11 (Segmentation fault). Server aborting 2009-11-12 06:57:09 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-04 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -auth /home/Eliot/.serverauth.8996 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 800 winInitializeDefaultScreens - Returning 2009-11-12 06:55:42 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-11-12 06:55:42 (II) xorg.conf is not supported 2009-11-12 06:55:42 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-11-12 06:55:42 winPrefsLoadPreferences: /etc/X11/system.XWinrc 2009-11-12 06:55:42 LoadPreferences: Done parsing the configuration file... 2009-11-12 06:55:42 winGetDisplay: DISPLAY=:0.0 2009-11-12 06:55:42 winDetectSupportedEngines - Windows NT/2000/XP 2009-11-12 06:55:42 winDetectSupportedEngines - DirectDraw installed 2009-11-12 06:55:42
Re: cygwin 1.7.0-63 problems with X programs
Thanks, Jon! Installing the three font collections you suggested seems to have solved all THREE of the problems I mentioned. I can only guess that somehow the font/locale issues prevented some .Xdefault information from being loaded or used properly, but I attach the .Xdefaults file anyway. The way I know it's not being used is that my .xinitrc has the following for strting xemacs, i.e., no override of the default, and the window definitely came up a different shape without the isas, jis, and deawoo fonts installed. xemacs -T xemacs -iconname xemacs -iconic In any case, I guess that as we move into cygwin 1.7 we'll save a lot of blood, sweat, and tears if we point out the need to install these fonts. In any case, now LANG=C.UTF-8 works well, as does LANG=en_US.UTF-8! Best wishes -- 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: Cut Paste problem between X windows
dbl...@comcast.net wrote: Hi, I just discovered that setting LANG=en_US.UTF-8 in my environment solved the problem with pasting into an xterm. Not exactly sure why this fixed that problem, anybody know? I still have the problem with clipboard sharing between windows and cygwinx, though. Could this also be related to the LANG environment variable? Is there some other value other than en_US.UTF-8 required to get it to work? -Dave Levi dbl...@comcast.net Explicitly setting LANG=C (not C.UTF-8) enabled me to work around various X problems until enough other things were fixed. With the latest available X-org packages and the latest cygwin (released just in the last day or so) en_US.UTF-8 and C.UTF-8 started working for me *provided* I also installed several sets of fonts: font-daewoo-misc font-isas-misc font-jis-misc Apparently these were needed because X wants them around *in case* it needs their encodings -- but only demands them if LANG is set to a UTF-8 encoding (meaning: not in the LANG=C case). Cheers -- Eliot Moss -- 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: Re: cygwin 1.7.0-63 problems with X programs
Corinna Vinschen wrote: On Nov 7 09:27, Eliot Moss wrote: Like another user, I had difficulty getting X to fire up. After setting LANG=en_US.UTF-8 I got farther, but these issues remain: Each xterm, xemacs, and xclock I start outputs this: Warning: Missing charsets in String to FontSet conversion I also get a series of: twm: warning: font for charset XXX is lacking. Where XXX is replaced by each of these in turn: JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 Those three lines repeat 6 times. Also: 1) the whole deal takes noticeably longer to start 2) xemacs does not receive its normal geometry from .Xdefaults 3) each xterm started from .xinitrc has a blank line before the initial bash prompt, that wasn't present before I can reproduce that, but I can't make any sense of it. What on earth does that have to do with setting LANG to en_US.UTF-8?!? I'll redirect this to the cygwin-xfree list. Thanks for the redirect, Corinna. I can report a bit more ... - Adding the locale lines for C.UTF-8 into locale.dir and compose.dir do work to get X to start for me. (These are the patches discussed in the X11R7.5 and C.UTF-8 thread on cygwin-xfree.) - The other problems go away if I set LANG=C, so it's definitely something about the locale. Am I unusual in using twm :-) ? Anyway, for now I am using LANG=C, set in the Windows environment variables, but once there are patches or updates to test, I am happy to try them ... Best wishes -- Eliot Moss -- 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/
twm issue under cygwin 1.7
Actually, the issue may not be cygwin per se, but perhaps changes in X. Anyway, I had typically put this in my .twmrc file: q = s | c : all : f.quit The intention was for control-shift-Q typed anywhere to cause twm to finish. I also have a menu item: quit f.quit If I exit using the menu item, everything is ok, but if I use the c-s-Q method, I get a seg fault in X. I attach the log file. I have other twm questions/issues, but it's probably best to put them in a different email :-) ... Eliot Moss Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-10-25 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -auth /home/Eliot/.serverauth.6872 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 800 winInitializeDefaultScreens - Returning 2009-11-08 09:16:53 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-11-08 09:16:53 (II) xorg.conf is not supported 2009-11-08 09:16:53 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-11-08 09:16:53 winPrefsLoadPreferences: /etc/X11/system.XWinrc 2009-11-08 09:16:53 LoadPreferences: Done parsing the configuration file... 2009-11-08 09:16:53 winGetDisplay: DISPLAY=:0.0 2009-11-08 09:16:53 winDetectSupportedEngines - Windows NT/2000/XP 2009-11-08 09:16:53 winDetectSupportedEngines - DirectDraw installed 2009-11-08 09:16:53 winDetectSupportedEngines - DirectDraw4 installed 2009-11-08 09:16:53 winDetectSupportedEngines - Returning, supported engines 0007 2009-11-08 09:16:53 winSetEngine - Using Shadow DirectDraw NonLocking 2009-11-08 09:16:53 winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel 2009-11-08 09:16:53 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2009-11-08 09:16:53 Screen 0 added at XINERAMA coordinate (0,0). 2009-11-08 09:16:53 MIT-SHM extension disabled due to lack of kernel support 2009-11-08 09:16:53 XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel 2009-11-08 09:16:53 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so 2009-11-08 09:16:53 (II) GLX: Initialized DRISWRAST GL provider for screen 0 2009-11-08 09:16:53 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! 2009-11-08 09:16:54 winPointerWarpCursor - Discarding first warp: 640 400 2009-11-08 09:16:54 (--) 8 mouse buttons found 2009-11-08 09:16:54 (--) Setting autorepeat to delay=500, rate=31 2009-11-08 09:16:54 (--) winConfigKeyboard - Layout: 0409 (0409) 2009-11-08 09:16:54 (--) Using preset keyboard for English (USA) (409), type 4 2009-11-08 09:16:54 Rules = base Model = pc105 Layout = us Variant = none Options = none 2009-11-08 09:16:54 winProcEstablishConnection - Hello 2009-11-08 09:16:54 winInitClipboard () 2009-11-08 09:16:54 winClipboardProc - Hello 2009-11-08 09:16:54 DetectUnicodeSupport - Windows NT/2000/XP 2009-11-08 09:16:54 winProcEstablishConnection - winInitClipboard returned. 2009-11-08 09:16:54 winGetDisplay: DISPLAY=:0.0 2009-11-08 09:16:54 winClipboardProc - DISPLAY=:0.0 2009-11-08 09:16:54 winClipboardProc - XOpenDisplay () returned and successfully opened the display. 2009-11-08 09:16:55 winClipboardFlushXEvents - unexpected event type 34 2009-11-08 09:17:31 winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. 2009-11-08 09:17:31 winClipboardProc - XDestroyWindow succeeded. 2009-11-08 09:17:31 Segmentation fault at address 0x268 2009-11-08 09:17:31 Fatal server error: 2009-11-08 09:17:31 Caught signal 11 (Segmentation fault). Server aborting 2009-11-08 09:17:31 -- 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/
changing monitors dynamically confuses Xwin
Dear Cygwin/Xwin maintainers: First let me say that I am running Cygwin/XFree 6.8.1.0-9 on a Windows XP box. I start X with the default parameters (plus -clipboard). Here's what I want to do, and what happens: -- Want to: Use the XP Display Properties Settings menu to add. on the fly, a second display, namely a video projector. I Extend the Windows Desktop to this projector for displaying PowerPoint slides. I want X to stay the way it was, in an XP window that covers the whole laptop LCD screen, but not displaying on the video projector. -- What happens: When I do this, after the display configuration change, the X window contents no longer display, though the cursors show and input appears to be active. XP things work as expected, and I can move the cursor from one screen to another, etc. PowerPoint does the right thin, showing presenter view on LCD screen anbd slide show on video projector. Once I am done and change the configuration back to one display, X works again like normal. Any suggestions? Or is this going to need some heavy duty programming to fix? Regards -- Eliot Moss == J. Eliot B. Moss, Associate Professor http://www.cs.umass.edu/~mosswww Director, Arch. and Lang. Impl. Lab. +1-413-545-4206voice Department of Computer Science+1-413-695-4226 cell 140 Governor's Drive, Room 372+1-413-545-1249 fax University of Massachusetts at Amherst[EMAIL PROTECTED] email Amherst, MA 01003-9264 USA +1-413-545-3733 Priscilla Coe sec'y ==
