Cygwin/X is a port of the X Window System to Cygwin. Cygwin provides a UNIX-like API on the Win32 platform.

Cygwin tools are, in the words of the Cygwin FAQ, " ports of the popular GNU development tools and utilities for Microsoft Windows. They run thanks to the Cygwin library which provides the POSIX system calls and environment these programs expect. " Cygwin provides the compiler (gcc), libraries, headers, and other utilities which build and support the operation of Cygwin/X.

[ScheiflerGettys92]

The X Window System, or X, is a network-transparent window system. With X, multiple applications can run simultaneously in windows, generating text and graphics in monochrome or color on a bitmap display. Network transparency means that application programs can run on machines scattered through the network.

An X Server is a program that provides display and user input services to other programs. In comparison, a file server provides other programs with access to file storage devices. File servers are typically located in a remote location and you use the services of a file server from the machine that you are located at. In contrast, an X Server is typically running on the machine that you are located at; display and user input services may be requested by programs running on your machine, as well as by programs running on remote machines.

An X client is a program that utilizes the display and user input services provided by an X Server. X clients may run on the same or disparate machine as the X Server that is providing display and user input services.

The DISPLAY environment variable instructs an X client which X server it is to connect to by default. Typically this can be overriden by running the client with a -display or -d command line option.

The :0.0 part of the DISPLAY variable denote the display and the screen of an X server.

The display is the first number and should equal the display number given to a running instance of an X server. By default the X server uses display number 0. If the X server is using TCP/IP for communication it listens on port 6000 + display-number for X client connections. For local (UNIX domain sockets) it uses the socket /tmp/.X11-unix/Xdisplay-number

The screen denotes different output devices of the X server. You could start X with two -screen options and would end up with two X11 windows. Each of them is a different screen. Other X servers open different screens for different monitors connected to the computer.

Cygwin/X supports different formats of the DISPLAY variable

• :0.0 or unix:0.0

  This names a local X server and the communication uses the UNIX domain sockets.

• hostname:0.0

  This names a remote X server and the communication uses the TCP/IP network.

See the DISPLAY NAMES section of man X for more information.

Porting X Window System to Microsoft Windows benefits many people and projects in many ways:

• Prior to Cygwin/X only commercial, closed source X Servers were available for Microsoft Windows.

• An X Server on Windows may be used to display the output of programs running on remote UNIX machines.

• Cygwin/X, in conjunction with Cygwin, provides a complete compatibility layer for compiling and running UNIX applications on Microsoft Windows.

No, Cygwin/X does not have a newsgroup; however, we do have a mailing list. See Q: 1.9.

You can read and post to the mailing list using your newsreader using the GMANE mail-to-news gateway.

Yes, Cygwin/X is on-topic for the cygwin@cygwin.com mailing list. Non-subscribers may post to this list. Visit the Cygwin Mailing Lists page to subscribe to cygwin@cygwin.com as well as to read and search an online archive of the mailing list traffic.

Cygwin/X aims to support all versions of Windows supported by Cygwin.

However, Cygwin/X is not tested on older versions of Windows (i.e. Windows NT4, Windows 2000) and may be broken. Problem reports are welcomed.

Cygwin/X requires Cygwin to compile and run. Cygwin is not, as of writing, available on Microsoft Windows CE, therefore Cygwin/X is not currently available on Microsoft Windows CE.

The Cygwin/X User's Guide thoroughly documents the installation process. Installation is performed through Cygwin's setup program.

This question should be obsolete.

A1: /tmp resides on a FAT filesystem

Start the server with the -nolock option. See Q: 4.2.

You should really consider updating the filesystem to NTFS using Microsoft's convert.exe tool.

A2: /tmp resides on a NTFS filesystem.

This can be caused by a stale lock file being left behind after the X server is run by a user with Adminstrator rights, which cannot be overwritten when the X server is next run by a user without Adminstrator rights.

Failure to clean up the lock file properly is a bug in the X server, but until that is fixed the following workarounds may be neccessary.

1. Try removing the stale lock file using rm -f /tmp/.Xn-lock where n is the display number. If this fails due to insufficent permissions, you must either get the owner or a user with Adminstrator rights to remove the stale lock file.

2. Try starting the server with the -nolock option. (See Q: 4.2.)

Technical details: The X server attempts to create a lock file in /tmp by creating the file under a temporary name, then renaming it to the proper name (by hard linking it under the correct name, then unlinking it from the temporary name). If this rename fails it attempts to read the existing lock file to determine the pid of an already running server. The FAT filesystem does not support hardlinks so this operation cannot succeed. On NFTS filesystems, the failure case appears to be that lock file was created successfully, but the rename failed due to a stale lock file created by a user with Adminstrator rights.

