[ANNOUNCEMENT] Updated: xorg-server-1.14.2-2 (64 bit only)
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.14.2-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.14.2-1: * [cygwin64] Fix multiwindow mode windows not being able to change title, icon or decoration after they are first shown. * [cygwin64] Fix ARGB cursors being vertically stretched by interleaving blank rows of pixels. 7eb32909079742014613b541aac1d96c *xorg-server-1.14.2-2.tar.bz2 af4b7b7d185b6e17a5635a9aa338b588 *xorg-server-common-1.14.2-2.tar.bz2 def267cf3f0ca22884f7879c90e0ef4a *xorg-server-debuginfo-1.14.2-2.tar.bz2 0a813828717cfd40d723572ae8c7dd0b *xorg-server-devel-1.14.2-2.tar.bz2 7f4d8456cb743eadfd25418e47549b6c *xorg-server-dmx-1.14.2-2.tar.bz2 1d0f60c30ac8c83b3ae7f329f4ecd22d *xorg-server-extra-1.14.2-2.tar.bz2 fcd30f2e0429052db28b17d413b58b1b *xserver-cygwin-1.14.2-2.tar.bz2 7d9b72fae0f5f0e3b0b7abf423c68073 *xwinclip-1.14.2-2.tar.bz2 41f4913fe1725e943a49a6fd49e60888 *xorg-server-1.14.2-2-src.tar.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/
[ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental)
The following packages have been updated in the Cygwin distribution: *** XtoW-20130802-1 *** libxcwm0-20130802-1 *** libxcwm-devel-20130802-1 xtow is a window manager using the libxcwm library, which is: * native: it integrates with native window management by putting each top-level X window in it's own Windows window (similar to XWin -multiwindow) * compositing: X windows with per-pixel alpha are composited into the native DWM desktop on Windows Vista and later (e.g. a native window can be seen through a semi-transparent X window placed over it) XtoW is still experimental, but should now be usable enough for doing some actual work. Testing and problem reports are appreciated. Changes since 20121220-1: * Window images are now transferred from the X server using shared memory when possible, which improves drawing speed measurably. This can be disabled with -noshm * XtoW exits cleanly when X server is shutdown * XtoW exits immediately when sent an unhandled signal (e.g SIGTERM from being ctrl-c'ed) * When X windows resize or reposition themselves, those changes are propagated to the native windows * Handle tilt wheel and renumber buttons to align with XWin -multiwindow * Implement iconic state. Handle WM_HINTS.initial_state on map and WM_CHANGE_STATE messages correctly * The active window is moved to the top of the stacking order to ensure it receives mouse events over itself (This is shortcut until proper Z-order <-> stacking synchronization is implemented) * Try harder to ensure newly created windows are at the top of the Z-order * Add -verbose option. Multiple -verbose options increase verbosity. * Lots of libxcwm cleanup, logging improvements, bug-fixes and refactoring * Fixes for x86_64 build Missing features compared to XWin -multiwindow: * You must manually use setxkbmap to set a keyboard layout matching the windows layout. * Probably lots more To use: * A startxtow script is provided, which writes a suitable xorg.conf, starts the X server, XtoW, xwinclip and a transparent urxvt. This script is intended to be temporary, to be replaced by something better later on... 32-bit: 74673adf7504f9c7c463e2760eb54d3f *libxcwm-20130802-1-src.tar.bz2 dc09df025e7bc1c6c2c4c0a05773840f *libxcwm-debuginfo-20130802-1.tar.bz2 6c9d5d4189f6aedb598c5f08a40b *libxcwm-devel-20130802-1.tar.bz2 b504e1e2a35b5ed261948fd222c79778 *libxcwm0-20130802-1.tar.bz2 87ec6a8c0edf1db142676a3d085a89e4 *XtoW-20130802-1-src.tar.bz2 445379bb679c83d7a3976d974c1d203d *XtoW-20130802-1.tar.bz2 c51aaa365fc7bc3a6d5db1a332c6d90e *XtoW-debuginfo-20130802-1.tar.bz2 64-bit: d95f6482b93eb50a5fabec34721cbde7 *libxcwm0-20130802-1.tar.bz2 edec6064c8526cafe30c675bf13c0abc *libxcwm-debuginfo-20130802-1.tar.bz2 fd402a3380909866e7084c7297913efd *libxcwm-devel-20130802-1.tar.bz2 0851bffc634ba9ec651b0579f42329dd *libxcwm-20130802-1-src.tar.bz2 8d427629181968c6c113d738d187fd0d *XtoW-20130802-1.tar.bz2 309ae5649e80b1142ef096b5cd65bc80 *XtoW-debuginfo-20130802-1.tar.bz2 4d467a813653ffc8be0fb92bdb34a585 *XtoW-20130802-1-src.tar.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental)
On 05/08/2013 09:54, Corinna Vinschen wrote: > On Aug 4 19:17, Jon TURNEY wrote: > I fixed http://cygwin.com/cygwin-64bit-missing > >> To use: >> >> * A startxtow script is provided, which writes a suitable xorg.conf, starts >> the X server, XtoW, xwinclip and a transparent urxvt. This script is >> intended >> to be temporary, to be replaced by something better later on... > > The script is missing in the 64 bit version. How to start XtoW > without that script? Oops. It seems that I made a packaging error and startxtow is missing from both x86 and x86_64 packages. I've uploaded a XtoW-20130802-2 which includes the script. It'll still need some adjusting on x86_64, as it requires both perl-Win32-GUI and rxvt-unicode-X which aren't yet packaged, but you could work around that by hard-coding your display dimensions and using a different X terminal... -- 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/
[ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental)
The following packages have been updated in the Cygwin distribution: *** XtoW-20130802-2 xtow is a window manager using the libxcwm library, which is: * native: it integrates with native window management by putting each top-level X window in it's own Windows window (similar to XWin -multiwindow) * compositing: X windows with per-pixel alpha are composited into the native DWM desktop on Windows Vista and later (e.g. a native window can be seen through a semi-transparent X window placed over it) XtoW is still experimental, but should now be usable enough for doing some actual work. Testing and problem reports are appreciated. Changes since 20130802-1: * Fix packaging to include the startxtow script omitted in error 32-bit: 8257d61cd3009f8650557d7bb51fc3c2 *XtoW-20130802-2-src.tar.bz2 ed03f3f86b3b9c8169d4d87c5afd5ef7 *XtoW-20130802-2.tar.bz2 68507bbf78b450afeb5eeb317a3de52c *XtoW-debuginfo-20130802-2.tar.bz2 64-bit: 0c0f2fefcf7397a014f4c0dfd3c27feb *XtoW-20130802-2.tar.bz2 57feeed6aa8cfd6aa6ba643ef15d83a7 *XtoW-debuginfo-20130802-2.tar.bz2 4bdc965921b2a75e7dd2a4f0ca9c86b5 *XtoW-20130802-2-src.tar.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: XtoW, a native compositing window manager (experimental)
On 20/08/2013 21:01, Jim Reisert AD1C wrote: >> * A startxtow script is provided, which writes a suitable xorg.conf, starts >> the X server, XtoW, xwinclip and a transparent urxvt. This script is >> intended >> to be temporary, to be replaced by something better later on... > > Once the window manager is running, how do I create new windows? In > X, there's an X icon in the system tray I can right-click. There's nothing to do that for you at the moment, so you will just have to start the applications from the command line, ensuring DISPLAY is set appropriately. Haven't really got around to thinking about what might be used as a separate launcher/panel application or how it might integrate with startmenu links. -- 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: unable to maximize gtk window
On 01/09/2013 16:13, Simon wrote: > $ gcc -o simple simple.c `pkg-config --libs --cflags gtk+-2.0` > $ ./simple.exe > > The window fails to maximize on startup > I've found this out when using gnome terminator on cygwin, which fails to > maximize on startup, and strangely is only able to maximize when opening up a > new tab Thanks for reporting this problem and the testcase. I've added a patch improves the window hint conversion in multiwindow mode so that the hint which gtk_window_maximize() sets is now recognized as maximizing the window. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it improves things for you? (This is a x86 binary. if you need an x64 binary, please let me know and I'll generate one) > On 01/09/2013 22:00, Angelo Graziosi wrote: >> Perhaps, there is a similar discussion for GTK builds of Emacs trunk on >> Cygwin: >> >> http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-08/msg00953.html This might be responsible for some of the problems listed there, but I think there is still something not quite right about the way a maximized emacs window is treated, so more work is needed. [1] ftp://cygwin.com/pub/cygwinx/XWin.20130909-git-7cebbec4b67fd4d8.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: unable to maximize gtk window
On 09/09/2013 15:43, Simon wrote: >> Thanks for reporting this problem and the testcase. >> >> I've added a patch improves the window hint conversion in multiwindow mode so >> that the hint which gtk_window_maximize() sets is now recognized as >> maximizing >> the window. >> >> I've uploaded a snapshot at [1]. Perhaps you could try that and see if it >> improves things for you? >> >> (This is a x86 binary. if you need an x64 binary, please let me know and I'll >> generate one) > Thanks, that appears to fix the testcase, but terminator still has the same > problems, I'll try to find out what is happening there. 'terminator -m' works correctly for me with that snapshot. -- 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.exe crashes on Windows restart
On 10/09/2013 22:16, Andreas Girgensohn wrote: > I start XWin.exe via a shortcut when logging into Windows 7 (64-bit). > Recently, I replaced my Cygwin installation with the 64-bit version. > Now, XWin.exe crashes (SIGSEGV) every time I restart or shutdown > Windows. > > I produced a gdb backtrace by cancelling the restart quickly after the > problem occurred. Additional files are attached. > > (gdb) bt full > #0 0x0001004071ea in winMsgWindowProc (hwnd=, > message=, > wParam=, lParam=) > at /usr/src/debug/xorg-server-1.14.2-2/hw/xwin/winmsgwindow.c:58 > pScreen = > hwnd = > message = 22 > wParam = > lParam = > #1 0x77139bd1 in USER32!TranslateMessageEx () >from /cygdrive/c/Windows/system32/USER32.dll > No symbol table info available. > #2 0x050c in ?? () > No symbol table info available. > #3 0x0001 in ?? () > No symbol table info available. > #4 0x in ?? () > No symbol table info available. Thanks for reporting this problem, and providing the backtrace. I've added a patch which should fix this crash and uploaded a snapshot at [1]. Perhaps you could try that and see if it improves things for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.x86_64.20130911-git-0919b42581c05bf8.exe.bz2 > On a different note, when running gdb, I noticed that XWin.exe twice > receives a SIGSYS when starting. That does not affect normal > operations. This is expected when cygserver (which provides SySV shared memory) is not running, as the X server tests to see if shared memory is available before using it, by checking if shmget() causes a SIGSYS... -- 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: unable to maximize gtk window
On 11/09/2013 19:05, Simon wrote: > On 12/09/2013 2:53 AM, Jon TURNEY wrote: >> On 09/09/2013 15:43, Simon wrote: >>>> Thanks for reporting this problem and the testcase. >>>> >>>> I've added a patch improves the window hint conversion in multiwindow mode >>>> so >>>> that the hint which gtk_window_maximize() sets is now recognized as >>>> maximizing >>>> the window. >>>> >>>> I've uploaded a snapshot at [1]. Perhaps you could try that and see if it >>>> improves things for you? >>>> >>>> (This is a x86 binary. if you need an x64 binary, please let me know and >>>> I'll >>>> generate one) >>> Thanks, that appears to fix the testcase, but terminator still has the same >>> problems, I'll try to find out what is happening there. >> 'terminator -m' works correctly for me with that snapshot. >> > It does for me too, but if I start terminator with no command line arguments > (directly after I start x server), then maximize the window using the windows > button, or by double clicking the title bar, I get a window that's not fully > maximized. This works for me, but this sounds like a different problem to the one you first reported. There is a difference between a window asking to maximize itself (via the appearance hint that gtk_window_maximize() sets), and using the window manager to maximize using the frame controls (title bar double click or maximize button) I'm not sure what you mean by 'not fully maximized', this seems different to 'not maximized' Perhaps the window may not get fully maximized as it's frame dimensions are (should be?) constrained to ensure that they are an integer multiple of the character cell size? -- 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/
[ANNOUNCEMENT] Updated: xorg-server-1.14.3-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.14.3-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes and improvements [1], this contains the following cygwin-specific changes since 1.14.2-2: * Display the host triplet in About... dialog * [cygwin64] Fix _WINDOWSWM_NATIVE_HWND window property (Thanks to Marc Haesen for the patch) * [cygwin64] Various warning fixes (Thanks to Marc Haesen for the patch) * Add support in multiwindow mode for the window hint used by gtk_window_maximize(), allowing such windows to maximize themselves (Reported by simonzack) * [cygwin674] Fix a WM_ENDSESSION crash (Reported by Andreas Girgensohn) * Update the WGL wrapper function generation script to use the Khronos group XML description of the WGL interface (Thanks to Marc Haesen for the patch) [1] http://lists.x.org/archives/xorg-announce/2013-September/002320.html x86: f987c294106e9966d19f3e747ea24c0b *xorg-server-1.14.3-1-src.tar.xz 328a1eeec40b75e7db7e0979dc1ac908 *xorg-server-1.14.3-1.tar.xz cd630db0286bababa3371e887cab77bc *xorg-server-common-1.14.3-1.tar.xz 2cce8b7af1006025e8b6323b078fd363 *xorg-server-debuginfo-1.14.3-1.tar.xz 0cdc530e3aec7fb3eca06a3d0de0db8c *xorg-server-devel-1.14.3-1.tar.xz 40f0bd90503a55a5f90fec4259e31de2 *xorg-server-dmx-1.14.3-1.tar.xz f749bc75bf83379e830d9a306cb4b5a3 *xorg-server-extra-1.14.3-1.tar.xz 9faf5969103ed5ddf7c34333b629aece *xwinclip-1.14.3-1.tar.xz x86_64: 5dadb7d161ca2d6fd53d5150e6630972 *xorg-server-1.14.3-1-src.tar.xz 6b47952fc0059844588e6e98247d860e *xorg-server-1.14.3-1.tar.xz 57439dc9a9f748301be3f7b1a728a7b8 *xorg-server-common-1.14.3-1.tar.xz fa52220ae88e58182715e92b05cb1b76 *xorg-server-debuginfo-1.14.3-1.tar.xz 7c40b0b524facdae5a17a035798b97af *xorg-server-devel-1.14.3-1.tar.xz a1c838ea45050f54aa907ae7f998e6a1 *xorg-server-dmx-1.14.3-1.tar.xz a5bc29308c5e5308473b1d211b41 *xorg-server-extra-1.14.3-1.tar.xz 6e053b1bd206e7c63a343c66c10243ca *xwinclip-1.14.3-1.tar.xz -- 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: font-misc-misc out of era
On 20/09/2013 17:37, Thomas Wolff wrote: > The X fonts in the package font-misc-misc is out-of-era, from ASCII times, > so that e.g. if you start xterm -fn 9x18 you wouldn't even see a Euro sign. > Please replace them with their Unicode versions from > http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html Markus Kuhn's X11 unicode bitmap fonts have been included in the upstream X.Org package for some years (see [1]) This seems to be an issue with the font specification: "9x18" aliases to "-misc-fixed-medium-r-normal--18-120-100-100-c-90-koi8-r" (which I don't have installed on my system, and probably doesn't have a euro character) $ xterm -fn 9x18 Warning: Cannot convert string "9x18" to type FontStruct xterm: cannot load font '9x18' xterm: cannot load font '9x18' but this works fine: $ xterm -fn -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1 and I can type € with no problem. We probably need to do something more intelligent than just using the upstream font aliases package verbatim to fix this problem. [1] http://cgit.freedesktop.org/xorg/font/misc-misc/log/ -- 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: Strange interaction between Cygwin/X and Mozilla Firefox Bookmarks
On 23/07/2013 22:15, Falk Tannhäuser wrote: > Am 23.07.2013 14:59, schrieb Jon TURNEY: >> I can't reproduce this. >> >> I think there must be some other factor at work: the XWin error message >> relates to a timeout during X -> Windows clipboard conversion, but I can't >> make clicking on a firefox bookmark cause that conversion to happen. >> >> There are definitely bugs in this area, so any additional information you can >> provide would be helpful. > > After deeper investigation, it occurs that the problem is triggered by gnuplot > in particular (I was effectively unable to reproduce it with a few other X11 > applications, as xterm, xfig, xdvi or ddd). Most of the time I use gnuplot > from within Octave, but the easiest way to reproduce the problem is by > launching gnuplot directly in a Cygwin terminal window, then entering "plot > sin(x), cos(x)" on the gnuplot prompt to open an X11 pop-up window containing > a plot. Here is the terminal output from gnuplot: > > $ gnuplot > > G N U P L O T > Version 4.6 patchlevel 3last modified 2013-04-12 > Build System: CYGWIN_NT-5.1 i686 > > Copyright (C) 1986-1993, 1998, 2004, 2007-2013 > Thomas Williams, Colin Kelley and many others > > gnuplot home: http://www.gnuplot.info > faq, bugs, etc: type "help FAQ" > immediate help: type "help" (plot window: hit 'h') > > Terminal type set to 'x11' > gnuplot> plot sin(x), cos(x) > gnuplot> > > After this, clicking on Firefox bookmarks shows the problem - also when using > the bookmark window opened with Ctrl-Shift-B. I also tried to relaunch FF in > "safe mode" i.e. with add-ons disabled, with the same result. After closing > gnuplot it is necessary to wait for a few minutes until FF's behaviour returns > to normal; alternatively one can close the X server to restore the normal > function of FF immediately. Thanks for taking the time to investigate this, and the detailed reproduction steps. This is indeed a strange interaction. The problem seems to be (i) (for some reason) Firefox asks for the current clipboard contents when any of the bookmarks are clicked on, (ii) gnuplot puts an image of the current plot in the PRIMARY selection, and (iii) a previous fix to clipboard integration code [1] has the unforeseen negative side-effect that when the monitored selection cannot be converted to text, the clipboard integration code sits there waiting for up to a second, which blocks the Windows application which asked for the clipboard contents (Firefox in this case) Thanks for reporting this problem. I've added a patch which tries to fix this behaviour by actually checking if the selection can be converted to a text format before trying, and uploaded a snapshot at [2]. Perhaps you could try that and see if it improves things for you? [1] http://cgit.freedesktop.org/xorg/xserver/commit/?id=a9aca218f557c723e637287272819a7c17174e1e [2] ftp://cygwin.com/pub/cygwinx/XWin.20130924-git-d5a9aea0e48a088b.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: font-misc-misc out of era
On 21/09/2013 18:25, Thomas Wolff wrote: > Am 20.09.2013 19:21, schrieb Jon TURNEY: >> On 20/09/2013 17:37, Thomas Wolff wrote: >>> The X fonts in the package font-misc-misc is out-of-era, from ASCII times, >>> so that e.g. if you start xterm -fn 9x18 you wouldn't even see a Euro sign. >>> Please replace them with their Unicode versions from >>> http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html >> Markus Kuhn's X11 unicode bitmap fonts have been included in the upstream >> X.Org package for some years (see [1]) > Looking precisely, they are actually included in the cygwin font-misc-misc > package, though in addition to small script-specific old versions. I think the > latter should be removed to reduce confusion. I'm sorry, I don't understand what you are suggesting here. Removing (for example) the ISO8859-1 encoded 9x18 font would seem to be a bad idea, as that will break things for anything which is currently using the font with that encoding? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.14.3-2
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.14.3-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.14.3-1: * [cygwin64] Enable GLX * Revert some clipboard integration changes which caused it to be unreliable * Clipboard integration tweaks and debug improvements * Avoid blocking the Windows application which requested the clipboard contents when the clipboard contents can't be converted to a text format (Reported by Falk Tannhäuser) * Add command line and tray menu options to control monitoring of the PRIMARY selection The crashes in software rendering on x86_64 are fixed in the mesa 8.0.5-4 packages, so GLX is now enabled on x86_64, and can use WGL (in multiwindow mode) or gallium softpipe rendering (in windowed mode, or when the -nowgl option is used). llvmpipe (which is used on x86, and is faster than softpipe) is not yet available as llvm is not yet available on x86_64. An experimental option '-noprimary' has been added to XWin and xwinclip, which disables monitoring of the X11 PRIMARY selection (normally, the highlighted text), so only the X11 CLIPBOARD selection (normally, the cut/copied text) is monitored for mapping to the Windows clipboard. XWin also has an additional item in the notification area icon right-click menu to allow this monitoring to be turned on and off while the server is running. x86: ddd35ac5c89e9476c98ed7d22b217e0c *xorg-server-1.14.3-2-src.tar.xz 87ae340fcb966343d36d06d58a02e4c9 *xorg-server-1.14.3-2.tar.xz ff37b9e63512bbd097342c0a68886895 *xorg-server-common-1.14.3-2.tar.xz 4720b80f829077c7a5a56af0ad96c0b4 *xorg-server-debuginfo-1.14.3-2.tar.xz 6f90909f1e8cc325ca08aa467c7366aa *xorg-server-devel-1.14.3-2.tar.xz ec3d8c6b9e83cc121b76fff077a28536 *xorg-server-dmx-1.14.3-2.tar.xz dbee599fe1bb2cda18f0c2aa3046a657 *xorg-server-extra-1.14.3-2.tar.xz 5bea39e888b424316e8274fc0f99ded9 *xwinclip-1.14.3-2.tar.xz x86_64: c0533889b92235c821d89dd2aa638fb7 *xorg-server-1.14.3-2-src.tar.xz 688a1efa094d21be39d06918b91d5022 *xorg-server-1.14.3-2.tar.xz 44d0f8eebb0e7840b7ec43b7243339ba *xorg-server-common-1.14.3-2.tar.xz 23595e02fd25c8ab9214231472fc3b3c *xorg-server-debuginfo-1.14.3-2.tar.xz 5ad79326439795a0e677123dbad33099 *xorg-server-devel-1.14.3-2.tar.xz 5bd182decb5b588ba86eb284ed40a816 *xorg-server-dmx-1.14.3-2.tar.xz 011b17c1d9315c4a2ea46948dbbfcce8 *xorg-server-extra-1.14.3-2.tar.xz 26e09f333cb963e38d0a7e1cf54d0d30 *xwinclip-1.14.3-2.tar.xz -- 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: 2 button keypad
On 30/09/2013 01:54, bagl...@tux.org wrote: > I am a long time user. And I love the new 64 bit version seems to cleared > up all my virus scanner induced problems. > > On two different laptops I noticed that -emulate3buttons 100 (or without > the 100) is ignored. I don't have 2 button mouse only 2 button mousepads. > This used to work. For Toshiba, I don't know of a work around. For my > Lenovo, I activated a middle button (but for consistency I would always > like the two button way to always work). -emulate3ubttons appears to work correctly for me. > According to documentation its > deactivated if you don't have a 2 button button mouse... so a 2 button > keypad does not seem to qualify? It seems to me it should never be > deactivated if someone requests it. The documentation for '-emulate3buttons' says that the *default* is to enable that option if Windows reports a two buttons, otherwise disabled. An explicit -emulate3buttons should always override the default. Can you please provide your /var/log/xwin/XWin.0.log -- 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 trying to build Cygwin X server from source
On 20/10/2013 23:57, Mark Lillibridge wrote: > Jon TURNEY writes: >> On 19/10/2013 20:54, Mark Lillibridge wrote: >> > >> > This is xserver-cygwin-1.14.3-1, the latest as of several weeks ago. >> > >> > The part that is failing (make done in >> > /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin/glx): >> > >> > CC wgl_ext_api.lo >> > In file included from wgl_ext_api.c:72:0: >> > generated_wgl_wrappers.c:79:1: error: unknown type name >> 'PFNWGLDXSETRESOURCESHAREHANDLENVPROC' >> > generated_wgl_wrappers.c:79:1: warning: initialization makes integer from >> pointer without a cast [enabled by default] >> > generated_wgl_wrappers.c:80:1: error: unknown type name >> 'PFNWGLDXOPENDEVICENVPROC' >> > generated_wgl_wrappers.c:80:1: warning: initialization makes integer from >> pointer without a cast [enabled by default] >> > generated_wgl_wrappers.c:81:1: error: unknown type name >> 'PFNWGLDXCLOSEDEVICENVPROC' >> > generated_wgl_wrappers.c:81:1: warning: initialization makes integer from >> pointer without a cast [enabled by default] >> > ... >> >> I think this is error is due to the khronos-opengl-registry package being >> more >> recent than the wglext.h provided by w32api-headers. >> >> I think the easiest way to work around this is to update wglext.h from >> http://www.opengl.org/registry/api/GL/wglext.h > > Hmmm. Which occurrence should I replace? > > mdl [103]# find /usr -name wglext.h -print > /usr/i686-w64-mingw32/sys-root/mingw/include/GL/wglext.h > /usr/include/GL/wglext.h > /usr/include/w32api/GL/wglext.h > /usr/x86_64-w64-mingw32/sys-root/mingw/include/GL/wglext.h > > mdl [112]# grep wglext * > wgl_ext_api.c:#include > wgl_ext_api.h:#include > > mdl [118]# grep usr/include * > Makefile:DBUS_CFLAGS = -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include > Makefile:DIX_CFLAGS = -DHAVE_DIX_CONFIG_H $(CWARNFLAGS) > -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -I/usr/include/pixman-1 -I/usr/include/freetype2 -I$(top_srcdir)/include > -I$(top_builddir)/include -I$(top_srcdir)/Xext -I$(top_srcdir)/composite > -I$(top_srcdir)/damageext -I$(top_srcdir)/xfixes -I$(top_srcdir)/Xi > -I$(top_srcdir)/mi -I$(top_srcdir)/miext/sync -I$(top_srcdir)/miext/shadow > -I$(top_srcdir)/miext/damage -I$(top_srcdir)/render -I$(top_srcdir)/randr > -I$(top_srcdir)/fb -I$(top_srcdir)/dbe > Makefile:PIXMAN_CFLAGS = -I/usr/include/pixman-1 > Makefile:XSERVERCFLAGS_CFLAGS = -D_BSD_SOURCE -DHAS_FCHOWN > -DHAS_STICKY_DIR_BIT -I/usr/include/pixman-1 -I/usr/include/freetype2 > Makefile:XSERVERLIBS_CFLAGS = -I/usr/include/pixman-1 > -I/usr/include/freetype2 > Makefile:oldincludedir = /usr/include > > mdl [119]# grep mingw/include * > > I'm guessing from the above that it's this one: > > /usr/include/GL/wglext.h Yes, I guess that's first in the include search path. Since w32api now provides a that header, we should probably stop providing it in libGL-devel. > I replaced that one and the code in > /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin/glx > now compiles. Unfortunately, code now fails elsewhere: > > cd /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin > make > > gives: > ... > make[2]: Leaving directory > `/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin/winclipboard' > Making all in . > make[2]: Entering directory > `/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin' > CC InitInput.o > CC InitOutput.o > InitOutput.c: In function ‘ddxGiveUp’: > InitOutput.c:240:9: warning: ISO C90 forbids mixed declarations and code > [-Wdeclaration-after-statement] > InitOutput.c: In function ‘winCheckMntOpt’: > InitOutput.c:284:16: warning: cast discards ‘__attribute__((const))’ > qualifier from pointer target type [-Wcast-qual] > CC winallpriv.o > CC winauth.o > In file included from > /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/winsock2.h:56:0, > from /usr/include/X11/Xwinsock.h:55, > from /usr/include/X11/Xpoll.h:163, > from ../../os/osdep.h:85, > from winauth.c:39: > /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/psdk_inc/_fd_types.h:100:2: > warning: #warning "fd_set and associated macros have been defined in > sys/types. This can cause runtime
Re: Problem trying to build Cygwin X server from source
On 19/10/2013 20:54, Mark Lillibridge wrote: > > This is xserver-cygwin-1.14.3-1, the latest as of several weeks ago. > > The part that is failing (make done in > /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin/glx): > > CC wgl_ext_api.lo > In file included from wgl_ext_api.c:72:0: > generated_wgl_wrappers.c:79:1: error: unknown type name > 'PFNWGLDXSETRESOURCESHAREHANDLENVPROC' > generated_wgl_wrappers.c:79:1: warning: initialization makes integer from > pointer without a cast [enabled by default] > generated_wgl_wrappers.c:80:1: error: unknown type name > 'PFNWGLDXOPENDEVICENVPROC' > generated_wgl_wrappers.c:80:1: warning: initialization makes integer from > pointer without a cast [enabled by default] > generated_wgl_wrappers.c:81:1: error: unknown type name > 'PFNWGLDXCLOSEDEVICENVPROC' > generated_wgl_wrappers.c:81:1: warning: initialization makes integer from > pointer without a cast [enabled by default] > ... I think this is error is due to the khronos-opengl-registry package being more recent than the wglext.h provided by w32api-headers. I think the easiest way to work around this is to update wglext.h from http://www.opengl.org/registry/api/GL/wglext.h > Any suggestions? The online documentation is seriously out of date, > predating the use of cygport. Which documentation, specifically? -- 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 trying to build Cygwin X server from source
On 27/10/2013 01:26, Mark Lillibridge wrote: > Jon TURNEY writes: > >> You will need to apply the attached change to /usr/include/Xpoll.h to fix >> xserver compilation with w32api-headers >= 3.0.0-1, which adds a new WIN32 >> define somewhere, which breaks this test. > > It's /usr/include/X11/Xpoll.h on my system. That patch indeed makes > the compilation proceed further. It's now stuck at: Sorry, my mistake. > CCLD XWin.exe > ../../glx/.libs/libglx.a(glxcmds.o): In function `FlushContext': > /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:221: > undefined reference to `__emutls_v._glapi_tls_Dispatch' > ../../glx/.libs/libglx.a(glxcmds.o): In function `DoMakeCurrent': > /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:623: > undefined reference to `__emutls_v._glapi_tls_Dispatch' > ../../glx/.libs/libglx.a(glxcmds.o): In function `_glXDisp_WaitGL': > /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:806: > undefined reference to `__emutls_v._glapi_tls_Dispatch' > ../../glx/.libs/libglx.a(glxcmds.o): In function `_glXDisp_CopyContext': > /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:904: > undefined reference to `__emutls_v._glapi_tls_Dispatch' > ../../glx/.libs/libglx.a(glxcmds.o): In function `_glXDisp_SwapBuffers': > /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:1647: > undefined reference to `__emutls_v._glapi_tls_Dispatch' > ../../glx/.libs/libglx.a(glxcmds.o):/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:1851: > more undefined references to `__emutls_v._glapi_tls_Dispatch' follow > collect2: error: ld returned 1 exit status > Makefile:890: recipe for target `XWin.exe' failed This looks like [1], a mis-match in TLS-ness between XWin and libglapi. If you are building using the .cygport file it should have ./configure'ed with --disable-glx-tls? [1] http://www.cygwin.com/ml/cygwin-xfree/2011-10/msg00065.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/
[ANNOUNCEMENT] Updated: xorg-server-1.14.4-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.14.4-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes and improvements [1], this contains the following cygwin-specific changes since 1.14.3-2: * Fix a crash on shutdown which could occur when using '-depth 8' x86: 93badb3cc24ccad50595a3ab62c306d4 *xorg-server-1.14.4-1-src.tar.xz a5ce603ae02e4de4e9ea8475b04cca5b *xorg-server-1.14.4-1.tar.xz e05eb13557a396b56e4ec056473247e0 *xorg-server-common-1.14.4-1.tar.xz 0088dc534429c52b073a9aafe3182924 *xorg-server-debuginfo-1.14.4-1.tar.xz d1842a3efa3f42f2ee9bb9d7b45d1ef6 *xorg-server-devel-1.14.4-1.tar.xz 35cedcf55a44bb4b99dc35cf8e65049c *xorg-server-dmx-1.14.4-1.tar.xz b12cff63276e561d108843b6d4d62af4 *xorg-server-extra-1.14.4-1.tar.xz a45e9b09c33c3802f26d59d415b2fbe3 *xwinclip-1.14.4-1.tar.xz x86_64: d89feb079071d10ba4bcb9a4319104f4 *xorg-server-1.14.4-1-src.tar.xz 11f5040fcc7e82985ec5e88c7be73452 *xorg-server-1.14.4-1.tar.xz 146e394f7281c4fe1bca82dfbd658e25 *xorg-server-common-1.14.4-1.tar.xz 6476ca490ec21f036f5c86bfdd155d49 *xorg-server-debuginfo-1.14.4-1.tar.xz c67dcd4cdf08991cc6bfc8338b396517 *xorg-server-devel-1.14.4-1.tar.xz 428548d4159fcf814b0ae46ec705bd7e *xorg-server-dmx-1.14.4-1.tar.xz 058e2592b2b27ab5ada89b0272b7ed55 *xorg-server-extra-1.14.4-1.tar.xz 0a7d294a6095b2ed014eeab48136156b *xwinclip-1.14.4-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2013-November/002352.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: Copy/paste broken from X to Windows
On 21/10/2013 05:45, Matt D. wrote: > Copy/paste seems to be broken when attempting to copy a large block of text > from X to Windows. See the attachment for an example. > > Copying the text from Windows to X seems fine but the reverse causes the mouse > cursor to spin and then a blank string to paste. Thanks for the bug report and reproduction steps. I can reproduce this problem, and there's definitely a timing sensitive bug here (which a larger paste seems to trigger). There is also perhaps something not quite right about the way select() is behaving here, as it seems to be returning 0 before the timeout expires, which I need to investigate further. I've uploaded a snapshot at [1] with a fix and a workaround. Perhaps you could try that and see if it improves things for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20131121-git-49551bf34e231173.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: DPI setting not respected in version 1.14.4
On 20/11/2013 16:53, Kostas Avgeropoulos wrote: > My Windows shortcut is > > 'C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c "/usr/bin/startxwin.exe > -- -clipboard -emulate3buttons -dpi 80"' > > Yet Cygwin/X does not seem to respect the DPI setting. Fonts are too big. > > This worked with previous versions of Cygwin/X. > > Any ideas? I can't reproduce this: $ startxwin -- -clipboard -emulate3buttons -dpi 80 $ xdpyinfo -display :1 | grep resolution resolution:80x80 dots per inch Can I please see your /var/log/xwin/XWin.0.log? -- 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: Clipboard periodically breaks
> On Thu Sep 26 20:35:21 2013, Matt D. wrote: >> However, an environment variable that tells it which clipboard to >> use would provide an immediate solution and be used used on a >> per-application basis. For example, I can use aliases when launching >> programs: >> >> $ xclip=clipboard1 gedit $@ (monitor only clipboard 1) >> $ xclip=clipboard2 gedit $@ (monitor only clipboard 2) >> >> No option would indicate that both clipboard 1 and clipboard 2 would >> be handled as they are now. >> >> I'm not familiar with X programming but I'm assuming here that it >> would be possible for xclip to read from a particular process's own >> environment (rather than xclip's own) while processing a clipboard >> event to do this. >> >> What do you think? This is not straightforward to implement and is not really a good solution as it won't work for remote X clients. In theory, it might be possible to annotate the X client window with a property which tells XWin/xwinclip how to treat it's clipboard use, but since the clipboard-owning window is often a hidden one, getting that property on there poses problems. Hopefully the -noprimary option makes this less of an issue. -- 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: Restricting Port 6000 access in Cygwin/X
On 09/12/2013 14:37, Kevin Brown wrote: > My company recently sent an audit finding requesting for our Cygwin/X users > with a finding of the following; > > "The remote host is running an X11 server. X11 is a client-server protocol > that can be used to display graphical applications running on a given host > on a remote client. Since the X11 traffic is not ciphered, it is possible > for an attacker to eavesdrop on the connection." > > The suggested solution was; > > "Restrict access to this port. If the X11 client/server facility is not > used, disable TCP support in X11 entirely (-nolisten tcp)." > > > My problem is that I haven't found any information that would help me > accomplish this task. I've only recently taken over support of our Cygwin > users and am not well versed in the software. Can this be done without > breaking the functionality of the the software? If so, can you please > advise on the steps to take to accomplish this? The usual caveat applies: if you have an actual need for security, a random person on the internet is not where you should be getting your information. As suggested, if you start the X server with the option '-nolisten tcp' (see 'man Xserver'), then it will not accept remote connections. There's probably something to be said for this being the default configuration and requiring an explicit '-listen', but historically it's been this way. If you then need to connect to remote clients, use ssh forwarding, see [1]. [1] http://x.cygwin.com/docs/ug/using-remote-apps.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/
[ANNOUNCEMENT] Updated: xorg-server-1.14.4-2
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.14.4-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.14.4-1: * Fix a regression introduced in 1.14.3-2 which caused large X->Windows clipboard pastes to fail (Reported by Matthew D'Onofrio and Markus Hoenicka) x86: 1b301b4adf30bcd676ed17b646da739f *xorg-server-1.14.4-2-src.tar.xz a9267d8e8b0de27a855c32c70873e3ce *xorg-server-1.14.4-2.tar.xz fb8600efa64cba8104ab95fb3193e342 *xorg-server-common-1.14.4-2.tar.xz 7a6fcf8e459b2d47dbc41d898dd8e13c *xorg-server-debuginfo-1.14.4-2.tar.xz e15c9b3b9a93da9f703293a9a574b272 *xorg-server-devel-1.14.4-2.tar.xz d1f990416adbd2128932de395ff76b92 *xorg-server-dmx-1.14.4-2.tar.xz eb87c1306f2d61df637e6c7699578870 *xorg-server-extra-1.14.4-2.tar.xz e4e6ab9a97521a2a676f6a0be2917b62 *xwinclip-1.14.4-2.tar.xz x86_64: b5b4275491dd52340f5624816fe57800 *xorg-server-1.14.4-2-src.tar.xz f20699106bb72e6d00e54eb4074a4297 *xorg-server-1.14.4-2.tar.xz c90e7fa2bc08705b139d0220eef05195 *xorg-server-common-1.14.4-2.tar.xz 126717f83e68a7cb727e2fa8fe8d417c *xorg-server-debuginfo-1.14.4-2.tar.xz 21b1552b741b868a7d953a30ff319b85 *xorg-server-devel-1.14.4-2.tar.xz 4e48650aa07b8e8ca460ddcd5c45492a *xorg-server-dmx-1.14.4-2.tar.xz c826a17f6efaa7366443fbca3d659567 *xorg-server-extra-1.14.4-2.tar.xz 34157b2dc670ba3ec921deacdd1217f8 *xwinclip-1.14.4-2.tar.xz -- 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: ideas on how to debug an X server crash on Windows 8.1 (x64)?
On 11/12/2013 01:13, Kevin Layer wrote: > I forgot to attach my XWin.0.log. Here it is: That log doesn't show any signs of a crash. If you install the xorg-server-debuginfo package, a possibly useful backtrace should be written to the log after a crash occurs. -- 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/
[ANNOUNCEMENT] Updated: xorg-server-1.14.5-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.14.5-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], this contains the following cygwin-specific changes since 1.14.4-2: * [source] Fix compilation issues due to wglext.h from current w32api-headers being older than current khronos-opengl-registry, by only generating wrappers for used WGL functions, rather than for all WGL functions in the khronos registry. * Add Windows 8.1, Windows Server 2012 R2 and Windows XP x64 to the list of Windows versions we know the name of x86: dce14b69416f4dd266e64259dd5608cd *xorg-server-1.14.5-1-src.tar.xz 7a6678e1faa65d68db2454d55d035fca *xorg-server-1.14.5-1.tar.xz c26482974b9d5489d45e7e3aa7f2ffa8 *xorg-server-common-1.14.5-1.tar.xz d10032aa8aef4232e985e1eb02fbcdd2 *xorg-server-debuginfo-1.14.5-1.tar.xz dccc65c582d969353e4240831372f6fe *xorg-server-devel-1.14.5-1.tar.xz fe4c78489e6292c15196ad2d4017b6e8 *xorg-server-dmx-1.14.5-1.tar.xz 5cda1742e20627e221d556a1247c5c34 *xorg-server-extra-1.14.5-1.tar.xz 7dc9c8ad2595c33a29950eeec9b357e7 *xwinclip-1.14.5-1.tar.xz x86_64: f443f626460c070ffa864388b4b313c1 *xorg-server-1.14.5-1-src.tar.xz bc2eada8deaa1a9302ba06467778f03f *xorg-server-1.14.5-1.tar.xz 315119e3b02fc24554a5ede0adfea5ad *xorg-server-common-1.14.5-1.tar.xz 9454005636a0d7e2e8a807ce845ef18a *xorg-server-debuginfo-1.14.5-1.tar.xz 983974d314c7bfe911cff24345cc130d *xorg-server-devel-1.14.5-1.tar.xz 29c1917eec35daa6b7526af4460b9bca *xorg-server-dmx-1.14.5-1.tar.xz 582293c6ee84bdd1b1cf5e94cf07ab32 *xorg-server-extra-1.14.5-1.tar.xz 0626211769fa5349491844649c56b912 *xwinclip-1.14.5-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2013-December/002380.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: Problem opening remote X applications
On 03/01/2014 04:51, Chris Carlson wrote: > I just downloaded Cygwin 64-bit for the first time. I've been using Cygwin > 32-bit for years. [...] > I usually "ssh -X " to a remote Linux machine. I can then read mail > (thunderbird), edit documents (LibreOffice 3.x), run Chrome, and edit programs > (Emacs). I'll have half a dozen windows open through the X tunnel provided by > ssh. Works well and lasts for hours. > > After upgrading to Cygwin 64-bit (this last weekend), everything *seems* to be > okay for a while. After about 20 minutes, though, I can no longer open > windows remotely. Even though I have thunderbird currently open, when I try > to run Chrome, I get "(google-chrome:20006): Gtk-WARNING **: cannot open > display: localhost:10.0". If I try to open xclock from the command line, I > get: > > xclock > Error: Can't open display: localhost:10.0 > > Does anybody know what happened? Why has the tunnel disappeared? It hasn't > actually disappeared because I'm still running thunderbird through it. http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-twenty-minute-timeout Use 'ssh -Y' -- 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/
[ANNOUNCEMENT] Updated: xorg-server-1.15.0-1 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.15.0-1 These packages contain XWin and the other X.Org X11 servers. This is the first release of the xserver 1.15 series. It is currently available as a test release, and will be made stable in approximately two weeks if no major regressions are reported. Please try test releases and report problems to the Cygwin/X mailing list. Testing helps ensure good releases! Unfortunately, the upstream announce mail [1] does not contain a full changelog since 1.14, so you will need to consult the changelog or git for a list of upstream fixes and improvements. There are no (intentional) cygwin-specific changes since 1.14.5-1. x86: d29aeff70c9fa7e622b04e86e88f2f9c *xorg-server-1.15.0-1-src.tar.xz f464b530a51fe8d55c3bc55d259d600f *xorg-server-1.15.0-1.tar.xz 9599fbcdd1897a9bd02817a0fbe2 *xorg-server-common-1.15.0-1.tar.xz 8403e211be7ab47c1c14f00869046de2 *xorg-server-debuginfo-1.15.0-1.tar.xz 972d713e25991778c839d3a2ef53e778 *xorg-server-devel-1.15.0-1.tar.xz 2b0040d028b446e5f683807dca6f7c29 *xorg-server-dmx-1.15.0-1.tar.xz 433dcd8a8529851dd75e5e203c3455ed *xorg-server-extra-1.15.0-1.tar.xz 2e43cfb335f1ba0f36987a327383cb11 *xwinclip-1.15.0-1.tar.xz x86_64: 048068b4580a067309a66639f4598158 *xorg-server-1.15.0-1-src.tar.xz 4a02e4a5fa3d884d24fb02e505bd39a0 *xorg-server-1.15.0-1.tar.xz 49f275342128be6d50246094f87e0d72 *xorg-server-common-1.15.0-1.tar.xz d862067d1a6dbb9f936d062b0998b0fd *xorg-server-debuginfo-1.15.0-1.tar.xz 5577996388cc04023db34944097d8dc4 *xorg-server-devel-1.15.0-1.tar.xz 3977151c3b5ebebd861e9c96d7d7b6a2 *xorg-server-dmx-1.15.0-1.tar.xz 644ffc8ccc5cad33f468cd5f226e9c7d *xorg-server-extra-1.15.0-1.tar.xz 7f425e320fd678e6a3f8ba6489b70f4f *xwinclip-1.15.0-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2013-December/002384.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: [ANNOUNCEMENT] Updated: xorg-server-1.15.0-1 (TEST)
On 08/01/2014 08:39, Angelo Graziosi wrote: > Jon TURNEY wrote: >> The following packages have been updated in the Cygwin distribution: >> >> *** xorg-server-*1.15.0-1 > > I DO NOT want install this test version, but when I run setup-x86 to update my > Cygwin installation (I find only a few GraphicsMagic packages to be updated), > it wants install additional packages needed by xorg-server set of packages. > This didn't occur a few minutes before this announcement... Could you be a bit more specific about the additional dependencies it wants to install? > I wonder if something went wrong when you updated this test version of > xorg-server*. If not, sorry for the noise.. :( There are small differences in the dependencies for 1.15, but setup handles this situation badly, so the current actual dependencies need to be the union of those for 1.14 and 1.15. -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.15.0-1 (TEST)
On 08/01/2014 14:34, Angelo Graziosi wrote: > Il 08/01/2014 15.03, Jon TURNEY ha scritto: >> Could you be a bit more specific about the additional dependencies it wants >> to >> install? > > Setup wants install also these packages Thanks. > libxcb-keysyms1 Required by: xorg-server-extra This is expected. This is a new dependency of Xephyr in 1.15 as it's been xcb-ified, and due to setup limitations this needs to be added as a dependency now. (Setup (still) doesn't have a mechanism to specify the dependencies per version, and if it is omitted test installations of xorg-server-extra 1.15 won't work) > resourceprotoRequired by: xorg-server-devel > scrnsaverprotoRequired by: xorg-server-devel These should have been listed as dependencies before. I don't know why they weren't. -- 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/
[ANNOUNCEMENT] Updated: xorg-server-1.15.0-2 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.15.0-2 These packages contain XWin and the other X.Org X11 servers. This is the first release of the xserver 1.15 series. It is currently available as a test release, and will be made stable in approximately two weeks if no major regressions are reported. Please try test releases and report problems to the Cygwin/X mailing list. Testing helps ensure good releases! The following cygwin-specific changes have been made since 1.15.0-1: * Fix a crash which could occur when a GL client exits without deleting it's GL contexts * Don't create fbConfigs for un-accelerated pixelFormats provided by the generic renderer. (This is a workaround for some GL clients ending up preferring them) x86: 308bbe0a4bd012f91f4ae7deb997fdcd *xorg-server-1.15.0-2-src.tar.xz 0bd884dc7c6b201e40d9c7dfc2ccd957 *xorg-server-1.15.0-2.tar.xz 60f3f468736386f39b6aea8fa40c6d62 *xorg-server-common-1.15.0-2.tar.xz 69901afd7bcac3f9dc4bac4b0b6db72c *xorg-server-debuginfo-1.15.0-2.tar.xz da1c755ead0fa193793efa136a6565f5 *xorg-server-devel-1.15.0-2.tar.xz 4d538efc0388f2377d2b32c4d6205bb0 *xorg-server-dmx-1.15.0-2.tar.xz 3bdea2a296b0c6ec392dfdb830a27473 *xorg-server-extra-1.15.0-2.tar.xz 7bdb50170d366922d821087f87d950cb *xwinclip-1.15.0-2.tar.xz x86_64: 1021f0fdf0380f558a80c0132dec005b *xorg-server-1.15.0-2-src.tar.xz 54188189b058ddfbe401a9e075495ff6 *xorg-server-1.15.0-2.tar.xz f95c2fd23cb0496053ba8ffd3de6381a *xorg-server-common-1.15.0-2.tar.xz 47527e5431121e7d8be8fdb2ff9c96b0 *xorg-server-debuginfo-1.15.0-2.tar.xz f054b102939f0d885a37277e3a269b55 *xorg-server-devel-1.15.0-2.tar.xz f96150cbf1f1e56cc2417ce088f18593 *xorg-server-dmx-1.15.0-2.tar.xz 004b334a74924674b0eaebbf50bf1a73 *xorg-server-extra-1.15.0-2.tar.xz 5994809ce08251085546a3aa64a56a13 *xwinclip-1.15.0-2.tar.xz -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xorg-server-1.15.0-2 (TEST)
On 11/01/2014 21:07, Jon TURNEY wrote: > The following packages have been updated in the Cygwin distribution: > > *** xorg-server-*1.15.0-2 > > These packages contain XWin and the other X.Org X11 servers. > > This is the first release of the xserver 1.15 series. It is currently > available as a test release, and will be made stable in approximately two > weeks if no major regressions are reported. These packages have been promoted from test to current. > Please try test releases and report problems to the Cygwin/X mailing list. > Testing helps ensure good releases! > > The following cygwin-specific changes have been made since 1.15.0-1: > > * Fix a crash which could occur when a GL client exits without deleting it's > GL contexts > * Don't create fbConfigs for un-accelerated pixelFormats provided by the > generic renderer. (This is a workaround for some GL clients ending up > preferring them) > > x86: > 308bbe0a4bd012f91f4ae7deb997fdcd *xorg-server-1.15.0-2-src.tar.xz > 0bd884dc7c6b201e40d9c7dfc2ccd957 *xorg-server-1.15.0-2.tar.xz > 60f3f468736386f39b6aea8fa40c6d62 *xorg-server-common-1.15.0-2.tar.xz > 69901afd7bcac3f9dc4bac4b0b6db72c *xorg-server-debuginfo-1.15.0-2.tar.xz > da1c755ead0fa193793efa136a6565f5 *xorg-server-devel-1.15.0-2.tar.xz > 4d538efc0388f2377d2b32c4d6205bb0 *xorg-server-dmx-1.15.0-2.tar.xz > 3bdea2a296b0c6ec392dfdb830a27473 *xorg-server-extra-1.15.0-2.tar.xz > 7bdb50170d366922d821087f87d950cb *xwinclip-1.15.0-2.tar.xz > > x86_64: > 1021f0fdf0380f558a80c0132dec005b *xorg-server-1.15.0-2-src.tar.xz > 54188189b058ddfbe401a9e075495ff6 *xorg-server-1.15.0-2.tar.xz > f95c2fd23cb0496053ba8ffd3de6381a *xorg-server-common-1.15.0-2.tar.xz > 47527e5431121e7d8be8fdb2ff9c96b0 *xorg-server-debuginfo-1.15.0-2.tar.xz > f054b102939f0d885a37277e3a269b55 *xorg-server-devel-1.15.0-2.tar.xz > f96150cbf1f1e56cc2417ce088f18593 *xorg-server-dmx-1.15.0-2.tar.xz > 004b334a74924674b0eaebbf50bf1a73 *xorg-server-extra-1.15.0-2.tar.xz > 5994809ce08251085546a3aa64a56a13 *xwinclip-1.15.0-2.tar.xz -- 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 xman-1.1.3-1
On 18/02/2014 07:56, Doran Kangwai wrote: > When I use xman 1.1.3-1 to view man pages it renders the pages as > postscript. It seems to omit the step to process the PS. Close, but not quite right. groff is not being given the -T option to set the output format, so it's producing the default, ps > So I see stuff like this > %!PS-Adobe-3.0 > %%Creator: groff version 1.22.2 > ... > ... > > Using man to display the page works fine. > > When I use xman 1.1.2-1 the man page is also rendered correctly. Thanks for reporting this problem, and the clear reproduction steps. I can reproduce the problem, and bisecting points to this commit [1], which changes the formatting command used by xman. Yaakov, Attached is trivial patch to fix. If it looks good to you can you apply and rebuild xman? [1] http://cgit.freedesktop.org/xorg/app/xman/commit/?id=d25a3b87ce9fdf950b42f45b644242d72e7167b3 >From ea0ecbfa007e03e29f80f976472a28e37cf59931 Mon Sep 17 00:00:00 2001 From: Jon TURNEY Date: Wed, 19 Feb 2014 14:51:34 + Subject: [PATCH app/xman] Use same FORMAT command on cygwin as on linux in HANDLE_ROFFSEQ case as well Signed-off-by: Jon TURNEY --- vendor.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vendor.h b/vendor.h index 548ded6..06df38f 100644 --- a/vendor.h +++ b/vendor.h @@ -159,7 +159,7 @@ from the X Consortium. # define REFER "refer" # if defined(CSRG_BASED) # define FORMAT "nroff -mandoc" -# elif defined(linux) +# elif defined(linux) || defined(__CYGWIN__) # define FORMAT "GROFF_NO_SGR= groff -Tlatin1 -mandoc" # elif defined(__DARWIN__) # define FORMAT "nroff -man" -- 1.8.3.4 -- 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: Clipboard integration does not work with XDMCP
On 21/02/2014 16:51, Danilo Turina wrote: > Hello, > I need to connect from my PC to a Linux machine that runs KDE and I use > the following command: > > XWin -from MY_PC_IP_ADDR -terminate -query LINUX_MACHINE_IP_ADDR > > It works well but the clipboard integration that fails. > > Notice that: > 1) XWin alone (i.e. no XDMCP, i.e. local) works nicely with my Windows > clipboard > 2) Xming works (almost) fine with XDMCP + clipboard (with the same Linux > machine) > > I gave a look at the XWin log in two cases: > A) XWin alone > B) XWin + XDMCP > > And the only differences I've found (apart from the different command line > arguments) is the following lines that were at the end of the log of the XDMCP > invokation: > > winProcEstablishConnection - winInitClipboard returned. > winClipboardThreadProc - DISPLAY=:0.0 > winClipboardProc - XOpenDisplay () returned and successfully opened the > display. > winClipboardIOErrorHandler! > winClipboardProc - setjmp returned for IO Error Handler. > winClipboardProc - trying to restart clipboard thread > winClipboardThreadProc - DISPLAY=:0.0 > winClipboardProc - XOpenDisplay () returned and successfully opened the > display. > winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT > message, exiting main loop. > winClipboardProc - XDestroyWindow succeeded. Thanks for reporting this problem, and the clear reproduction steps. The issue here is that the XDMCP login dialog kills all other X clients (including the clipboard integration client) for security. The clipboard integration client is supposed to restart and reconnect as necessary, but it seems this has been broken for a while. I've has a go at fixing this and uploaded a snapshot at [1]. Perhaps you could try that and see if it improves things for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20140222-git-c14d82e878fc884d.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/
[ANNOUNCEMENT] Updated: xorg-server-1.15.0-3
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.15.0-3 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.15.0-2: * Repair clipboard thread restart to fix clipboard integration when using XDMCP x86: d7781c8687ccc1899247d926ee9e3ac4 *xorg-server-1.15.0-3-src.tar.xz bbc29bb3fa18db2718d76194d85af29d *xorg-server-1.15.0-3.tar.xz e0532f3c58c23fbc26bc106ec0787fd4 *xorg-server-common-1.15.0-3.tar.xz 3f454a19e21ae0946f3feac5f3126d63 *xorg-server-debuginfo-1.15.0-3.tar.xz f56c1be28a08641e1f8760802a01 *xorg-server-devel-1.15.0-3.tar.xz dae8627af10f67cbc7e05481e40f79a9 *xorg-server-dmx-1.15.0-3.tar.xz 23fda3a7ad5e3715cce264e276bd9d26 *xorg-server-extra-1.15.0-3.tar.xz 1cff6e920a03faae1aa92073f284495b *xwinclip-1.15.0-3.tar.xz x86_64: defec20186c24179bdcc3788121546af *xorg-server-1.15.0-3-src.tar.xz 0fbcf1723f69e5ad60b671abcf9ba629 *xorg-server-1.15.0-3.tar.xz 336fb72e0f0cdb8ab1a74a9e87696730 *xorg-server-common-1.15.0-3.tar.xz 0228c041826e2a9f08448030aa943aab *xorg-server-debuginfo-1.15.0-3.tar.xz 48bf6754524d5fb0b1e5a3fd676f1804 *xorg-server-devel-1.15.0-3.tar.xz b9bc92c27bc49f4b367eb251d7bc569d *xorg-server-dmx-1.15.0-3.tar.xz 565d6f9c0f62af0cade69b70ea77c86f *xorg-server-extra-1.15.0-3.tar.xz 46d177a5bf0928215ccf16fe02e656ed *xwinclip-1.15.0-3.tar.xz -- 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/
Re: problem with opengl (glxgears) running on cygwin ....
On 20/03/2014 08:41, Linda Walsh wrote: > When I try to run glxgears locally, it displays the initial gears, > but now they are just frozen. It doesn't work remotely, either, > which was what I tried initially. It *used* to work -- remotely > at 20-30 frames/second (as measured by fraps). > > Interestingly enough, I get a glx window, -- fraps will display > 30 (the right number for my screen refresh rate), in the right corner > of the glxgears window... but the gears don't move. > > Same effect happens when I try remotely. Window comes up with gears > displayed, but no motion. Fraps also shows 30 FPS. Thanks for pointing out this issue. I think that currently glxgears doesn't work very well with the combination of indirect rendering and vsync-limited buffer swapping, so you are getting 30 fps, but they aren't useful frames. Since [1], glxgears turns at a constant 70 degrees per second. glxSwapBuffers does not block when used with indirect rendering, which means that lots of frames can be rendered almost instantly, with no apparent rotation, since the elapsed time between frames is very small. glxgears is a very basic test that GLX is functioning, and definitely not a benchmark. Real GLX clients should have a better mechanism for ensuring their animation rate doesn't outrun the vsync frequency. If you have any problems with real GLX clients, I would be interested to hear them. [1] http://cgit.freedesktop.org/mesa/demos/commit/src/xdemos/glxgears.c?id=0b19fb0a5c6299baf28e26625e39773846f815b2 > When I try remote display, the above is pretty much the same except > I get an error on the client system that it can't load the 3d swrast.so > driver on the other end. There is some problem with loading the swrast_dri.so renderer on the remote system, so it is falling back to indirect rendering. What is the OS of the remote system? > But it sees pretty much the same capabilities -- FWIW, there is next to zilch > network traffic happening when I try this.. I mean while it is happening. > > Before and after ~ 200-400KB/s (xosview), during, all my X windows become > very slow and no longer refresh steadily. Network throughput registers a drop > to 1-80KB/s. Despite that -- xwin pegs a cpu @100% and stays that way > until I exit glxgears. I think this is because glxgears will send frames as fast as it can, and can saturate the X server. -- 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/
[ANNOUNCEMENT] Updated: xorg-server-1.15.0-4
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.15.0-4 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.15.0-3: * Improve mapping of no-decoration MOTIF hint to remove system menu controls (This avoids a problem with fbpanel fighting the WM if it is minimized, causing it to spin) * Remove decorations and system menu controls from _NET_WM_WINDOW_TYPE_SPLASH type windows (e.g. GIMP splash screen) * Fix a regression introduced in 1.15.0-1 with Xephyr initial window sizing (fd.o bug #74849) x86: e605c0fb8d88d5b9a487ae6a1cf00237 *xorg-server-1.15.0-4-src.tar.xz d12e033678dcafde281f79b7501e587a *xorg-server-1.15.0-4.tar.xz d99e85f5cc4eaeb85c5480344d1c442b *xorg-server-common-1.15.0-4.tar.xz 2c334080fb5096ef4dd35fd75b996fe8 *xorg-server-debuginfo-1.15.0-4.tar.xz 3c7aed02c28caff4a537a95833b77836 *xorg-server-devel-1.15.0-4.tar.xz 84aeffd498d851dc8d1e4aad5dbeaa81 *xorg-server-dmx-1.15.0-4.tar.xz 1d19e543c3c0300d5cbb2e9d8031519b *xorg-server-extra-1.15.0-4.tar.xz 7824e7c0c493466804402658bbee0c63 *xwinclip-1.15.0-4.tar.xz x86_64: a5263742d75b2a09193a6eb184b63fe0 *xorg-server-1.15.0-4-src.tar.xz e5cad2b04a1156b65049ded9b968f1f5 *xorg-server-1.15.0-4.tar.xz 20467393505b8a5b6f8d15183d563e0c *xorg-server-common-1.15.0-4.tar.xz d12431ffa174028b8fdff7c9f132938d *xorg-server-debuginfo-1.15.0-4.tar.xz c5bece08ce1435a2b14cb356ebe5bc24 *xorg-server-devel-1.15.0-4.tar.xz 1b483964cc7196bb6f66c9097b3908b5 *xorg-server-dmx-1.15.0-4.tar.xz e0c6816c143b06cb08792461bd98ffed *xorg-server-extra-1.15.0-4.tar.xz 244ec52ab31578aa2c4f1e7b7ca89361 *xwinclip-1.15.0-4.tar.xz -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.15.1-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.15.1-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], this contains the following cygwin-specific changes since 1.15.0-4: * In multiwindow mode, the -hostintitle option to add the remote hostname to window title is now enabled by default. It can be disabled with -nohostintitle. * Fixed checking of WM_NORMAL_HINTS for not-maximizeable and fixed-size hints in multiwindow mode * Stop reporting GL extensions which are supported by WGL but not by the X server * libXfont is now linked to as a shared library (Thanks to Yaakov Selkowitz for patch) * Fix GL_ARB_vertex_program glGetvertex[dfi]v() failing with GLXUnsupportedPrivateRequest * Cosmetic and technical improvements to crash backtrace logging * The obsolete PrimaryDD and ShadowDD DirectDraw2 drawing engines are disabled and will be removed at a later date. * Fixed crashing if OpenGL is used on the root window in multiwindow mode. (It still doesn't do anything useful as the root window is hidden, but now it doesn't crash) * [source] Fix building for MinGW (Thanks to Yaakov Selkowitz for patch) x86: bdcbdee28da5126cc81b684e33cf2259 *xorg-server-1.15.1-1-src.tar.xz ba8b2a08799f178cc01fb201b287f47e *xorg-server-1.15.1-1.tar.xz 3d3cfd3ca19332c51d506c13a2ed8e0d *xorg-server-common-1.15.1-1.tar.xz f30910e49494912c178a91d101265784 *xorg-server-debuginfo-1.15.1-1.tar.xz 0c76f69036a09a7ac60ccd2e648d3e40 *xorg-server-devel-1.15.1-1.tar.xz 3925f14898a917cef6e483a58e9536ed *xorg-server-dmx-1.15.1-1.tar.xz 790530fde2ac4382e8fa2f42eec474cf *xorg-server-extra-1.15.1-1.tar.xz 79ce74744dd9a523aea4870f15b7f79b *xwinclip-1.15.1-1.tar.xz x86_64: cd79db430cf1ad3b8270ae199543922a *xorg-server-1.15.1-1-src.tar.xz 90989661e754d27a9b9985ca4826980d *xorg-server-1.15.1-1.tar.xz feae2ee57cc98cd9f370ce91c6ce34a6 *xorg-server-common-1.15.1-1.tar.xz c8f4c730d8e523fee246e691b58bab03 *xorg-server-debuginfo-1.15.1-1.tar.xz bcbf3dfb7b733901c5e04d3d7e1b255f *xorg-server-devel-1.15.1-1.tar.xz c5aecb803ea0e096460bd992a0b8ddc9 *xorg-server-dmx-1.15.1-1.tar.xz 9039179b84f66e63985d8973e0f5f4d1 *xorg-server-extra-1.15.1-1.tar.xz 5fe7a096682f8d955d39294088da836b *xwinclip-1.15.1-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2014-April/002419.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: 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: running openGL application remotely using ssh -X and cygwin/x ,extension "NV-GLX" missing on display "localhost:10.0
On 24/04/2014 23:45, Biris, Octavian wrote: I am attempting to run an opengl application remptely to a ubuntu linux machine from my windows 8 machine. To do so I start the cygwin console, call startxwin. Running glxinfo | grep OpenGL returns the vendor of my graphics card, NVIDIA. glxinfo |grep OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 580/PCIe/SSE2 OpenGL version string: 1.4 (4.4.0) OpenGL extensions: Then I ssh on the ubuntu machine using -X -C as the parameters. When attempting to start the application the console reads extension "NV-GLX" missing on display "localhost:10.0". Afterwards, the cygwin/X server crashes and I have to restart it.I attached the log from /var/log/Xwin/XWin.0.log Thanks for the bug report. I'm afraid that the log doesn't contain enough information for me to identify the cause of the crash. Can you install the xorg-server-debuginfo package and try again? I also have been working on a tool to automate sending better crash information using minidumps. If you would like to try that, download it from [1] (anonymous ftp) and put it into /usr/bin and reproduce your crash again. [1] ftp://cygwin.com/pub/cygwinx/x86_64/xorg_cygwin_crash_reporter_gui.exe Does cygwin/x support running OpenGL applications remotely? Am I missing something? Do I have to install the mesa-utils libraries on the remote machine? Yes, this should work. I'm not entirely clear if the 'extension “NV-GLX” missing' message is a warning or an error, but according to the internet it seems to be due to having a Nvidia libGL installed on the remote machine, so if all else fails you might look at uninstalling the Nvidia proprietary driver and libGL, and using mesa instead. -- 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: running openGL application remotely using ssh -X and cygwin/x ,extension "NV-GLX" missing on display "localhost:10.0
On 28/04/2014 22:02, Linda Walsh wrote: Jon TURNEY wrote: Yes, this should work. *But*, I'm pretty sure it doesn't anymore since the "Xgl" extension that was used to transport the openGL commands between client/server was removed from xorg's Xserver. You seem to be confusing Xgl (an X server implementation) and GLX (an X protocol extension). While they do contain the same letters in a different order, they are very different things. AIGLX doesn't work with client's native openGL drives when the DISPLAY isn't local. Instead, it sends full-frame-buffer updates to simulate what would be happening -- something that "appears" to work correctly for small OpenGL windows. But is entirely 'faked' (not really remote openGL that used the Server's acceleration Hardware. Which would give you unaccelerated frame-buffer updates to simulate the effect. Not quite what used to be available. This is also totally wrong. You are (more or less) describing how mesa's direct software rendering works (which is usually the default path for remote displays) which is completely different to AIGLX (where GL commands are sent via the GLX protocol to the X server and rendered using acceleration there) So, again, please stop spreading misinformation. I'm sure there are bugs in and limitations with OpenGL and the XWin server, but if you have a problem, please don't hijack someone else's thread, but report it in sufficient detail for me to try to reproduce it. -- 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 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/
[ANNOUNCEMENT] Updated: xorg-server-1.15.1-2
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.15.1-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.15.1-1: * Fix X server sometimes getting stuck during exit if it owns the Windows clipboard * Fix sometimes missing system menu icons in multiwindow mode on Vista and later * Avoid a "Your OS is unknown" warning when configuring Xorg for cygwin x86: a4a3a9cbf96f57caea3aa75817c315fd *xorg-server-1.15.1-2-src.tar.xz f2005846a8c6532f525e47bd2c7835b6 *xorg-server-1.15.1-2.tar.xz 3e528d91583a661723b278c14f653f1d *xorg-server-common-1.15.1-2.tar.xz 66a59d1dbc264082ad358cbdb92b858f *xorg-server-debuginfo-1.15.1-2.tar.xz a2b7312bb6fd367f1f7c8d87cec35c1a *xorg-server-devel-1.15.1-2.tar.xz ddcb841a1d0957b2752791bdf7c4f76f *xorg-server-dmx-1.15.1-2.tar.xz 3cb714b19889766592f5a66cdcf2dbee *xorg-server-extra-1.15.1-2.tar.xz b5c65120980a02352801c5d9ae74e13b *xwinclip-1.15.1-2.tar.xz x86_64: db259c96e6c865a3d2ffebfce8a61014 *xorg-server-1.15.1-2-src.tar.xz ab3522058a8ef4f8381c87070f468718 *xorg-server-1.15.1-2.tar.xz 2a0be52c750164ce76c534e5760f4042 *xorg-server-common-1.15.1-2.tar.xz 2dfed21f9a7207908a69fd48df228a1e *xorg-server-debuginfo-1.15.1-2.tar.xz f91d28ef5fe063f1198eae5a4769f56c *xorg-server-devel-1.15.1-2.tar.xz cb7686a79e2638a8740a4348cc4863c6 *xorg-server-dmx-1.15.1-2.tar.xz df0247c00f3d419181ee378db9e0ee50 *xorg-server-extra-1.15.1-2.tar.xz 6c3b481887427ad640fcb7614d43b85a *xwinclip-1.15.1-2.tar.xz -- 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
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: xterm crashing when trying to access Ctrl- menu items
On 05/05/2014 19:39, Nem W Schlecht wrote: For over a month now I've been having issues with my xterms in Cygwin. If I try to access *any* menu item under the Ctrl- menu items (change font, turn on/off scrollbar, redraw window, etc.), my xterm crashes the moment I un-press my mouse button. I don't access them all that often, so I don't know how long the issue has been around, but it's been a couple of months now. I've tried launching it with an empty .Xdefaults file (home dir) and by moving my .bashrc/.bash_profile files out of the way - still the same result. I've also gone out and downloaded the latest XTerm code and have a version compiled with debugging, but my C skills are really rusty and I'm not seeing anything terribly useful in gdb (I set my CYGWIN env var to "error_start=dumper -d %1 %2" so I would get core dumps). I compiled a version with a different "DEFCLASS" set so that I *know* it's not a bad resource or resource file. I'm running 64 bit on Windows 7. More details in the attached cygcheck.out. Anybody else on 64bit Cygwin / Win 7 having the same issues? Thanks for reporting this issue. I can reproduce it. This appears to be an issue with Xt, as a Cygwin-specific patch does not work correctly on x86_64 when another DLL which is using Xt is loaded >2GB away from it. Until we have a fix, you *might* be able to work around this by rebasing the DLLs, e.g. in the specific case of xterm, which uses Xaw: cd /usr/bin rebase -v -b 0x40000 cygXt-6.dll rebase -v -b 0x41000 cygXaw-7.dll -- 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: startxwin.exe no longer processes -- :1
On 09/05/2014 16:55, Withers, Robert C CTR USARMY USAASC (US) wrote: I have tried -- :1, -d 1 and -display 1, none of which work. What am I doing wrong? This works fine for me. $startxwin -- :1 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.15.1.0 OS: CYGWIN_NT-6.3 tambora 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64 OS: Windows 8.1 [Windows NT 6.3 build 9600](Win64) Package: version 1.15.1-2 built 2014-05-06 XWin was started with the following command line: X :1 -multiwindow [...] [143571.031] winInitMultiWindowWM - DISPLAY=:1.0 [143571.031] winMultiWindowXMsgProc - pthread_mutex_unlock () returned. [143571.046] winProcEstablishConnection - winInitClipboard returned. [143571.046] winClipboardThreadProc - DISPLAY=:1.0 [143571.046] winMultiWindowXMsgProc - DISPLAY=:1.0 You seem to have cut off the start of your log, so I can't actually see what command line the X server is being started with. -- 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: where are xfig libraries specified?
On 16/05/2014 17:19, apchar wrote: [moved from gmane.os.cygwin] I don't really know anything about xfig, so perhaps you can clarify a few things for me? I want to add some components to the default xfig libraries. I want to put them where they'd ultimately go (/usr/lib/xfig/Libraries/newstuffdir) Are you asking if that path is correct (it seems to be)? Or are you asking how to discover that path programmatically? $XFIGLIBDIR is not set. I think the idea of XFIGLIBDIR is for you to set it to override the default. -- 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: Fatal error when starting Cygwin/X v1.15.0-2 built 2014-01-11
On 26/05/2014 14:18, Ralf Oltmanns wrote: I just installed cygwin/X on a freshly installed Windows 7 Professional (64bit). When trying to start XWin Server, it crashes with signal 11 (Segmentation fault) My installation is as follows: Release: 1.15.0.0 Package: version 1.15.0-2 built 2014-01-11 Thanks for the bug report. The current XWin version is 1.15.1-2. Perhaps you could try again with that? If that doesn't resolve your problem, I'm afraid that the log doesn't contain enough information for me to identify the cause of the crash. Could you then install the xorg-server-debuginfo package, which enables a more useful backtrace to be generated in the log, and try again? With 1.15.1, I also enabled a tool I have been working to automate sending better crash information using minidumps. If you would like to try that, download it from [1] (anonymous ftp) and put it into /usr/bin and reproduce your crash again. [1] ftp://cygwin.com/pub/cygwinx/x86_64/xorg_cygwin_crash_reporter_gui.exe -- 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: Automatic X server startup
On 27/05/2014 13:52, Pavel Fedin wrote: Recently i have started using Insight (https://sourceware.org/insight/) under Cygwin/X. Everything is quite good except one thing. I remember once upon a time i worked on MacOS X. There, X server starts up automatically if there is some program requesting it. On Cygwin i still have to run it by hands. Is is possible to set up autostart of the X server ? May be i just don't know how to do it ? I believe this is arranged using launchd on OS X, which listens on the socket the X server will use, and starts the X server when something connects. Unfortunately, there is no similar system facility on Windows. You can achieve a somewhat similar effect by copying the X server shortcut to the startup group to start it automatically at login, at the cost of slowing down system startup somewhat. -- 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: Fatal error when starting Cygwin/X v1.15.0-2 built 2014-01-11
On 26/05/2014 16:55, Ralf Oltmanns wrote: I updated to 1.15.1-2 and placed the crash-reporter into cygwin64/bin. A crash report has been submitted to your server. The same problem still persists. Thanks very much. Could you please also install the xorg-server-debuginfo package, remove xorg_cygwin_crash_reporter_gui and show the log you get then? On 05/26/2014 03:32 PM, Jon TURNEY wrote: On 26/05/2014 14:18, Ralf Oltmanns wrote: I just installed cygwin/X on a freshly installed Windows 7 Professional (64bit). When trying to start XWin Server, it crashes with signal 11 (Segmentation fault) My installation is as follows: Release: 1.15.0.0 Package: version 1.15.0-2 built 2014-01-11 Thanks for the bug report. The current XWin version is 1.15.1-2. Perhaps you could try again with that? If that doesn't resolve your problem, I'm afraid that the log doesn't contain enough information for me to identify the cause of the crash. Could you then install the xorg-server-debuginfo package, which enables a more useful backtrace to be generated in the log, and try again? With 1.15.1, I also enabled a tool I have been working to automate sending better crash information using minidumps. If you would like to try that, download it from [1] (anonymous ftp) and put it into /usr/bin and reproduce your crash again. [1] ftp://cygwin.com/pub/cygwinx/x86_64/xorg_cygwin_crash_reporter_gui.exe -- 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: glXMakeCurrent() call crashes X server
On 02/06/2014 13:04, Chris Marshall wrote: On Thu, May 29, 2014 at 1:00 PM, Chris Marshall wrote: I've been unable to debug the following failure because it results in the entire cygwin X server crashing. The code involved is from building the Prima::OpenGL module which fails running test t/02_basic.t in the call to glXMakeCurrent() in the x11.c file. I've attached an edited version of the cygcheck output, the XWin.0.log, and the output error message from the mintty console which appears to have the "final gasp" message which does not make it into XWin.0.log (presumably because of the crash): winGetWindowInfo: forcing window to exist assertion "pWin->parent" failed: file "/wip/cygport-git/xorg-server/xorg-server-1.15.0-3/src/xserver-cygwin-1.15.0-3/hw/xwin/winmultiwindowwindow.c", line 63, function: isToplevelWindow Thanks for the bug report and reproduction steps. I think this looks like a bug I fixed in 1.15.1-1, where the X server would crash if OpenGL was used on the (hidden) root window in multiwindow mode. [1] In any case, can you please retry with the latest X server version. [1] https://cygwin.com/ml/cygwin-xfree-announce/2014-04/msg3.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: Automatic X server startup
On 28/05/2014 13:57, Pavel Fedin wrote: I believe this is arranged using launchd on OS X, which listens on the socket the X server will use, and starts the X server when something connects. Unfortunately, there is no similar system facility on Windows. But it should be possible to make xlib a little bit more smart, isn't it ? It could automatically run X server when a connection is attempted but refused. So we would achieve the same effect as on MacOS. We could e. g. have some directory like /etc/X11/autostart, to be examined by xlib. If it detects that e. g. :0 screen is not accessible, it would attempt to look up 0.xlaunch file there and run "xlaunch -run /etc/X11/autostart/0.xlaunch" command. What do you think ? I could implement this idea if you have no time to work on that, i believe it should be very easy. Patches are always welcome, so please feel free to work on this if you like. I have my doubts that that it's straightforward to add this in libX11 in a way that is generally useful (for e.g.: there would be a race condition if two processes both try to start the server at the same time, there's much room for confusion about how to specify the X server options to be used, if it could be started explicitly for the start menu, or implicitly by libX11,...) You can achieve a somewhat similar effect by copying the X server shortcut to the startup group to start it automatically at login, at the cost of slowing down system startup somewhat. Heh, it's already slow because of antivirus and other corporate stuff (i cannot disable it). Running on demand would be better. You might consider looking at starting it from launchd or perhaps xinitd if possible, and then just that can be started by the X server shortcut, or at startup. -- 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: emacs holding focus, not granting it to xterm
On 27/05/2014 12:45, Hans-Georg Scherneck wrote: I'm running cygwin x on my laptop [version 1.7.29(0.272/5/3), Windows 7 prof], start windows on remote machines (cygwin and linux mint), that are exported to my laptop. I've noted the problem for more than a year now and it's irritating still, new versions of cygwin and applications notwithstanding. Here's what happens: I enter text into emacs, move mouse to an xterm, click and enter text there, but text is going into emacs. I can only move keyboard flow away from emacs after having done some nuisance operations in the emacs window, like moving around the pointer; it mostly helps with one such instance, sometimes I have to repeat. It's rather unpredictable. The raised status of the xterm window, however, is deceiving me. So text goes even into hidden emacs windows. I can't reproduce this. Can you be a bit more specific about how you are running the X server (/var/log/xwin/XWin.0.log would be nice) and which window manager you are using? -- 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/
[ANNOUNCEMENT] Updated: xlaunch-20140605-1
*** xlaunch-20140605-1 * Fix opening HtmlHelp when Cygwin isn't installed in the default location, C:\cygwin(64) * Fix opening HtmlHelp when run without Administrator privileges x86: dd3d229ccf6e0abd8b7dd00ca3185f7b *xlaunch-20140605-1-src.tar.xz 6da153acf43fc13dd82bc3bf6a9bba4e *xlaunch-20140605-1.tar.xz x86_64: 364d377b823f2330a609c424d1fb60f4 *xlaunch-20140605-1-src.tar.xz b52aa91d9fb06c1c698b49d3bc50103c *xlaunch-20140605-1.tar.xz -- 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 @@ void glTexturePageCommitmentEXT GLuint texture -GLenum target GLint level GLint xoffset GLint yoffset -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.15.1-3
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.15.1-3 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.15.1-2: * A cosmetic fix to version reporting on x86_64 * Improve visual matching with a remote libGL by not reporting pbuffer size limits * Log counts of WGL pixel formats which couldn't be used for various reasons * Correctly interpret WM_HINTS, WM_NORMAL_HINTS properties on x86_64 * Ignore any WM_NORMAL_HINTS PPosition if it specifies the origin * Fix building with khronos-opengl-registry since 2013-08-16 by limiting the considered features for shim generation to GL version <=1.2 x86: f7857118deebe18a89fa6093f3f03837 *xorg-server-1.15.1-3-src.tar.xz 22f4a00a84ad9f48d0ee78a6a2974f1f *xorg-server-1.15.1-3.tar.xz a34e20b0aa50d4ab2aea75d2e23a2691 *xorg-server-common-1.15.1-3.tar.xz 9a0a43e8a07ca545b7c6e4cdb8f38bc8 *xorg-server-debuginfo-1.15.1-3.tar.xz ef95370bd6b61ab030798a4735cca3e0 *xorg-server-devel-1.15.1-3.tar.xz ac17ded0743fcdb2b491e7ce80675f51 *xorg-server-dmx-1.15.1-3.tar.xz 1e84c4811bee5563e8b6d72259425d6d *xorg-server-extra-1.15.1-3.tar.xz 08b1f7971b7b4ac230258c2c9fd24145 *xwinclip-1.15.1-3.tar.xz x86_64: cdde770c4ca8f389f79939d0065a3293 *xorg-server-1.15.1-3-src.tar.xz 56595977e462d90a20635ec104dcc099 *xorg-server-1.15.1-3.tar.xz dc46816c8d55d2a1f86ddb7b3b8805a2 *xorg-server-common-1.15.1-3.tar.xz d80debe791e9b1431337980bc4917593 *xorg-server-debuginfo-1.15.1-3.tar.xz f6dd021669b49b674d0cde243a0d606a *xorg-server-devel-1.15.1-3.tar.xz d92381f261f7dedc53edb983fc565291 *xorg-server-dmx-1.15.1-3.tar.xz e5bf84a691fd774c0a021ec6cbe07e02 *xorg-server-extra-1.15.1-3.tar.xz 916a376a150c598c7cba94f0e0b17396 *xwinclip-1.15.1-3.tar.xz -- 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 @@ void glTexturePageCommitmentEXT GLuint texture -GLenum target GLint level GLint xoffset GLint yoffset 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: problem evaluating window resize hints under 64 bit
On 19/06/2014 13:22, Oliver Schmidt wrote:
The current cygwin x server 1.15.1-2 under 64-bit cygwin seems to have a
problem correctly evaluating the window resize hints.
In hw/xwin/winmultiwindowwndproc.c the function ValidateSizing calls
winMultiWindowGetWMNormalHints and gets wrong values in
sizeHints.width_inc and sizeHints.height_inc.
In function winMultiWindowGetWMNormalHints in file
hw/xwin/winmultiwindowclass.c you can see that a memcpy occurs from
prop->data with sizeof(WinXSizeHints).
As it turns out, everything is correct if you modify the typedef of
WinXSizeHints in hw/xwin/winmultiwindowclass.h so that long type becomes
int:
--- a/cygwin/hw/xwin/winmultiwindowclass.h
+++ b/cygwin/hw/xwin/winmultiwindowclass.h
@@ -63,7 +63,7 @@ typedef struct {
* used with WM_NORMAL_HINTS.
*/
typedef struct {
-long flags; /* marks which fields in this structure
are defined */
+int flags; /* marks which fields in this structure
are defined */
int x, y; /* obsolete for new window mgrs, but
clients */
int width, height; /* should set so old wm's don't mess
up */
Thanks for pointing this out and the patch.
The same problem also occurs with WM_HINTS a few lines above.
I can only guess why this works: in the X11 message protocol all int and
long types are mapped to 32 bit integers. It seems that the memcpy in
winMultiWindowGetWMNormalHints has source data that has memory layout as
in the X11 message protocol.
Yes. For historical reasons, 'long' is used for the CARD32 type in the
libX11 API (which this structure has been copied from), but because that
has a different size on x86 and x86_64, so libX11 marshalls that into a
32-bit quantity before storing it into the window property.
--
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: How do fonts work when you have no font packages installed?
On 04/07/2014 08:16, Michael DePaulo wrote: I just installed cygwin64 with only the base packages, "xorg-server", and its dependencies installed. The FAQ (2014-04-29) states: 3.5. My favourite font has gone! The font Emacs uses is just boxes Only minimal fonts will be installed after the upgrade. However, on my system, /usr/share/fonts/ is empty. The X server has a version of 6x13 fixed font built-in, to allow it and (some) apps which use core fonts, to operate in this situation. If some local X clients were installed, this would (hopefully) cause any X core fonts they require to be installed. Yet I am able to XDMCP into a GNOME2 CentOS 6.5 machine and all the fonts show up fine with the handful of apps I tested. Can someone explain how text is being rendered? Is Cygwin Xwin using fonts from the Windows OS? While this is technically possible by adding the Windows font directory to the X server font path, that is not done. (Although those fonts are made available to local clients by telling fontconfig to look in the Windows font directory, although this is not technically perfect as there isn't any mechanism to tell fontconfig to update it's cache when Windows fonts are added or removed) > Are the fonts being rendered client-side via XRender? Yes, if the apps you tested are modern, client-side fonts are almost certainly being used. [1] explains this fairly well: "The first X11 clients used the core X11 protocol to draw text, as that was the only choice. [...] Because GTK+ and Qt, the toolkits behind several applications including all GNOME and KDE applications, switched to Xft, many programs on most desktops [...] now use Xft." Core fonts are a legacy feature. If you want to use an older remote application which requires a particular core font, you will have to install it. [1] http://en.wikibooks.org/wiki/Guide_to_X11/Fonts -- 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: Wine creating windows offscreen when "multiwindow" is used?
On 03/07/2014 23:46, Matt D. wrote: I have a monitor configuration with three 1920x1080 monitors aligned side-by-side horizontally with a fourth above the center. The primary monitor is the center one at the bottom. xinit generates a single screen 5760x2160 to cover the area. The root window is hidden and all windows in the buffer are drawn with native Windows decorations. When an X window is created at 0,0, it is visible on the primary monitor, despite 0,0 in the buffer being offscreen. This is great. However, when Wine creates a window at 0,0, it is aligned to 0,0 in the buffer (-1920x-1080 screen coordinates on Windows) and is not visible. Is there a solution for this? This is a discrepancy between what regular X windows do and where Wine positions its windows. I also noticed that when creating a window with XCreateSimpleWindow, the x and y coordinates are ignored. For example, I would expect a window created at 0,0 in the X buffer to be visible at 0,0 screen coordinates; but instead it's just somewhere offset slightly from the top left of the primary monitor. Any x/y coordinates specified do not seem to affect where it goes. Normally, an X window manager ignores the x,y position specified for the window when it's created, and places the window according to some heuristic (for example, try to ensure that windows don't completely overlap) The -multiwindow mode window manager defers to Windows native window placement (which appears to be something like placing the ith window created at x=y=30+26*(i%9)) But, if the PPosition or USPosition flags in WM_NORMAL_HINTS are set, the -multiwindow mode window manager places the window as requested. (Most toolkits will set USPosition if you explicitly specify a window position e.g. using a -geometry option) I guess that Wine is setting one of these flags so it can emulate Windows window placement. The behavior I would expect is for 0,0 in the buffer to be mapped to 0,0 in screen coordinates, 1920x, 1080y in my configuration. Unfortunately, X window coordinates are defined to be positive, with 0,0 being the top-left of the desktop. So, while you could do this with the -screen option (e.g -screen 0 @1), to move the origin to your primary monitor, windows which are moved to the left or above of that probably won't render correctly. If you can't turn off the placement behaviour in Wine, perhaps the best compromise might be to use something like '-screen 0 5760x1080+0+1080' so you have an X desktop which covers the bottom 3 screens, and avoid moving X windows into the 4th screen? To clarify my use of Wine, I connected to a remote CentOS 6.5 machine via ssh with x forwarding for testing. Can anyone provide some insight on this? There is some code in XWin which attempts to ensure that the window is placed somewhere visible, but that assumes that the Window virtual desktop is a rectangle of size GetSystemMetrics(SM_CXVIRTUALSCREEN) x GetSystemMetrics(SM_CYVIRTUALSCREEN). I think it should be pretty straightforward to change this, perhaps to use MonitorFromPoint() to determine if the window will be visible on a non-rectangular virtual desktop. -- 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: Wine creating windows offscreen when "multiwindow" is used?
On 06/07/2014 17:27, Jon TURNEY wrote: There is some code in XWin which attempts to ensure that the window is placed somewhere visible, but that assumes that the Window virtual desktop is a rectangle of size GetSystemMetrics(SM_CXVIRTUALSCREEN) x GetSystemMetrics(SM_CYVIRTUALSCREEN). I think it should be pretty straightforward to change this, perhaps to use MonitorFromPoint() to determine if the window will be visible on a non-rectangular virtual desktop. I've built a snapshot with this change. Perhaps you could try that and see if it improves things for you? ftp://cygwin.com/pub/cygwinx/x86/XWin.20140709-git-2e9c13ea41c51df7.exe.bz2 ftp://cygwin.com/pub/cygwinx/x86_64/XWin.20140709-git-2e9c13ea41c51df7.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/
[ANNOUNCEMENT] Updated: xorg-server-1.15.1-4
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.15.1-4 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.15.1-3: * Give the window opened by "View logfile" a better title * Fix bugs in WGL GLX which prevented pbuffers from being created with certain fbconfigs * Improve the check that window position is visible to work correctly for non-rectangular virtual desktops * Downgrade the "forcing window to exist" log message from error to debug * Some compilation warning fixes * Remove an incorrect assertion in WGL GLX, triggered by glXSwapBuffers() in the piglit glx_make_current test x86: 1860dde6aac061b0dfdda6f6d8058914 *xorg-server-1.15.1-4-src.tar.xz 9d0a0d8ec0489f2c82e6b3def4c4515a *xorg-server-1.15.1-4.tar.xz 1997c143d62cc3200a50a9c3dceb6e8b *xorg-server-common-1.15.1-4.tar.xz 185301523810734629a44b14c964551a *xorg-server-debuginfo-1.15.1-4.tar.xz a6dd1aa066b982a0c569ffda02e1a5d7 *xorg-server-devel-1.15.1-4.tar.xz 1da132c818d94b65876d6efffa2ffc1e *xorg-server-dmx-1.15.1-4.tar.xz dbcd9b591a283d2ae94ca45c73625f20 *xorg-server-extra-1.15.1-4.tar.xz 3c03a460a456018511643f4631996ece *xwinclip-1.15.1-4.tar.xz x86_64: 4d0a8cf348241607677ebab936ffa930 *xorg-server-1.15.1-4-src.tar.xz d0d82d4ba5f9c9f66714224702acc0b5 *xorg-server-1.15.1-4.tar.xz 7dad87510941a6cb1f8574ae34a9e067 *xorg-server-common-1.15.1-4.tar.xz 6c1b57cb93be5c7c3396b49d3fb6235c *xorg-server-debuginfo-1.15.1-4.tar.xz 344fc8ff65c7443065bb1d6a3116f7e1 *xorg-server-devel-1.15.1-4.tar.xz 641d55fcd6f12e856a73c1dc70b276b8 *xorg-server-dmx-1.15.1-4.tar.xz 628378b4437b78b5c2b141a6d4cc79d2 *xorg-server-extra-1.15.1-4.tar.xz 9bd491aa34e29abd51d3e9ef182e5294 *xwinclip-1.15.1-4.tar.xz -- 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: Wine creating windows offscreen when "multiwindow" is used?
On 09/07/2014 23:22, Matt D. wrote: Yes! That fixed it. Windows from Wine open up just as regular X windows on the primary monitor. Thanks for testing. This change is included in 1.14.1-4 To achieve this is appears as though you're ignoring the Window's requested x/y position entirely and favoring the placement heuristics, as these coordinates are being ignored. When the requested position isn't on a monitor, yes. I do have a use-case where I want windows from Wine to be created at a designated position for testing, so I don't have to test on a Windows machine for placement as well. Is it at all possible to have these windows map their coordinates strictly, as in 0,0 on the primary monitor would be 1920x1080 in my case. This is a bit more work. Firstly, it seems there are some bugs in the way we transform between X and Windows coordinates, so it's only done correctly when the top-left of the X screen is at the top-left of the Windows virtual desktop. Secondly, I'm not sure how we can have X coordinates 0,0 not at the top-left and have things work correctly. X windows with negative coordinates are by definition off-screen, so may not render correctly. Or we could adjust the placement of all windows by the required offset, but I'm not sure that is a good idea. For example, I may want a child window which is a custom dialog aligned to the center of its parent, or a newly created window to be center-aligned to the screen. You might find running wine in 'virtual desktop' mode helpful, as I don't think it has enough knowledge of the Xinerama monitor layout to place windows centered on a monitor. -- 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
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: Resize a Cygwin64 xterm on Windows 7 64-bit jumps in increments of two or three columns
On 30/07/2014 19:04, C Linus Hicks wrote: I have run Cygwin on multiple versions of Windows including recently on Windows XP and don't think I ever had this problem. Resizing or specifying a geometry always resulted in the exact number of columns requested, with increments of 1 column being available when dragging the borders of a window to resize. Now, after upgrading to Windows 7 64-bit, I cannot get the window to have 80 columns on resize. It jumps in increments of two or three, depending on the number of columns prior to resizing. For example: Thanks for reporting this problem. I think this may be resolved by a fix "Correctly interpret WM_HINTS, WM_NORMAL_HINTS properties on x86_64" I made in 1.15.1-3 [1]. Can you please test with the latest version? Should I be able to resize by increments of one column? Yes [1] https://cygwin.com/ml/cygwin-xfree/2014-06/msg00017.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: keyboard problem with mwm and window done with Motif
On 01/08/2014 15:00, Isabelle EDOUARD wrote: I run with command line on my Windows 7 Xwin.exe in rootless mode. After I run the window manager: mwm.exe and finally I launch an application in a Red-Hat Server which use window done in Motif and Qt. With Qt windows the Keypad of my Keyboard works well (All the keyboard is OK) in a xterm too but with Motif windows is different: All seems to be well except 0. When I want to make 0 with the keypad, nothing appear, it's Ok with 1,2,3,4 etc ... but not with 0. Have I forgotten to configure a file or file(s) have bad configuration? Thanks for your help. Thanks for reporting this problem. I can't immediately reproduce it, so perhaps you can help me with a bit more information Can you attach your /var/log/xwin/XWin.0.log so I can see precisely what keyboard layout you are using? Can you tell me what particular motif application and version of Red-Hat server you are connecting to? -- 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 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
#include
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/
[ANNOUNCEMENT] Updated: xorg-server-1.16.0-1 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.0-1 These packages contain XWin and the other X.Org X11 servers. This is the first release of the xserver 1.16 series. It is currently available as a test release, and will be made stable in approximately two weeks, if no major regressions are reported. Please try test releases and report problems to the Cygwin/X mailing list. Testing helps ensure good releases! Unfortunately, the upstream announce mail [1] does not contain a full changelog since 1.15, so you will need to consult the changelog or git for a list of upstream fixes and improvements. There are no (intentional) cygwin-specific changes since 1.15.1-4. x86: 216a51a629bcd4742b7b826adc0002f4 *xorg-server-1.16.0-1-src.tar.xz 1ac20f486d79ea8265d8c2bd71f84480 *xorg-server-1.16.0-1.tar.xz fc95cbac01494fd8c6606ce42cb57e3d *xorg-server-common-1.16.0-1.tar.xz 0c26f66ad820f3cf35b688f391b8 *xorg-server-debuginfo-1.16.0-1.tar.xz ff468207cf884ea9ae5b12915749adfd *xorg-server-devel-1.16.0-1.tar.xz a97a9a98c952eb75ff0b1674e675b7b0 *xorg-server-dmx-1.16.0-1.tar.xz cf3a0e1bbdb4886af612009785c6f6da *xorg-server-extra-1.16.0-1.tar.xz 591d3a44361da533f61a661f11f81b90 *xwinclip-1.16.0-1.tar.xz x86_64: f422bf9198638eadf9e67debcfd52124 *xorg-server-1.16.0-1-src.tar.xz 2c25e1613cd257947a7b0948f555ef5a *xorg-server-1.16.0-1.tar.xz f343043b0fee407f278fefd6bf3e170f *xorg-server-common-1.16.0-1.tar.xz d16da2c1e663d02ce2a4f7f632a6a2e3 *xorg-server-debuginfo-1.16.0-1.tar.xz 88ca9cd147a34a231d543c6d1a19a166 *xorg-server-devel-1.16.0-1.tar.xz e40e5b425ff81529d43887ea72eeac65 *xorg-server-dmx-1.16.0-1.tar.xz f754e024a2dded60c7621e3c53e41141 *xorg-server-extra-1.16.0-1.tar.xz 4f31330dd0fe1274019d9f93ab90a74f *xwinclip-1.16.0-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2014-July/002457.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: [ANNOUNCEMENT] Updated: xorg-server-1.16.0-1 (TEST)
On 18/08/2014 14:43, Michael DePaulo wrote: On Sat, Aug 16, 2014 at 10:41 AM, Jon TURNEY wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.0-1 I think I found a bug: There is no stdout or stderr. So for example, "xwin --version" does not output anything. Nothing is logged to /var/log/xwin/Xorg.0.log when I type that command. This is the same as with xorg-server 1.15. If I specify an invalid argument (e.g. "xwin --foobar"). then I see the information dialog box, and the xwin usage info is outputted to that log file. I did all my testing with 32-bit Cygwin. Thanks for reporting this. Are you using the same terminal in both cases? (For obscure reasons, XWin --version doesn't work in a cmd.exe terminal, see [1]) You also seem to be using a separate cygwin installation to test xorg-server 1.16, which might also be related to this in some way. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=9763 -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.16.0-1 (TEST)
On 16/08/2014 15:41, Jon TURNEY wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.0-1 These packages contain XWin and the other X.Org X11 servers. This is the first release of the xserver 1.16 series. It is currently available as a test release, and will be made stable in approximately two weeks, if no major regressions are reported. These packages have been promoted from test to current. -- 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: X11 open gl c++ code does not compile with new cygwin download
On 01/09/2014 20:42, Tony wrote: "For the X11 GL/glu.h, you need to install libGLU-devel and its dependencies." How do you install libGLU-devel and its dependencies (on Windows 8.1)? Thanks. You use the cygwin setup program to install the libGLU-devel package. See https://cygwin.com/install.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: problems installing Cygwin/x
On 04/09/2014 18:46, Marco Atzeri wrote: On 04/09/2014 19:33, t s wrote: I can't get cygwin/x to run. I downloaded the latest revision. Here is what happened. (EE) Fatal server error: (EE) Can't read lock file /tmp/.X0-lock This is covered in the FAQ [1]. [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file Start the server with the -nolock option. This option is turned on automatically when you have a FAT filesystem, but it seems this doesn't happen for exFAT filesystems. Thanks for reporting this 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/
Re: Possible X11 server bug
On 05/09/2014 17:55, mathog wrote: I have run into an issue which _may_ indicate a bug in the cygwin X11 server. The issue is documented here: https://bugs.launchpad.net/inkscape/+bug/1365153 In brief, for certain test files viewed in Inkscape (current trunk at least) over a putty ssh tunnel from an Ubuntu 12.04lts system to the cygwin 1.14.1.0 X11 server there are glitches in the image when it is zoomed in and out. This does not occur if the same program is run locally on the console of the test machine. Thanks for reporting this problem. It's not quite clear, but I think you are saying that it renders correctly when run locally on the Ubuntu 12.04 system? There are a couple of possible variables, which might affect things The version of the X server may not be the same. It would be useful to compare the same version, and also be helpful if you could test with the most recent X server (1.16.0) FWIW, the .svgs attached to that bug seem to render identically (although I'm not sure what correctly looks like) using a Cygwin Inkscape 0.48.4 r9939 (from cygwinports) and X server 1.16.0-1 It also does not happen if I run a native Windows version (not cygwin, not X11) of Inkscape on the same PC which hosts that X11 server on the same test files. The glitch does not occur with a huge number of other test files I have looked at over the years. It seems there is something specific to the clipping code in Inkscape and this particular X11 transport path/server combination. Moreover, it looks like the problem is only manifested (or only manifested frequently) when the clipping path consists of two (or more?) disjoint sections. When the glitches occur nothing is added to XWin.0.log. Also this X11 server is not running in the full cygwin environment, but rather in one edited down to just the minimum needed to run the X11 server. I distribute this version here: http://sourceforge.net/projects/minimalcygwinx/ I don't think this is a factor though, since all of the action is going on inside the X11 server process(es). -- 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/
[ANNOUNCEMENT] Updated: xorg-server-1.16.0-2
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.0-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.16.0-1: * Fix -displayfd to respect -pn/-nopn * Fix -displayfd to check port 65535 * Fix problems with pixelformat selection for GLX pixmaps with certain display drivers * Add experimental Windows-DRI extension x86: cff75107d42345622f063cd2e02ff4bc *xorg-server-1.16.0-2-src.tar.xz 1a61054927751d233c5ed5c0d2e0cefd *xorg-server-1.16.0-2.tar.xz dc41d9b3536df9261f6851884eeb5e6f *xorg-server-common-1.16.0-2.tar.xz be9984f25a1cdc987040d30a4ceab946 *xorg-server-debuginfo-1.16.0-2.tar.xz f0a4074a0647321ce9475e9940321155 *xorg-server-devel-1.16.0-2.tar.xz d918a31db9db190fd60b8d99762436d0 *xorg-server-dmx-1.16.0-2.tar.xz 910359981408a60b952efbed9d47781a *xorg-server-extra-1.16.0-2.tar.xz b494cc65bcc0be350a8307ee0c047dcd *xwinclip-1.16.0-2.tar.xz x86_64: aac6ba4d7e6f82abf7aad058004d7d4d *xorg-server-1.16.0-2-src.tar.xz d02369e2ccc09f0525fe17d15741d11f *xorg-server-1.16.0-2.tar.xz 5f00d12d2096d559540df716bf684b24 *xorg-server-common-1.16.0-2.tar.xz 26928680a222a3aac74b2931f21144a1 *xorg-server-debuginfo-1.16.0-2.tar.xz 26088e769294b5ce85301e2bfec08d27 *xorg-server-devel-1.16.0-2.tar.xz c6bb3770f5f8c3ce27d4986f4bfa30b6 *xorg-server-dmx-1.16.0-2.tar.xz 52ea659a4556f76eb0ca3a9fc8ebb1e4 *xorg-server-extra-1.16.0-2.tar.xz 8ce3ed3f4cc02d499629611ad5b109d9 *xwinclip-1.16.0-2.tar.xz -- 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: Clipboard interaction issues - breaks after awhile
On 10/09/2014 18:57, Nem W Schlecht wrote: That 'nedit' thread looks pretty old. Cut/Paste was working perfectly for me pre-1.16.0-1. I've decided to downgrade, as I was having zero issues with 1.15.1-4. I can see I'm getting winClipboardFlushXEvents errors in my XWin.0.log file (attached). First, multiple time out events after trying "Conversion to format 242 refused." and then later OpenClipboard () failed: 0005 errors. On Wed, Sep 10, 2014 at 12:17 PM, mathog wrote: On 10-Sep-2014 09:33, Nem W Schlecht wrote: After the latest update to xorg-server (1.16.0-1), I've been having issues with clipboard interaction between my xterm windows and Windows apps. Bi-directional copy/paste works initially, but at some unknown point stops working. Anybody else seeing this as well? What can I do to help debug this issue? Thanks for reporting this problem, and the log file. Unfortunately, I can't reproduce this problem. winClipboardFlushXEvents - SelectionNotify - Conversion to format 242 refused. winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_TARGETS I think the log timestamps indicate this occurs approximately 9 hours after the server was started. I guess that that format 242 is 'TARGETS' (The value of the atom will vary depending on circumstances. You could check with 'xlsatoms | grep 242'), in which case this means that something went wrong when asking the X client what conversion formats are supported for the selection, which is odd. I also notice an 'nxterm' process is started. Is this a wrapper for xterm, or some other terminal program? But are these errors actually correlated with your problem? About a day later we have: winClipboardFlushXEvents - SelectionRequest - OpenClipboard () failed: 0005 0005 is 'access denied', which typically means that the X server can't take ownership of the clipboard, because some other Windows program isn't letting go of it. On 10/09/2014 22:23, Nem W Schlecht wrote: Hmm.. I might have to reboot. I went back to 1.15.1-4 and everything was fine, but now its not working again and same errors as before. :( There should be no clipboard-related changes between 1.15.1-4 and 1.16.0-1, so perhaps something else changing is the cause of this 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/
Re: Clipboard interaction issues - breaks after awhile
On 19/09/2014 14:53, Nem W Schlecht wrote: Like you mention, I assume its one of my *Windows* apps that is really the cause of the issue. Not sure which one, though, if that's the case. If it comes back up again, I'll shoot out another note to the list. Thanks. I would appreciate any help you can give in tracking down the cause of this problem. I plan to add a bit more logging in the next release which should help identify the Windows application which own the clipboard when OpenClipboard() is failing. -- 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: problems running Cygwin/x
On 21/09/2014 17:56, t s wrote: I successfully installed Cygwin/x on an NTFS drive unfortunately the menu items are limited to; one item for Cygwin (cygwin64 terminal) five items for cygwinx (GNOME openbox, KDE openbox, openbox, xlaunch, xwin server) if I try GNOME Openbox, or KDE Openbox, or Openbox; it appears to start, but I cannot run xclock and there is no X server icon in the lower right icon panel [...] essentially I want to be sure Cygwin/x has installed correctly; particularly the three Openbox options do not seem to do anything; should they be bringing up some sort of GNOME or KDE desktop? It seems that the open start menu links don't work correctly anymore. It seems that shortcut targets like 'C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c "/usr/bin/startx /usr/bin/openbox-session"' need the new --quote option in run-1.3.3 to work correctly. Thanks for drawing this problem to my attention. -- 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 starting the X server
On 26/09/2014 03:52, Joel Ledain wrote: I just installed the Cygwin packages on top of a "Windows 7". The machine is Gateway NV55S28u. Install went fine. Rebooted the machine and tried the bash window, this works fine. Then tried to start the X server, and here I have a problem. I thing my problem is related to the keyboard binding/support/missing packages... I tried to use the command setxkbmap, but without the X server running I am not getting anything beside "cannot open display". For the Windows control panel -> devices -> keyboard, I see a "standard PS2 keyboard". I have the xkeyboard-config package installed. I am attaching the log of my troubles. (EE) Couldn't open compiled keymap file /var/lib/xkb/server-0.xkm (EE) XKB: Failed to load keymap. Loading default keymap instead. (EE) Couldn't open compiled keymap file /var/lib/xkb/server-0.xkm XKB: Failed to compile keymap Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. (EE) Fatal server error: (EE) Failed to activate core devices. (EE) Server terminated with error (1). Closing log file. You should check that xkeyboard-config and xkbcomp are installed correctly, that xkbcomp can be run, and that you don't have any software which is known to interfere with cygwin installed, as described at [1]. You might also check if the TEMP or TMP environment variables are set, and if so, contain the unix-style pathname of a directory which both exists and is writeable. If that doesn't help, perhaps could you try the snapshot [2], which is built with additional debug logging enabled. [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-failed-to-compile-keymap [2] ftp://cygwin.com/pub/cygwinx/x86_64/XWin.20140926-git-6f318e09efcfdbe9.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/
[ANNOUNCEMENT] Updated: xorg-server-1.16.1-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.1-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1][2], this contains the following cygwin-specific changes since 1.16.0-2: * Also automatically activate the -nolock option if /tmp is on an exFAT filesystem (Reported by 't s') * Log owning HWND when OpenClipboard fails * Log name of format atom when conversion of X clipboard to a format is refused * Also use _NET_WM_NAME for window titles in multiwindow mode * Downgrade some uninformative, always-emitted log output to debug * Check TEMP and TMP directories for accessibility before using for xkbcomp temporary file * Log filename when xkbcomp temporary file cannot be opened * Don't add an extra null character at the end of the text on the Windows clipboard (Thanks to Colin Harrison for patch) x86: 6b72d0bdaba1e89e90430a751eef61a9 *xorg-server-1.16.1-1-src.tar.xz 7b63f2b0e424292b62ceead452802f80 *xorg-server-1.16.1-1.tar.xz 9ca33a0326e50c5583730c495940903d *xorg-server-common-1.16.1-1.tar.xz 90c76a195c62251322883b31709817da *xorg-server-debuginfo-1.16.1-1.tar.xz ab4dfe97c97d333bb1cfb30f9ebee8b7 *xorg-server-devel-1.16.1-1.tar.xz da75032daeaf0e4664ed85c1d333657e *xorg-server-dmx-1.16.1-1.tar.xz 0eb18d9a456f6f37a403febc49080c9c *xorg-server-extra-1.16.1-1.tar.xz c1478d018c9be5781d85b8ee040398b8 *xwinclip-1.16.1-1.tar.xz x86_64: 46e54c368dd214df58810a6c703680b4 *xorg-server-1.16.1-1-src.tar.xz b90e45d736c3f79261518a4c9c9aa9c5 *xorg-server-1.16.1-1.tar.xz ed7dae27a5430a584b44265996b21a15 *xorg-server-common-1.16.1-1.tar.xz 763fd8a59ac318549bf9f5ee963e593a *xorg-server-debuginfo-1.16.1-1.tar.xz 12a2cc29adc45533bfcda7c33392deaf *xorg-server-devel-1.16.1-1.tar.xz 7dcfedb1a26176345f56c2c3d9058fbe *xorg-server-dmx-1.16.1-1.tar.xz 973da9ca3368b4356dc8e5b89880fc40 *xorg-server-extra-1.16.1-1.tar.xz 9e222444d273c7989631343557e878b3 *xwinclip-1.16.1-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2014-September/002478.html [2] http://lists.x.org/archives/xorg-announce/2014-September/002480.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: Problem with Cygwin/X from remote Linux
On 02/10/2014 04:53, Chris Carlson wrote: I've been using Cygwin on a Windows 7 laptop for a few years as an X server from my Fedora Linux system. I "ssh -X" to my Linux system and run various X programs (thunderbird, chrome, nautilus, etc.) with very few issues. [...] Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.16.1.0 OS: CYGWIN_NT-6.1 grover 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.16.1-1 built 2014-09-29 XWin was started with the following command line: X :0 -multiwindow I discovered there are no visuals available to remote X connections that support OpenGL double buffering. There used to be, but no longer. There are visuals available to direct connections, but not for remote. Thanks for reporting this problem. Unfortunately, I can't reproduce it. Please can you attach the output of 'X -multiwindow -logverbose 3', so I can see what visuals the server thinks should be available, and the output of running 'glxinfo' on your remote system. Can you give the version of Fedora you are using, and the version of the libGL package you have? I tried looking through the FAQ for answers, but I didn't see anything. Is this something that has intentionally changed? Where would I find it if it is (for future reference so I don't bug you)? No, this is not intentional. I guess this is an unintended consequence of a change. It would be useful in tracking down that change if you could identify the last X server release which worked correctly. The release announce mails are a hopefully accurate summary of intended changes (e.g [1]) [1] https://cygwin.com/ml/cygwin-xfree-announce/2014-09/msg4.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: FW: Cygwin start menu / mirrors
Firstly, please do not send me personal email. Please read http://cygwin.com/problems.html#personal-email, particularly the section starting "Shouldn't I just send email to straight to a Cygwin developer or package maintainer?" On 02/10/2014 11:07, t s wrote: Do these updates solve the problem with the start menu? No, they solve the problems that they say they solve. If you are uncertain, you could always test it yourself. In addition to upstream fixes [1][2], this contains the following cygwin-specific changes since 1.16.0-2: * Also automatically activate the -nolock option if /tmp is on an exFAT filesystem (Reported by 't s') * Log owning HWND when OpenClipboard fails * Log name of format atom when conversion of X clipboard to a format is refused * Also use _NET_WM_NAME for window titles in multiwindow mode * Downgrade some uninformative, always-emitted log output to debug * Check TEMP and TMP directories for accessibility before using for xkbcomp temporary file * Log filename when xkbcomp temporary file cannot be opened * Don't add an extra null character at the end of the text on the Windows clipboard (Thanks to Colin Harrison for patch) -- 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 Cygwin/X from remote Linux
On 03/10/2014 05:19, Chris Carlson wrote: I discovered there are no visuals available to remote X connections that support OpenGL double buffering. There used to be, but no longer. [...] I thought the two logs that you requested were a bit large for this e-mail, so I put them on my web site. You can access them as: Thanks. So, this is the set visuals that the X server supports. GL_VERSION: 3.1.0 - Build 8.15.10.2455 GL_VENDOR: Intel GL_RENDERER:Intel(R) HD Graphics Family [...] pxf vis fb render Ste aux accumMSdrawable Group/ idx ID ID VisualType Depth Lvl RGB CI DB Swap reo R G B A Z S buf AR AG AB AA bufs num W P Pb Float Trans Caveat - 1 51 42 TrueColor32 0 y . . . 8 8 8 8 0 0 0 0 0 0 000 y . y . . 2 2 52 43 TrueColor32 0 y . y xchg . 8 8 8 8 0 0 0 16 16 16 1600 y . y . . 2 3 53 44 TrueColor32 0 y . . . 8 8 8 8 24 8 0 0 0 0 000 y . y . . 2 4 21 45 TrueColor32 0 y . y xchg . 8 8 8 8 24 8 0 16 16 16 1600 y . y . . 2 5 54 46 TrueColor32 0 y . . . 8 8 8 8 16 0 0 0 0 0 000 y . y . . 2 6 55 47 TrueColor32 0 y . y xchg . 8 8 8 8 16 0 0 16 16 16 1600 y . y . . 2 7 56 48 TrueColor32 0 y . y copy . 8 8 8 8 0 0 0 16 16 16 1600 y . y . . 2 8 57 49 TrueColor32 0 y . y copy . 8 8 8 8 16 0 0 16 16 16 1600 y . y . . 2 9 41 4a TrueColor32 0 y . y copy . 8 8 8 8 24 8 0 16 16 16 1600 y . y . . 2 10 58 4b TrueColor32 0 y . . . 8 8 8 8 0 0 0 0 0 0 014 y . y . . 2 11 59 4c TrueColor32 0 y . y xchg . 8 8 8 8 0 0 0 16 16 16 1614 y . y . . 2 12 5a 4d TrueColor32 0 y . . . 8 8 8 8 16 0 0 0 0 0 014 y . y . . 2 13 5b 4e TrueColor32 0 y . y xchg . 8 8 8 8 16 0 0 16 16 16 1614 y . y . . 2 14 5c 4f TrueColor32 0 y . . . 8 8 8 8 24 8 0 0 0 0 014 y . y . . 2 15 5d 50 TrueColor32 0 y . y xchg . 8 8 8 8 24 8 0 16 16 16 1614 y . y . . 2 The mesa software renderer on the remote host constructs the set of visuals the client gets offered by picking the visuals from the server's set of visuals which match one of it's visuals OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300) OpenGL version string: 2.1 Mesa 8.0.4 [...] visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat 0x051 24 tc 0 32 0 r . . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None 0x053 24 tc 0 32 0 r . . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None Unfortunately this set is small, and indeed doesn't contain any double-buffered visuals. Workarounds are to use either start Cygwin X server with -nowgl (so it too uses the software renderer and will offer a set of visual which is probably exactly the same), or to run the client with the LIBGL_ALWAYS_INDIRECT env var set (so that indirect rendering is used and the remote client has access to the actual set of visuals the server supports) I think the real fix to this is to fix the remote libGL, either so it matches visuals less precisely, or so it offers more visuals which can match, but this is not simple. Believe it or not, I just so happen to have an XWin.0.log from my old, old, old version of Cygwin. It was: Package: version 1.15.1-2 built 2014-05-06 Now I can reproduce this, it seems that this can be an unfortunate side-effect of the "Improve visual matching with a remote libGL by not reporting pbuffer size limits" change in 1.15.1-3 [1], which was intended to have the opposite effect, if previously no visuals at all were matching, so the software renderer was disabled, and we were falling back to indirect rendering. [1] https://cygwin.com/ml/cygwin-xfree-announce/2014-06/msg2.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: Clipboard interaction issues - breaks after awhile
On 03/10/2014 21:02, mathog wrote: Today I ran into an interesting variant of this. 1. putty ssh -X session from XP to a remote Centos 6.5 system. 2. on the remote system: xterm & 3. copy a line of text on remote system 4. paste it into a roundcube "compose" window on XP system. The browser is Seamonkey 2.29. It works fine for a while and then the _browser_ locks. It is definitely an X11 issue because this unlocked the browser: exit all xterms, exit the putty session, kill the X11 server. The browser didn't unlock until the last step. This lock up happened twice within half an hour. Now I can't reproduce it. There is supposed to be a 1 second timeout to ensure that we always respond to the Windows application in a timely fashion. (The issue here is that Windows clipboard pastes are synchronous (when the Windows application calls GetClipboardData(), it sends a WM_RENDERFORMAT to the clipboard owner, and blocks until that returns), but the X11 clipboard render is asynchronous (since we send a XConvertSelection() request to the clipboard owner and wait for a SelectionNotify event)) I've looked at this code again, and can't see anything wrong with they way this timeout is implemented. So, I'm afraid there's not a lot I can do without a repeatable reproduction or a log file. That is the only system I have used recently that uses xterm instead of uxterm. The clipboard problems I have seen previously were all in the other direction, where clip going into an X11 application would fail. Unfortunately I didn't save the X server log file. Which, brings up another point. The X11 server is started by clicking on "start_server.bat" which contains: @echo off set CYGXTOP=%~dp0 C: chdir "%CYGXTOP%\bin" start Xwin :0 -multiwindow It always overwrites the Xwin.0.log file when it starts. Is there some change we could make to this .bat script that would cause it to at least save one previous version? I guess you could add to the above something like: move C:\cygwin\var\log\XWin.0.log C:\cygwin\var\log\XWin.0.log.old but yes, there is actually some code in the server to do that, but it's not turned on in XWin for unknown reasons... -- 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: Subject: Re: FW: Cygwin start menu / mirrors
On 04/10/2014 18:16, t s wrote: first of all, regarding the Cygwin setup program; the options are install / re-install / un-install / default is it correct that to install only the latest updates, I would choose the option 'default' ? I'm not sure what text you are looking at. The options for an individual package which is already installed are 'reinstall', 'uninstall', 'keep' and specific versions other than the currently installed one (if any). I can't see "default" anywhere. If you mean the default version, then yes, when "curr" is selected at the top, all packages which have updates, will be updated. next question : if I delete the start menu option "Cygwin/x" and run the setup program for option "default", it doesn't re-create the start menu option "Cygwin/x" is this 'feature' acknowledged, and is it being addressed? The start menu link for for the X server is owned by the package xinit. If you reinstall that package, it should be recreated. I'm not sure what you are asking for here. If you were (for example) to delete /usr/bin/XWin.exe, are you expecting setup to reinstall that file, even though the package which owns it has no updates? While setup has many, many infelicities, I'm not sure this is one of them. Patches are always thoughtfully considered. -- 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: glwDrawingAreaWidgetClass
On 07/10/2014 03:31, Chris Carlson wrote:
I've discovered that the constant glwDrawingAreaWidgetClass is set to
0. It's supposed to be defined as:
WidgetClass glwDrawingAreaWidgetClass=(WidgetClass)&glwDrawingAreaClassRec;
Can I ask you to please provide some more details as to how you made
this discovery?
If you do this:
$ cat glw-test.c
#include
#include
#include
int main()
{
printf("glwDrawingAreaWidgetClass %p", glwDrawingAreaWidgetClass);
}
then you could reach that conclusion:
$ gcc glw-test.c ; ./a
glwDrawingAreaWidgetClass 0x0
but this isn't testing correctly as glwDrawingAreaWidgetClass isn't
marked as extern in GLwDrawA.h
$ cat glw-test.c
#include
#include
extern WidgetClass glwDrawingAreaWidgetClass;
int main()
{
printf("glwDrawingAreaWidgetClass %p", glwDrawingAreaWidgetClass);
}
$ gcc glw-test.c -lGLw ; ./a
glwDrawingAreaWidgetClass 0x5bd8e3640
Is it broken?
I don't know.
--
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/
[ANNOUNCEMENT] Updated: xorg-server-1.16.1-2
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.1-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.16.1-1: * Fix transposed format specifiers in some logging added in 1.16.1-1, which is probably the cause of some crashes/hangs (Thanks to Colin Harrison for patch) x86: 2487d4ffba759b3023150298d53616e7 *xorg-server-1.16.1-2-src.tar.xz fba03eb030540c292188c736f410ab77 *xorg-server-1.16.1-2.tar.xz e988cd1a540f3b5a4ebc44619ca340fd *xorg-server-common-1.16.1-2.tar.xz 9b4ccf2d47947820eded95dcc4e855b8 *xorg-server-debuginfo-1.16.1-2.tar.xz 369e9a8ef1d80225d742dec17e69b88e *xorg-server-devel-1.16.1-2.tar.xz a091007b24dd1ae64d4a80be5a3ea279 *xorg-server-dmx-1.16.1-2.tar.xz ba1e3a9cbd7ffe4834b7387a09169528 *xorg-server-extra-1.16.1-2.tar.xz d19cd8a9cd65657c20af1c0f440cd40f *xwinclip-1.16.1-2.tar.xz x86_64: 78666e1511ce24b8786d4cc2697ca71d *xorg-server-1.16.1-2-src.tar.xz de105c6b353d0bc98493a80bc1bfe9d5 *xorg-server-1.16.1-2.tar.xz 5f8b3f6b6c63c7e99bf35a966a5b5252 *xorg-server-common-1.16.1-2.tar.xz 395931026c9f63d7cac23ac433931527 *xorg-server-debuginfo-1.16.1-2.tar.xz 4cfc2b7aac8e7ab18329303f3b378f42 *xorg-server-devel-1.16.1-2.tar.xz 8fa287196a578e4eeb2e8ec57bccf9a9 *xorg-server-dmx-1.16.1-2.tar.xz ae1207c3b901cbb0da96eaf55ff9c8be *xorg-server-extra-1.16.1-2.tar.xz 51a9cb28eaab5ae481aaa45283554e7f *xwinclip-1.16.1-2.tar.xz -- 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: FW: Cygwin start menu / mirrors
On 08/10/2014 23:40, t s wrote: On 04/10/2014 18:16, t s wrote: first of all, regarding the Cygwin setup program; the options are install / re-install / un-install / default is it correct that to install only the latest updates, I would choose the option 'default' ? I'm not sure what text you are looking at. The options for an individual package which is already installed are 'reinstall', 'uninstall', 'keep' and specific versions other than the currently installed one (if any). I can't see "default" anywhere. If you mean the default version, then yes, when "curr" is selected at the top, all packages which have updates, will be updated. The current version of the setup program, 2.850 (64 bit), on the "select packages" screen, features a "default" option. Please see; http://cpm86.com/default.jpg The four options are; Install; Reinstall; Uninstall; Default I just want to be sure; to install only the latest updates, I would choose 'Default' ? Oh yes, on the category view, you have that option next to each category, which does what you expect. I have a further question. Choosing menu item "Cygwin-X / X Win Server" boots X windows. If you right click on the 'X' icon in the lower right side of the screen, it features applications xterm / emacs / notepad / xload. Is it possible to tailor the list of applications referenced above? to include say xclock, xeyes Yes. See http://x.cygwin.com/docs/ug/configure-cygwin-xwinrc.html And yet another question; I note the presence of a number of files in \usr\bin which start with 'gnome'. Does Cygwin/x feature gnome or kde as user interfaces? or does it only allow compilation of apps which use features of those interfaces? I don't think KDE or GNOME desktop environments are available. -- 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: problems with cygwin/x
On 14/10/2014 17:19, t s wrote: [duplicate email] Please don't spam the list with the same mail. If you get no answer, it is because no-one has an answer for you (yet). -- 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: glwDrawingAreaWidgetClass
On 13/10/2014 02:48, Chris Carlson wrote: I have a fairly large program that I developed on Fedora Linux. It uses glwDrawingAreaClassRec to create a GL window. I attempted to compile and run it on Cygwin, and I got the failure. I added a print statement just before calling XtCreateManagedWidget() and discovered the value was 0 on Cygwin and an address on Linux. I presumed that meant there was an issue. To get around the problem, I downloaded the source from Mesa and compiled it myself. The .a that was generated identifies the following (using nm): 0640 D glwDrawingAreaClassRec 0728 D glwDrawingAreaWidgetClass I then compared it to /lib/libGLw.dll.a and got this: nm /lib/libGLw.dll.a | grep DrawingAreaClass I __imp_glwMDrawingAreaClassRec I __nm_glwMDrawingAreaClassRec I __imp_glwDrawingAreaClassRec I __nm_glwDrawingAreaClassRec Unfortunately, this isn't telling you anything useful as the __imp import symbols are fixed up at run-time. Now I tried compiling your test program and found that it did work as you showed, but I then added the include of GLwDrawA.h, and it fails. This doesn't make a whole lot of sense to me, and it doesn't seem right. The issue is that without the extern, the declaration of glwDrawingAreaWidgetClass is also a 'tentative definition' If there are no other references to symbols in libGLw, then that tentative definition (with a value of 0) will be used by ld as the definition. (Linking with a shared library on linux is more relaxed) What do you think? If I want to use the GLwDrawingAreaWidgetClass, I would presume that I should include the corresponding header file and the class would be defined. On 07/10/2014 14:50, Jon TURNEY wrote: but this isn't testing correctly as glwDrawingAreaWidgetClass isn't marked as extern in GLwDrawA.h Sorry, I should have said something like 'it's a bug that glwDrawingAreaWidgetClass isn't marked as extern in GLwDrawA.h' So, something like the following attached patch to GLwDrawA.h is needed. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer --- GLwDrawA.h.bak 2014-10-13 13:00:18.140625400 +0100 +++ GLwDrawA.h 2014-10-13 13:01:06.581762300 +0100 @@ -136,7 +136,7 @@ typedef struct _GLwMDrawingAreaClassRec*GLwMDrawingAreaWidgetClass; typedef struct _GLwMDrawingAreaRec *GLwMDrawingAreaWidget; -GLAPI WidgetClass glwMDrawingAreaWidgetClass; +extern GLAPI WidgetClass glwMDrawingAreaWidgetClass; #else @@ -144,7 +144,7 @@ typedef struct _GLwDrawingAreaClassRec *GLwDrawingAreaWidgetClass; typedef struct _GLwDrawingAreaRec *GLwDrawingAreaWidget; -GLAPI WidgetClass glwDrawingAreaWidgetClass; +extern GLAPI WidgetClass glwDrawingAreaWidgetClass; #endif -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xorg-server-1.16.1-2
On 10/10/2014 19:32, Nem W Schlecht wrote: Just to confirm - I haven't had any crashes with 1.16.1-2 so far. Woot! :) On Wed, Oct 8, 2014 at 11:08 PM, Chris Carlson wrote: No sooner did I respond than I see the update. Nevermind. On 10/8/2014 8:31 PM, Nem W Schlecht wrote: I just remembered that my version of xv has been modified to place the current image filename in the X11 clipboard. That might have been the cause of the issue. Regardless, my crashes seem to have gone away with this update. Thanks for all the hard work on Cygwin X11! Thanks for letting me know there was a problem, and apologies for the inconvenience. -- 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/
[ANNOUNCEMENT] Updated: xorg-server-1.16.1-3
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.1-3 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.16.1-2: * Make XWin backup the previous logfile as .old * Properly log the reason in an XDMCP unwilling response * Only invoke the experimental crashreporter on a fatal signal, not in places where we just want to log a backtrace * Add marketing name for Windows 6.4 and manifest for compatibility * Unsilence an XErrorHandler x86: 2f657d4e5dd9dfa56a2c626e54665437 *xorg-server-1.16.1-3-src.tar.xz efce43991b64c7f806dbc5943449ee13 *xorg-server-1.16.1-3.tar.xz 0a7bbfdd37e75bbaf917190690c783a8 *xorg-server-common-1.16.1-3.tar.xz d4be75ad26fb86b09609bc6522847754 *xorg-server-debuginfo-1.16.1-3.tar.xz 19a6ad1d4dfe68961c283832e92e2425 *xorg-server-devel-1.16.1-3.tar.xz 19bc13b7430f93feb4c4c1d70c04f843 *xorg-server-dmx-1.16.1-3.tar.xz 4aaacc3dadbcccdf6e9b673b122c8012 *xorg-server-extra-1.16.1-3.tar.xz 4e9ee40665b37fdbbb5abd0f35580535 *xwinclip-1.16.1-3.tar.xz x86_64: 40d6eae6fcbc6ceca1b6b11235d36b2d *xorg-server-1.16.1-3-src.tar.xz 609d0c94e661c23b7c2018b0e8642231 *xorg-server-1.16.1-3.tar.xz aac0d1b6e4230e655212fa4906032ba2 *xorg-server-common-1.16.1-3.tar.xz 754f76c3fab31d020ffe9a2c9083b609 *xorg-server-debuginfo-1.16.1-3.tar.xz 5c8de82b0875a13dc676a682fc6a1bfa *xorg-server-devel-1.16.1-3.tar.xz 465e5dc756cb40b1e2cd347e045ec4d9 *xorg-server-dmx-1.16.1-3.tar.xz 725f30b5a43504cf4f78d69b151c56de *xorg-server-extra-1.16.1-3.tar.xz 1b67e0cd64740f9eecef8e556b787dd8 *xwinclip-1.16.1-3.tar.xz -- 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: Clipboard error - trace owner?
On 31/10/2014 16:20, Nem W Schlecht wrote: After a *very* long time of the clipboard working perfectly, it just started to stop working on me: [252960.192] winClipboardFlushXEvents - OpenClipboard () failed: 0005 Owner 0002089e [252960.192] winClipboardFlushXEvents - OpenClipboard () failed: 0005 Owner 0002089e [253010.517] winWindowProc - WM_DISPLAYCHANGE - new width: 1600 new height: 1200 new bpp: 32 [253380.957] winClipboardFlushXEvents - OpenClipboard () failed: 0005 Owner 0002089e [253445.199] winClipboardFlushXEvents - OpenClipboard () failed: 0005 Owner 0002089e How do I trace the owner HEX code to the program that is causing the issue? (Or is the owner X11 here?) This is a window handle (HWND). You could find out the corresponding window using a tool such as Spy++. I will improve this so that the window title is reported here as well, which would be much better, but that is not quite straightforward. -- 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: An issue with libX11?
On 09/11/2014 15:38, Angelo Graziosi wrote:
From another application I have an issue with libX11 which I can
reproduce with the following STC,
I don't think this test case is well-formed.
int main()
{
dis = XOpenDisplay(NULL);
win = XCreateSimpleWindow(dis, RootWindow(dis, 0), 1, 1, 500, 500,
0, BlackPixel (dis, 0), BlackPixel(dis, 0));
XMapWindow(dis, win);
A 'XSelectInput(dis, win, KeyPress)' is needed here to tell the X server
that this client wishes to receive KeyPress event.s
I am not an X11 expert, so it could be I am doing the wrong things but
the same code runs fine on OSX+XQuartz and GCC-4.9.1.
I tried with XQuartz 2.7.8_beta1 and I couldn't reproduce that.
--
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: An issue with libX11?
On 09/11/2014 20:49, Angelo Graziosi wrote:
Il 09/11/2014 21:16, Jon TURNEY ha scritto:
On 09/11/2014 15:38, Angelo Graziosi wrote:
From another application I have an issue with libX11 which I can
reproduce with the following STC,
I don't think this test case is well-formed.
int main()
{
dis = XOpenDisplay(NULL);
win = XCreateSimpleWindow(dis, RootWindow(dis, 0), 1, 1, 500, 500,
0, BlackPixel (dis, 0), BlackPixel(dis,
0));
XMapWindow(dis, win);
A 'XSelectInput(dis, win, KeyPress)' is needed here to tell the X server
that this client wishes to receive KeyPress event.s
I found the issue trying the examples of libXbgi library
(http://libxbgi.sourceforge.net), so I tried to create a STC adapting
the example discusses here:
https://user.xmission.com/~georgeps/documentation/tutorials/Xlib_Beginner.html
Anyway, the STC on Cygwin64 doesn't work if I add your suggestion,
...
XMapWindow(dis, win);
XSelectInput(dis, win, KeyPress);
Oops. I think that should be KeyPressMask.
XFlush(dis);
...
I am not an X11 expert, so it could be I am doing the wrong things but
the same code runs fine on OSX+XQuartz and GCC-4.9.1.
as I wrote, on OSX it works (there XQuartz is 2.7.7). For this reason I
flagged this to X-Cygwin list..
I tried with XQuartz 2.7.8_beta1 and I couldn't reproduce that.
On which system? OSX?
XQuartz doesn't run on anything else :D
--
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/
[ANNOUNCEMENT] Updated: xorg-server-1.16.2-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.2-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1][2], the following cygwin-specific changes have been made since 1.16.1-3: * Use the modern clipboard viewer API, which doesn't require applications to maintain the clipboard viewer list, when available (on Vista and later) * Log clipboard formats when GetClipboardData() fails * Log name of owning HWND when OpenClipboard fails * In multiwindow mode, add EWMH properties for describing multiple desktops to the root window (Thanks to Yaakov Selkowitz for the patch) * Fix a problem with logging using a format specifier with a variable field width or precision * Default to -noresize when -fullscreen is used * Propagate crashreporter exit code through the xorg-crashreport script x86: 1e09ed43c66e952fa63209bc47ac4a74 *xorg-server-1.16.2-1-src.tar.xz 87be2a8c4efbe79f445872e5cf408911 *xorg-server-1.16.2-1.tar.xz 80bcd90ce7e1cf555e46a2ef3a9bc6d9 *xorg-server-common-1.16.2-1.tar.xz 221ee0f4b24f0cd8b14f0ac37bfdc20d *xorg-server-debuginfo-1.16.2-1.tar.xz 70430010f7923952baa2a9d84306d312 *xorg-server-devel-1.16.2-1.tar.xz 92768886af09af23cd8686c27441e802 *xorg-server-dmx-1.16.2-1.tar.xz 594fb040fd79be3a6b5571f24039b8da *xorg-server-extra-1.16.2-1.tar.xz 9e1cbf5b81aae62bf681b35da81c3466 *xwinclip-1.16.2-1.tar.xz x86_64: cefc740f4206eda28c5949d355a27678 *xorg-server-1.16.2-1-src.tar.xz 0ea2aa23ec20afc7ac695bba6d91ccfd *xorg-server-1.16.2-1.tar.xz 83da0599eb97fb768abe5e77d1a303fb *xorg-server-common-1.16.2-1.tar.xz 75ed1f09141ba6b96d0ed7a69c7da604 *xorg-server-debuginfo-1.16.2-1.tar.xz 5be2e080229226ed01cdf9c053637dff *xorg-server-devel-1.16.2-1.tar.xz 76e8e0591336db4f80bf342d914aae3d *xorg-server-dmx-1.16.2-1.tar.xz 8f99b28212c2486b2fc9cbee5c205b20 *xorg-server-extra-1.16.2-1.tar.xz f154f180ecb2843896b45ffca7269c80 *xwinclip-1.16.2-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2014-November/002492.html [2] http://lists.x.org/archives/xorg-announce/2014-November/002495.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: [ANNOUNCEMENT] Updated: xinit-1.3.4-1 (Major overhaul of X session handling)
On 28/11/2014 08:45, Marco Atzeri wrote: On 11/28/2014 4:03 AM, Yaakov Selkowitz wrote: The following package has been updated in the Cygwin distribution: * xinit-1.3.4-1 xinit contains commands used for starting X sessions. noticed this new warning xinit: XFree86_VT property unexpectedly has 0 items instead of 1 For what I see there is no XFree86_VT setting anywhere xinit has been emitting this warning for a long time, it's just now you see it with startxwin. It's entirely safe to ignore, but I guess we should do something to quench that warning to prevent confusion and alarm... -- 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/
