XWin Server starts but terminates shortly after
Since about six months: I can start XWin-Server, but it terminates
shortly after without any chance to start any X11-application.
The X11-log shows:
-- SNIP
# cat XWin.0.log
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.17.4.0
OS: CYGWIN_NT-6.1 nc403-muc 2.3.0(0.291/5/3) 2015-11-09 10:24 x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64)
Package: version 1.17.4-1 built 2015-10-29
XWin was started with the following command line:
/usr/bin/XWin -multiwindow -clipboard
ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1920 h 1200
winInitializeScreenDefaults - native DPI x 96 y 96
[ 996.393] (II) xorg.conf is not supported
[ 996.393] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html
for more information
[ 996.393] LoadPreferences: /cygdrive/c/Users/sct-muc.BFS/.XWinrc not found
[ 996.393] LoadPreferences: Loading /etc/X11/system.XWinrc
[ 996.393] LoadPreferences: Done parsing the configuration file...
[ 996.409] winDetectSupportedEngines - DirectDraw4 installed,
allowing ShadowDDNL
[ 996.409] winDetectSupportedEngines - Returning, supported engines 0005
[ 996.456] winSetEngine - Multi Window or Rootless => ShadowGDI
[ 996.456] winScreenInit - Using Windows display depth of 32 bits per pixel
[ 996.456] winAllocateFBShadowGDI - Creating DIB with width: 1920
height: 1200 depth: 32
[ 996.456] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[ 996.456] winInitVisualsShadowGDI - Masks 00ff ff00
00ff BPRGB 8 d 24 bpp 32
[ 996,471] MIT-SHM extension disabled due to lack of kernel support
[ 996,471] XFree86-Bigfont extension local-client optimization
disabled due to lack of shared memory support in the kernel
[ 996,471] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
-- SNAP
xorg.conf is no existing.
An user ~/.XWinrc doesn't exist.
A system wide /etc/X11/system.XWinrc exists:
-- SNIP
$ cat /etc/X11/system.XWinrc
# XWin Server Resource File - EXAMPLE
# Earle F. Philhower, III
# Place in ~/.XWinrc or in /etc/X11/system.XWinrc
# Keywords are case insensitive, comments legal pretty much anywhere
# you can have an end-of-line
# Comments begin with "#" or "//" and go to the end-of-line
# Paths to commands are **cygwin** based (i.e. /usr/local/bin/xcalc)
# Paths to icons are **WINDOWS** based (i.e. c:\windows\icons)
# Menus are defined as...
# MENU {
#EXEC
# ^^ This command will have any "%display%"
# string replaced with the proper display
# variable (i.e. 127.0.0.1:.0)
# (This should only rarely be needed as
# the DISPLAY environment variable is also
# set correctly)
# orMENU
# orALWAYSONTOP
# ^^ Sets the window to display above all others
# orRELOAD
# ^^ Causes ~/.XWinrc or the system.XWinrc file
#to be reloaded and icons and menus regenerated
# or SEPARATOR
# ...
# }
# Set the taskmar menu with
# ROOTMENU
# If you want a menu to be applied to all popup window's system menu
# DEFAULTSYSMENU <atstart|atend>
# To choose a specific menu for a specific WM_CLASS or WM_NAME use ...
# SYSMENU {
# <atstart|atend>
# ...
# }
# When specifying an ICONFILE in the following commands several different
# formats are allowed:
# 1. Name of a regular Windows .ico format file
#(ex: "cygwin.ico", "apple.ico")
# 2. Name and index into a Windows .DLL
#(ex: "c:\windows\system32\shell32.dll,4" gives the default folder icon
# "c:\windows\system32\shell32.dll,5" gives the floppy drive icon)
# 3. Index into XWin.EXE internal ICON resource
#(ex: ",101" is the 1st icon inside XWin.exe)
# To define where ICO files live (** Windows path**)
# ICONDIRECTORY
# NOTE: If you specify a fully qualified path to an ICON below
# (i.e. "c:\xxx" or "d:\")
# this ICONDIRECTORY will not be prepended
# To change the taskbar icon use...
# TRAYICON
# To define a replacement for the standard X icon for apps w/o specified icons
# DEFAULTICON
# To define substitute icons on a per-window basis use...
# ICONS {
#
# ...
# }
# In the case where multiple matches occur, the first listed in the ICONS
# section will be chosen.
# To disable exit confirmation dialog add the line containing SilentExit
# DEBUG prints out the string to the XWin.log file
// Below are just some silly menus to demonstrate writing your
// own configuration file.
// Make some menus...
menu apps {
xterm exec"xterm"
"Emacs" exec"emacs"
note
Re: Following update to XWin or xorg-server: changed syntax to get a xterm terminal window
Michael DePaulo gmail.com> writes: |On Wed, Jun 10, 2015 at 7:28 AM, Fergus Daly | frontier-science.co.uk> wrote: |> For ages I used |> XWin -nolock -nolisten local -multiwindow & |> xterm -display localhost:0.0 |> to get a xterm terminal. |> Following recent updates I get a fatal error: "Cannot establish any |> listening sockets." In the past, updates to XWin have sometimes led |> to similar difficulties, but I have always managed to iterate to a |> new successful joint syntax |> XWin |> xterm | By default, XWin 1.17 no longer listens on TCP sockets, only on unix | domain sockets. | https://www.cygwin.com/ml/cygwin-announce/2015-06/msg3.html | However, "-nolisten local" disables unix domain sockets., | So to use unix domain sockets: | XWin -nolock -multiwindow & | xterm -display :0.0 | Or to keep using TCP sockets: | XWin -nolock -nolisten local -listen tcp -multiwindow & | xterm -display localhost:0.0 I found that I also had to rejig my ~/.startxwinrc. ~/.startxwinrc: --- xrdb -load $HOME/.Xresources xterm -display :0.0 # xterm & exec sleep infinity -- 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/
Following update to XWin or xorg-server: changed syntax to get a xterm terminal window
For ages I used XWin -nolock -nolisten local -multiwindow xterm -display localhost:0.0 to get a xterm terminal. Following recent updates I get a fatal error: Cannot establish any listening sockets. In the past, updates to XWin have sometimes led to similar difficulties, but I have always managed to iterate to a new successful joint syntax XWin arguments xterm arguments but this time I am totally stymied. Can anybody offer me a working syntax please? Thank you. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Following update to XWin or xorg-server: changed syntax to get a xterm terminal window
On Wed, Jun 10, 2015 at 7:28 AM, Fergus Daly ferg...@frontier-science.co.uk wrote: For ages I used XWin -nolock -nolisten local -multiwindow xterm -display localhost:0.0 to get a xterm terminal. Following recent updates I get a fatal error: Cannot establish any listening sockets. In the past, updates to XWin have sometimes led to similar difficulties, but I have always managed to iterate to a new successful joint syntax XWin arguments xterm arguments but this time I am totally stymied. Can anybody offer me a working syntax please? Thank you. Fergus By default, XWin 1.17 no longer listens on TCP sockets, only on unix domain sockets. https://www.cygwin.com/ml/cygwin-announce/2015-06/msg3.html However, -nolisten local disables unix domain sockets., So to use unix domain sockets: XWin -nolock -multiwindow xterm -display :0.0 Or to keep using TCP sockets: XWin -nolock -nolisten local -listen tcp -multiwindow xterm -display localhost:0.0 -Mike -- 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 XWin 1.17.1 crash at startup
On 31/03/2015 19:36, Michel Poirier wrote: Since last X-Cygwin update several of my X-Win applications are not working properly. Googling cygwin xorg 1.17 crash gave many posts reporting probably similar issues but I couldn't find a fix for the error. I also looked at the Cygwin-FAQ and mailing list without real success. The issue appeared using a long-time tested DOS script launching xmgrace which failed with a message telling A fatal error has occurred and Cygwin/X will now exit. And other XWin programs were not working properly. So I tried to make a fresh install of X-Cygwin (32 bits) on another computer and went through the procedure explained on page Can you be a bit more specific than not working properly, please? I made a brief test with xmgrace, and I wasn't able to observe any problems. Is there some specific option or action in xmgrace which causes this crash? http://x.cygwin.com/devel/backtrace.html Would it be possible for you to try the a backtrace when some specific action is making the X server crash method on the machine which shows the crash? which produced the debug info attached as backtrace for X server crashing at startup.txt. The X Server crashed when the r command was launched and a copy of the Windows error message is provided at Capture of Windows error message.txt. I checked that no other X Server was then running and clicked Ok button to finish the procedure. Thanks for attempting this. Unfortunately, this looks like the server refusing to start as one is already running. If there really isn't one running, this looks like a different problem. -- 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/
Cygwin XWin 1.17.1 crash at startup
Dear Cygwin maintainer Since last X-Cygwin update several of my X-Win applications are not working properly. Googling cygwin xorg 1.17 crash gave many posts reporting probably similar issues but I couldn't find a fix for the error. I also looked at the Cygwin-FAQ and mailing list without real success. The issue appeared using a long-time tested DOS script launching xmgrace which failed with a message telling A fatal error has occurred and Cygwin/X will now exit. And other XWin programs were not working properly. So I tried to make a fresh install of X-Cygwin (32 bits) on another computer and went through the procedure explained on page http://x.cygwin.com/devel/backtrace.html which produced the debug info attached as backtrace for X server crashing at startup.txt. The X Server crashed when the r command was launched and a copy of the Windows error message is provided at Capture of Windows error message.txt. I checked that no other X Server was then running and clicked Ok button to finish the procedure. The content of the file /var/log/xwin/XWin.0.log is listed at the end of the first attached file. I also tried to install the most recent xlaunch program as suggested here https://www.cygwin.com/ml/cygwin-xfree/2015-02/msg00089.html but it did not solve the issue. Sorry for asking something that might be FAQ but as I told I could not find a clear answer elsewhere and indeed xlaunch reproduced the error consistently. Thanking you in advance for your assistance, and of course for providing this invaluable software that is cygwin. Regards -- Michel Poirier CEA, IRAMIS Laboratoire Interactions, Dynamique et Lasers Centre d'Études de Saclay, bât. 522 F91191 Gif/Yvette (France) Tél. : +33 1 69 08 46 29 FAX : +33 1 69 08 87 07 e-mail: michel.poir...@cea.fr IRAM-FA-004439+admin-local@IRAM-FA-004439 ~ $ gdb --args /usr/bin/XWin -multiwindow GNU gdb (GDB) 7.8 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-cygwin. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from /usr/bin/XWin...Reading symbols from /usr/lib/debug//usr/bi n/XWin.exe.dbg...Can't read data for section '.debug_frame' in file '/usr/lib/de bug/usr/bin/XWin.exe.dbg' (gdb) handle SIGSYS nostop SignalStop Print Pass to program Description SIGSYSNoYes Yes Bad system call (gdb) r Starting program: /usr/bin/XWin -multiwindow [New Thread 5852.0xc88] [New Thread 5852.0x1a0c] [New Thread 5852.0xcec] [New Thread 5852.0x1548] [New Thread 5852.0x50c] [New Thread 5852.0x4e0] [Thread 5852.0x4e0 exited with code 1] [Thread 5852.0x1a0c exited with code 1] [Thread 5852.0x50c exited with code 1] [Thread 5852.0xcec exited with code 1] [Inferior 1 (process 5852) exited with code 01] (gdb) bt full No stack. (gdb) q IRAM-FA-004439+admin-local@IRAM-FA-004439 ~ $ cat /var/log/xwin/XWin.0.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.17.1.0 OS: CYGWIN_NT-6.1-WOW IRAM-FA-004439 1.7.35(0.287/5/3) 2015-03-04 12:07 i686 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.17.1-2 built 2015-02-23 XWin was started with the following command line: /usr/bin/XWin -multiwindow ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1920 h 1200 winInitializeScreenDefaults - native DPI x 96 y 96 _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running (EE) Fatal server error: (EE) Cannot establish any listening sockets - Make sure an X server isn't alread y running(EE) [ 17451.691] (EE) Server terminated with error (1). Closing log file.A fatal error has occurred and Cygwin/X will now exit. Cannot establish any listening sockets - Make sure an X server isn't already running Please open /var/log/xwin/XWin.0.log for more information. Vendor: The Cygwin/X Project Release: 1.17.1.0 Contact: cygwin-xfree@cygwin.com Package: version 1.17.1-2 built 2015-02-23 XWin was started with the following command-line: /usr/bin/XWin -multiwindow -- 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 XWin 1.17.1 crash at startup
On 3/31/2015 8:36 PM, Michel Poirier wrote: Dear Cygwin maintainer Since last X-Cygwin update several of my X-Win applications are not working properly. Googling cygwin xorg 1.17 crash gave many posts reporting probably similar issues but I couldn't find a fix for the error. I also looked at the Cygwin-FAQ and mailing list without real success. can you just run startxwin from mintty and report the outcome ? There were several changes in the default https://www.cygwin.com/ml/cygwin-xfree-announce/2015-02/msg0.html https://www.cygwin.com/ml/cygwin-xfree-announce/2015-02/msg00014.html may be you are hitting one of them. Regards Marco -- 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 cursor huge on one computer but normal on another
On 03/08/2014 15:32, Matt D. wrote:
I primarily work on my workstation which has four 1080p monitors (three
on the bottom with the fourth at center top) and for the longest time I
thought that it this was a configuration error on my part; and perhaps
it still it.
The issue is that on my worksation, the cursor is huge and is sometimes
even cropped for being too large. This is especially noticeable for
applications like xterm and gedit.
I think it might be a DPI or scaling issue due to my large screen size,
however I've always explicitly defined -dpi 96 in my xinit.
I had thought that this was a known bug and hadn't thought much about it
until I pulled up gedit on my laptop where I saw that the cursors were
all fine. I thought that maybe I had different packages but even after
copying my entire cygwin directory and startup scripts over, on my
laptop it still shows cursors no larger than the default Windows size.
Has anyone experienced this before?
This is pretty odd. Not a known bug, or one that I think we have a had
reported before.
I guess what you are seeing when you say the cursor is 'cropped' is the
X cursor being truncated to fit in the Windows cursor size of
GetSystemMetrics(SM_CXCURSOR) by GetSystemMetrics(SM_CYCURSOR)
The libXcursor checks various things [1] when choosing a cursor size,
falling back to (smallest screen dimension/48), so I guess it's your
large display causing this issue.
I'm not sure about the best way to fix this, but as a workaround for the
moment, you might try setting the XCURSOR_SIZE env var to something
reasonable.
You might like to try this small test program to confirm what's going on:
$ cat cursor.c
#include X11/Xwindows.h
#include X11/Xcursor/Xcursor.h
int main()
{
Display *dpy = XOpenDisplay(NULL);
int c = XcursorGetDefaultSize(dpy);
printf(XcursorGetDefaultSize = %d\n, c);
printf(GetSystemMetrics(SM_CXCURSOR) = %d\n,
GetSystemMetrics(SM_CXCURSOR));
printf(GetSystemMetrics(SM_CYCURSOR) = %d\n,
GetSystemMetrics(SM_CYCURSOR));
}
$ gcc cursor.c -o cursor -lXcursor -lX11
$ ./cursor
XcursorGetDefaultSize = 22
GetSystemMetrics(SM_CXCURSOR) = 32
GetSystemMetrics(SM_CYCURSOR) = 32
[1] http://cgit.freedesktop.org/xorg/lib/libXcursor/tree/src/display.c#n168
--
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: xinit hangs on XWin infinite loop when using -displayfd
On 29/07/2014 00:57, Matt D. wrote: Doh! I was so blind! Windows XP does not have an IPv6 protocol installed by default. I added it and the problem went away. This sounds like a bug. XWin should verify whether a device which supports the target protocol exists before attempting to open a socket on it. Yes, it shouldn't fail like this if IPv6 isn't installed I suspect the same problem will occur if you use X -displayfd built with IPv6 on linux kernel without IPv6 support What is this used for? Sharing a local X session with someone else? Logging onto an existing X session at work from home? I've only ever used X locally or through ssh forwarding. It's used to allow remote X clients to connect to an X server without using a ssh tunnel (e.g. [1]) [1] http://x.cygwin.com/docs/ug/using-remote-apps.html#using-remote-apps-telnet -- 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/
XWin cursor huge on one computer but normal on another
I primarily work on my workstation which has four 1080p monitors (three on the bottom with the fourth at center top) and for the longest time I thought that it this was a configuration error on my part; and perhaps it still it. The issue is that on my worksation, the cursor is huge and is sometimes even cropped for being too large. This is especially noticeable for applications like xterm and gedit. I think it might be a DPI or scaling issue due to my large screen size, however I've always explicitly defined -dpi 96 in my xinit. I had thought that this was a known bug and hadn't thought much about it until I pulled up gedit on my laptop where I saw that the cursors were all fine. I thought that maybe I had different packages but even after copying my entire cygwin directory and startup scripts over, on my laptop it still shows cursors no larger than the default Windows size. Has anyone experienced this before? Thanks, Matt D. -- 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: xinit hangs on XWin infinite loop when using -displayfd
Thanks for reporting this problem. On 21/07/2014 18:30, Matt D. wrote: I found as a workaround to add the arguments -nolisten tcp when invoking xinit. However, I was under the impression that it was incompatible with -multiwindow and -clipboard, both of which seem to be working fine: https://cygwin.com/ml/cygwin-xfree/2009-05/msg00016.html That restriction no longer exists. https://cygwin.com/ml/cygwin-xfree/2009-10/msg7.html On 7/21/2014 12:00 PM, Matt D. wrote: Ok.. so I let xinit do its thing to see if it got anywhere. Eventually it will pop and error box. Interestingly, I specified a displayfd value of 3 and yet both the popup and the log are reporting 5: This is expected. xinit must know the display number of the X server it starts, so it can pass it on to any clients it starts, so it has a patch which should notice the -displayfd option, transparently use it to determine the display number for any clients they start, and then pass on the display number to the specified file descriptor My XWin.0.log is about 15MB of repeated attempts to open a socket. Here is a snippet. I hope this helps: InitConnectionLimits: MaxClients = 255 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.15.1.0 OS: CYGWIN_NT-5.1 matthew-17ffb52 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32) Snapshot: 20140709-git-2e9c13ea41c51df7 XWin was started with the following command line: X -displayfd 5 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1062 h 703 winInitializeScreenDefaults - native DPI x 96 y 96 ddxProcessArgument - arg: -displayfd Trying to create socket for display number 0 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/matthew-17ffb52:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 .. Trying to create socket for display number 59534 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/matthew-17ffb52:59534 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 (EE) Fatal server error: (EE) Failed to find a socket to listen on(EE) [ 58128.390] (EE) Server terminated with error (1). Closing log file. Ah. So, it seems that we have checked all ports from 6000 to 59534 + 6000 = 65534 and decided they are no good because we can't open an ipv6 socket. (It looks like there is another minor bug here in that we don't try port 65535! :-)) I guess if you just run XWin, it reports that it can't create an inet6 listener, but it continues anyway (unless the -nopn option is used). But, the implementation of -displayfd requires that creating all the listener socket succeeds. (It's not clear that this should be changed, otherwise we could reach the conclusion that it's ok to start a server on display n with a limited set of protocols, when a server already exists on display n with an non-intersecting set of protocols) So, you may find that -nolisten inet6, rather than -nolisten tcp (which prevents both ipv4 and ipv6 listening) also works around the problem. You might want to also investigate why inet6 sockets can't be opened. -- 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: xinit hangs on XWin infinite loop when using -displayfd
Doh! I was so blind! Windows XP does not have an IPv6 protocol installed by default. I added it and the problem went away. This sounds like a bug. XWin should verify whether a device which supports the target protocol exists before attempting to open a socket on it. What is this used for? Sharing a local X session with someone else? Logging onto an existing X session at work from home? I've only ever used X locally or through ssh forwarding. Matt D. On 7/28/2014 8:34 AM, Jon TURNEY wrote: Thanks for reporting this problem. On 21/07/2014 18:30, Matt D. wrote: I found as a workaround to add the arguments -nolisten tcp when invoking xinit. However, I was under the impression that it was incompatible with -multiwindow and -clipboard, both of which seem to be working fine: https://cygwin.com/ml/cygwin-xfree/2009-05/msg00016.html That restriction no longer exists. https://cygwin.com/ml/cygwin-xfree/2009-10/msg7.html On 7/21/2014 12:00 PM, Matt D. wrote: Ok.. so I let xinit do its thing to see if it got anywhere. Eventually it will pop and error box. Interestingly, I specified a displayfd value of 3 and yet both the popup and the log are reporting 5: This is expected. xinit must know the display number of the X server it starts, so it can pass it on to any clients it starts, so it has a patch which should notice the -displayfd option, transparently use it to determine the display number for any clients they start, and then pass on the display number to the specified file descriptor My XWin.0.log is about 15MB of repeated attempts to open a socket. Here is a snippet. I hope this helps: InitConnectionLimits: MaxClients = 255 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.15.1.0 OS: CYGWIN_NT-5.1 matthew-17ffb52 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32) Snapshot: 20140709-git-2e9c13ea41c51df7 XWin was started with the following command line: X -displayfd 5 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1062 h 703 winInitializeScreenDefaults - native DPI x 96 y 96 ddxProcessArgument - arg: -displayfd Trying to create socket for display number 0 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/matthew-17ffb52:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 .. Trying to create socket for display number 59534 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/matthew-17ffb52:59534 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 (EE) Fatal server error: (EE) Failed to find a socket to listen on(EE) [ 58128.390] (EE) Server terminated with error (1). Closing log file. Ah. So, it seems that we have checked all ports from 6000 to 59534 + 6000 = 65534 and decided they are no good because we can't open an ipv6 socket. (It looks like there is another minor bug here in that we don't try port 65535! :-)) I guess if you just run XWin, it reports that it can't create an inet6 listener, but it continues anyway (unless the -nopn option is used). But, the implementation of -displayfd requires that creating all the listener socket succeeds. (It's not clear that this should be changed, otherwise we could reach the conclusion that it's ok to start a server on display n with a limited set of protocols, when a server already exists on display n with an non-intersecting set of protocols) So, you may find that -nolisten inet6, rather than -nolisten tcp (which prevents both ipv4 and ipv6 listening) also works around the problem. You might want to also investigate why inet6 sockets can't be opened. -- 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: xinit hangs on XWin infinite loop when using -displayfd
Still hangs with the latest 1.15.1-4 release. On my main machine, I get the following output: $ xinit -- -displayfd 1 read display number ':0' from X server 0 On the VM it just hangs. Taskmanager shows xinit.exe waiting or hung with XWin.exe churning cycles and eating memory; about 4kB a tick. Also on the VM, if I run the following: $ xinit -- -displayfd Then the display will open. So it seems to be an issue with whatever code is dealing with the file descriptors. Matt D. On 7/20/2014 9:06 PM, Matt D. wrote: The operating system is Windows XP Professional. It is a CLEAN install on a VMware virtual machine and is 100% patched up. Cygwin also is a clean install. I did try a rebaseall with no effect. This is the first time I've encountered this. When I run xinit -- -displayfd 3, xinit will hang and XWin takes up 100% of the cpu. I've confirmed that file descriptors are working: $ exec 3a $ echo test 3 $ cat a test $ exec 3- I can confirm that ports are available and that both xinit and XWin work without this argument by running: $ xinit -- Everything else works fine but without -displayfd I can't record where the display is for this session to disk. I've also tried copying known-working Cygwin installs into the VM and still have the same error. Copying the erroring install from the VM outside and running it on my development machine (Windows 7 x64) does not generate an error. Unless something stands out here, I can provide the VMware image for testing (how convenient). Matt D. -- 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/ -- 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: xinit hangs on XWin infinite loop when using -displayfd
Ok.. so I let xinit do its thing to see if it got anywhere. Eventually it will pop and error box. Interestingly, I specified a displayfd value of 3 and yet both the popup and the log are reporting 5: http://oi58.tinypic.com/106fono.jpg My XWin.0.log is about 15MB of repeated attempts to open a socket. Here is a snippet. I hope this helps: InitConnectionLimits: MaxClients = 255 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.15.1.0 OS: CYGWIN_NT-5.1 matthew-17ffb52 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32) Snapshot: 20140709-git-2e9c13ea41c51df7 XWin was started with the following command line: X -displayfd 5 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1062 h 703 winInitializeScreenDefaults - native DPI x 96 y 96 ddxProcessArgument - arg: -displayfd Trying to create socket for display number 0 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/matthew-17ffb52:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 .. Trying to create socket for display number 59534 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/matthew-17ffb52:59534 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 (EE) Fatal server error: (EE) Failed to find a socket to listen on(EE) [ 58128.390] (EE) Server terminated with error (1). Closing log file. Matt D. On 7/21/2014 11:49 AM, Matt D. wrote: Still hangs with the latest 1.15.1-4 release. On my main machine, I get the following output: $ xinit -- -displayfd 1 read display number ':0' from X server 0 On the VM it just hangs. Taskmanager shows xinit.exe waiting or hung with XWin.exe churning cycles and eating memory; about 4kB a tick. Also on the VM, if I run the following: $ xinit -- -displayfd Then the display will open. So it seems to be an issue with whatever code is dealing with the file descriptors. Matt D. On 7/20/2014 9:06 PM, Matt D. wrote: The operating system is Windows XP Professional. It is a CLEAN install on a VMware virtual machine and is 100% patched up. Cygwin also is a clean install. I did try a rebaseall with no effect. This is the first time I've encountered this. When I run xinit -- -displayfd 3, xinit will hang and XWin takes up 100% of the cpu. I've confirmed that file descriptors are working: $ exec 3a $ echo test 3 $ cat a test $ exec 3- I can confirm that ports are available and that both xinit and XWin work without this argument by running: $ xinit -- Everything else works fine but without -displayfd I can't record where the display is for this session to disk. I've also tried copying known-working Cygwin installs into the VM and still have the same error. Copying the erroring install from the VM outside and running it on my development machine (Windows 7 x64) does not generate an error. Unless something stands out here, I can provide the VMware image for testing (how convenient). Matt D. -- 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/ -- 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/ -- 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/
xinit hangs on XWin infinite loop when using -displayfd
The operating system is Windows XP Professional. It is a CLEAN install on a VMware virtual machine and is 100% patched up. Cygwin also is a clean install. I did try a rebaseall with no effect. This is the first time I've encountered this. When I run xinit -- -displayfd 3, xinit will hang and XWin takes up 100% of the cpu. I've confirmed that file descriptors are working: $ exec 3a $ echo test 3 $ cat a test $ exec 3- I can confirm that ports are available and that both xinit and XWin work without this argument by running: $ xinit -- Everything else works fine but without -displayfd I can't record where the display is for this session to disk. I've also tried copying known-working Cygwin installs into the VM and still have the same error. Copying the erroring install from the VM outside and running it on my development machine (Windows 7 x64) does not generate an error. Unless something stands out here, I can provide the VMware image for testing (how convenient). Matt D. -- 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: compiling xwin 1.15.1-2
) I've uploaded an updated khronos-opengl-registry-20140619_svn27116-1 package, which includes this fix. ) Due to other changes it includes, an additional change is needed to compile xorg-server with it, which is included in 1.15.1-3. I'm seeing the following error now. Is this what you are talking about? = Making all in glx make[4]: Entering directory '/usr/src/xorg-server-1.15.1-3/xorg-server-1.15.1-3/ build/hw/xwin/glx' GEN generated_gl_shim.c GEN generated_gl_thunks.c GEN generated_gl_thunks.def Traceback (most recent call last): File /usr/src/xorg-server-1.15.1-3/xorg-server-1.15.1-3/src/xserver-cygwin-1. 15.1-3/hw/xwin/glx/gen_gl_wrappers.py, line 28, in module from reg import * EOFError: EOF read where not expected Makefile:921: recipe for target 'generated_gl_shim.c' failed make[4]: *** [generated_gl_shim.c] Error 1 -- 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: compiling xwin 1.15.1-2
) ) Due to other changes it includes, an additional change is needed to ) compile xorg-server with it, which is included in 1.15.1-3. ) ) I'm seeing the following error now. Is this what you are talking about? No, it was just a python thing. After installing additional python3 libraries, it did compile. So 1.15.1-3 does build and works beautifully. Even with my 10-year-old patch.:-) 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: XWin ignores all parameters related to multiple monitors
On 09/05/2014 21:25, Lukas Haase wrote: On 2014-05-09 3:15, Jon TURNEY wrote: On 09/05/2014 00:27, Lukas Haase wrote: On 2014-05-08 5:15, Jon TURNEY wrote: I've built a snapshot [1], which adds a heuristic which ignores a 'program specified location' hint if the location is the origin, which you might like to try and see if that fixes your problem, but I'm not sure if that is the correct solution. I have just the issue that the exe does not seem to work for me. Is there anything special I need to consider? Sorry, my snapshot building script went wrong and the snapshot was broken. Try this one instead. ftp://cygwin.com/pub/cygwinx/x86/XWin.20140509-git-c4a16a6606868d3e.exe.bz2 Can't believe it, great! Works exactly as it should (just with the standard configuration, X :0 -multiwindow)!! Now I just hope that this 'patch' somehow finds its way into the trunk ;-) This fix is included is 1.15.1-3. On reflection, I think a better approach would be to look at _NET_WM_WINDOW_TYPE and if it's _NET_WM_TYPE_NORMAL or absent, ignore PPosition and place the window as we like, but that is not quite as straightforward to implement. -- 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: compiling xwin 1.15.1-2
On 12/06/2014 23:54, Jon TURNEY wrote: On 12/06/2014 22:49, J. Offerman wrote: Can you help me resolve this compile error that I'm seeing now? Thanks. Please use the mailing list for these kinds of questions. === In file included from /usr/src/xorg-server-1.15.1-2/src/xserver-cygwin-1.15.1-2/hw/xwin/glx/glthunk.c:87:0: ./generated_gl_thunks.c: In function 'glTexturePageCommitmentEXTWrapper': ./generated_gl_thunks.c:10560:3: error: too many arguments to function 'proc' RESOLVED_PROC(PFNGLTEXTUREPAGECOMMITMENTEXTPROC)( texture_, target_, level_, xoffset_, yoffset_, zoffset_, width_, height_, depth_, resident_ ); Thanks for drawing this to my attention. This fails because the description of glTexturePageCommitmentEXT() in /usr/share/opengl/api/gl.xml from (khronos-opengl-registry) needs to match it's prototype in /usr/include/w32api/GL/glext.h (from w32api-headers) There was an upstream bug where an extra 'target' parameter was erroneously added. The latest w32api-headers have updated GL headers that have that fixed, but it seems I haven't updated khronos-opengl-registry Until I make an updated package, you'll have to fix gl.xml yourself, like this: --- gl.xml~ 2013-08-08 18:07:23.0 +0100 +++ gl.xml 2014-05-02 17:35:52.000120700 +0100 @@ -22968,7 +22968,6 @@ command protovoid nameglTexturePageCommitmentEXT/name/proto paramptypeGLuint/ptype nametexture/name/param -paramptypeGLenum/ptype nametarget/name/param paramptypeGLint/ptype namelevel/name/param paramptypeGLint/ptype namexoffset/name/param paramptypeGLint/ptype nameyoffset/name/param I've uploaded an updated khronos-opengl-registry-20140619_svn27116-1 package, which includes this fix. Due to other changes it includes, an additional change is needed to compile xorg-server with it, which is included in 1.15.1-3. -- 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: compiling xwin 1.15.1-2
On 12/06/2014 22:49, J. Offerman wrote: Can you help me resolve this compile error that I'm seeing now? Thanks. Please use the mailing list for these kinds of questions. === In file included from /usr/src/xorg-server-1.15.1-2/src/xserver-cygwin-1.15.1-2/hw/xwin/glx/glthunk.c:87:0: ./generated_gl_thunks.c: In function 'glTexturePageCommitmentEXTWrapper': ./generated_gl_thunks.c:10560:3: error: too many arguments to function 'proc' RESOLVED_PROC(PFNGLTEXTUREPAGECOMMITMENTEXTPROC)( texture_, target_, level_, xoffset_, yoffset_, zoffset_, width_, height_, depth_, resident_ ); Thanks for drawing this to my attention. This fails because the description of glTexturePageCommitmentEXT() in /usr/share/opengl/api/gl.xml from (khronos-opengl-registry) needs to match it's prototype in /usr/include/w32api/GL/glext.h (from w32api-headers) There was an upstream bug where an extra 'target' parameter was erroneously added. The latest w32api-headers have updated GL headers that have that fixed, but it seems I haven't updated khronos-opengl-registry Until I make an updated package, you'll have to fix gl.xml yourself, like this: --- gl.xml~ 2013-08-08 18:07:23.0 +0100 +++ gl.xml 2014-05-02 17:35:52.000120700 +0100 @@ -22968,7 +22968,6 @@ command protovoid nameglTexturePageCommitmentEXT/name/proto paramptypeGLuint/ptype nametexture/name/param -paramptypeGLenum/ptype nametarget/name/param paramptypeGLint/ptype namelevel/name/param paramptypeGLint/ptype namexoffset/name/param paramptypeGLint/ptype nameyoffset/name/param -- 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 ignores all parameters related to multiple monitors
On 09/05/2014 00:27, Lukas Haase wrote: On 2014-05-08 5:15, Jon TURNEY wrote: So, do you have an example of this working as you would like on a unix system, and what is the window manager is that case? I am not sure if I get the question. What I could do is to login via VNC and see how the windows are placed are if they are placed the correct way? Is this what you mean? Unfortunately I have no chance to install Cadence locally and run it from a local, dual monitor setup from Linux because Cadence is a proprietary, expensive tool. I understand that. I am just looking for some evidence that it isn't a bug in the application, i.e. that it works correctly for *anyone* :D Knowing a window manager which places these windows correctly would also give me some source code to look at to work out what I need to change. I've built a snapshot [1], which adds a heuristic which ignores a 'program specified location' hint if the location is the origin, which you might like to try and see if that fixes your problem, but I'm not sure if that is the correct solution. I have just the issue that the exe does not seem to work for me. Is there anything special I need to consider? Sorry, my snapshot building script went wrong and the snapshot was broken. Try this one instead. ftp://cygwin.com/pub/cygwinx/x86/XWin.20140509-git-c4a16a6606868d3e.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/
Re: XWin ignores all parameters related to multiple monitors
On 2014-05-09 3:15, Jon TURNEY wrote: On 09/05/2014 00:27, Lukas Haase wrote: On 2014-05-08 5:15, Jon TURNEY wrote: So, do you have an example of this working as you would like on a unix system, and what is the window manager is that case? I am not sure if I get the question. What I could do is to login via VNC and see how the windows are placed are if they are placed the correct way? Is this what you mean? Unfortunately I have no chance to install Cadence locally and run it from a local, dual monitor setup from Linux because Cadence is a proprietary, expensive tool. I understand that. I am just looking for some evidence that it isn't a bug in the application, i.e. that it works correctly for *anyone* :D Knowing a window manager which places these windows correctly would also give me some source code to look at to work out what I need to change. Hmm, what I just did is that I started a VNC session and used VNC. Everything seems to work as expected, new windows are /not/ placed at (0,0). Window manager is Gnome. However, as mentioned, this is clearly not a local multi-monitor X session :( I've built a snapshot [1], which adds a heuristic which ignores a 'program specified location' hint if the location is the origin, which you might like to try and see if that fixes your problem, but I'm not sure if that is the correct solution. I have just the issue that the exe does not seem to work for me. Is there anything special I need to consider? Sorry, my snapshot building script went wrong and the snapshot was broken. Try this one instead. ftp://cygwin.com/pub/cygwinx/x86/XWin.20140509-git-c4a16a6606868d3e.exe.bz2 Can't believe it, great! Works exactly as it should (just with the standard configuration, X :0 -multiwindow)!! Now I just hope that this 'patch' somehow finds its way into the trunk ;-) Luke -- 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 ignores all parameters related to multiple monitors
On 06/05/2014 22:54, Lukas Haase wrote: On 2014-05-05 13:03, Jon TURNEY wrote: On 04/05/2014 06:56, Lukas Haase wrote: I use Cygwin/X to display a CAD application on my Windows cient. For some reason new windows always open on the secondary display and I always need to manually drag them to my primary display. That's sooo annoying (since UNIX applications tend to open new windows on every action). I think that it's a bug that these windows are appearing at the top-left, rather than on the primary display, in that we don't distinguish well enough between the application asked us to place the window at 0x0 and the application didn't specify where to put the window It would help if you could give the name of this application, and can you install 'xprop', and show the output you get from running that, then clicking on one of the window which gets placed incorrectly. Sure. It's Cadence Virtuoso/ADE. The xprop output is: [...] WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 100 by 100 program specified maximum size: 3820 by 2500 Hmmm... There are 2 possible flags here: program specified location and user specified location (e.g. by using -geometry on the command line), and at the moment we honour them both. Now, it might be that the client expects to see some EWMH capabilities advertised by the multiwindow mode WM, the absence of which causes it to set this, or it only sets this after the window is placed, but if it always creates the window with that property, it's not clear how to fix this. (Just ignoring program specified location is tempting, but there are legitimate uses, for example a toolbar window which should be placed at the side) So, do you have an example of this working as you would like on a unix system, and what is the window manager is that case? I've built a snapshot [1], which adds a heuristic which ignores a 'program specified location' hint if the location is the origin, which you might like to try and see if that fixes your problem, but I'm not sure if that is the correct solution. (I also found a bug with how this hint is handled in 64-bit builds, but I don't think that affects you) [1] ftp://cygwin.com/pub/cygwinx/x86/XWin.20140508-git-c4a16a6606868d3e.exe.bz2 This is not how it behaves for me. Using -nomultiplemontiors, or an explicit -screen setting shows an appropriately sized root window when turning off Hide Root Window. (Although this is not terribly useful as you can move the Windows windows out of this area, which causes their contents to not be drawn) You are right. Further research shows me that my arguments never showed up in XWin.0.log. Maybe I there's a different bug here? I call XWin like this: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -nomultimonitors And this appears in XWin.0.log: XWin was started with the following command line: X :0 -multiwindow You need to quote the whole command after bash's -c flag, otherwise they are interpreted as additional flags to bash. See http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args for an example. However, unfortunately this does not change anything: You are right that when I uncheck Hide Root window, the black root window *only* covers the primary monitor. That's good. But windows are *still* opened at the second monitor! What's even worse (and pretty astonishing to me): All X windows are *only* displayed correctly on the *secondary* display with the command line above. On the primary display, the window frames are shown but the windows are not drawn (they are transparent) and they do not accept mouse/keyboard input. So it's completely the opposite as it is intended ... Yes, it seems there is also something wrong with the translation between Windows (which has 0,0 at the top-left of the primary monitor) and X (which has 0,0 at the top-left of the virtual screen) coordinate spaces here. But even if that was fixed, there is still the problem of how X windows are supposed to behave when moved off the virtual screen (not allowed to move? empty?) Because of that, assuming that I can fix your problem with correct window placement, I am inclined to just disable the combination of -multiwindow and -screen. -- 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: XWin ignores all parameters related to multiple monitors
Hi Jon, First of all, thank you so much for your effort! I am struggling for so long with the issue and I am so happy to see your encouragement here. On 2014-05-08 5:15, Jon TURNEY wrote: On 06/05/2014 22:54, Lukas Haase wrote: On 2014-05-05 13:03, Jon TURNEY wrote: [...] It would help if you could give the name of this application, and can you install 'xprop', and show the output you get from running that, then clicking on one of the window which gets placed incorrectly. Sure. It's Cadence Virtuoso/ADE. The xprop output is: [...] WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 100 by 100 program specified maximum size: 3820 by 2500 Hmmm... There are 2 possible flags here: program specified location and user specified location (e.g. by using -geometry on the command line), and at the moment we honour them both. Now, it might be that the client expects to see some EWMH capabilities advertised by the multiwindow mode WM, the absence of which causes it to set this, or it only sets this after the window is placed, but if it always creates the window with that property, it's not clear how to fix this. Thank you! I think I understand it (I am no X expert). (Just ignoring program specified location is tempting, but there are legitimate uses, for example a toolbar window which should be placed at the side) Sounds legitimate. Aside: Maybe it's possible to make this configurable via config or environment variable? (but I guess the X server does not see environment variables etc.) So, do you have an example of this working as you would like on a unix system, and what is the window manager is that case? I am not sure if I get the question. What I could do is to login via VNC and see how the windows are placed are if they are placed the correct way? Is this what you mean? Unfortunately I have no chance to install Cadence locally and run it from a local, dual monitor setup from Linux because Cadence is a proprietary, expensive tool. I've built a snapshot [1], which adds a heuristic which ignores a 'program specified location' hint if the location is the origin, which you might like to try and see if that fixes your problem, but I'm not sure if that is the correct solution. (I also found a bug with how this hint is handled in 64-bit builds, but I don't think that affects you) [1] ftp://cygwin.com/pub/cygwinx/x86/XWin.20140508-git-c4a16a6606868d3e.exe.bz2 Thanks so much for that! I have just the issue that the exe does not seem to work for me. Is there anything special I need to consider? I tried copying both, 63 and 32 bit versions to c:\cygwin\bin: 32 bit version gives: c:\cygwin\binXWin.new.32 XWin.new.32:./.libs/lt-XWin.c:233: FATAL: couldn't find XWin.new.32. And 64 bit gives: The application was unable to start correctly (0xc07b). Click OK to close the application. What bothers me is that my original XWin.exe has 2363943 Bytes (and the X icon) whereas your new versions are just 26624 and 27150 Byes (and no icon). c:\cygwin\binuname -a CYGWIN_NT-6.2-WOW64 think 1.7.29(0.272/5/3) 2014-04-07 13:44 i686 Cygwin [...] I call XWin like this: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -nomultimonitors And this appears in XWin.0.log: XWin was started with the following command line: X :0 -multiwindow You need to quote the whole command after bash's -c flag, otherwise they are interpreted as additional flags to bash. See http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args for an example. Thanks but I think I have tried that already. It may be hard to believe but: c:\cygwin\var\log\xwindel XWin.0.log c:\cygwin\var\log\xwinC:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -nomultimonitors -foobar c:\cygwin\var\log\xwinc:\cygwin\bin\head -n 10 XWin.0.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.15.1.0 OS: CYGWIN_NT-6.2-WOW64 think 1.7.29(0.272/5/3) 2014-04-07 13:44 i686 OS: Windows 8 [Windows NT 6.2 build 9200] (WoW64) Package: version 1.15.1-1 built 2014-04-16 XWin was started with the following command line: X :0 -multiwindow c:\cygwin\var\log\xwin I made sure that XWin was not running before and waited after the call until I saw the tray icon. [...] What's even worse (and pretty astonishing to me): All X windows are *only* displayed correctly on the *secondary* display with the command line above. On the primary display, the window frames are shown but the windows are not drawn (they are transparent) and they do not accept mouse/keyboard input. So it's completely the opposite as it is intended ... Yes, it seems there is also something wrong with the translation between Windows (which has 0,0 at the top-left of the primary monitor) and X (which has 0,0 at the top-left of the virtual screen) coordinate spaces here. I mean something different here
Re: XWin ignores all parameters related to multiple monitors
Hi Jon, Thanks for helping! On 2014-05-05 13:03, Jon TURNEY wrote: On 04/05/2014 06:56, Lukas Haase wrote: I use Cygwin/X to display a CAD application on my Windows cient. For some reason new windows always open on the secondary display and I always need to manually drag them to my primary display. That's sooo annoying (since UNIX applications tend to open new windows on every action). I'm assuming that your secondary display is to the left of your primary display. Yes. Secondary: builtin laptop display (on left) Primary: main monitor (on right) If I do Identify, the laptop display is identified as 1 and the main monitor as 2. I think that it's a bug that these windows are appearing at the top-left, rather than on the primary display, in that we don't distinguish well enough between the application asked us to place the window at 0x0 and the application didn't specify where to put the window It would help if you could give the name of this application, and can you install 'xprop', and show the output you get from running that, then clicking on one of the window which gets placed incorrectly. Sure. It's Cadence Virtuoso/ADE. The xprop output is: _WINDOWSWM_NATIVE_HWND(INTEGER) = 77728452 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x200178 bitmap id # of mask for icon: 0x200179 window id # of group leader: 0x21 _NET_WM_ICON(CARDINAL) =Icon (50 x 50): [...] _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 2097527 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_USER_TIME(CARDINAL) = 744838078 _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x200176 WM_CLIENT_LEADER(WINDOW): window id # 0x21 _NET_WM_PID(CARDINAL) = 24636 WM_LOCALE_NAME(STRING) = C WM_CLIENT_MACHINE(STRING) = corn WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 100 by 100 program specified maximum size: 3820 by 2500 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = Qt-subapplication, Virtuoso WM_ICON_NAME(STRING) = Virtuoso® Schematic Editor L Editing: project sch1 schematic on corn _NET_WM_ICON_NAME(UTF8_STRING) = Virtuoso® Schematic Editor L Editing: project sch1 schematic on corn WM_NAME(STRING) = Virtuoso® Schematic Editor L Editing: project sch1 schematic on corn _NET_WM_NAME(UTF8_STRING) = Virtuoso® Schematic Editor L Editing: project sch1 schematic on corn To avoid this, I want to disable the second monitor (and *only* use the primary). But whatever I do, XWin seems to ignore whatever I supply. For example, I start /usr/bin/startxwin.exe -- -nomultiplemonitors /usr/bin/startxwin.exe -- -screen 0 @1 -nomultiplemonitors /usr/bin/startxwin.exe -- -screen 0 @1 /usr/bin/startxwin.exe -- -mwextwm -screen 0 @1 -nomultiplemonitors and so on. Nothing works - everything as before. When I select Hide Root Window from the tray icon I see that the root window indeed covers both monitors. This is not how it behaves for me. Using -nomultiplemontiors, or an explicit -screen setting shows an appropriately sized root window when turning off Hide Root Window. (Although this is not terribly useful as you can move the Windows windows out of this area, which causes their contents to not be drawn) You are right. Further research shows me that my arguments never showed up in XWin.0.log. Maybe I there's a different bug here? I call XWin like this: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -nomultimonitors And this appears in XWin.0.log: XWin was started with the following command line: X :0 -multiwindow However, if I directly start the XServer, XWin.exe -screen 0 @1 -multiwindow -nomultimonitors it works: XWin was started with the following command line: XWin -screen 0 @1 -multiwindow -nomultimonitors Why does startxwin.exe does not pass the parameters to the XServer. However, unfortunately this does not change anything: You are right that when I uncheck Hide Root window, the black root window *only* covers the primary monitor. That's good. But windows are *still* opened at the second monitor! What's even worse (and pretty astonishing to me): All X windows are *only* displayed correctly on the *secondary* display with the command line above. On the primary display, the window frames are shown but the windows are not drawn (they are transparent) and they do not accept mouse/keyboard input. So it's completely the oppisite as it is intended ... Can you check if the screen dimensions reported by xdpyinfo match those you are requesting, and attach your /var/log/xwin/XWin.0.log? Hmm, I have here: [...] default screen number:0 number of screens:1 screen #0: dimensions
Re: XWin ignores all parameters related to multiple monitors
On 04/05/2014 06:56, Lukas Haase wrote: I use Cygwin/X to display a CAD application on my Windows cient. For some reason new windows always open on the secondary display and I always need to manually drag them to my primary display. That's sooo annoying (since UNIX applications tend to open new windows on every action). I'm assuming that your secondary display is to the left of your primary display. I think that it's a bug that these windows are appearing at the top-left, rather than on the primary display, in that we don't distinguish well enough between the application asked us to place the window at 0x0 and the application didn't specify where to put the window It would help if you could give the name of this application, and can you install 'xprop', and show the output you get from running that, then clicking on one of the window which gets placed incorrectly. To avoid this, I want to disable the second monitor (and *only* use the primary). But whatever I do, XWin seems to ignore whatever I supply. For example, I start /usr/bin/startxwin.exe -- -nomultiplemonitors /usr/bin/startxwin.exe -- -screen 0 @1 -nomultiplemonitors /usr/bin/startxwin.exe -- -screen 0 @1 /usr/bin/startxwin.exe -- -mwextwm -screen 0 @1 -nomultiplemonitors and so on. Nothing works - everything as before. When I select Hide Root Window from the tray icon I see that the root window indeed covers both monitors. This is not how it behaves for me. Using -nomultiplemontiors, or an explicit -screen setting shows an appropriately sized root window when turning off Hide Root Window. (Although this is not terribly useful as you can move the Windows windows out of this area, which causes their contents to not be drawn) Can you check if the screen dimensions reported by xdpyinfo match those you are requesting, and attach your /var/log/xwin/XWin.0.log? Separately, it's possible that we should do something better with the combination of -nomultiplemontors and -multiwindow, but it's not quite clear to me what. (See discussion [1]) [1] https://sourceware.org/ml/cygwin-xfree/2011-07/msg7.html -- 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/
XWin ignores all parameters related to multiple monitors
Hi, I use Cygwin/X to display a CAD application on my Windows cient. For some reason new windows always open on the secondary display and I always need to manually drag them to my primary display. That's sooo annoying (since UNIX applications tend to open new windows on every action). To avoid this, I want to disable the second monitor (and *only* use the primary). But whatever I do, XWin seems to ignore whatever I supply. For example, I start /usr/bin/startxwin.exe -- -nomultiplemonitors /usr/bin/startxwin.exe -- -screen 0 @1 -nomultiplemonitors /usr/bin/startxwin.exe -- -screen 0 @1 /usr/bin/startxwin.exe -- -mwextwm -screen 0 @1 -nomultiplemonitors and so on. Nothing works - everything as before. When I select Hide Root Window from the tray icon I see that the root window indeed covers both monitors. Any suggestions? Thanks, Luke -- 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/
windows 7 cygwin/XWin session dies
Hello, I run my cygwin/XWin.exe session on Windows 7 Professional and this session dies when I iconify it during some time (let'say 20 min). I think the problem is not to iconify it but more to not do anything. It is very uncomfortable because I have to relaunch it every time I do something else (emails, internet,...) more than about 20 minutes... I do not understand why the X session crashes... Could anyone help me ? It seems there is something with : XDM: Alive response indicates session dead, declaring session dead but I do not know which parameter I have to change to modify this behaviour... Here is the log file of the session : Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.9.2.0 (10902000) Build Date: 2010-11-03 XWin was started with the following command line: /usr/bin/XWin -query asterix ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1920 h 1200 winInitializeDefaultScreens - native DPI x 96 y 96 [ 5918.085] winInitializeScreens - 1 [ 5918.085] winInitializeScreen - 0 [ 5918.085] (II) xorg.conf is not supported [ 5918.085] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 5918.085] LoadPreferences: /home/caubel/.XWinrc not found [ 5918.085] LoadPreferences: Loading /etc/X11/system.XWinrc [ 5918.085] LoadPreferences: Done parsing the configuration file... [ 5918.085] winGetDisplay: DISPLAY=:0.0 [ 5918.085] winDetectSupportedEngines - Windows NT/2000/XP [ 5918.116] winDetectSupportedEngines - DirectDraw installed [ 5918.116] winDetectSupportedEngines - Allowing PrimaryDD [ 5918.116] winDetectSupportedEngines - DirectDraw4 installed [ 5918.116] winDetectSupportedEngines - Returning, supported engines 001f [ 5918.131] winSetEngine - Using Shadow DirectDraw NonLocking [ 5918.131] winScreenInit - Using Windows display depth of 32 bits per pixel [ 5918.147] winFinishScreenInitFB - Masks: 00ff ff00 00ff [ 5918.147] Screen 0 added at virtual desktop coordinate (0,0). [ 5918.147] MIT-SHM extension disabled due to lack of kernel support [ 5918.163] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 5918.194] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [ 5918.194] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 5918.506] winPointerWarpCursor - Discarding first warp: 957 566 [ 5918.506] (--) 8 mouse buttons found [ 5918.506] (--) Setting autorepeat to delay=500, rate=31 [ 5918.506] (--) Windows keyboard layout: 040C (040c) French, type 4 [ 5918.506] (--) Found matching XKB configuration French (Standard) [ 5918.506] (--) Model = pc105 Layout = fr Variant = none Options = none [ 5918.506] Rules = base Model = pc105 Layout = fr Variant = none Options = none [ 5919.286] winProcEstablishConnection - Hello [ 5919.286] winInitClipboard () [ 5919.286] winProcEstablishConnection - winInitClipboard returned. [ 5919.286] winClipboardProc - Hello [ 5919.286] DetectUnicodeSupport - Windows NT/2000/XP [ 5919.301] winGetDisplay: DISPLAY=:0.0 [ 5919.301] winClipboardProc - DISPLAY=:0.0 [ 5919.301] winClipboardProc - XOpenDisplay () returned and successfully opened the display. [ 6240.102] XDM: Alive response indicates session dead, declaring session dead [ 6240.102] winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. [ 6240.102] winClipboardProc - XDestroyWindow succeeded. [ 6240.102] winClipboardProc - Clipboard disabled - Exit from server [ 6240.149] winDeinitMultiWindowWM - Noting shutdown in progress Thanks a lot in advance ! Best regards, Arnaud -- 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 cygwin/XWin session dies
On 22/04/2014 11:00, Arnaud Caubel wrote: I run my cygwin/XWin.exe session on Windows 7 Professional and this session dies when I iconify it during some time (let'say 20 min). I think the problem is not to iconify it but more to not do anything. It is very uncomfortable because I have to relaunch it every time I do something else (emails, internet,...) more than about 20 minutes... I do not understand why the X session crashes... Could anyone help me ? It seems there is something with : XDM: Alive response indicates session dead, declaring session dead but I do not know which parameter I have to change to modify this behaviour... Release: 1.9.2.0 (10902000) Build Date: 2010-11-03 This is quite an old version. While I am not aware of any fixes in this area, you might like to try with the current version. [ 6240.102] XDM: Alive response indicates session dead, declaring session dead This means I sent an XDMCP keepalive for the current session to the XDM server, but it's response said that the session wasn't alive. One question I have is if your machine running XWin is idle, and going into a sleep state before this problem occurs? If that is the case, that may be the problem, as XDM will, by default, periodically test if it can contact the display and declare the session dead if that fails. If your display manager is XDM, that can be turned off by setting the DisplayManager.DISPLAY.pingInterval resource to 0. Other display managers may have similar settings. Alternatively, you could arrange for sleeping to be suspended while the X server is running (It seems on Win7 or later you can use powercfg -requestsoverride to prevent sleep while a specified program is running, or there are several simple utilities available which prevent suspend while they are running) If that is not the case, the XDM logs on the XDM host might be informative, if you have access to them. Failing that, you could use wireshark or similar to monitor the XDMCP protocol interactions. -- 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: Problem with Multi-Key Sequences... They Seem To Be Filtered Out By XWin
On 06/03/2014 22:25, Cutler, David (NonStop) wrote: I downloaded a new copy of Cygwin in the last 5 days (effectively started from scratch) and am trying to use XWin on a Windows 7 virtual machine running an old proprietary X program (it's called x6530 which is a terminal emulator for a proprietary terminal built originally by Tandem Computers and now owned by Hewlett Packard.) I start up the server and window manager using the following command: /usr/bin/setsid \ /usr/bin/XWin \ -mwextwm \ -multimonitors \ -internalwm \ -nowinkill \ While probably not the cause of your problems, -mwextwm is an experimental option and -internalwm is undocumented. I think you should get the same effect with just '-multiwindow -nowinkill' I'm trying to use multi-key sequences like Control_L-Alt_L-F6, Shift_L-Control_L-F6, etc. I do see that xev recognizes these sequences but the Control_L and Alt_L keys seem to be filtered out when I run x6530. All it seems to get is F6 or Shift_L-F6. I've tried different window managers, run /usr/bin/XWin directly, used the right-hand modification keys like Control_R, etc. and no matter what I try, I see the same filtering behavior in x6530.I have recently used exceed (formally owned by Hummingbird) with x6530 and the Control_L and Alt_L keys are passed to x6530 as expected so my suspicion is that XWin is responsible for the unwanted behavior of filtering out the keys like Control_L and Alt_L keys. Is this the case? Is there a way to get these sequences unfiltered. The evidence doesn't really support your conclusion: If one X client (xev) gets these key events, why would the X server not send them to a different X client (x6530)? However, it's perfectly possibly that they aren't sent in the expected form, or some other problem. I guess that x6530 is running on a remote host, so the details of that remote host might be pertinent. FAQ 5.1.8 [1] and the linked email thread may be relevant. If you still have access to the working setup, you might want to compare the xev output for these keys to see if there any differences. You might also consider using wireshark, xmon or xscope to examine the protocol interactions between client and server to see if there is any difference there. If there is additional information I can provide, please let me know. It would be nice to see /var/log/xwin/XWin.0.log just to see what keyboard configuration is being used by the X server etc. [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#alt-gr-with-old-x -- 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/
Problem with Multi-Key Sequences... They Seem To Be Filtered Out By XWin
Hello, I downloaded a new copy of Cygwin in the last 5 days (effectively started from scratch) and am trying to use XWin on a Windows 7 virtual machine running an old proprietary X program (it's called x6530 which is a terminal emulator for a proprietary terminal built originally by Tandem Computers and now owned by Hewlett Packard.) I start up the server and window manager using the following command: /usr/bin/setsid \ /usr/bin/XWin \ -mwextwm \ -multimonitors \ -internalwm \ -nowinkill \ I'm trying to use multi-key sequences like Control_L-Alt_L-F6, Shift_L-Control_L-F6, etc. I do see that xev recognizes these sequences but the Control_L and Alt_L keys seem to be filtered out when I run x6530. All it seems to get is F6 or Shift_L-F6. I've tried different window managers, run /usr/bin/XWin directly, used the right-hand modification keys like Control_R, etc. and no matter what I try, I see the same filtering behavior in x6530.I have recently used exceed (formally owned by Hummingbird) with x6530 and the Control_L and Alt_L keys are passed to x6530 as expected so my suspicion is that XWin is responsible for the unwanted behavior of filtering out the keys like Control_L and Alt_L keys. Is this the case? Is there a way to get these sequences unfiltered. If there is additional information I can provide, please let me know. Thanks for any information you can provide. -David Cutler -- 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/
XWin hangs connecting to SunOS 5.11
Greetings! I have a SunOS 5.11, jcabrera@whale:~$ uname -a SunOS whale 5.11 11.1 i86pc i386 i86pc which has X installed. One of the folks that uses this machine connects = ok with XMing and putty, but I am trying to use it with XWin and the = display stays black for ever. I am using these two commands, xwin :0 -clipboard -query 13.121.188.152 -fp tcp/13.121.188.152:7100 and this one, xwin :0 -clipboard -query 13.121.188.152 they both connect, but no actual display from the SunOS display in the = PC, but just a dark screen. I have enabled xhost xhost + any other thoughts? Any help would be greatly appreciated. Thanks. josé -- 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 hangs connecting to SunOS 5.11
Attached is the log From: jose isaias cabrera wrote... Greetings! I have a SunOS 5.11, jcabrera@whale:~$ uname -a SunOS whale 5.11 11.1 i86pc i386 i86pc which has X installed. One of the folks that uses this machine connects = ok with XMing and putty, but I am trying to use it with XWin and the = display stays black for ever. I am using these two commands, xwin :0 -clipboard -query 13.121.188.152 -fp tcp/13.121.188.152:7100 and this one, xwin :0 -clipboard -query 13.121.188.152 they both connect, but no actual display from the SunOS display in the = PC, but just a dark screen. I have enabled xhost xhost + any other thoughts? Any help would be greatly appreciated. Thanks. josé -- 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/ XWin.0.log Description: Binary data -- 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 hangs connecting to SunOS 5.11
jose isaias cabrera wrote... Attached is the log From: jose isaias cabrera wrote... Greetings! I have a SunOS 5.11, jcabrera@whale:~$ uname -a SunOS whale 5.11 11.1 i86pc i386 i86pc which has X installed. One of the folks that uses this machine connects = ok with XMing and putty, but I am trying to use it with XWin and the = display stays black for ever. I am using these two commands, xwin :0 -clipboard -query 13.121.188.152 -fp tcp/13.121.188.152:7100 and this one, xwin :0 -clipboard -query 13.121.188.152 they both connect, but no actual display from the SunOS display in the = PC, but just a dark screen. I have enabled xhost xhost + any other thoughts? Any help would be greatly appreciated. Thanks. josé -- 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/ So, has anyone being able to connect to a SunOS 5.11 from Windows XP using cygwin XWin? If no one has, then, I will stop and see other options, but I would like to be able to do this with cygwin and not any other tool. I know cygwin pretty well and don't want to move. Thanks for the support. Oh, I tried these other options, Commented xdm DisplayManager.requestPort: 0 (!DisplayManager.requestPort: 0) Also added the ip and hostname of the window client to /etc/hosts and still no success. And also tried this command, xwin :0 -clipboard -query 13.121.188.152 -from 13.142.1.82 -fp tcp/13.121.188.152:7100 See attached log. Thanks for your support. josé XWin.0.log Description: Binary data -- 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 1.14.2 (64 bit) extreme memory page faulting
snip Trying again; last time i tried it was looking like CentOS was going to skip the 5.9 release entirely... It seems it is there now and (so far) has two of the previously missing dependencies... we will see how far i get... --- Erik And that idea crashed and burned badly... After much googling and trying to force-fit the pieces anyway, it quickly became apparent that if I succeeded I would by then be running a Fedora system rather than CentOS; IS team here would have had my hide for breakfast... Next attempt: trying to get a test VM for Ubuntu or Mint; IS team may have my hide just for asking that one... Erik -- 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 1.14.2 (64 bit) extreme memory page faulting
On 04/10/2013 9:21 AM, Erik Soderquist wrote: if I succeeded I would by then be running a Fedora system rather than CentOS; IS team here would have had my hide for breakfast... Next attempt: trying to get a test VM for Ubuntu or Mint; IS team may have my hide just for asking that one... I suppose all of this comes in the name of security ? Sounds like you guys have the IT equivalent of the TSA... (my condolences to you and your colleagues) Ryan -- 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 1.14.2 (64 bit) extreme memory page faulting
On Fri, Oct 4, 2013 at 10:03 AM, Ryan Johnson ryan.john...@cs.utoronto.ca wrote: On 04/10/2013 9:21 AM, Erik Soderquist wrote: if I succeeded I would by then be running a Fedora system rather than CentOS; IS team here would have had my hide for breakfast... Next attempt: trying to get a test VM for Ubuntu or Mint; IS team may have my hide just for asking that one... I suppose all of this comes in the name of security ? Sounds like you guys have the IT equivalent of the TSA... (my condolences to you and your colleagues) Ryan Actually they are quite honest about it being purely policy enforcement and software auditing. We're all network techs here, and are responsible for securing our own systems. --- Erik -- I do not think any of us are truly sane, Caleb. Not even you. Courage is not sanity. Being willing to die for someone else is not sanity. ... Love is not sane, nor is faith. ... If sanity lacks those things, Caleb, I want no part of it. -- Alexandria Terri in Weaving the Wyvern by Alexis Desiree Thorne - http://alexisthorne.webs.com/ -- 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 1.14.2 (64 bit) extreme memory page faulting
On 02/10/2013 7:55 PM, Erik Soderquist wrote: On Wed, Oct 2, 2013 at 6:51 PM, Ryan Johnson ryan.john...@cs.utoronto.ca wrote: I doubt it's an X-server code issue. You tried it on too many machines with problems, and too many other people aren't spamming the list about this, which suggests it's something on your side (like BLODA). Further, the only cygwin bug I've known to cause lots of paging was plugged months ago (it had to do with sparse executable files and should have been irrelevant for this situation anyway). The only (known) BLODA I have from that list is the McAfee A/V-firewall, which I can't remove, but I believe was completely disabled by the above described method. Unfortunately, McAfee is one of the worst offenders in my experience [1]. I seriously doubt you can disable it completely from user space, given its habits of interposing on device drivers and burrowing into other kernel bits [2]. [1] IMO it's a cure that's worse than the disease, but that's a rant for a different thread. [2] McAfee actually sued MS for anticompetitive behavior a while back, after the latter closed a bunch of security loopholes in the kernel that virus-writers love but McAfee also depended on (including the interrupt dispatch table IIRC). My advice: check out the cygwin FAQ about BLODA, uninstall anything listed there (or install a fresh VM image somewhere without those) and try again. If it's still a problem, somebody more familiar with X than me will have to take over... If I can get the authorization for a VM test without A/V, I will and the results will be posted here either way. Thank you for your time in looking at this. Good luck! Ryan -- 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 1.14.2 (64 bit) extreme memory page faulting
snip The only (known) BLODA I have from that list is the McAfee A/V-firewall, which I can't remove, but I believe was completely disabled by the above described method. Unfortunately, McAfee is one of the worst offenders in my experience [1]. I seriously doubt you can disable it completely from user space, given its habits of interposing on device drivers and burrowing into other kernel bits [2]. [1] IMO it's a cure that's worse than the disease, but that's a rant for a different thread. [2] McAfee actually sued MS for anticompetitive behavior a while back, after the latter closed a bunch of security loopholes in the kernel that virus-writers love but McAfee also depended on (including the interrupt dispatch table IIRC). ... So fixing security failures is 'anticompetitive' in McAfee's book?? Wow... That is the kind of business that if i had the funds I would buy just to dismantle... I knew they were bad but didn't know they were *that* bad. snip there (or install a fresh VM image somewhere without those) and try again. If it's still a problem, somebody more familiar with X than me will have to take over... If I can get the authorization for a VM test without A/V, I will and the results will be posted here either way. Thank you for your time in looking at this. Good luck! Ryan Installed a fresh VM with a Windows XP 64 bit ISO, sp2 already applied. VM has 512 MB ram, and the only package I installed after the OS was cygwin. Issue presents in this environment as soon as Firefox connects/starts. Page Faults Delta over 5,000 minimum anytime I'm doing anything in Firefox, including typing this message, usually over 10,000. Then I went to the services applet and started disabling anything not needed to run the X server and get the connection to/from the remote host. Once nearly everything was disabled, i rebooted the VM. Currently there are only four Windows services running. They are: CYGWIN sshd, DHCP Client, Plug and Play, and Remote Procedure Call (RPC). Issue still presents. I've attached the XWin log and the cygcheck output from the VM. --- Erik vm_XWin.4.log Description: Binary data vm_cygcheck.out Description: Binary data -- 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 1.14.2 (64 bit) extreme memory page faulting
snip Installed a fresh VM with a Windows XP 64 bit ISO, sp2 already applied. VM has 512 MB ram, and the only package I installed after the OS was cygwin. snip Followup: I confirmed that my VM host's environment's memory setting is set to lock all VM guest memory into physical ram, and doubled the VM's ram. No difference in results, issue still presents. --- Erik -- 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 1.14.2 (64 bit) extreme memory page faulting
On 03/10/2013 11:44 AM, Erik Soderquist wrote: Installed a fresh VM with a Windows XP 64 bit ISO, sp2 already applied. VM has 512 MB ram, and the only package I installed after the OS was cygwin. Issue presents in this environment as soon as Firefox connects/starts. Page Faults Delta over 5,000 minimum anytime I'm doing anything in Firefox, including typing this message, usually over 10,000. I just fired up a 64-bit Ubuntu VM I had laying around, installed firefox, and tunneled it to cygwin64/X on my win7-64 machine. X isn't even visible in the task manager when I sort descending by PF delta, CPU, or memory. This in spite of having half a dozen tabs with content (including ads, an html5 game, and a youtube video playing). Opening a couple dozen more empty tabs brought PFdelta up to the ~7k range, but the rate dropped back to ~0 as soon as the dust settled. Typing remains fully responsive, and I'm officially out of ideas. Ryan -- 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 1.14.2 (64 bit) extreme memory page faulting
snip I just fired up a 64-bit Ubuntu VM I had laying around, installed firefox, and tunneled it to cygwin64/X on my win7-64 machine. X isn't even visible in the task manager when I sort descending by PF delta, CPU, or memory. This in spite of having half a dozen tabs with content (including ads, an html5 game, and a youtube video playing). Opening a couple dozen more empty tabs brought PFdelta up to the ~7k range, but the rate dropped back to ~0 as soon as the dust settled. Typing remains fully responsive, and I'm officially out of ideas. Ryan That is the kind of responsiveness I expect, and what other people I've discussed this with experience, which is why I think it is something unusual in my setup or environment... Unfortunately, I'm currently unable to find it myself, and can reliably reproduce the issue even in a virgin environment. So far, the only common factors (that I see) across each of these has been my Linux host, (CentOS 5.8 at present) and my various tabs/accounts. However, I am at a complete loss as to even guess at how these could affect page faulting on the X server. For reference: on the Linux host, when the Windows host is experiencing these page faults, the Linux host is reporting 20-30% CPU usage overall, no swap usage. --- Erik -- 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 1.14.2 (64 bit) extreme memory page faulting
On 03/10/2013 12:27 PM, Ryan Johnson wrote: On 03/10/2013 11:44 AM, Erik Soderquist wrote: Installed a fresh VM with a Windows XP 64 bit ISO, sp2 already applied. VM has 512 MB ram, and the only package I installed after the OS was cygwin. Issue presents in this environment as soon as Firefox connects/starts. Page Faults Delta over 5,000 minimum anytime I'm doing anything in Firefox, including typing this message, usually over 10,000. I just fired up a 64-bit Ubuntu VM I had laying around, installed firefox, and tunneled it to cygwin64/X on my win7-64 machine. X isn't even visible in the task manager when I sort descending by PF delta, CPU, or memory. This in spite of having half a dozen tabs with content (including ads, an html5 game, and a youtube video playing). Opening a couple dozen more empty tabs brought PFdelta up to the ~7k range, but the rate dropped back to ~0 as soon as the dust settled. Typing remains fully responsive, and I'm officially out of ideas. Huh. I have 1.14.3, not 1.14.2... have you tried upgrading just in case that's the issue? Ryan -- 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 1.14.2 (64 bit) extreme memory page faulting
snip Huh. I have 1.14.3, not 1.14.2... have you tried upgrading just in case that's the issue? Ryan The virgin XP-64 VM is using 1.14.3, issue still presents. --- Erik -- 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 1.14.2 (64 bit) extreme memory page faulting
On 10/3/2013 12:46 PM, Erik Soderquist wrote: snip I just fired up a 64-bit Ubuntu VM I had laying around, installed firefox, and tunneled it to cygwin64/X on my win7-64 machine. X isn't even visible in the task manager when I sort descending by PF delta, CPU, or memory. This in spite of having half a dozen tabs with content (including ads, an html5 game, and a youtube video playing). Opening a couple dozen more empty tabs brought PFdelta up to the ~7k range, but the rate dropped back to ~0 as soon as the dust settled. Typing remains fully responsive, and I'm officially out of ideas. Ryan That is the kind of responsiveness I expect, and what other people I've discussed this with experience, which is why I think it is something unusual in my setup or environment... Unfortunately, I'm currently unable to find it myself, and can reliably reproduce the issue even in a virgin environment. So far, the only common factors (that I see) across each of these has been my Linux host, (CentOS 5.8 at present) and my various tabs/accounts. However, I am at a complete loss as to even guess at how these could affect page faulting on the X server. For reference: on the Linux host, when the Windows host is experiencing these page faults, the Linux host is reporting 20-30% CPU usage overall, no swap usage. Any chance of finding or setting up an alternate host to test against? -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xwin 1.14.2 (64 bit) extreme memory page faulting
On Thu, Oct 3, 2013 at 3:27 PM, Erik Soderquist erik.soderqu...@gmail.com wrote: snip Similar, to but different from Larry's suggestion, can you install Firefox on CentOS using the installer from Firefox itself, and not the distro version? I can imagine it could be something about flags or settings they used when compiling it. Jack I tried a couple times, and am willing to try again; however, I have not been able to resolve dependency conflicts to get a current version of Firefox to successfully install, let alone run. I fear this may have to wait for the host to be wiped and reloaded. Even then, I don't know what level of success I'll have, as currently it looks like it will be reloaded with CentOS 6. RHEL/CentOS are known for keeping solid and stable, not current... --- Erik Trying again; last time i tried it was looking like CentOS was going to skip the 5.9 release entirely... It seems it is there now and (so far) has two of the previously missing dependencies... we will see how far i get... --- Erik -- I do not think any of us are truly sane, Caleb. Not even you. Courage is not sanity. Being willing to die for someone else is not sanity. ... Love is not sane, nor is faith. ... If sanity lacks those things, Caleb, I want no part of it. -- Alexandria Terri in Weaving the Wyvern by Alexis Desiree Thorne - http://alexisthorne.webs.com/ -- 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 1.14.2 (64 bit) extreme memory page faulting
On 02/10/2013 2:50 PM, Erik Soderquist wrote: I am currently using the X server on a Windows 7 64 bit host for Firefox (in particular, occasional terminals too). While everything works, I am experiencing very severe memory page faulting causing the graphical interface to appear to hang for several seconds at a time, and when not appearing hung, responsiveness is very painfully slow, sometimes to the extent that I will type a paragraph and then sit back and watch as the graphical interface slowly displays what I typed at a rate of 1-2 characters per second. Is there really a Firefox build for cygwin/X ? Or are you tunneling from some other machine? Testing with antivirus and firewall enabled/disabled did not affect the results. (faq reference http://x.cygwin.com/docs/faq/cygwin-x-faq.html#poor-performance found during searches). If antivirus is a problem (as in BLODA), you probably need to uninstall, not just disable. They're usually too lazy to actually remove their hooks when off and just (try to) make the hooks become (mostly) no-ops instead. Not saying it's your problem, necessarily, just that merely disabling AV is not enough to rule it out. Also (not necessarily related to this particular problem), cygcheck reports a surprising selection of *nix-like utilities in c:\windows\bin. Whatever they are, they can't be helping. I doubt it's an X-server code issue. You tried it on too many machines with problems, and too many other people aren't spamming the list about this, which suggests it's something on your side (like BLODA). Further, the only cygwin bug I've known to cause lots of paging was plugged months ago (it had to do with sparse executable files and should have been irrelevant for this situation anyway). My advice: check out the cygwin FAQ about BLODA, uninstall anything listed there (or install a fresh VM image somewhere without those) and try again. If it's still a problem, somebody more familiar with X than me will have to take over... Ryan -- 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 1.14.2 (64 bit) extreme memory page faulting
On Wed, Oct 2, 2013 at 6:51 PM, Ryan Johnson ryan.john...@cs.utoronto.ca wrote: On 02/10/2013 2:50 PM, Erik Soderquist wrote: I am currently using the X server on a Windows 7 64 bit host for Firefox (in particular, occasional terminals too). snip Is there really a Firefox build for cygwin/X ? Or are you tunneling from some other machine? My apologies; Firefox is running on a CentOS host and I have tried both raw X and tunneled through ssh. I am currently tunneling though ssh as the raw X was a test only to see if it was a tunnel issue. Testing with antivirus and firewall enabled/disabled did not affect the results. (faq reference http://x.cygwin.com/docs/faq/cygwin-x-faq.html#poor-performance found during searches). If antivirus is a problem (as in BLODA), you probably need to uninstall, not just disable. They're usually too lazy to actually remove their hooks when off and just (try to) make the hooks become (mostly) no-ops instead. Not saying it's your problem, necessarily, just that merely disabling AV is not enough to rule it out. Unfortunately, uninstall is not an option for me. Corporate Policy prevents it on several levels. However, my disable of the A/V-firewall packages was by going into the Windows Services applets and disabling the services there and via a couple registry hacks and then rebooting so the A/V and firewall pieces could not load to start with. They are as ruled out as I can make them currently. I will look into the possibility of a VM to test without them entirely and see if i can still reproduce the issue. Also (not necessarily related to this particular problem), cygcheck reports a surprising selection of *nix-like utilities in c:\windows\bin. Whatever they are, they can't be helping. Those existed only on the current test machine. In theory, since they are later in the path in the cygwin environment, they should never be executed unless called by full path, but I do appreciate it being pointed out. I should have mentioned their existence on this machine to start with. I doubt it's an X-server code issue. You tried it on too many machines with problems, and too many other people aren't spamming the list about this, which suggests it's something on your side (like BLODA). Further, the only cygwin bug I've known to cause lots of paging was plugged months ago (it had to do with sparse executable files and should have been irrelevant for this situation anyway). The only (known) BLODA I have from that list is the McAfee A/V-firewall, which I can't remove, but I believe was completely disabled by the above described method. My advice: check out the cygwin FAQ about BLODA, uninstall anything listed there (or install a fresh VM image somewhere without those) and try again. If it's still a problem, somebody more familiar with X than me will have to take over... Ryan If I can get the authorization for a VM test without A/V, I will and the results will be posted here either way. Thank you for your time in looking at this. --- Erik -- 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 and xwin and super and hyper
On 21/06/2013 16:56, J. David Boyd wrote:
Jon TURNEY writes:
On 19/06/2013 22:27, J. David Boyd wrote:
I can get my capslock key to be super with the command line 'setxkbmap
-option
caps:super', but I can't get 'setxkbmap -option altwin:hyper_win' to do
anything.
Running 'setxkbmap -print' shows both options as being set, but the win keys
still act as the win key.
Is there something else I need to do so windows lets go of these keys?
Yes.
Again, let me refer you to [1]. The operative sentence is:
(Note that mapping the Windows keys to hyper also requires the -keyhook
option, so that the X server sees those keys before the Windows shell)
One thing I failed to mention there is that without any keymap options the
keymap should give you super on the windows keys, but you will still need
-keyhook X server option to enable the X server to see the key.
[1] http://cygwin.com/ml/cygwin/2012-03/msg00427.html
I can get everything working up to the point I start emacs.
The output from 'setxkbmap -print' is:
xkb_keymap {
xkb_keycodes { include xfree86+aliases(qwerty) };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include
pc+us+inet(pc105)+altwin(alt_super_win)+capslock(hyper) };
xkb_geometry { include pc(pc105) };
};
and if I run XEV, and press capslock I get:
KeyPress event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8145997, (504,324), root:(2162,400),
state 0x0, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8146122, (504,324), root:(2162,400),
state 0x40, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
and if I press Left Windows key I get:
KeyPress event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8148993, (504,324), root:(2162,400),
state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8149102, (504,324), root:(2162,400),
state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
All perfect so far.
So, when I start up emacs, and press C-h k, then, for example, Capslock-d,
(hyper-d) I get 'H-d is undefined'. Yeah.
Then I press C-h k, then Left-Win-d, (super-d), I get 'H-d is undefined', and
not 's-d is undefined', which is what I expected to see.
Any ideas how I might resolve this?
Looking at the xev output for Hyper-d and Super-d, it seems they have the same
state (modifier) value.
This is because xkeyboard-config seems to place super and hyper on the same
modifier, mod4, as can be seen looking at the output of 'xmodmap -pm'
$ xmodmap -pm
xmodmap: up to 5 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock
control Control_L (0x25), Control_R (0x6d)
mod1Alt_L (0x40), Alt_R (0x74), Meta_L (0x9c)
mod2Num_Lock (0x4d)
mod3
mod4Hyper_L (0x42), Super_L (0x73), Super_R (0x75), Super_L
(0x7f), Hyper_L (0x80)
mod5Mode_switch (0x8), ISO_Level3_Shift (0x7c)
And it seems that emacs only looks at the modifier state, not the actual
proceeding keypress.
A workaround for this is to move Hyper_L to the unused mod3 modifier.
$ xmodmap -e remove mod4 = Hyper_L
$ xmodmap -e add mod3 = Hyper_L
$ xmodmap -pm
xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock
control Control_L (0x25), Control_R (0x6d)
mod1Alt_L (0x40), Alt_R (0x74), Meta_L (0x9c)
mod2Num_Lock (0x4d)
mod3Hyper_L (0x42), Hyper_L (0x80)
mod4Super_L (0x73), Super_R (0x75), Super_L (0x7f)
mod5Mode_switch (0x8), ISO_Level3_Shift (0x7c)
It's probably a bug that this doesn't work as expected, but I'm not sure in
what.
--
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: cygwin and xwin and super and hyper
Jon TURNEY jon.tur...@dronecode.org.uk writes: On 21/06/2013 16:56, J. David Boyd wrote: Jon TURNEY writes: On 19/06/2013 22:27, J. David Boyd wrote: All perfect so far. So, when I start up emacs, and press C-h k, then, for example, Capslock-d, (hyper-d) I get 'H-d is undefined'. Yeah. Then I press C-h k, then Left-Win-d, (super-d), I get 'H-d is undefined', and not 's-d is undefined', which is what I expected to see. Any ideas how I might resolve this? Looking at the xev output for Hyper-d and Super-d, it seems they have the same state (modifier) value. This is because xkeyboard-config seems to place super and hyper on the same modifier, mod4, as can be seen looking at the output of 'xmodmap -pm' $ xmodmap -pm xmodmap: up to 5 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_R (0x74), Meta_L (0x9c) mod2Num_Lock (0x4d) mod3 mod4Hyper_L (0x42), Super_L (0x73), Super_R (0x75), Super_L (0x7f), Hyper_L (0x80) mod5Mode_switch (0x8), ISO_Level3_Shift (0x7c) And it seems that emacs only looks at the modifier state, not the actual proceeding keypress. A workaround for this is to move Hyper_L to the unused mod3 modifier. $ xmodmap -e remove mod4 = Hyper_L $ xmodmap -e add mod3 = Hyper_L $ xmodmap -pm xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_R (0x74), Meta_L (0x9c) mod2Num_Lock (0x4d) mod3Hyper_L (0x42), Hyper_L (0x80) mod4Super_L (0x73), Super_R (0x75), Super_L (0x7f) mod5Mode_switch (0x8), ISO_Level3_Shift (0x7c) It's probably a bug that this doesn't work as expected, but I'm not sure in what. Thanks, that just what I did, and now it works fine. -- 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 and xwin and super and hyper
Jon TURNEY jon.tur...@dronecode.org.uk writes:
On 19/06/2013 22:27, J. David Boyd wrote:
I can get my capslock key to be super with the command line 'setxkbmap
-option
caps:super', but I can't get 'setxkbmap -option altwin:hyper_win' to do
anything.
Running 'setxkbmap -print' shows both options as being set, but the win keys
still act as the win key.
Is there something else I need to do so windows lets go of these keys?
Yes.
Again, let me refer you to [1]. The operative sentence is:
(Note that mapping the Windows keys to hyper also requires the -keyhook
option, so that the X server sees those keys before the Windows shell)
One thing I failed to mention there is that without any keymap options the
keymap should give you super on the windows keys, but you will still need
-keyhook X server option to enable the X server to see the key.
[1] http://cygwin.com/ml/cygwin/2012-03/msg00427.html
I can get everything working up to the point I start emacs.
The output from 'setxkbmap -print' is:
xkb_keymap {
xkb_keycodes { include xfree86+aliases(qwerty) };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include
pc+us+inet(pc105)+altwin(alt_super_win)+capslock(hyper) };
xkb_geometry { include pc(pc105) };
};
and if I run XEV, and press capslock I get:
KeyPress event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8145997, (504,324), root:(2162,400),
state 0x0, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8146122, (504,324), root:(2162,400),
state 0x40, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
and if I press Left Windows key I get:
KeyPress event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8148993, (504,324), root:(2162,400),
state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8149102, (504,324), root:(2162,400),
state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
All perfect so far.
So, when I start up emacs, and press C-h k, then, for example, Capslock-d,
(hyper-d) I get 'H-d is undefined'. Yeah.
Then I press C-h k, then Left-Win-d, (super-d), I get 'H-d is undefined', and
not 's-d is undefined', which is what I expected to see.
Any ideas how I might resolve this?
Dave
--
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 and xwin and super and hyper
On 19/06/2013 22:27, J. David Boyd wrote: I can get my capslock key to be super with the command line 'setxkbmap -option caps:super', but I can't get 'setxkbmap -option altwin:hyper_win' to do anything. Running 'setxkbmap -print' shows both options as being set, but the win keys still act as the win key. Is there something else I need to do so windows lets go of these keys? Yes. Again, let me refer you to [1]. The operative sentence is: (Note that mapping the Windows keys to hyper also requires the -keyhook option, so that the X server sees those keys before the Windows shell) One thing I failed to mention there is that without any keymap options the keymap should give you super on the windows keys, but you will still need -keyhook X server option to enable the X server to see the key. [1] http://cygwin.com/ml/cygwin/2012-03/msg00427.html -- 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/
cygwin and xwin and super and hyper
I can get my capslock key to be super with the command line 'setxkbmap -option caps:super', but I can't get 'setxkbmap -option altwin:hyper_win' to do anything. Running 'setxkbmap -print' shows both options as being set, but the win keys still act as the win key. Is there something else I need to do so windows lets go of these keys? Dave -- 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: 1.14.0-2 XWin does not start, though 1.13.2.0 X Server latest snapshot 20130210-git works
On 2013-05-06 21:52, Vasiliy wrote: - 1.14.0-2 XWin X Server installation is broken after replacing 1.13 in Cygwin (1.17.18 / 1.17.19s) Do you have only a 3-button mouse? If so, the issue is known and a fix is already queued up for 1.14.1-1. Yaakov -- 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: 1.14.0-2 XWin does not start, though 1.13.2.0 X Server latest snapshot 20130210-git works
On 07/05/2013 03:52, Vasiliy wrote:
- 1.14.0-2 XWin X Server installation is broken after replacing 1.13
in Cygwin (1.17.18 / 1.17.19s)
- no software interfering with Cygwin is installed
- reinstalling xorg-server doesn't help
- with the latest Cygwin snapshot (20130503) it might cause 1.14.0-2
XWin core dump
Please try again with the Xserver 1.14.1-1 test release I uploaded today.
XWin-backtrace.log contains:
1.17.18-backtrace
1.17.19s-backtrace (XWin.0.log)
Thanks for these. Unfortunately these aren't as useful as they might be, due
to some recent change which the instructions at
http://x.cygwin.com/devel/backtrace.html haven't caught up with yet.
$ gdb --args /usr/bin/XWin -multiwindow -wgl
[...]
Program received signal SIGSYS, Bad system call.
CheckForShmSyscall () at /usr/src/debug/xorg-server-1.14.0-2/Xext/shm.c:188
188 if (shmid != -1) {
When running the X server under gdb, to avoid stopping with SIGSYS when
checking if shared memory is available, either cygserver needs to be running,
or gdb needs to be told to not stop on SIGSYS with 'handle SIGSYS nostop'
before the program is started.
--
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/
Fwd: 1.14.0-2 XWin does not start, though 1.13.2.0 X Server latest snapshot 20130210-git works
Works Just Fine For Me
http://cygwin.com/acronyms/#WJFFM
Thanks for the test release, and your suggestions.
Kind regards,
Vasiliy
PS. Please, update also the instructions at
http://x.cygwin.com/devel/backtrace.html
On Tue, May 7, 2013 at 6:35 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote:
On 07/05/2013 03:52, Vasiliy wrote:
- 1.14.0-2 XWin X Server installation is broken after replacing 1.13
in Cygwin (1.17.18 / 1.17.19s)
- no software interfering with Cygwin is installed
- reinstalling xorg-server doesn't help
- with the latest Cygwin snapshot (20130503) it might cause 1.14.0-2
XWin core dump
Please try again with the Xserver 1.14.1-1 test release I uploaded today.
XWin-backtrace.log contains:
1.17.18-backtrace
1.17.19s-backtrace (XWin.0.log)
Thanks for these. Unfortunately these aren't as useful as they might be, due
to some recent change which the instructions at
http://x.cygwin.com/devel/backtrace.html haven't caught up with yet.
$ gdb --args /usr/bin/XWin -multiwindow -wgl
[...]
Program received signal SIGSYS, Bad system call.
CheckForShmSyscall () at /usr/src/debug/xorg-server-1.14.0-2/Xext/shm.c:188
188 if (shmid != -1) {
When running the X server under gdb, to avoid stopping with SIGSYS when
checking if shared memory is available, either cygserver needs to be running,
or gdb needs to be told to not stop on SIGSYS with 'handle SIGSYS nostop'
before the program is started.
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
XWin.log
Description: Binary data
XWin.0.log
Description: Binary data
--
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: Is there a way to spawn processes from the XWin login shell?
Actually, I use windows shortcut with the following command line: C:\cygwin\bin\run.exe /usr/bin/zsh -l -c 'exec startxwin' I'm guessing the startxwin is responsible for setting up the login environment. Still, the only way to start processes inheriting from the login shell seems to be by using the tray icon. It would be nice to have a startxwin flag that did that, eg: startxwin -command 'urxvtc -e zsh' # instead of starting a new xwin instance, this would send a command to be spawned by the running login shell which would have the same effect as select a .XWinrc menu entry with the following 'urxvtc -e zsh' On Fri, Mar 22, 2013 at 9:02 PM, Thiago Padilha tpadilh...@gmail.com wrote: XWin uses a login shell to configure its environment when it starts up, and processes spawned from the tray icon inherit XWin environment so they don't have to be spawned from login shells. Is there a way to achieve the same effect without using a tray icon? For example, can I have a desktop shortcut that launches a terminal emulator with a simple interactive(non-login) shell and still have it inherit the currently running XWin environment like it was started from the tray icon? -- 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: Is there a way to spawn processes from the XWin login shell?
On 23/03/2013 00:02, Thiago Padilha wrote: XWin uses a login shell to configure its environment when it starts up, and processes spawned from the tray icon inherit XWin environment so they don't have to be spawned from login shells. Is there a way to achieve the same effect without using a tray icon? Yes. For example, can I have a desktop shortcut that launches a terminal emulator with a simple interactive(non-login) shell and still have it inherit the currently running XWin environment like it was started from the tray icon? To inherit implies that it is a child of XWin, so no. However, you can create a process with an identical login environment by requesting the shell to create a login environment. On 27/03/2013 15:52, Thiago Padilha wrote: Actually, I use windows shortcut with the following command line: C:\cygwin\bin\run.exe /usr/bin/zsh -l -c 'exec startxwin' I'm guessing the startxwin is responsible for setting up the login environment. Still, the only way to start processes inheriting from the login shell seems to be by using the tray icon. Reading 'man zsh' would save you having to guess. The login environment is nothing to do with startxwin. You are requesting zsh to create the login environment with the '-l' flag. -- 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: Is there a way to spawn processes from the XWin login shell?
As you have shown me, I probably overcomplicated my question. It would have been simpler if I asked: 'can I make XWin start child processes without using the tray icon?' :) The reason I was trying to do that is because my zsh login scripts set things that only make sense once in a traditional XServer lifetime(setxkbmap,xmodmap,ssh-agent), not to mention xmodmap complains the second time it is ran. I managed to refactor the scripts so they can be run many times in the same x-server so everything is fine now. In any case, you should consider implementing a flag to XWin.exe so it can spawn processes in an already running instance of XWin.exe, as this would bring XWin more close to the spirit of traditional X window managers where a login environment is only created once per session. Anyway, thanks for your help Jon On Wed, Mar 27, 2013 at 1:41 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 23/03/2013 00:02, Thiago Padilha wrote: XWin uses a login shell to configure its environment when it starts up, and processes spawned from the tray icon inherit XWin environment so they don't have to be spawned from login shells. Is there a way to achieve the same effect without using a tray icon? Yes. For example, can I have a desktop shortcut that launches a terminal emulator with a simple interactive(non-login) shell and still have it inherit the currently running XWin environment like it was started from the tray icon? To inherit implies that it is a child of XWin, so no. However, you can create a process with an identical login environment by requesting the shell to create a login environment. On 27/03/2013 15:52, Thiago Padilha wrote: Actually, I use windows shortcut with the following command line: C:\cygwin\bin\run.exe /usr/bin/zsh -l -c 'exec startxwin' I'm guessing the startxwin is responsible for setting up the login environment. Still, the only way to start processes inheriting from the login shell seems to be by using the tray icon. Reading 'man zsh' would save you having to guess. The login environment is nothing to do with startxwin. You are requesting zsh to create the login environment with the '-l' flag. -- 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/
Is there a way to spawn processes from the XWin login shell?
XWin uses a login shell to configure its environment when it starts up, and processes spawned from the tray icon inherit XWin environment so they don't have to be spawned from login shells. Is there a way to achieve the same effect without using a tray icon? For example, can I have a desktop shortcut that launches a terminal emulator with a simple interactive(non-login) shell and still have it inherit the currently running XWin environment like it was started from the tray icon? -- 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 disable focus stealing prevention in XWin Xorg Multi-Window
On 18/10/2012 17:26, Jim Steed wrote: I have an X windows program that uses multiple windows and has buttons to bring up the other windows to the top. These buttons don't work (have no effect) in the default settings of Cygwin's Xorg port due to focus stealing prevention. I'm afraid your diagnosis is incorrect. It's a long-standing defect in multiwindow mode that no attempt is made to synchronize changes in the X window Z-order (e.g. made by XRaiseWindow()) to the native Windows window Z-order. See, for example [1] for some discussion about why this isn't easy to fix. I have a little background with this in Linux as I know the magic in KDE to disable focus stealing prevention and get these buttons to work. Is there a similar setting I can make to XWin Server's startxwin.exe to disable this? I have noted that twm and WindowMaker do not prevent focus stealing, and my program works fine in those window managers. However, for look and feel, I would much prefer it to closer integrated into Microsoft Windows with the multi-window approach. [1] http://cygwin.com/ml/cygwin-xfree/2011-08/msg00034.html -- 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: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl
On 16/10/2012 21:34, Tim Edwards wrote: The current implementation of GLX using WGL takes a few shortcuts, basically anything that is drawn with OpenGL isn't composed into the screen, it's just drawn on top of it. I wouldn't want to sound too peevish, as I was quite happy to find that OpenGL hardware acceleration was even possible, as it was not on the previous version of Cygwin that I had downloaded. That it fails in obscure applications is sort of to be expected. This works well enough when the GLX window is a top-level window, or is non-top-level and has no occluding relatives and is drawn after anything it occludes, but mis-renders in more complex scenarios. This is discussed a bit more in [1] As mentioned there I have done a bit of work fix the mis-rendering in some cases. I can't quite tell from you description exactly what's going wrong, so I am not sure if those changes are going to help in this particular case. I have built a test release including the changes discussed there, available at [2], if you would like to test if it makes things better/worse/no difference. I downloaded the link, ran the X server, ran my application, and get no difference in the behavior. Ok. Thanks for testing, anyhow. The proper solution is probably something like rendering the OpenGL to an offscreen buffer, and then composing it into the un-occluded area of the window, but that is considerably more complex to implement. The two problems with this approach are that (1) I have found more buggy implementations in OpenGL servers by doing offscreen rendering; and (2) this particular tool is a VLSI layout editor and must be rendered directly on the front buffer. The general approach is to render everything as fast as possible and always be willing to break on key interrupt to start over. And I have misappropriated the back buffer for backing store purposes. . . Sorry, I wasn't clear here. I'm not suggesting that the application should be changed. I'm just describing a possible approach to fixing this problem in the X server. -- 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: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl
On 01/10/2012 22:34, Tim Edwards wrote: I have a tool I maintain called magic, a VLSI layout editor. One of its nicer features is a graphics mode based on OpenGL. Occasionally I generate Cygwin versions of it, and was delighted to discover on my last update of Cygwin that there is a support for hardware-accelerated OpenGL using some translation between GLX and WGL calls at the level of the X server. I tried using this with my Cygwin version of magic, and for the most part it works. But it does have the strange effect of overwriting the OpenGL window with contents of other windows. My setup is very non-standard but works under Linux and OS-X. The application is built as an extension of Tcl/Tk. Because the application makes all the OpenGL calls from C routines, it generates a generic window using a call to Tk_CreateWindow(), and maps it using Tk_MapWindow(). The returned window is then passed to glXMakeCurrent(). All of this works fine. The window that is used for the OpenGL rendering is framed by scrollbars on the side and bottom that are canvas windows in Tk. What I am seeing is that any time the scrollbars are redrawn, the OpenGL window is over-drawn, looks like with the default Tk background gray color. A similar thing happens if I pop a window on top of the OpenGL window; when I pop it down, the image of the window remains in the OpenGL window. I presume that in the way GLX is supposed to work, X11 has reserved pixmap space somewhere for the window, but once the call to glXMakeCurrent() has been made, the contents of this pixmap should not show up on the screen. Yet that is what I am seeing. Any clue as to what might be going on? Yes, unfortunately. The current implementation of GLX using WGL takes a few shortcuts, basically anything that is drawn with OpenGL isn't composed into the screen, it's just drawn on top of it. This works well enough when the GLX window is a top-level window, or is non-top-level and has no occluding relatives and is drawn after anything it occludes, but mis-renders in more complex scenarios. This is discussed a bit more in [1] As mentioned there I have done a bit of work fix the mis-rendering in some cases. I can't quite tell from you description exactly what's going wrong, so I am not sure if those changes are going to help in this particular case. I have built a test release including the changes discussed there, available at [2], if you would like to test if it makes things better/worse/no difference. The proper solution is probably something like rendering the OpenGL to an offscreen buffer, and then composing it into the un-occluded area of the window, but that is considerably more complex to implement. One I tarball up this version of magic, I can send a pointer to where it can be obtained if anybody wants to download it and test for the bug. Thanks. This would be useful as a test case for any future work to improve this. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10472 [2] ftp://cygwin.com/pub/cygwinx/XWin.20121012-git-3807fe48a7282459.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/
Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl
Hello Jon, Thanks for the detailed response. The current implementation of GLX using WGL takes a few shortcuts, basically anything that is drawn with OpenGL isn't composed into the screen, it's just drawn on top of it. I wouldn't want to sound too peevish, as I was quite happy to find that OpenGL hardware acceleration was even possible, as it was not on the previous version of Cygwin that I had downloaded. That it fails in obscure applications is sort of to be expected. This works well enough when the GLX window is a top-level window, or is non-top-level and has no occluding relatives and is drawn after anything it occludes, but mis-renders in more complex scenarios. This is discussed a bit more in [1] As mentioned there I have done a bit of work fix the mis-rendering in some cases. I can't quite tell from you description exactly what's going wrong, so I am not sure if those changes are going to help in this particular case. I have built a test release including the changes discussed there, available at [2], if you would like to test if it makes things better/worse/no difference. I downloaded the link, ran the X server, ran my application, and get no difference in the behavior. The proper solution is probably something like rendering the OpenGL to an offscreen buffer, and then composing it into the un-occluded area of the window, but that is considerably more complex to implement. The two problems with this approach are that (1) I have found more buggy implementations in OpenGL servers by doing offscreen rendering; and (2) this particular tool is a VLSI layout editor and must be rendered directly on the front buffer. The general approach is to render everything as fast as possible and always be willing to break on key interrupt to start over. And I have misappropriated the back buffer for backing store purposes. . . The issue here is that I have the whole tool running as an extension of Tcl/Tk. I make a low-level call to Tk to give me an X11 window, which is a simple frame window in Tk but also part of a grid of sub-windows that includes a menu on top and scrollbars on side and bottom. I make a GLX call to render into the window I get from Tk. There are two occasions when the window gets rudely overdrawn, apparently by Tk (that is, the X server appears to know when not to draw into the OpenGL window except when the drawing requests come from the same process): One is that if I raise the Tk console window to obscure part of the OpenGL window, and then lower it behind the OpenGL window, the interior contents (not the frame, therefore, only those drawing requests sent to the server by Tk) continue to be drawn onto the OpenGL window. The second case is a little bit strange to me, in that Tk apparently wants to draw the background of the left- side scrollbar as a gray rectangle that covers not just the scrollbar window but most of the OpenGL window, too. It may be a Tk error that it draws outside the bounds of its own sub-window, but in a correctly working X server, it does not take precedence over the OpenGL window contents. I have found that if I disable the scrollbar, the effect disappears. So I can manage to work around everything (if necessary) except for the obscuring window problem. One I tarball up this version of magic, I can send a pointer to where it can be obtained if anybody wants to download it and test for the bug. Thanks. This would be useful as a test case for any future work to improve this. The program (Cygwin version) is a two-part install that includes an X11-based version of Tcl/Tk for Cygwin: http://opencircuitdesign.com/cygwin Where tcltk_x11_w7.tgz is the 64-bit version that I was using when I found the problem, and the VLSI layout tool is http://opencircuitdesign.com/cygwin/magic.html where the 64-bit Windows 7 version is magic-8.0.116w7.tgz. The direct download URLs are http://opencircuitdesign.com/cygwin/archive/tcltk_x11_w7.tgz http://opencircuitdesign.com/cygwin/archive/magic-8.0.116w7.tgz The latter one installs a shell script /usr/local/bin/magic that launches the layout tool. Use magic -d OGL from a Cygwin xterm to get the OpenGL-based version. The error can be seen by alternately raising the Tk console window and the layout window, with the contents of the console window continuing to be drawn after the window is pushed under the OpenGL window. Regards, Tim ++-+ | Dr. R. Timothy Edwards (Tim) | email: t...@opencircuitdesign.com| | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane| phone: (301) 528-5030 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | ++-+ --
Re: XWin on taskbar
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. -- 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: 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: AW: AW: possible to run XWin as windows service?
On 28/07/2012 14:08, Paul Maier wrote: The cygwin program run.exe is designed to do just that. It's what I use for this purpose :-) ... thank you for your input. 8-) 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? You might try the patched run from [1] and see if that improves matters. -- 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: XWin on taskbar
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. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer On my Win 7 Pro, I never had the extra taskbar item. But on my Win 7 Home Premium laptop, the patched version of run eliminated the extra item. -- Ross -- 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 01/08/2012 04:10, Eliot Moss wrote:
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.
I strongly suspect this is a problem which only manifests itself on W7, as the
mechanisms which cygwin and run use to keep these console windows invisible
have to be different for W7.
I finally had a bit of time to try to reproduce this on W7, and succeeded in
seeing a problem, but I'm not sure if it's the same one as you are seeing:
If I have a non-empty ~/.startxwinrc, or no ~/.startxwinrc so startxwin starts
a default xterm, then I was seeing an additional taskbar item labelled XWin
Server, but this taskbar item has no associated window, the only option in
the right-click menu is close window. When you close all the X programs
which have been started by startxwin, this taskbar item disappears.
Poking around a bit more, this taskbar item does seem be owned by the conhost
process which is associated with the xterm process started by startxwin.
Of course, if you try to debug this problem, it disappears, so this does look
like some kind of timing problem with the way we hide the console window.
I was able to get things to work properly by applying the attached patch to
run, although it's unclear to me that this is the correct fix or if this just
moves the problem around.
I've uploaded a build of run.exe at [1], perhaps you could try replacing
/usr/bin/run.exe with it and see if it improves things for you?
[1] ftp://cygwin.com/pub/cygwinx/run.exe
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--- run.c.old 2012-08-02 13:11:52.90625 +0100
+++ run.c 2012-08-02 13:12:03.56250 +0100
@@ -499,7 +499,7 @@
{
AllocConsole ();
bHaveConsole = TRUE;
- SetParent ((*GetConsoleWindowFP) (), HWND_MESSAGE);
+ ShowWindowAsync((*GetConsoleWindowFP) (), SW_HIDE);
}
}
else if (!bHaveConsole)
--
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/
XWin on taskbar
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? Thanks, Ross -- 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/
AW: possible to run XWin as windows service?
I would like to start XWin automatically on Windows startup (Windows user login). I couldn't find any hint in the manual. Is it possible to run (and automatically start) XWin as windows service? Possible? Yes. [...] Running it from the Startup program group is the correct approach. Hi Jon, running it from the Startup program group worked fine as long as my ~/.startxwinrc has been empty. But I had to add the line /bin/ico -r -obj cube -sleep .05 to ~/.startxwinrc to fix http://cygwin.com/ml/cygwin-xfree/2012-07/msg00012.html That workaround is perfect, but as a side effect, startxwin won't terminate any more; it blocks as long ico runs, and ico runs forever, so startxwin never terminates. This results in an annoying task bar entry staying there all day. This X Server task bar entry is (obviously) not being attached to any visible window or application, so this entry shouldn't exist in the task bar. Can you recommend me how to start the X Server without getting a task bar entry? Thank you regards, Paul -- 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/
AW: AW: possible to run XWin as windows service?
The cygwin program run.exe is designed to do just that. It's what I use for this purpose :-) ... Hi Eliot, thank you for your input. 8-) 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? Regards, Paul -- 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: possible to run XWin as windows service?
On 26/07/2012 23:30, Paul Maier wrote: I would like to start XWin automatically on Windows startup (Windows user login). I couldn't find any hint in the manual. Is it possible to run (and automatically start) XWin as windows service? Possible? Yes. You can't run an arbitrary executable as a service, you need to use the cygwin service wrapper cygrunsrv to make it respond to service control messages. However, this is not the way to achieve what you want to do. Google Allow service to interact with desktop to learn why... Running it from the Startup program group is the correct approach. -- 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/
possible to run XWin as windows service?
Hi, I would like to start XWin automatically on Windows startup (Windows user login). I couldn't find any hint in the manual. Is it possible to run (and automatically start) XWin as windows service? I tried these attempts, but they don't work: sc create testabc1 binpath= D:\Programme\cygwin\bin\startxwin.exe -- /bin/XWin -clipboard -emulate3buttons 100 -nounixkill -nowinkill -xkboptions nbsp:level3 displayname= testabc1 start= demand sc create testabc2 binpath= D:\Programme\cygwin\bin\XWin.exe -clipboard -emulate3buttons 100 -nounixkill -nowinkill -xkboptions nbsp:level3 displayname= testabc2 start= demand ... they all come with the same error message on startup: sc start testabc2 [SC] StartService FEHLER 1053: Der Dienst antwortete nicht rechtzeitig auf die Start- oder Steuerungsanforderung. Thank you very much for ideas! Regards, Paul -- 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: possible to run XWin as windows service?
From: Paul Maier I would like to start XWin automatically on Windows startup (Windows user login). I couldn't find any hint in the manual. How about just adding the XWin Server shortcut to the Startup program group? -- 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 1.12.1.0 seg faults on startup?
On 27/06/2012 16:33, Nick Vasilatos wrote: You might try creating an empty ~/.startxwinrc (so the default xterm is not started by startxwin) and see if that makes a difference? Would seem not/seems to fail as before. See below and log attached. Okay. thanks for trying anyhow. This is going to be somewhat problematic to debug since the debugger seems unable to attach to the faulted process. I'm not sure what might cause that, if it's some software you have installed which is interfering with Cygwin or some security policy you have set? Are you running XWin under a local Administrator account? I've uploaded a new snapshot at [1], can you try running that, adding the -notrapsignals option to your usual command line. This should generate a XWin.exe.stackdump file when it crashes. Can you attach that to an email, please. [1] ftp://cygwin.com/pub/cygwinx/XWin.20120628-git-59d15f68d4fd9bb8.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/
Re: XWin 1.12.1.0 seg faults on startup?
On 21/06/2012 04:39, Nick Vasilatos wrote: Well... the new server (i1.12.2.0) also seg faults at 0x0 on startup. Debugger says ``No Stack''? The log file is attached. [Inferior 1 (process 17136) exited with code 01] (gdb) bt full No stack. (gdb) This says that the XWin process exited, so either gdb somehow failed to catch it when it segfaulted. Or did it not segfault at all? On 6/17/2012 10:09 AM, Jon TURNEY wrote: On 09/06/2012 17:32, Nick Vasilatos wrote: XWin doesn't want to start for me. This is a new install of Cygwin/new install of Win7 on an AMD x64 system with an Nvidia gtx-570 GPU; I've reinstalled the X components a couple of times; rebasedall a couple of times. The log (I installed an XWin.exe w/symbols) says: [ 5306.810] winPositionWindowMultiWindow: (x, y) = (0, 0) [ 5306.810] immediately return since hWnd is NULL [ 5306.810] winMapWindowMultiWindow - pWin: 80062268 [ 5306.810] winUpdateWindowsWindow [ 5306.810] winReshape () [ 5306.826] Segmentation fault at address 0x0 So, this looks like maybe it's failing while trying to create a window, so this might be a timing condition at startup. You might try creating an empty ~/.startxwinrc (so the default xterm is not started by startxwin) and see if that makes a difference? -- 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: XWin 1.12.1.0 seg faults on startup?
On 09/06/2012 17:32, Nick Vasilatos wrote: XWin doesn't want to start for me. This is a new install of Cygwin/new install of Win7 on an AMD x64 system with an Nvidia gtx-570 GPU; I've reinstalled the X components a couple of times; rebasedall a couple of times. The log (I installed an XWin.exe w/symbols) says: [ 5306.810] winPositionWindowMultiWindow: (x, y) = (0, 0) [ 5306.810] immediately return since hWnd is NULL [ 5306.810] winMapWindowMultiWindow - pWin: 80062268 [ 5306.810] winUpdateWindowsWindow [ 5306.810] winReshape () [ 5306.826] Segmentation fault at address 0x0 [ 5306.826] Segmentation fault at address 0x0 [ 5306.826] Segmentation fault at address 0x0 [ 5306.826] Fatal server error: [ 5306.826] Fatal server error: [ 5306.826] Fatal server error: [ 5306.826] Caught signal 11 (Segmentation fault). Server aborting [ 5306.826] Caught signal 11 (Segmentation fault). Server aborting [ 5306.826] Caught signal 11 (Segmentation fault). Server aborting [ 5306.826] [ 5306.826] [ 5306.826] [ 5306.826] Server terminated with error (1). Closing log file. Any ideas/what am I doing wrong? Thanks for reporting this problem. If this crash still occurs with the latest Cygwin X server version, please can you follow the instructions at [1] to install debug symbols and use gdb to get a backtrace for the X server when it crashes. [1] http://x.cygwin.com/devel/backtrace.html -- 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/
XWin crashes with Fatal server error when starting SYBYL 8.1 over SSH
Hello, In our lab, we use Cygwin to run SYBYL 8.1. SYBYL does not run locally, we instead forward the X server of the remote machine where it is installed over SSH. This used to work fine until a few weeks ago, though I am embarassed to say I can't pinpoint the exact time when it stopped working. SYBYL usually opens two windows, a main window and a (graphical) terminal. When the first (main) window pops up, XWin crashes with the following error: Fatal server error ... Package version: 1.12.1-1 built 2012-05-02 ... X was called with: X :0 -multiwindow An full Cygwin update didn't rectify the problem, and IIRC it's not possible to downgrade packages in Cygwin. The corresponding /var/log/xwin/XWin.0.log is found on my dropbox [1], as the list's spam filter won't let me post this mail otherwise. The output of cygcheck -s -v -r is there, too [2]. If I should post those files elsewhere for persistence, just let me know. I tried following the advice on [3], to no avail. Regards, Patrice [1] http://dl.dropbox.com/u/26784238/XWin.0.log [2] http://dl.dropbox.com/u/26784238/cygcheck.out [3] http://sourceware.org/lists.html#spam -- 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 crashes with Fatal server error when starting SYBYL 8.1 over SSH
On 6/11/2012 3:23 PM, Patrice Peterson wrote: Hello, In our lab, we use Cygwin to run SYBYL 8.1. SYBYL does not run locally, we instead forward the X server of the remote machine where it is installed over SSH. This used to work fine until a few weeks ago, though I am embarassed to say I can't pinpoint the exact time when it stopped working. SYBYL usually opens two windows, a main window and a (graphical) terminal. When the first (main) window pops up, XWin crashes with the following error: Fatal server error ... Package version: 1.12.1-1 built 2012-05-02 ... X was called with: X :0 -multiwindow An full Cygwin update didn't rectify the problem, and IIRC it's not possible to downgrade packages in Cygwin. it is possible. On Select Packages window look for xorg-server row, click on Keep and you can circle around options: keep / version 1.12.1-1 version 1.12.0-5 source reinstall uninstall please check if version 1.12.0-5 is functional in your case Regards Marco -- 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/
XWin 1.12.1.0 seg faults on startup?
Hi, XWin doesn't want to start for me. This is a new install of Cygwin/new install of Win7 on an AMD x64 system with an Nvidia gtx-570 GPU; I've reinstalled the X components a couple of times; rebasedall a couple of times. The log (I installed an XWin.exe w/symbols) says: [ 5306.810] winPositionWindowMultiWindow: (x, y) = (0, 0) [ 5306.810] immediately return since hWnd is NULL [ 5306.810] winMapWindowMultiWindow - pWin: 80062268 [ 5306.810] winUpdateWindowsWindow [ 5306.810] winReshape () [ 5306.826] Segmentation fault at address 0x0 [ 5306.826] Segmentation fault at address 0x0 [ 5306.826] Segmentation fault at address 0x0 [ 5306.826] Fatal server error: [ 5306.826] Fatal server error: [ 5306.826] Fatal server error: [ 5306.826] Caught signal 11 (Segmentation fault). Server aborting [ 5306.826] Caught signal 11 (Segmentation fault). Server aborting [ 5306.826] Caught signal 11 (Segmentation fault). Server aborting [ 5306.826] [ 5306.826] [ 5306.826] [ 5306.826] Server terminated with error (1). Closing log file. Any ideas/what am I doing wrong? Thanks, Nick InitConnectionLimits: MaxClients = 255 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.12.1.0 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Snapshot: 20120427-git-d3fae865c57f6709 XWin was started with the following command line: /usr/bin/X :1 -multiwindow -clipboard -wgl -multimonitors -logverbose 3 -auth /home/boxer/.serverauth.2812 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1920 h 1200 winInitializeScreenDefaults - native DPI x 96 y 96 ddxProcessArgument - arg: :1 ddxProcessArgument - arg: -multiwindow ddxProcessArgument - arg: -clipboard ddxProcessArgument - arg: -wgl ddxProcessArgument - arg: -multimonitors ddxProcessArgument - arg: -logverbose ddxProcessArgument - arg: -auth [ 5306.467] OsVendorInit - Creating default screen 0 [ 5306.467] winInitializeScreens - 1 [ 5306.467] winInitializeScreen - 0 [ 5306.498] InitOutput [ 5306.498] winValidateArgs - Returning. [ 5306.498] (II) xorg.conf is not supported [ 5306.498] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 5306.498] LoadPreferences: /home/boxer/.XWinrc not found [ 5306.498] LoadPreferences: Loading /etc/X11/system.XWinrc [ 5306.498] LoadPreferences: Done parsing the configuration file... [ 5306.498] winGetDisplay: DISPLAY=:1.0 [ 5306.514] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD [ 5306.514] winDetectSupportedEngines - Windows NT, allowing PrimaryDD [ 5306.514] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [ 5306.530] winDetectSupportedEngines - Returning, supported engines 001f [ 5306.530] winMsgWindowThreadProc - Hello [ 5306.530] winScreenInit - dwWidth: 1920 dwHeight: 1200 [ 5306.530] winAllocateScreenPrivates - g_ulServerGeneration: 0 serverGeneration: 1 [ 5306.530] winSetEngine - Multi Window or Rootless = ShadowGDI [ 5306.530] winScreenInit - Using Windows display depth of 32 bits per pixel [ 5306.530] winCreateBoundingWindowWindowed - User w: 1920 h: 1200 [ 5306.530] winCreateBoundingWindowWindowed - Current w: 1920 h: 1200 [ 5306.530] winGetWorkArea - Primary Monitor WorkArea: 0 0 1200 1920 [ 5306.530] winGetWorkArea - Virtual screen is 3520 x 1200 [ 5306.530] winGetWorkArea - Virtual screen origin is 0, 0 [ 5306.530] winGetWorkArea - Primary screen is 1920 x 1200 [ 5306.530] winGetWorkArea - Adjusted WorkArea for multiple monitors: 0 0 1200 3520 [ 5306.530] [ 5306.530] winCreateMsgWwinCreateMsgWindow - Created msg window hwnd 0x1c0722 [ 5306.530] winAdjustForAutoHide - Taskbar is auto hide [ 5306.530] winAdjustForAutoHide - Found BOTTOM auto-hide taskbar [ 5306.530] winAdjustForAutoHide - Adjusted WorkArea: 0 0 1199 3520 [ 5306.530] winCreateBoundingWindowWindowed - User did not give height and width [ 5306.530] winWindowProc - WM_CREATE [ 5306.545] winWindowProc - WM_SIZE [ 5306.545] winCreateBoundingWindowWindowed - CreateWindowEx () returned [ 5306.545] winCreateBoundingWindowWindowed - WindowClient w 3520 h 1200 r 3520 l 0 b 1200 t 0 [ 5306.545] winCreateBoundingWindowWindowed - Returning [ 5306.545] winQueryScreenDIBFormat - First call masks: [ 5306.545] winQueryScreenDIBFormat - First call masks: [ 5306.545] winQueryRGBBitsAndMasks - Masks: 00ff ff00 00ff [ 5306.545] winQueryRGBBitsAndMasks - Bitmap: 1x1 32 bpp 1 planes [ 5306.545] winQueryRGBBitsAndMasks - Compression: 3 (BI_BITFIELDS) [ 5306.545] winAllocateFBShadowGDI - Creating DIB with width: 3520 height: 1200 depth: 32 [ 5306.545] winAllocateFBShadowGDI - Shadow buffer allocated [ 5306.545] winAllocateFBShadowGDI - Dibsection width: 3520 height: 1200 depth: 32 size image: 16896000 [ 5306.545] winAllocateFBShadowGDI - Attempting a shadow blit [ 5306.545
RE: XWin 1.12.0-4 crash
From: Jon TURNEY Mentioning the name of the application which caused the crash (multi-gnome-terminal) would have helped. Sorry, I thought it was clear from the startup script that I had attached. So, in fact, it's not a crash when the X server is started, but when you try to run the application multi-gnome-terminal? Yes. But because the MGT was started just after X in my startup script, it looked like a startup issue. When I removed the MGT from the script, I was able to run the apps I needed, using a local mintty+ssh. It looks like this is the same crash as reported at [1], and should be fixed in X server 1.12.0-5. It is indeed. Thanks for the quick support. Greetings, (s) M. Bardiaux. -- 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 1.12.0-4 crash
On 23/04/2012 14:03, Michel Bardiaux wrote: Yes, it is a crash at startup. I could not find XWin.exe.stackdump anywhere on my hard drive. I have attached the bat script (renamed into .txt) used to start cygwin/X, maybe I need to modify it. Would it work to add CYGWIN='error_start=c:\cygwin\bin\dumper.exe' in the system environment (meaning, via the control panel), to have a core file that I could then open with gdb? No, I don't think that would work (for various uninteresting reasons) Start the X server from a terminal using 'gdb --args XWin -multiwindow', type 'r' to start the X server running, and 'bt full' after it crashes. -- 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: XWin 1.12.0-4 crash
From: Jon TURNEY Start the X server from a terminal using 'gdb --args XWin -multiwindow', type 'r' to start the X server running, Did exactly that in a minty. Then in another one: export DISPLAY=localhost:0.0 ssh -X -Y michel@besdev01 multi-gnome-terminal and 'bt full' after it crashes. Which gives: winProcEstablishConnection - winInitClipboard returned. winClipboardProc - DISPLAY=:0.0 winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. winClipboardProc - XOpenDisplay () returned and successfully opened the display. [New Thread 1452.0x350] winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. [New Thread 1452.0xcf0] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1452.0xf04] 0x0040a41e in winXIconToHICON () (gdb) bt full #0 0x0040a41e in winXIconToHICON () No symbol table info available. #1 0x0040a6ab in winUpdateIcon () No symbol table info available. #2 0x0041f5e7 in UpdateIcon.clone.3 () No symbol table info available. #3 0x004210d0 in winMultiWindowWMProc () No symbol table info available. #4 0x610fbd52 in pthread::thread_init_wrapper(void*) () from /cygdrive/c/cygwin/bin/cygwin1.dll No symbol table info available. #5 0x610868f2 in thread_wrapper(void*) () from /cygdrive/c/cygwin/bin/cygwin1.dll No symbol table info available. Backtrace stopped: Not enough registers or memory available to unwind further Note that if I invoke xclock instead of multi-gnome-terminal, it works. Ditto xterm, emacs, and fortunately all my personal apps! Greetings, (s) M. Bardiaux -- 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/
xlogo crahes XWin with Fatal Error (Segmentation Fault)
Dear sirs, Some days ago I updated the cygwin system by 'setup.exe', expecting some GL problems are fixed. Since then XWin crashes with some application programs. One of the most simplest is 'xlogo'. What I have done is as follows; Start [XWin Server] (wait some time for bringing up xterm), then enter 'xlogo' in xterm, [Cygwin/X] window appears immediately. It says, A fatal error ... Caught signal 11 (Segmentation fault). ... Please open /var/log/xwin/XWin.0.log ... Vendor: .. Release: 1.12.0.0 Contact: .. Package: version 1.12.0-4 built 2012-04-17 XWin was started ... X :0 -multiwindow /var/log/xwin/XWin.0.log does not report anything important at all. OK, I tried 'X :0 -multiwindow' on one terminal, and on the other terminal $ export DISPLAY=:0.0 $ xlogo then, the message appears on one therminal; Segmentation fault at address 0x44 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting Server terminated with error (1). Closing log file. winDeinitMultiWindowWM - Noting shutdown in progress winMsgWindowProc - pthread_mutex_unlock () failed: 1 while entering 'X :0' on one terminal, entring 'xlogo' on the other, there was no fatal problem. Obviously '-multiwindow' does something wrong. Keith Lindsay's post might be helpfull as workaround, but I cannot rollback to the 'version 1.12.0-1 of xorg-server (built 2012-03-12)' using 'setup.exe', April 25, 2012 21:45 Re: X segmentation fault when particular application attempts to open a window http://cygwin.com/ml/cygwin-xfree/2012-04/msg00100.html best regards, Yusuke Tamura --- -- 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 1.12.0-4 crash
On 23/04/2012 12:55, Michel Bardiaux wrote: Nothing much to add to the 2 attached files - except that my X worked fine until the last update. Will try reverting to previous version. Mentioning the name of the application which caused the crash (multi-gnome-terminal) would have helped. On 23/04/2012 14:03, Michel Bardiaux wrote: Yes, it is a crash at startup. So, in fact, it's not a crash when the X server is started, but when you try to run the application multi-gnome-terminal? On 26/04/2012 15:54, Michel Bardiaux wrote: Start the X server from a terminal using 'gdb --args XWin -multiwindow', type 'r' to start the X server running, Did exactly that in a minty. Then in another one: export DISPLAY=localhost:0.0 ssh -X -Y michel@besdev01 multi-gnome-terminal It looks like this is the same crash as reported at [1], and should be fixed in X server 1.12.0-5. [1] http://cygwin.com/ml/cygwin-xfree/2012-04/msg00097.html -- 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: xlogo crashes XWin with Fatal Error (Segmentation Fault)
Re: xlogo crashes XWin with Fatal Error (Segmentation Fault) 2012.04.26.18:13:33 UT Hey cygwin-x folks, I have not had notable difficulties with XWin-1.12.0-4. Just about everything that I have done with it over the past few days has been fine. However, when I read Yusuke's post, I thought that I should try one of those old-timey X-programs to see whether it would crash. I've been able to reproduce an XWin crash similar to the one experienced by Yusuke. My XWin did _not_ fail when I was running octave with either the fltk or its usual gnuplot backends. I was also able to run xfig with no problem. This was a crash caused when I opened the xcalc program. I'm not certain that I understand his experiment with two terminal windows as a method of narrowing the difficulty to the -multiwindow option. However like Yusuke, I am starting XWin with the -mulitwindow option. The crash I observed was with just a single xterm, and then the xcalc program. Other programs that opened x-windows seemed fine. In this instance, I had the debugging symbols available, and collected information from a backtrace using (gdb). I've attached gdb.xwin.20120426.txt and my XWin.0.20120426.log. I did not see anything interesting in the xwin0-log, and my (gdb) backtrace is just the output from my glance at Jon Turney's recipe. I'm tossing it in this list in case it helps better-informed folks to track down the difficulty with XWin-1.12.0-4. If there is more specific or nuanced stuff that I can log with (gdb) to provide more information, please e-mail me. George gbarrick_at_walsh_dot_edu Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2528.0xf34] 0x0040a41e in winXIconToHICON (pDisplay=0x20279a30, id=10485779, iconSize=optimized out) at /opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-4/src/xserver-cygwin-1.12.0-4/hw/xwin/winmultiwindowicons.c:535 535 /opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-4/src/xserver-cygwin-1.12.0-4/hw/xwin/winmultiwindowicons.c: No such file or directory. in /opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-4/src/xserver-cygwin-1.12.0-4/hw/xwin/winmultiwindowicons.c #0 0x0040a41e in winXIconToHICON (pDisplay=0x20279a30, id=10485779, iconSize=optimized out) at /opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-4/src/xserver-cygwin-1.12.0-4/hw/xwin/winmultiwindowicons.c:535 root = error reading variable root (Cannot access memory at address 0x7fdfcbf8) y = error reading variable y (Cannot access memory at address 0x7fdfcbf0) depth = error reading variable depth (Cannot access memory at address 0x7fdfcbe0) xImageIcon = 0x0 x = error reading variable x (Cannot access memory at address 0x7fdfcbf4) width = error reading variable width (Cannot access memory at address 0x7fdfcbec) height = error reading variable height (Cannot access memory at address 0x7fdfcbe8) border_width = error reading variable border_width (Cannot access memory at address 0x7fdfcbe4) xImageMask = 0x0 mask = optimized out image = optimized out imageMask = optimized out dst = optimized out src = optimized out planes = 1 bpp = 32 i = optimized out biggest_size = optimized out hDC = optimized out ii = error reading variable ii (Cannot access memory at address 0x7fdfcbcc) hints = 0x203ae1e8 hIcon = 0x0 biggest_icon = optimized out _XA_NET_WM_ICON = error reading variable _XA_NET_WM_ICON (Cannot access memory at address 0x5fd554) generation = error reading variable generation (Cannot access memory at address 0x5fd550) icon = optimized out icon_data = 0x0 size = 0 type = 0 format = 0 left = error reading variable left (Cannot access memory at address 0x7fdfcbfc) #1 0x0040a6ab in winUpdateIcon ( hWnd=error reading variable: Cannot access memory at address 0x7fdfcc70, hWnd@entry=error reading variable: Cannot access memory at address 0x7fdfcc6c, pDisplay=error reading variable: Cannot access memory at address 0x7fdfcc74, id=error reading variable: Cannot access memory at address 0x7fdfcc78, hIconNew=error reading variable: Cannot access memory at address 0x7fdfcc7c) at /opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-4/src/xserver-cygwin-1.12.0-4/hw/xwin/winmultiwindowicons.c:560 hIcon = optimized out hIconSmall = 0x0 hIconOld = optimized out A debugging session is active. Inferior 1 [process 2528] will be detached. Quit anyway? (y or n) error return /netrel/src/gdb-7.3.50-3/gdb/windows-nat.c:1251 was 31 Quitting: Can't detach process 2528 (error 5) XWin.0.20120426.log Description: XWin.0.20120426.log -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem
Re: Issue with XWin under xlaunch
On 23/04/2012 17:41, Eliot Moss wrote: Ok -- by perusing the log I figured it out ... [727848.279] executing 'xterm -display :0.0 -ls -title swarm -bg rgbi:.0/.20/.0 -geometry 120x47+0+0 -e /usr/bin/ssh m...@swarm.cs.umass.edu', pid 13748 [727848.311] (pid 13748 stderr) /bin/sh: xterm: command not found 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 :-) ... This is not intentional. I can't reproduce this, so I'm not quite sure what is causing this. What I am expecting to happen is that xlaunch is invoked via the start menu shortcut which it's package creates, which runs bash -l -c xlaunch, which reads /etc/profile, which sets PATH to include /usr/bin, which should be inherited by XWin and used when it execs /bin/sh -c 'your xterm command'. We try to create the login environment as far up the process hierarchy as possible, rather than starting the processes from the notification area menu with bash -l -c, as creating the login environment can be expensive. -- 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: Issue with XWin under xlaunch
On 23/04/2012 16:04, Ken Brown wrote: I've added some code to capture stdout and stderr from these subprocesses to the X server log, and to more clearly diagnose problems which could occur while fork/exec-ing them. Would it be possible for you to also add some code for diagnosing problems with processes started from .startxwinrc? I'm hoping it might help with the problem I reported in http://cygwin.com/ml/cygwin-xfree/2012-04/msg00050.html Hmm.. not sure code is really needed. You can see the output from startxwin by running it from a terminal, or capture it by changing the shortcut which runs it to something like the following (perhaps we should do that by default) C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe /var/log/xwin/startxwin.log 21' -- 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: 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
On 4/24/2012 7:54 AM, Jon TURNEY wrote: On 23/04/2012 16:04, Ken Brown wrote: I've added some code to capture stdout and stderr from these subprocesses to the X server log, and to more clearly diagnose problems which could occur while fork/exec-ing them. Would it be possible for you to also add some code for diagnosing problems with processes started from .startxwinrc? I'm hoping it might help with the problem I reported in http://cygwin.com/ml/cygwin-xfree/2012-04/msg00050.html Hmm.. not sure code is really needed. You can see the output from startxwin by running it from a terminal, or capture it by changing the shortcut which runs it to something like the following (perhaps we should do that by default) C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe /var/log/xwin/startxwin.log 21' That doesn't help, but I'll reply to my original thread to explain why. I shouldn't have interjected my question into this thread. Ken -- 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 1.12.0-4 crash
On 23/04/2012 12:55, Michel Bardiaux wrote: Nothing much to add to the 2 attached files - except that my X worked fine until the last update. Will try reverting to previous version. From the log timestamps, this looks like a crash at startup. Is that correct? Thanks very much for reporting this problem. There should be an XWin.exe.stackdump file produced by the crash, if you could attach that, that would be helpful. Even more helpful would be following the instructions at [1] to use gdb to get a backtrace for the X server when it crashes. If your crash is at startup, you will need to modify the instruction slightly, start X using 'gdb --args XWin -multiwindow' rather than trying to attach to a running XWin. [1] http://x.cygwin.com/devel/backtrace.html -- 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: XWin 1.12.0-4 crash
Yes, it is a crash at startup. I could not find XWin.exe.stackdump anywhere on my hard drive. I have attached the bat script (renamed into .txt) used to start cygwin/X, maybe I need to modify it. Would it work to add CYGWIN='error_start=c:\cygwin\bin\dumper.exe' in the system environment (meaning, via the control panel), to have a core file that I could then open with gdb? @echo off SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/X, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=\cygwin SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/X11R6/bin SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% SET XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults SET XCMSDB=/usr/X11R6/lib/X11/Xcms.txt SET XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB SET XNLSPATH=/usr/X11R6/lib/X11/locale REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM The error Fatal server error: could not open default font 'fixed' is REM caused by using a DOS mode mount for the mount that the Cygwin/X REM fonts are accessed through. See the Cygwin/X FAQ for more REM information: REM http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof REM if %OS% == Windows_NT goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP/2003 rem echo startxwin.bat - Starting on Windows NT/2000/XP/2003 :STARTUP REM Brief descriptions of XWin-specific options: REM REM -screen scr_num [width height] REM Enable screen scr_num and optionally specify a width and REM height for that screen. REM Most importantly, any parameters specified before the first -screen REM parameter apply to all screens. Any options after the first -screen REM parameter apply only to the screen that precedes the parameter. REM Example: REM XWin -fullscreen -screen 0 -screen 1 -depth 8 -screen 2 REM All screens will be fullscreen, but screen 2 will be depth 8, while REM screens 0 and 1 will be the default depth (whatever depth Windows REM is currently running at). REM -multiwindow REM Start an integrated Windows-based window manager. Not to be used REM with -rootless nor -fullscreen. REM -rootless REM Use a transparent root window with an external window manager REM (such as twm). Not to be used with -multiwindow nor REM with -fullscreen. REM -fullscreen REM Use a window as large as possible on the primary monitor. REM -multiplemonitors REM Create a root window that covers all monitors on a REM system with multiple monitors. REM -clipboard REM Enable the integrated version of xwinclip. Do not use in REM conjunction with the xwinclip program. REM -depth bits_per_pixel REM Specify the screen depth to run at (in bits per pixel) using a REM DirectDraw-based engine in conjunction with the -fullscreen REM option, ignored if the -fullscreen option is not specified. REM By default, you will be using a DirectDraw based engine on any REM system that supports it. REM -unixkill REM Trap Ctrl+Alt+Backspace as a server shutdown key combination. REM -nounixkill REM Disable Ctrl+Alt+Backspace as a server shutdown key combination (default). REM Example: REM XWin -unixkill -screen 0 -screen 1 -screen 2 -nounixkill REM Screens 0 and 1 will allow Ctrl+Alt+Backspace, but screen 2 will not. REM -winkill REM Trap Alt+F4 as a server shutdown key combination (default). REM -nowinkill REM Disable Alt+F4 as a server shutdown key combination. REM -scrollbars REM Enable resizing of the server display window. Do not use in conjunction REM with -multiwindow nor with -rootless. REM -nodecoration REM Draw the server root window without a title bar or border. REM Do not use with -mutliwindow nor with -rootless. REM -lesspointer REM Hide the Windows mouse cursor anytime it is over any part of the REM window, even if Cygwin/X is not the window with the focus. REM -refresh rate_in_Hz REM Specify a refresh rate to use when used with the -fullscreen option. REM
Re: Issue with XWin under xlaunch
On 11/04/2012 11:23, Eliot Moss wrote: When I start XWin using xlaunch, trying to the start programs from the .XWinrc popup menu (right-click on the X icon, left-click on the program's entry in the menu), programs do not start. I get only those programs started by my script that I told xlaunch to run. I would like to use xlaunch, since it solves the issue I had with the startxwin taskbar icon being visible (when I claim it should not be, and it didn't use to be), but not being able to start additional programs makes this approach less useable. Looking at this from outside, it is hard to say whether the real issue is in xlaunch, in XWin, or the result of some misunderstanding between them. At the moment, the output from processes started from the notification area icon doesn't go anywhere useful, which can make it hard to debug problems with processes started this way. I've added some code to capture stdout and stderr from these subprocesses to the X server log, and to more clearly diagnose problems which could occur while fork/exec-ing them. Perhaps you could try the snapshot at [1] and see if this gives a bit more information about why these processes are failing? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120423-git-638383315ef51e46.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/
Re: Issue with XWin under xlaunch
On 4/23/2012 9:51 AM, Jon TURNEY wrote: On 11/04/2012 11:23, Eliot Moss wrote: When I start XWin using xlaunch, trying to the start programs from the .XWinrc popup menu (right-click on the X icon, left-click on the program's entry in the menu), programs do not start. I get only those programs started by my script that I told xlaunch to run. I would like to use xlaunch, since it solves the issue I had with the startxwin taskbar icon being visible (when I claim it should not be, and it didn't use to be), but not being able to start additional programs makes this approach less useable. Looking at this from outside, it is hard to say whether the real issue is in xlaunch, in XWin, or the result of some misunderstanding between them. At the moment, the output from processes started from the notification area icon doesn't go anywhere useful, which can make it hard to debug problems with processes started this way. I've added some code to capture stdout and stderr from these subprocesses to the X server log, and to more clearly diagnose problems which could occur while fork/exec-ing them. Would it be possible for you to also add some code for diagnosing problems with processes started from .startxwinrc? I'm hoping it might help with the problem I reported in http://cygwin.com/ml/cygwin-xfree/2012-04/msg00050.html BTW, I tried the snapshot at ftp://cygwin.com/pub/cygwinx/XWin.20120423-git-638383315ef51e46.exe.bz2 and the resulting log has a lot of messages like this: winMultiWindowXMsgProcErrorHandler - ERROR: BadWindow (invalid Window parameter) winMultiWindowXMsgProcErrorHandler - ERROR: BadMatch (invalid parameter attributes) Is that to be expected, or does it indicate a real problem? Ken -- 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/