A1:

This answer should be obsolete.

Task manager shows the startxwin.exe process starting, spawning XWin.exe and xterm.exe, but no windows are shown. Running startxwin.exe from a bash shell works correctly. This is caused by having tty in the CYGWIN environment variable set through the Windows control panel. Removing tty resolves this issue.

If you really need CYGWIN=tty for working with cmd.exe windows, you'll have to arrange to set that by some other means before invoking cygwin.bat.

A2:

Try running startxwin from a bash shell in the mintty terminal emulator, it should output some error message which should indicate why it's not able to start.

The upgrade from X.Org R6.8 to modular X.Org R7.4 made a lot of changes. Please read the announce email and pay attention to the upgrade instructions

This question should be obsolete.

Launch the X server via the shortcut under "Cygwin-X" on the start menu.

Technical details: The startxwin.bat script used to set several enviroment variables used by the X server to specify the location of files it needs to access. Specifically this batch file would set XKEYSYMDB to /usr/X11R6/lib/X11/XKeysymDB. This file was moved to /usr/share/X11/XKeysymDB. The keyboard won't work if XKEYSYMDB points to a non-existent file.

If you are (perhaps unintentionally) using a copy of the old startxwin.bat (perhaps under another name) to start the X server, remove the environment variables XAPPLRESDIR, XCMSDB, XNLSPATH and XKEYSYMDB from it, or (preferrably) use the updated startxwin.

If echo $XKEYSYMDB outputs something, you have something else setting XKEYSYMDB in your environment. Find it and remove it.

These variables were always being set to the defaults, so they can simply be removed. See Q: 8.8. for the reason why you might need to set them.

The executable startxwin.exe previously used to start the X server has been retired and replaced with a shell script startxwin.

The MS-DOS batch file startxwin.bat previously used to start the X server has been retired, as implementing this as a batch file made it difficult to reliably wait until the the X server had started before starting any clients.

X.Org now uses the prefix /usr not /usr/X11R6. So startxwin.bat was moved from /usr/X11R6/bin/startxwin.bat to /usr/bin/startxwin.bat.

A "XWin Server" shortcut to startxwin is created on the Start menu, under "Cygwin-X"

startxwin and the Start menu link to it are now installed by the xinit package.

Only minimal fonts will be installed after the upgrade from X.Org R6.8 to modular X.Org.

Font packages are now named font-<author/class>-<fonttype>

Some packages dependencies have not yet been updated for the fonts they require, so you may need to manually install the needed fonts. For example, to provide the font emacs wants to use by default you will probably want to install font-adobe-dpi75 (or font-adobe-dpi100 if you like large fonts). This package provides the courier, helvetica, new century schoolbook and times font families.

The lucida font family is provided by the package font-bh-dpi75 (or font-bh-dpi100). The monospaced version, lucida typewriter is provided by the package font-bh-lucidatypewriter-dpi75 (or font-bh-lucidatypewriter-dpi100).

Note that after installing fonts you will need to restart the X server or run xset fp default; xset fp rehash to make the new fonts available

Previously all the X utility programs were contained in a single package, xorg-x11-bin, which needed to be updated when any of the programs it contained was updated. In modular X each of these programs can be found in a separate package, usually named xhost/xlsfont/etc.

Run it as xterm +tb, or add XTerm*toolBar: false to ~/.Xresources

See Q: 6.1. and following. See point 3 in this mail. Use ssh -Y.

Technical details: ssh tried to run xauth generate to create a untrusted cookie for the session, which failed because the server isn't compiled with the XCSECURITY extension built-in. Since OpenSSH 7.2p1, ssh does not fallback to trusted forwarding, so no X11 forwarding is setup.

This question should be obsolete.

$ nedit X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 70 (X_PolyFillRectangle) Serial number of failed request: some number Current serial number in output stream: some other number

nedit needs rebuilding with a patch to work around an issue lesstif has with current X servers.

Until this happemns, you can work around the issue by adding XLIB_SKIP_ARGB_VISUALS to your enviroment, e.g.

$ export XLIB_SKIP_ARGB_VISUALS=1 $ nedit

This is a deliberate change from Cygwin/X X11 R6.9 behaviour.

1. Start the X server using the "XWin Server" shortcut under "Cygwin-X" on the Start menu, or using startxwin.

   Note: If you wish to customize the X clients started when the X server starts, you can do so using a ~/.startxwinrc script.

2. Alternatively, add the server option -multiwindow to your xinit or startx invocation, i.e. xinit -- -multiwindow or startx -- -multiwindow

3. Alternatively, put XWin -multiwindow into ~/.xserverrc or /etc/X11/xinit/xserverrc

Since xinit-1.3.4-1, startxwin is now implemented by a script based on startx. Unfortunately, this has changed the behaviour in a backwards-incompatible way, as the X server is now killed when ~/.startxwinrc exits.

If you have an empty ~/.startxwinrc, you should change it to contain exec sleep infinity so the X server will not exit until explicitly told to do so.

If you are using a custom ~/.startxwinrc, either run the last client in the foreground (i.e. without &), so the X server exits when that client exits, or use exec sleep infinity as described above.

You should also make sure that ~/.startxwinrc is executable (e.g. chmod +x ~/.startxwinrc).

See the announce mail for more details.

A1:

Since X server 1.17, by default the server does not listen for TCP/IP connections, only accepting local connections on a unix domain socket.

For local clients, use DISPLAY=:0.0, rather than DISPLAY=localhost:0.0, DISPLAY=127.0.0.1:0.0, DISPLAY=::1:0.0, etc. See Q: 1.6..

A2:

For remote clients, rather than connecting over TCP/IP by explicitly setting DISPLAY and allowing access using xhost or by disabling access control, use ssh tunnelling with ssh -Y instead. (See the User's Guide section on X forwarding using ssh for more details).

A3:

Use the -listen tcp option to restore the previous behaviour, allowing the X server to open a TCP/IP socket as well e.g. startxwin -- -listen tcp. See Q: 4.2..

No. Options which are configurable are available as command line options. For example, for more information on configuring other keyboard layouts using command line options, see Q: 5.1.1.

The Cygwin/X User's Guide and man XWin document the command line options for X.

To supply a command line option to X:

• If you use the start menu shortcut to start the X server, you will need to amend it's target to add an option, e.g. C:\cygwin\bin\run.exe --quote /usr/bin/bash.exe -l -c "/usr/bin/startxwin -- -nolock"

  Note: Note well that the entire command after -c is quoted

  Note: Note that this start menu shortcut is created by the xinit package, and your changes will be overwritten when the xinit package is updated.

  Note: Note that X server options to startxwin are preceded by --.

• If you use startxwin, xinit or startx to start the server, run it as e.g. startxwin -- -nolock, xinit -- -nolock or startx -- -nolock

• If you use startxwin.bat or startxwin.sh to start the server, add e.g. -nolock to the XWin line in that script.

When running in windowed mode or GDI-based fullscreen mode, X must run the X Server at whatever display depth Windows is currently using; in these cases the display depth passed on the command line is ignored. X only uses the display depth parameter when running in a DirectDraw-based fullscreen mode, as DirectDraw allows applications to change the display resolution and depth when running in fullscreen mode.

Yes. Pass the -emulate3buttons timeout_in_milliseconds parameter to X, where timeout_in_milliseconds is the, optional, maximum number of milliseconds between a button release and opposite button press that will trigger an emulated third button press.

This is a setting of the window manager used. The default window manager twm has no such feature. But with fvwm2 this can be achieved with the this configuration entry:

Focus FocusFollowsMouse

Other window managers (eg. windowmaker) have similar features too.

If you are using the -multiwindow mode you can not set this behaviour in the window manager but you can use the TweakUI tool to enable this feature for all windows, not limited to Cygwin/X windows.

This question should be obsolete as the TerminateServer keybinding is no longer present by default.

The TerminateServer keybinding can be enabled with

setxkbmap -option terminate:ctrl_alt_bksp

You should start X with the -multiplemonitors option.

Note that this option is enabled by default in -multiwindow mode.

X uses port 6000/TCP when the option -listen tcp is used. You will have to allow incoming and outgoing traffic on this port even if you are only using local clients. X has a builtin access control so you won't have to worry about opening the port. If you are still concerned about security, you may limit the allowed hosts to the local IP addresses.

If you use a different display number check section Q: 1.6. for details about which ports are used. For additional information about firewalls and XDMCP connections check Q: 7.3..

A1:

Try adding the -v option to ssh, which often pinpoints the reason for a connection problem.

From the ssh man-page : -v Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3.

A2:

Before establishing the ssh connection the xserver must be started and the environment variable DISPLAY must be set.

$ DISPLAY=:0.0 $ export DISPLAY $ ssh -Y remotehost

or

$ DISPLAY=:0.0 ssh -Y remotehost

A3:

Make sure you're not starting ssh with the option -X. Since OpenSSH 7.2p1, ssh does not fallback to trusted forwarding, option -Y, so no X11 forwarding is setup. Use ssh -Y.

Make sure you're not starting ssh with the option -x (lowercase). This disables X11 forwarding.

A4:

Check that X11Forwarding is not disabled in the ssh client configuration.

The configfiles are by default ~/.ssh/config and /etc/ssh_config. The file in the home directory overrides settings in the global one.

The configfile is split into various sections starting with "Host wildcard". The section applies to all hosts where wildcard matches the hostname.

If this section contains an entry "ForwardX11 no" then X11Forwarding is disabled. To enable it change the entry to:

ForwardX11 yes

A5:

Check that X11Forwarding is not disabled in the ssh server configuration.

The configfile is by default /etc/ssh/sshd_config. If there is an entry "X11Forwarding no" then X11Forwarding is disabled.

If you have write access to the config file then change it to

X11Forwarding yes

The OpenSSH server must be restarted or SIGHUP'ed to re-read the configuration file after it is changed. Otherwise, ask your administrator to change this for you.

A6:

[Frederick W. Wheeler] If the remote machine is a Windows machine using Cygwin OpenSSH server, make sure the Cygwin xauth package is installed on the remote machine. The OpenSSH server needs to be able to run xauth to do X11 Forwarding.

This question should be obsolete since the SECURITY extension is now disabled

OpenSSH 3.8 enables untrusted X11Forwarding by default when connecting to an ssh server that supports it.

You will quickly notice that this is the case if most of your X applications are now killed when you try to copy and paste, X applications fail with an error similar to that below, or if xdpyinfo returns only a fraction of the supported extensions that it does if run locally.

 X Error of failed request: BadAtom (invalid Atom parameter)
  Major opcode of failed request: 18 (X_ChangeProperty)
  Atom id in failed request: 0x114
  Serial number of failed request: 370
  Current serial number in output stream: 372

It is easiest to just override untrusted X11Forwarding by passing -Y to ssh in place of -X. The -Y does the same thing as -X, but it enables trusted X11 forwarding for the current connection.

Setting "ForwardX11Trusted yes" in the ssh client configuration file does the same thing. See man ssh_config for more information.

See also Q: 6.1.

The warning means that ssh is going to use trusted X11 forwarding because untrusted X11 forwarding depends on the SECURITY extension, which isn't built into the X server and has been disabled by default upstream.

Trusted X11 forwarding means that you trust the server that you wish to ssh into. The X server will allow remote clients to do whatever a local client would be able to do to your X session, for example, monitor your keypresses and take a screenshot. Such programs could be run by a malicious or compromised root user on the ssh server, or under your account if it was compromised on the ssh server.

Starting with OpenSSH 3.8, untrusted forwarding is the default when X forwarding is requested using the -X command line option and you need to use the option -Y or specify "ForwardX11Trusted yes" in the client configuration for trusted forwarding by default.

Since OpenSSH 7.2p1, untrusted forwarding (ssh -X) does not fallback to ssh -Y trusted forwarding.

So why is this disabled? Untrusted X11 forwarding was meant to be a way to allow logins to unknown or insecure systems. It generates a cookie with xauth and uses the security extension to limit what the remote client is allowed to do. But this is widely considered to be not useful, because the security extension uses an arbitrary and limited access control policy, which results in a lot of applications not working correctly (e.g. not being able to cut and paste) and what is really a false sense of security. See this mail for more on the subject.

(Words adapted from an email by Yaakov Selkowitz)

Unless you started the X server with the -auth option (typically by using startx) this warning is expected and can safely be ignored.

Starting with OpenSSH 5.6, ssh enforces the ForwardX11Timeout (which defaults to 1200 seconds) when an untrusted connections is requested, even if an untrusted connection could not be made (e.g. you used ssh -X which asks for an untrusted connection, and got the "untrusted X11 forwarding setup failed" warning). This means that no new connections to the X server can be made 20 minutes after the ssh connection is established.

Use ssh -Y. See also Q: 6.2..

The X server now uses -nolisten tcp by default, which increases the security of the X server by not opening a TCP/IP socket.

Use the -listen tcp option to allow the X server to open a TCP/IP socket as well, e.g. startxwin -- -listen tcp. See Q: 4.2..

A better solution is to stop explicitly setting DISPLAY and allowing access using xhost or by disabling access control. Use ssh -Y instead. (See the User's Guide section on X forwarding using ssh for more details).

The X server now uses -nolisten tcp by default, which increases the security of the X server by not opening a TCP/IP socket, only a local (UNIX domain) socket. Non-cygwin applications cannot connect to that socket.

Use the -listen tcp option to allow the X server to open a TCP/IP socket as well, e.g. startxwin -- -listen tcp. See Q: 4.2..

Cygwin/X is sometimes unable to determine which local network interface's address should be reported to the XDMCP server; in these cases you need to pass -from local_host_name_or_ip_address to X to specify which interface address to report.

The problem is most likely a wrong DNS (Network name resolution). Make sure your windows host has a hostname which is valid from linux too and an IP address which linux can resolve to that hostname.

If you add a line

192.168.26.1 myhost

to /etc/hosts on the XDMCP server with the IP address and the hostname of your windows host the name resolution should work.

A1: Disabled XDMCP on servers

[Mika Laitio] For security reasons, XDMCP is not enabled by default on most Linux/UNIX/*NIX/*BSD distributions (Red Hat, Mandrake, SuSE, FreeBSD, NetBSD, etc.) by default. You have to manually enable remote logins to your X Display Manager (e.g. xdm, kdm, or gdm). The location of the proper config file is distribution/OS dependent, but a short list of known config file locations is given in Table 1. You must change the line:

[Xdmcp] Enable=false

to:

[Xdmcp] Enable=true

or for xdm style configuration:

DisplayManager.requestPort: 0

to:

!DisplayManager.requestPort: 0

A2: XDMCP and firewalls

XDMCP will not work correctly if you have a personal firewall installed or the built-in firewall of Windows is activated.

The XDMCP protocol will send and receive data on port 177/UDP. But the actual connections will be made to the local port 6000/TCP. It is safe to allow connections since the xserver has an own security layer. An overview of used ports is given in Table 2.

See Q: 7.3.

Newer versions of GDM have a more complex startup mechanism than the other display manager have. This can interfere with the way the clipboard integration client is started.

Workaround: add (or modify) this section in the gdm.conf (or /etc/gdm/custom.conf) file.

[daemon] KillInitClients=false

See also Q: 7.7. and Q: 7.8.

[David Dawson] For whatever reason, certain versions of Solaris need fonts that are not provided by Cygwin/X; the result is that you may see the Solaris background tile and the hourglass cursor, but the XDM login prompt will never appear. The simplest solution is to point Cygwin/X at the font server that is usually running on the Solaris machine. You'll need a command line similar to the following to start your XDMCP session and to connect to the Solaris font server:

X -query solaris_hostname_or_ip_address -fp tcp/solaris_hostname_or_ip_address:7100

The standard port number for a font server is 7100, however, you may need to ask your system administrator what the font server port number is if you cannot connect to a font server on port 7100. It is also possible that your Solaris machine is not running a font server, in which case you will need to consult your Solaris documentation for instructions on how to run a font server.

See also Q: 7.6. and Q: 7.8.

Solaris appears to not support certain display bit depths, such as 24 bits per pixel. Change your Windows display bit depth to 8, 16, or 32 and try logging in again. File a complaint with Sun if this issue is important to you, or change your Solaris machines to use XFree86 instead of the Solaris X Window System.

See also Q: 7.6. and Q: 7.7.

Install the recommended set of patches for your version of Solaris.

See the Linux XDMCP HOWTO for more information about XDMCP.

The Fatal Error is a general error message. More specific information what caused this is available in /var/log/xwin/XWin.0.log. Please check the common error messages in the Section called Error and Warning Messages. If your error is not mentioned proceed with Q: 8.4.

Yes. The Cygwin/X log file is located at /var/log/xwin/XWin.0.log. You will find solutions to the most common error messages in the Section called Error and Warning Messages.

See the Error and Warning Messages section for help with specific error messages. Return to this section if you do not find a specific answer for the error message that you have.

Search the Cygwin/X mailing list archives to see if the error message has already been reported and/or addressed. Report the error message to the cygwin@cygwin.com mailing list, how the error message was caused, and the behavior of the X Server after the error message was generated (exit, freeze, etc.), only if the error message has not been reported, if the circumstances that produced the error message are significantly different from other reports, or if you have additional information regarding the error message to contribute. Please include /var/log/xwin/XWin.0.log in your mail. This may help us identify the cause of your problem quicker.

Some bug reports are deliberately ignored by project members if the bug in question was recently dealt with; did you search the mailing list archives for a solution to your problem before submitting your bug report? Some bug reports are ignored if they do not contain sufficient information to understand the situation that produces the bug; did your bug report have enough information? Some bug reports are missed or forgotten, thus some valid bug reports do not receive a reply; simply resubmit such bug reports that have not received a response within 7 days of submission.

Zone Alarm 5 is known to break Cygwin/X. As a result you'll see this line (or a similar) as last output in /var/log/xwin/XWin.0.log

Rules = "xorg" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null)"

Disabling Zone Alarm will not solve this problem. You can only uninstall Zone Alarm 5 and switch to an earlier version (4.5 is known to work) or use a different personal firewall.

Another reason is /tmp mounted in textmode. This does only happen with the -multiwindow and -clipboard switches because of the extra threads within Cygwin/X.

You can remount /tmp to binmode with these commands:

mount -b "$(cygpath -m /tmp)" /tmp

If this fails with an error message stating insufficient rights, try

mount -b -u "$(cygpath -m /tmp)" /tmp

Most likely you have installed some kind of personal firewall, VPN software or any other software that modifies the TCP/IP stack of Windows. Especially Webwasher and some other filtering software are known to slow down the network traffic.

Some online virus scanners like Symantec Antivirus do slowdown Cygwin/X a lot. They scan every file access and network traffic which causes serious processing overhead beyond that from the X11 protocol and the unix emulation layer.

So far there is no known solution but to disable the virus scanner completely.

[Dr. Edward Wornar] Certain programs that are installed by various drivers and software packages can consume an incredible amount of system resources and processing time. One known example of such a program is ATI2evxx.exe, a utility installed with some ATI Technologies graphics card drivers. Answers That Work has information on ATI2evxx.exe on their Task List Programs - A page. You may want to try disabling, one-by-one, ATI2evxx.exe and other such programs until you find the program that is causing the slowdown.

Microsoft Services for Unix set some environment variables which points Cygwin/X to outdated or not existing files. These variables are

XAPPLRESDIR XCMSDB XKEYSYMDB XNLSPATH

To have Cygwin/X work correctly you have to unset at least XKEYSYMDB.

Reported by Juan Medina, Pavel Rozenboim

see Q: 8.7..

[Gerald S. Williams] The TrackPoint driver tries to send scroll up/down messages to the default scrollbar in a window. Cygwin/X does not use Windows scrollbars for X Client windows, so we must configure the TrackPoint driver to send standard WM_MOUSEWHEEL messages to the Cygwin/X window. This can be done by editing the TrackPoint configuration that can be found in the tp4table.dat and/or tp4scrol.dat files, which are usually located in %SYSTEM_ROOT%\System32\, %PROGRAMFILES%\Synaptics\SynTP\ or %PROGRAMFILES%\Lenovo\Trackpoint\.

Add the following to the "Pass 0 rules"section and then restart your computer to ensure the driver reloads it's settings.

; X Windows *,*,XWin.exe,*,*,*,WheelStd,0,9

This question should be obsolete.

This question should be obsolete

To workaround this add the command

run xsetroot -cursor_name left_ptr -fg white -bg black

to startxwin.bat

We think this question is probably obsolete

Try starting resize.

The problem are programs which treat Num-Lock as modifier similar to Control. The programs expect a plain click but received some strange Num-Lock-Click combination and can't associate this with the action "open menu".

_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created

This question should be obsolete as this error is no longer generated.

This warning message can be ignored; it does not cause any known problems.

This question should be obsolete as this error is no longer generated.

This error is harmless.

Most likely you have started X twice.

if you start multiple instances of X you have to give then unique display numbers

X -query foo X :1 -query bar X :2 -query blubb

Specifying no display number is the same as using :0

If you want another terminal window (which in fact is just a convenient side effect of running startxwin) you should do this by starting xterm & from an existing terminal window, from the notification area icon menu, from a cygwin shell or from the start menu.

This question should be obsolete as the default font is now built into the server.

This error occurs for one of three reasons:

1. You do not have a font package which provides the default font ('fixed') installed. This is rarely the problem; but in the event that it is the problem, just rerun Cygwin' setup program, select the font-misc-misc package and install it.

2. The mount point for /usr/share/fonts/ was either invalid (does not point to a valid folder on your system) or is a text-mode mount. You can confirm that this is the problem by running mount from a Cygwin shell and checking the disk path returned for the /usr/share/fonts/ mount point.

   Note: You cannot reliably fix this problem by deleting your Cygwin installation and reinstalling it. The mount points that Cygwin was using will be left in your system settings and the invalid mount point for /usr/share/fonts/ will be used again when you perform the reinstallation. You SHOULD follow the instructions below to fix the problem.

   To fix the problem, perform the following steps:

   1. Open a Cygwin shell and run umount /usr/share/fonts/.

   2. Close the Cygwin shell.

   3. Run Cygwin's setup program.

   4. For each of the font packages, if they are marked Keep, then select Reinstall, otherwise leave them as they are:

   5. Allow Cygwin's setup program to download and reinstall the fonts packages. The key to fixing this problem is that the files were previously untarred into an invalid location; removing the mount point for the fonts directory should result in the files being untarred to a valid location.

3. You chose "DOS/text" as the "Default Text File type" during Cygwin setup, ignoring the advice that the Default Text File Type should be left on Unix/binary unless you have a very good reason to switch it to DOS/text.

   Open a Cygwin shell and run.

   umount /usr/share/fonts/ mount -f -s -b "C:/cygwin/usr/share/fonts" "/usr/share/fonts"

   Reinstall your fonts

These warnings are generally harmless since they indicate that default search paths for fonts do not actually contain fonts; this is only a problem if the misc path does not contain fonts and/or all of the paths do not contain fonts.

If you are getting these message and the X Server is also failing to start, then see Q: 9.4. for information on how to fix your fonts.

This question should be obsolete.

Programs that you are attempting to use were compiled against a newer version of Cygwin than is currently on your system. Run Cygwin's setup program to update your installation to the latest version.

This question should be obsolete.

• It is believed that this may have the same underlying causes as Q: 9.16.

• cygwin1.dll uses a shared memory section amongst all loaded copies of cygwin1.dll; unfortunately, the layout and usage of the shared memory section changes between versions of cygwin1.dll. Loading two different versions of cygwin1.dll will cause the shared memory section to become corrupted, which almost always results in an Exception: STATUS_ACCESS_VIOLATION. You must search your filesystem(s) and remove all copies of cygwin1.dll except the copy in /bin. You must remove the different versions of cygwin1.dll even if they are not in your path, as programs that depend on cygwin1.dll attempt to load the file from the local directory before searching other paths; thus, it is rather easy, and common, for multiple versions of cygwin1.dll to become loaded at the same time if they exist on a particular system.

• See also this main Cygwin FAQ question for an issue which may cause this problem with older binaries on Terminal Server.

Cygwin/X queries getdtablesize() for the maximum number of client connections allowed; by default Cygwin returns 32 from getdtablesize(). Cygwin/X Server Test Series release Test44, released on 2001-08-15, changed the maximum number of clients from 32 to 1024 by passing the square of getdtablesize() to setdtablesize().

See Q: 9.9.

Certain classes of software, such as that used for Virtual Private Networking and fire-walling may cause the IP address 127.0.0.1, or other local adapter addresses, to be redirected, to become inoperable in some way, or to be operated in a manner that violates the defined operation of IP address.

As a potential remedy, try removing all instances of such software; this may not always fix the problem though, as some software may leave artifacts even after uninstallation is completed. The only way to be sure that you have not found a Cygwin/X bug is to install Windows on a freshly formatted hard drive, followed by Cygwin and Cygwin/X, and finally add your other software one application at a time until Cygwin/X stops working.

Some products that have been reported to cause problems:

• Aventail Connect

• Zonealarm PC Firewall from Zonelab

Increase your Windows environment space by following the instructions provided by Microsoft.

See Q: 9.12.

This question should be obsolete.

Both of these represent bugs in a caller of libX11, and not in libX11 or libxcb. The first assertion means that a caller attempted to lock the display while already locked. The second assertion means that a caller attempted to unlock the display without having it locked.

If you encounter such bugs, please report a bug against the offending software (which is not libX11 or libxcb)

This error can be worked around by using export LIBXCB_ALLOW_SLOPPY_LOCK=1

(EE) XKB: Could not invoke xkbcomp (EE) XKB: Couldn't compile keymap XKB: Failed to compile keymap Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. Fatal server error: Failed to activate core devices.

• Verify that xkeyboard-config is correctly installed using cygcheck -c xkeyboard-config,

• Check that /usr/bin/xkbcomp can be run from a bash shell. If that fails, see if cygcheck /usr/bin/xkbcomp reports any missing DLLs.

• Something is interferring with the ability of the X server to invoke xkbcomp to compile the keymap.

  See Q: 9.16. for possible causes.

This is commonly caused by one of three things:

• You have run Cygwin's setup program to do an update while some cygwin processes were running, and then clicked on the continue option in the "In-use files detected" dialog, and then tried to carry on using Cygwin without rebooting as advised by setup. Reboot.

• This is one of the symptoms of an application interfering with Cygwin's fork() emulation. See the main Cygwin FAQ question for a list of software which has been known to interfere with the correct operation of Cygwin.

• This also caused by DLLs with conflicting base addresses preventing Cygwin's fork() emulation from functioning correctly. See the main Cygwin FAQ question for advice.

This is believed to have the same underlying causes as Q: 9.16.

Look in Cygwin's setup program for packages in the X11 category.

Cygwin/X provides a software interface that is very similar to the software interface provided by GNU/Linux and other UNIX systems. Most software packages will compile on Cygwin/X without any changes at all. To begin with, try to compile a given software package following that package's compilation instructions for GNU/Linux.

One common problem encountered when porting software to Cygwin/X is due to Cygwin's inability to distinguish between files with the same name but different capitalization (e.g. XvMC.h and xvmc.h), which is due to a Windows' limitation.

#include "XvMC.h"

#include "../../../include/extensions/XvMC.h"

Cygwin has two OpenGL implementations:

1. headers in /usr/include/w32api/GL, libraries (-lglut32 -lglu32 -lopengl32) from the opengl and w32api packages which are for displaying OpenGL graphics directly through the native Windows interface (Win32) without any X server

2. headers in /usr/include/GL, libraries (-lglut -lglu -lgl) from the Mesa libGL packages (libGL-devel, libGL1, libGLU-devel, libGLU1, libglut-devel, libglut3, freeglut) which are for displaying OpenGL graphics through an X server.

These are incompatible, even the headers (as the native OpenGL API has the stdcall calling convention on x86), so you must exercise care if you have both sets of devel packages installed. An application must be built using only one of these.

• X applications using GLX must be built using option 2.

• Applications using GLUT have a choice.

• Applications using the WGL API must be built using option 1.

(Words adapted from an email by André Bleau)

Yes. The Cygwin/X Contributor's Guide has step-by-step instructions for obtaining the source, building the source, building debug versions of the source, and even cross-compiling under Linux.

Yes. Emacs and XEmacs are available for Windows; they both understand and preserve UNIX end of line characters.

Only submit patches that have UNIX end of line characters. See Q: 11.2. for information on editors for Windows that are aware of UNIX end of line characters.

Submit patches for Cygwin/X to the cygwin@cygwin.com mailing list.

See Q: 11.3. for more information on generating patches.

It does! Thanks to the excellent efforts of the X.Org community, the X Window System has been autotoolized since X.Org R7.0.

Anyone who despaired of touching the monolithic tree will find things much easier now with modular packages.

Cygwin/X uses the gcc compiler from the Free Software Foundation. Cygwin/X source code is mostly ANSI C compliant, but we cannot guarantee that Cygwin/X will compile with any other compiler, nor can we afford the time to support compilers other than gcc.

See the GCC Home Page for more information on gcc.

Cross-compiling from a non-Cygwin platform is described in the Cygwin/X Contributor's Guide

The required packages are listed in the Cygwin/X Contributor's Guide.

Cygwin/X proper isn't covered by a single license, as Cygwin/X is made up of two parts that are covered by distinct licenses: Cygwin and the X Window System.

See Q: 12.2. and Q: 12.3. for more information regarding the licenses that apply to Cygwin/X.

X Window System source code is generally licensed under an X11 style license, which is certified by the Free Software Foundation as compatible with the GNU GPL.

Cygwin source code is licensed under a modified version of the GNU GPL . Cygwin's license modification specifically allows third-party software under an open source license to be linked with Cygwin without requiring that the source code for the third-party software be distributed under the terms of the GNU GPL. Cygwin's developers went to great trouble to obtain this modification and should be thanked for doing so, as without it the modification, Cygwin/X linking to Cygwin would be the subject of endless discussion.

Cygwin/X proper doesn't have a single copyright holder, as Cygwin/X is made up of two parts, namely Cygwin and the X Window System; each part follows a different scheme in regards to who will hold the copyright on source code.

See Q: 12.5. and Q: 12.6. for more information regarding who holds the copyright on Cygwin/X source code.

Each source code file in the X Window System typically has its own license and copyright statement. Therefore, there is not a general rule for determining who holds the copyright on a particular X Window System source file, as each author is free to assign the copyright to someone else, to some group, or to keep the copyright themselves. You must inspect the source code file in question to determine who holds the copyright for that file.

Red Hat owns the copyright on the Cygwin source code. Red Hat requires that copyright be assigned to Red Hat for non-trivial changes to Cygwin. You must fill out a copyright transfer form if you are going to contribute substantial changes to Cygwin.

Motif is a product of The Open Group. After many years under the The Open Group Public License (which does not satisfy the Open Source Definition and is thus not compatible with Cygwin's license), Motif was released as free software under the LGPL v2.1 in October 2012.

Not in the USA, at least. A quick search at the United States Patent and Trademark Office for "XWin" turns up one dead record and one live record. The live record is for a logo belonging to a rock crusher manufacturer based out of Belgium. Neither trademark affects Cygwin/X, as the dead record is no longer enforceable, while the live record is in an unrelated and distinct industry; there cannot be confusion between rock crushers and computer programs.