Re: Spurious pastes
On 02-Feb-2018 13:13, David Mathog wrote: I seem to recall that before this if I highlighted a region in an xterm window, then moved to another X11 application window, and center clicked, it would paste the highlighted text. However, if nothing was highlighted in the last window, nothing would paste. My memory may be faulty on this issue though, as I never paid a lot of attention to it before it started misbehaving. That wasn't right, but cut/paste is slightly different between "on the console" and "over putty ssh tunnel with X11 Server on Windows". On an XFCE4 ubuntu system console this is what happens: I'm guessing this means a non-X terminal? That is a regular X11 server, xorg 1.15.1. It just acts differently in that it was possible to "select nothing". Hmm... I'm not sure what to make of that. In my brief testing, the behaviour does seem to vary with different terminals: terminator doesn't let you select an empty region, lxterm empties the selection (your expected behaviour), and xterm/rxvt don't change the selection. -- Unsubscribe info: http://cygwin.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: Spurious pastes
On 02/02/2018 22:26, David Mathog wrote: In the last few days nedit on those remote machines has been doing spurious pastes. That is, whatever is currently in the X11 paste buffer (not the program's paste buffer) is ending up dropped into whatever file is being edited. Unclear why they are landing where they do, I have not actually seen it happen, just found it when diff indicated these odd insertions. My best guess is that these happen while I am scrolling over these regions. Needless to say, this is really not a good thing. There have been only two changes recently. 1. I cleaned my mouse. 2. yum on 1/27/18 automatically installed on those servers: xorg-x11-server-common-1.17.4-16.el6.centos.1.x86_64 To eliminate (1) the mouse was swapped with another one. Too soon to know if that did anything. I wonder if you aren't somehow accidentally clicking the middle mouse button whilst scrolling? On 02-Feb-2018 13:13, David Mathog wrote: I seem to recall that before this if I highlighted a region in an xterm window, then moved to another X11 application window, and center clicked, it would paste the highlighted text. However, if nothing was highlighted in the last window, nothing would paste. My memory may be faulty on this issue though, as I never paid a lot of attention to it before it started misbehaving. That wasn't right, but cut/paste is slightly different between "on the console" and "over putty ssh tunnel with X11 Server on Windows". On an XFCE4 ubuntu system console this is what happens: I'm guessing this means a non-X terminal? 1. type "pwd" into an uxterm window 2. highlight "pwd" on the line at the preceding prompt, center click once at the current prompt. "pwd" is pasted. Press "enter". 3. left click once on the still highlighted "pwd", now 2 lines up. The highlight goes away. Center click once at the prompt. "pwd" is still pasted. Press "enter". 4. With the left mouse button drag across any letter and back to the original position. So nothing is highlighted. This can be on any text anywhere in the window. Center click at the prompt. Nothing is pasted - the paste buffer is now empty. So on the console it is possible to select "nothing". On the X11 server ssh to the Ubuntu system and it is the same for the first 3 steps, but the 4th still pastes "pwd". The rule seems to be "paste buffer can be replaced by anything selected, but not by a select operation which ends with nothing highlighted." On the X11 server ssh to the Centos system, it behaves just like a similar connection to the Centos system. The operations do the same thing when going between two uxterm windows on any of these tests. Which is right? Is "nothing" a valid thing to load into the paste buffer or no? From the testing I did on a couple of linux systems, making an empty selection in urxvt doesn't change the clipboard contents, so I don't think this is specifically a Cygwin X server problem. I think it's up to the client (i.e. urxvt) how it interprets making an empty selection, which seems to be to not update the selection. Is there a standard way to clear this buffer? I was going to suggest 'xsel -c' or 'xclip -i /dev/null', but that doesn't work (in this case) for obscure reasons to do with cut buffers... For future issues, can I ask you to use the cygwin list, per [1] [1] https://cygwin.com/ml/cygwin-xfree-announce/2015-03/msg1.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: Keybord layout under X mode
On 02/10/2017 12:28, Patrick Etienne wrote: I installed Cygwin 64 bit on my laptop. This one has a Belgian keyboard but in graphic mode the default keyboard is a Belgian keyboard. How do I change this configuration? You don't say what layout you want, but does [1] help answer your question? You can change the layout using the X server option -xkblayout, or the setxkbmap command. [1] https://x.cygwin.com/docs/faq/cygwin-x-faq.html#i18n-keyboard -- 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: Menus from Fedora virtual machine off screen
On 11/02/2017 22:14, Gulliver Smith wrote: I don't know if this is a Fedora 25 question or a cygwin X question since I upgraded at the same time. Ever since my Fedora 25 upgrade, the menus from programs running on the Linux box using cygwin x as the X server appear off screen at the top left. It is impossible to use these menus. Thanks for reporting this. There have been a few other similar reports, so I'd like to understand what the problem is here. For future issues, can I ask you to use the cygwin list, per [1] [1] https://cygwin.com/ml/cygwin-xfree-announce/2015-03/msg1.html An example is Firefox'smenu, but this happens with many Linux programs. Is there a configuration option that I am missing in cygwin X? No, I think this is probably a bug, somewhere. Fedora release 25 (Twenty Five) I built an x64 Fedora 25 VM and attempted to reproduce this problem, but with no success. Are you using a non-default visual theme? Can you attach an XWin.0.log file? I'm interested if you have a single or multiple monitor setup, and what the monitor geometry is. -- 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: -displayfd outputting some garbage?
On 08/02/2017 01:02, Matt D. wrote: On 2/7/2017 7:46 PM, Matt D. wrote: I have an xinit script which outputs the display id to a file with the following option: xinit .. -displayfd 3 3>$HOME/.display Thanks for reporting this. For future issues, can I ask you to use the cygwin list, per [1] [1] https://cygwin.com/ml/cygwin-xfree-announce/2015-03/msg1.html I hope you mean ' xinit -- -displayfd 3 3>$HOME/.display' This outputs correctly '0' but appends 0x00 and 0x0A. Why is it outputting a null byte and this 0x0A? Yeah, this seem to be a bug in xinit (which needs to insert itself into the displayfd pipeline to learn the display number for it's own purposes) $ X -displayfd 3 3>~/.display [...] $ xxd ~/.display : 300a 0. $ xinit -- -displayfd 3 3>~/.display [...] $ xxd ~/.display : 3000 0a 0.. This is causing issues where I try to perform: echo $(cat .display) Which results in: bash: warning: command substitution: ignored null byte in input 0 This warning is new in bash 4.4, I think. I think this is a just a warning though, and shouldn't actually cause any issues? -- 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: new start method (again?)
On 24/11/2016 14:46, David Lee Lambert wrote: So I have several Win7 or Win10 PCs with a small set of users who use them, I had modified the "XWin Server" shortcut by making it a per-user start menu item that would start each user's server at a different display number. Since some recent update, those shortcuts no longer work. Here's the error message... A fatal error has occurred and Cygwin/X will now exit. Unrecognized option: /home/**user**/.serverauth.17056 Please open the logfile for more information. Vendor: The Cygwin/X Project Release: 1.18.4.0 Contact: cyg...@cygwin.com Package: varsion 1.18.4-1 built 2016-07-22 XWin was started with the following command-line: /usr/bin/XWin :3 -multiwindow -listen -auth /home/**user**/.serverauth.17056 Since xinit-1.3.4-5/xserver-1.17.0-1 the -listen option is implemented in Xwin, not in startx, and now takes a protocol name. So I think you need to change '-listen' to '-listen tcp' in your shortcut. Screenshot at http://bit.ly/2gEeJkZ . Also, when I do start X, Win32 PuTTY doesn't seem to be able to forward remote programs to it any more. PuTTY does have an option to point to a ".Xauthority" file, but that doesn't seem to help. I sw some threads a few months ago that sounded similar, but reading through them so far I don't see a concise solution. I guess [1],[2] are the threads you refer to. I'm afraid there is no simple solution, currently. I guess what's needed is a patch to startx(|win) to use a deterministic .serverauth filename, or to add an option to disable the use of an authority file with the -auth option. [1] https://cygwin.com/ml/cygwin-xfree/2015-02/msg00075.html [2] https://cygwin.com/ml/cygwin/2015-09/msg00358.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: SIGSEGV in XopenDisplay in Cygwin64 X11
On 21/07/2016 17:25, John Watts wrote: cygcheck.out [...] gamin 0.1.10-15OK gawk4.1.3-1 OK gdb 7.10.1-1 OK [...] mingw64-x86_64-binutils 2.25.0.1.23f238d-1 OK mingw64-x86_64-gcc-core 4.9.2-2 OK mingw64-x86_64-gcc-fortran 4.9.2-2 OK mingw64-x86_64-gcc-g++ 4.9.2-2 OK mingw64-x86_64-headers 4.0.6-1 OK mingw64-x86_64-runtime 4.0.6-1 OK mingw64-x86_64-windows-default-manifest 6.4-1OK mingw64-x86_64-winpthreads 4.0.6-1 OK So, I don't see that you have cygwin gfortran installed, so I assume the gfortran below is mingw64-x86_64 targeted one? # Compile code with following flags gfortran -g -fdollar-ok -c testxod.f gfortran -g -I/cygdrive/c/cygwin64/usr/include -I/cygdrive/c/cygwin64/usr/include/X11 -c isox11.c gfortran testxod.o isox11.o defmap.o bmp_comms.o read_cmap_params.o isoflush.o -o ../ISOPARIX/testxod.exe -L/cygdrive/c/cygwin64/lib -lX11 So this doesn't seem right. Linking the cygwin libX11 with objects built with a mingw64 targeted compiler isn't going to work correctly. I'm afraid we don't provide packages for mingw64 X libraries, so I guess your alternatives are to build those yourself, or to build everything using a cygwin targeted compiler. -- 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: new start method questions
On 10/06/2016 18:05, mathog wrote: On 09-Jun-2016 17:55, mathog wrote: Last time around the start bat script was just: @echo off set CYGXTOP=%~dp0 C: chdir "%CYGXTOP%\var\log\xwin" move XWin.0.log.1 XWin.0.log.2 move XWin.0.log XWin.0.log.1 chdir "%CYGXTOP%\bin" start Xwin :0 -multiwindow Is there some reason that a similar cut down bat file would not work with the current cygwin X11 server? (With "-listen tcp" plus a windows firewall rule to only let it talk to localhost.) Usually, the fastest way to answer that kind of question is to try it :) In a regular CMD shell navigated to the bin directory and did: start Xwin :0 -multiwindow -listen tcp and it worked. So none of the current start script seems to be necessary if the only goal is to start the X11 server. It seems to work normally, at least by the criterion that xdpyinfo returns the same information as for the other starts. Yes, if running XWin doesn't actually start the server, that would be a bug On a related note - are there any situations where the X11 server itself (not something in its startup script) will start a subprocess and run a different binary? For instance, some sort of font search operation, or perhaps some conditional load of an X11 feature which isn't normally started, or some funny kind of cut and paste operation on the Window side? There are only 2 cases I can think of: - The xserver runs xkbcomp during start up to compile the keyboard map - Menu items in Xwinrc which use the EXEC instruction -- 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: Persistent CYGWIN/X server taskbar button with urxvt in CYGWIN-64, not rxvt in CYGWIN-32. Why?
On 02/12/2015 00:16, John J Ottusch wrote: Makes sense that it could be run.exe behavior. However, the version of run.exe from [2] (which is 220K in size vs. 68K for the original version ?!?) does not seem to do anything. Running it from a CMD window with urxvtermX.bat as the argument does not produce an error message, a urxvt term, nothing. It's larger because it doesn't have debug information stripped. BTW, I made an effort to give both versions of run.exe (I renamed the new one runX.exe) the same ownership and permissions, but to no avail. Am I missing something essential? Just chmod +x should be sufficient. I've probably done something wrong, although I have re-tested this run.exe and it seems to work for me. Perhaps you could try 'strace ./run XWin', that might shed some light on what's going wrong? -- 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: Persistent CYGWIN/X server taskbar button with urxvt in CYGWIN-64, not rxvt in CYGWIN-32. Why?
On 29/11/2015 02:56, John J Ottusch wrote: I use CYGWIN a lot with 64-bit Windows 7 and have been transitioning from 32-bit CYGWIN to 64-bit CYGWIN primarily in hopes of avoiding repeated STATUS_ACCESS_VIOLATION errors. If I could set up 64-bit CYGWIN (= C64) to behave exactly the same way as my 32-bit CYGWIN (= C32) set up I would, but the applications don't match up exactly and they don't behave exactly the same way. One difference I notice is that opening a urxvt in C64 creates a separate button associated with the Cygwin/X server process in the taskbar, whereas opening an rxvt in C32 does not. (rxvt is not available as a C64 application, but I would expect urxvt to operate similarly). In Yes, please use rxvt-unicode (urxvt). rxvt has been dead upstream for a decade. both cases an icon for the Cygwin/X server process shows up in the notification area. Both are started from a Windows shortcut: C32 target: C:\win32app\cygwin\bin\run.exe C:\win32app\cygwin\rxvtermX.bat C64 target: C:\win64app\cygwin\bin\run.exe C:\win64app\cygwin\urxvtermX.bat The batch files that run are similar. Both start 'XWin' if it is not already running, then run 'rxvt/urxvt'. [...] I prefer NOT to have the taskbar button for the Cygwin/X server process show up. Having an icon show up in the notification area is cleaner. Why are they behaving differently? Is there a way to make the urxvt version (C64) behave like the rxvt version (C32)? I think this is not a problem with the X server, but with the Cygwin run utility, which is supposed to run the .bat file with a hidden console. See [1] a previous discussion of this problem. I've built an x86_64 run.exe with that patch applied and uploaded it at [2]. Perhaps you could try that and see if it improves things. [1] http://cygwin.com/ml/cygwin-xfree/2012-08/msg0.html [2] ftp://cygwin.com/pub/cygwinx/x86_64/run.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: X no longer spawning windows after update
On 24/07/2015 01:27, l.w...@surrey.ac.uk wrote: Updated cygwin 32-bit with installer, now X no longer spawning windows or terminal on launch. Just seems to hang after running startxwin. Is there anything obvious in the log below? I think what you are seeing is the deliberate change described in the last bullet point of [1] The log you provide looks normal. [1] https://cygwin.com/ml/cygwin-announce/2015-07/msg00013.html (--) 8 mouse buttons found (eight mouse buttons? on a three-button mouse?) The value logged here comes from GetSystemMetrics(SM_CMOUSEBUTTONS) Some USB mice seem to report incorrect values. I'm guessing this is something like the maximum number of buttons the microcontroller inside can support, rather than the number which are actually physically present. This value is only used to see if it's not 2, in which case -emulate3buttons is enabled by default. I'm not sure what can be done about this, except perhaps changing found to reported :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/
Re: Some changed behaviors ...
On 04/06/2015 02:41, Eliot Moss wrote: I just updated to the latest XWin and got some different behaviors: - In my .XWinrc file I was using MINIMIZE in the STYLES. This now seems to permanently iconize a window. If I click on the icon, it briefly flahses large and then iconizes again. Thanks for reporting this. This regression seems to be a side-effect of the change I made in 1.17.1-5. If you would like to try it, I made a snapshot which hopefully fixes this without breaking anything else, but when working on this code I always get the feeling that something else is going to unravel when I pull on one of the loose ends :) ftp://cygwin.com/pub/cygwinx/x86/XWin.20150702-git-b872b0571855112c.exe.bz2 ftp://cygwin.com/pub/cygwinx/x86_64/XWin.20150702-git-b872b0571855112c.exe.bz2 - When using -geometry (with xemacs in particular), the height of the screen seems different, and if I change the geometry height by 1, the height of the window does not change by 1 -- it either doesn't change, or changes by more than one. Hmmm I think that the size of the emacs window is (or at least, should be) constrained so it can only change by a whole character? Can you give a bit more detail e.g. what version you were using previously, the geometry you are requesting and the actual size of the window as reported by xwininfo? -- 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: Magic Cookie - SSH Secure Shell
On 19/04/2015 22:08, Nicholas Fitzkee wrote: Typically, I start Xwin when I log in, and I rarely use the Cygwin terminal to run programs. Instead, I use an older SSH client (SSH Secure Shell 3.2.9), similar to PuTTY, to use X11 apps remotely. I don't want to see any xterms or menus when I start, and I need to listen for TCP connections from my SSH app. [snip] In addition, I added the server args to my XWin Server shortcut. The complete shortcut target now reads: D:\cygwin\bin\run.exe --quote /usr/bin/bash.exe -l -c cd; /usr/bin/startxwin -- -listen tcp -multiwindow -clipboard All seems to be well and good - when I start Cygwin Terminal and type export DISPLAY=:0.0 and then xeyes, the eyes come up. Similarly, when I use export DISPLAY='localhost:0.0' and run xeyes from Cygwin Terminal, it also works. However, when I try logging into my remote server (X-connections are forwarded) using the program, I get the following error messages, and I can't run X11 apps remotely: --- snip --- Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-79-generic x86_64) ... blah blah ... Last login: ... blah blah ... Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyxset: unable to open display localhost:16.0 Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyxset: unable to open display localhost:16.0 Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyxset: unable to open display localhost:16.0 Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyxset: unable to open display localhost:16.0 Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyxhost: unable to open display localhost:16.0 --- snip --- I have no idea how to fix this or what it means, but I think it may be related to the following thread (regarding PuTTY), which doesn't appear to have ever been resolved. https://cygwin.com/ml/cygwin-xfree/2015-02/msg00075.html I will note that I can work around this using a shortcut target of: D:\cygwin\bin\run.exe --quote /usr/bin/bash.exe -l -c cd; Xwin -listen tcp -multiwindow -clipboard However, this seems like a bit of a hack. You are correct, this is the same issue. The problem is that starting the server using startx or startxwin generates a random authentication cookie, which is passed to the server using the -auth option and which is required for clients to connect. Local cygwin X clients (including ones forwarded using cygwin's ssh client) will use that token automatically. Unfortunately, at this point in time, the solutions to your problem are limited to - starting XWin directly - using cygwin ssh - configuring your non-cygwin X client to use the correct authentication token (It seems to be possible to do this with PuTTY as discussed in that thread. I don't know if it your ssh program has that option) I'm not sure about how to solve this problem. I guess it would be possible to make startxwin not use -auth by default, as it did previously, but reducing the security of the default configuration like that doesn't seem a good idea. Ultimately, I have graduate and undergraduate students who need to be able to quickly set up their own Windows systems to run X11 apps on my linux server. These students are often not particularly tech-saavy, so I'd like my tutorial for them to be as simple as posslble. As an example, you can see what I wrote for the old xinit at this link: http://fitzkee.chemistry.msstate.edu/sites/default/files/bootcamp/session-03 _running-x11.pdf I'm afraid this link doesn't work for me. If all you are using cygwin for is the Xserver, perhaps you might find Xming or Vcxsrv more suitable to your needs? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin XWin 1.17.1 crash at startup
On 31/03/2015 19:36, Michel Poirier wrote: Since last X-Cygwin update several of my X-Win applications are not working properly. Googling cygwin xorg 1.17 crash gave many posts reporting probably similar issues but I couldn't find a fix for the error. I also looked at the Cygwin-FAQ and mailing list without real success. The issue appeared using a long-time tested DOS script launching xmgrace which failed with a message telling A fatal error has occurred and Cygwin/X will now exit. And other XWin programs were not working properly. So I tried to make a fresh install of X-Cygwin (32 bits) on another computer and went through the procedure explained on page Can you be a bit more specific than not working properly, please? I made a brief test with xmgrace, and I wasn't able to observe any problems. Is there some specific option or action in xmgrace which causes this crash? http://x.cygwin.com/devel/backtrace.html Would it be possible for you to try the a backtrace when some specific action is making the X server crash method on the machine which shows the crash? which produced the debug info attached as backtrace for X server crashing at startup.txt. The X Server crashed when the r command was launched and a copy of the Windows error message is provided at Capture of Windows error message.txt. I checked that no other X Server was then running and clicked Ok button to finish the procedure. Thanks for attempting this. Unfortunately, this looks like the server refusing to start as one is already running. If there really isn't one running, this looks like a different problem. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] cygwin-xfree list deprecation
Dear Internet, It no longer makes much sense to have a separate list for Cygwin X related traffic, so the cygwin-xfree list is now officially deprecated. Reasons for this decision include: - the level of traffic on the cygwin-xfree list is low - splitting the traffic in this way currently serves no useful purpose - the distinction between what is and is not an X issue is artificial, vague, and often ignored The cygwin-xfree list will continue to operate, but I suggest and encourage you to use the main cygwin list for all your cygwin X server and X application related questions, bug reports, moans, gripes, whines and patches ;-). The Cygwin X website and documentation will be updated to point to the main cygwin list. Mail delivery for the cygwin-xfree list may be turned off at some future date, but even if that happens, the list archives will continue to be available. Live Long and Prosper, Jon -- 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: Cannot run Qt5 applications.
On 03/03/2015 09:04, Corinna Vinschen wrote: On Mar 2 17:34, Yaakov Selkowitz wrote: On Fri, 2015-02-13 at 18:32 +, Jon TURNEY wrote: On 05/02/2015 01:40, Jon TURNEY wrote: On 04/02/2015 23:20, David Stacey wrote: I'm having difficulty running any Qt5 application. These are the commands I'm issuing: [snip] and I see the clock, so X is up and running. Then: [snip] Possibly you need to install and start cygserver (See [1]) If so, this is because Qt5 is assuming shared memory is available, which could possibly be handled in a better way... This looks like a portability problem in Qt5, where it only handles shmget() failing with a return value of -1, not with SIGSYS, to fallback to using an image in unshared memory. Patch attached. Or is it a problem with our shmget()? http://pubs.opengroup.org/onlinepubs/9699919799/functions/shmget.html http://man7.org/linux/man-pages/man2/shmget.2.html Perhaps we should be just returning -1 with an errno (ENOSYS?) instead of raise(SIGSYS)? I think it was a BSD-ism to raise SIGSYS if shared memory is not available due to policy. Historically, there must have been some OS which did this, because there is code to detect this situation in the X server [1] [1] http://cgit.freedesktop.org/xorg/xserver/tree/Xext/shm.c#n167 Looking at [2],[3] it seems perhaps this was added in Cygwin because some FreeBSD test code was used? [2] https://cygwin.com/ml/cygwin-cvs/2003-q4/msg00130.html [3] https://cygwin.com/ml/cygwin-cvs/2003-q4/msg00128.html I'd kind of assumed that modern BSDs behave in the same way, but that doesn't actually seem likely. I have absolutely no problem with changing this to return ENOSPC (there is a limit of 0 SHM identifiers, and we have reached it), or whatever is appropriate in this state. Or you just add signal(SIGSYS, SIG_IGN) prior to calling shmget. SIGSYS is raised when calling a system call which isn't available. That's perfectly valid. This is true. I guess it's not how Linux behaves, though, so I think changing it ought to be considered to minimize porting effort. I'll also note that checking once at startup, as the X server does, is not enough. If the cygserver is stopped, it will die with an unexpected SIGSYS when a client tried to use shared memory. Of course, it would be nice if Qt5 used POSIX shared memory objects instead, but that's asked too much, probably. Unfortunately, it has to use whatever the X server's MIT-SHM extension uses... -- 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: Display issue
On 24/02/2015 23:06, Maarten Hoes wrote: Im experiencing an issue where the graphics arent displayed correctly. When I start LibreOffice on my Fedora 21 Linux system from a cygwin/x system, the left hand side (open file, template, writer document, etc.) isnt displayed properly initially. After clicking around some, the display updates and gets displayed right. Here's a screenshot of the badly displayed graphics: http://imgur.com/bTD4yQ3 And this is what it looks like (correctly) after some clicking around: http://imgur.com/adj5mKD I have no idea on how to start troubleshooting the issue; all thoughts and ideas are more than welcome. To me, this looks like a different icon set is being used. Note that the Open File and Templates icons have completely different outlines between the two screenshots. Have you verified that this problem doesn't occur with XDMCP sessions using a different X server (e.g when run locally on Fedora 21)? I think this is probably best addressed by raising an issue on LibreOffice. It might be that XWin is doing something to make LibreOffice render like this, but LibreOffice devs might have more insight into what that something might be. -- 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-20150224-2
*** xlaunch-20150224-2 * Update for uname change WOW64 - WOW in cygwin 1.7.34 x86: ab0b0d226435cb4af1a1ee00f8413ab2 *xlaunch-20150224-2-src.tar.xz 330978c54489e2e4fd0ee93ab0b8ecb4 *xlaunch-20150224-2.tar.xz 6dc7859b65bf9b223d93791124716e92 *xlaunch-debuginfo-20150224-2.tar.xz x86_64: 7e558c753289130c96bea4c4ba4c8739 *xlaunch-20150224-2-src.tar.xz 4d8d7b9ea0d3fb4099c72186b3557513 *xlaunch-20150224-2.tar.xz 3afe55a304161ffc83666cdb77231670 *xlaunch-debuginfo-20150224-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: Dfficulty with xorg-server-1.17.1-2.
On 25/02/2015 14:30, GEORGE BARRICK wrote: I have one small note for other folks who might like to run their system in a way similar to mine. I like to have xlaunch automatically start a single colored xterm for me (in multi-window mode). After that I just open more from the command line as it suits me. If I use the command line embedded in the installed xlaunch.lnk file: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xlaunch.exe it always prompts me through the tiresome configure start GUI at the beginning. Adding the phrase -run ~/config/config.xlaunch at the end of that command line always gets ignored in favor of the configure start GUI. You need to quote the whole command line for bash after the -c, otherwise bash treats words after the first one as positional parameters. However, getting this quotation passed correctly through run requires a little bit of gymnastics, but this should work: C:\cygwin\bin\run.exe --quote /usr/bin/bash.exe -l -c xlaunch -run ~/config/config.xlaunch However, when I strip the invocation of the bash from that command: C:\cygwin\bin\run.exe /usr/bin/xlaunch.exe -run ~/config/config.xlaunch the xlaunch goes right ahead to run the single xterm that's described in my ~/config/config.xlaunch file. This is not quite equivalent as there is no login shell in the ancestry of whatever your config.xlaunch starts, so your ~/.profile may not have been read. For that reason, using 'bash -l -c ' is preferred and that's what start menu links that cygwin installs generally use. -- 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: Dfficulty with xorg-server-1.17.1-2.
On 25/02/2015 04:35, Jim Reisert AD1C wrote: # gdb --pid=`pidof /usr/bin/XWin` ... Reading symbols from /usr/bin/XWin.exe...Reading symbols from /cygdrive/c/Cygwin /lib/debug//usr/bin/XWin.exe.dbg...Can't read data for section '.debug_frame' in file '/cygdrive/c/Cygwin/lib/debug/usr/bin/XWin.exe.dbg' (gdb) c Continuing. Cannot execute this command while the selected thread is running. (gdb) At this point, I can not right-click on the 'X' icon to do anything. Once I exit gdb, then I can. How can I get past this? Odd. Are you sure you are using the current, cygwin gdb? But let's step back a moment, since I don't think you have the same problem as the OP. [ 164.799] winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. Perhaps we need to be a little more specific about what we mean by 'crashing'. This log message probably means that the X server is just spontaneously deciding it should exit, rather than exiting due to a program error signal with the A fatal error has occurred dialog. Can you provide a full Xwin.0.log file, please? I am assuming that this problem started with xorg-server 1.17 and reverting to 1.16.3-1 fixes 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: Dfficulty with xorg-server-1.17.1-2.
On 24/02/2015 18:03, GEORGE BARRICK wrote: I've been using xlaunch with a windows desktop shortcut for about a year to start a multi-window instance of xwin on my Win7 computers. [snip] OK. Now for the difficulty. I recently (today) updated my cygwin system to include the newest xorg-server, xorg-server-common and xorg-server-dmx (the 1.17.1-2 versions) as well as xf86-video-dummy_0.3.7-3 xf86-video-nested-0.1.0-6 and xinit_1.3.4-5, and have found that xlaunch no longer seems capable of finding my .xlaunch-file. It starts X as before, but does not automatically spin up the xterm that my .xlaunch-file requests. I wind up having to start an xterm manually from the xwin Applications menu. In summary, I have changed _nothing_ except for the new X-stuff, and have this problem. The log-file from xwin does not seem radically different: [snip] The other notable problem to report is that my X-server now crashes after about 5-10 minutes of use. [snip] P.S. Excuse verbosity of this report; I've tried to give complete description. Thanks for providing such a detailed report, this enabled me to quickly reproduce what I think is the issue. This seems to be a problem with xlaunch, which needs a small update to work correctly with xserver 1.17. I've just uploaded xlaunch-20150224-1, which should fix this. I think this is actually also the cause of your 'crashes' as well. After about 12 minutes, xlaunch is deciding that the X server hasn't started successfully and is killing 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: Dfficulty with xorg-server-1.17.1-2.
On 24/02/2015 19:35, Jon TURNEY wrote: On 24/02/2015 19:05, Jim Reisert AD1C wrote: On Tue, Feb 24, 2015 at 11:03 AM, GEORGE BARRICK wrote: The other notable problem to report is that my X-server now crashes after about 5-10 minutes of use. Since this issue does not get reported in xwin.0.log or xwin.0.log.old, I do not yet know how to provide more information. I have seen this also. It only happens on my PC at home, if I leave it alone for hours on end. It's not nearly as frequent as 5-10 minutes. I need to check the log files again, but I don't remember seeing anything there the first time I looked. With regard to the crash problems, can you please try the instructions at [1] to generate a backtrace. [1] http://x.cygwin.com/devel/backtrace.html Possibly this was xlaunch deciding that the X server hasn't started successfully after ~12 minutes or so, and killing it. So don't bother, unless you have crash problems after upgrading to xlaunch-20150224-1, or when not using xlaunch. -- 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: X refuses to start
On 24/02/2015 20:59, Will Parsons wrote: I'm accustomed to start X via a shortcut which runs the command: C:\cygwin\bin\run.exe --quote /usr/bin/bash.exe -l \ -c cd; /usr/bin/startxwin -- -listen [...] I can't make sense out of what this is telling me about why X failed to start. Since xorg-server-1.17.0-1 and xinit-1.3.4-1, the syntax has changed and you should now use '-listen tcp'. -- 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: Dfficulty with xorg-server-1.17.1-2.
On 24/02/2015 19:05, Jim Reisert AD1C wrote: On Tue, Feb 24, 2015 at 11:03 AM, GEORGE BARRICK wrote: The other notable problem to report is that my X-server now crashes after about 5-10 minutes of use. Since this issue does not get reported in xwin.0.log or xwin.0.log.old, I do not yet know how to provide more information. I have seen this also. It only happens on my PC at home, if I leave it alone for hours on end. It's not nearly as frequent as 5-10 minutes. I need to check the log files again, but I don't remember seeing anything there the first time I looked. With regard to the crash problems, can you please try the instructions at [1] to generate a backtrace. [1] http://x.cygwin.com/devel/backtrace.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xlaunch-20150224-1
*** xlaunch-20150224-1 * Fix for X server 1.17 * Close help window when xlaunch is closed * Use cygpath on path provided to xlaunch for Open/Edit actions x86: 7afc52b7c36fd076896929d9d45b1632 *xlaunch-20150224-1-src.tar.xz 6fd65620e45b41ddbf1c9359723ecbbb *xlaunch-20150224-1.tar.xz eaf3e599de386e14d91a58ec5270facc *xlaunch-debuginfo-20150224-1.tar.xz x86_64: a98166f9c2962226e2ce7bff7edc7d89 *xlaunch-20150224-1-src.tar.xz 5d8f13f3e4a412bccb2b54f27e109cda *xlaunch-20150224-1.tar.xz 0a054c7f4306894c5e89d56e6a4313d4 *xlaunch-debuginfo-20150224-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: Help porting the XLaunch feature to autoselect the display number
On 24/02/2015 03:57, Michael DePaulo wrote: I am trying to port this feature of VcXsrv (and XMing also I think) to Cygwin XLaunch: https://sourceforge.net/p/vcxsrv/code/ci/460182676a960385dff96c1563f781213060f6fc/ Attached is my WIP patch. (I know it needs the comments updated for main.cc). There's a bug in main.cc that is causing this to happen when -1 is specified: http://imgur.com/Jv4tpip Protip: Ctrl-c works on MessageBox dialogs to copy their contents. Thanks for looking into this. Unfortunately, this turns into a non-trivial amount of work. The upstream design is that -displayfd introduces a file descriptor that the child X server process inherits, to which it will write it's display number. (This fd will be one end of a pipe which the parent process has opened, and it will read the display number from the fd for the other end) In the VcXsrv implementation, instead a handle to some shared memory is used to pass the display number back. (I guess a Windows anonymous pipe would have worked just as well, but possibly this is simpler to implement). So, you will need to re-write the changes to main.cc to create a pipe (using pipe()), pass the write fd using -displayfd, and read the diplay number from the read fd. Even after you've done this, I'm not 100% sure that cygwin pipes are successfully propagated across CreateProcess(). I have a vague memory this is where I got stuck when I last looked at this, but I'm not sure I'd noticed that CreateProcess() is being invoked with bInheritHandles=FALSE. I found my old (non-working) attempt at implementing this [1], which might help you a bit. [1] https://github.com/jon-turney/xlaunch/commit/b3fc02fcc9ac43224137963e2aba39abb88608da -- 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: Can't open display with PuTTY and xinit 1.3.4-1
On 24/02/2015 16:55, Fj wrote: On 2015-01-05 05:31, Laurens Blankers wrote: When using PuTTY with X11 forwarding enabled X clients are no longer able to connect to the X server running locally. When reverting back to 1.3.2-1 the problem goes away. This may be related to the -nolisten tcp which is now the default[1]. If this is indeed the case it would be create of adding the '-listen' flag to startxwin could be added to the FAQ. Or another, more secure, solution would also be appreciated. Hi, I updated Cygwin today and hit the same problem, except even after I added -listen tcp xterm (and gvim) still refused to work complaining about No protocol specified (before was: Can't open display). The No protocol specified message is a bit obtuse. It comes back from the server when an attempt is made to open a connection, and really means something like Authorization required, but no authorization protocol specified - the server was started with an authorization file using the -auth option, but the client didn't offer any authorization data. Putty logs say Opening X11 forward connection succeeded (before -listen tcp it was: Forwarded X11 connection terminated due to local error), which seems to indicate that the problem is with the X server (and the way xterm/gvim communicate with it). I'm afraid it seems '-listen tcp' is not enough for PuTTY to successfully connect. If the server was started with -auth (which startxwin does since xinit-1.3.4-1), then PuTTY will need authorization data to successfully connect. Whilst you can do this by setting the X authority file for local display in PuTTY's configuration to the Windows path equivalent to ~/.serverauth., this isn't much of a solution as this filename changes everytime the server is started. Perhaps xinit needs an option to avoid using -auth? One can demonstrate that works by starting the server directly, e.g. using 'XWin -multiwindow -listen tcp' rather than 'startxwin'. Definitely some sort of change is needed to make this work better. Ssh-ing to the server from Cygwin terminal works and I can even launch gvim from the Putty's tty by specifying the same DISPLAY the Cygwin connection provides. After reverting to some early 2014 version of xinit and xorg (thank god for Cygwin Time Machine) everything resumed working properly. (on a side note, I tried to figure out what are the possible -listen options by looking at the xserver code, there are three, tcp, unix, local. What does local mean, couldn't it be loopback adapter? Where is _XSERVTransNoListen function implemented?) I think local is an alias for unix, which uses a UNIX domain socket (as emulated by cygwin) _XSERVTransNoListen is implemented (via some macros) in libXtrans. -- 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.17.1-2
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.17.1-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.17.1-1: * Fixes for regressions caused by RANDR change in 1.17.1-1 Addresses: https://cygwin.com/ml/cygwin-xfree/2015-02/msg00032.html * Add marketing name for Windows 10.0 * Log the locale when it's not supported by libX11 * Log windows thread ID on fatal signal to aid in interpreting crash reports NOTEWORTHY CHANGES IN 1.17 == The creation of indirect GLX contexts is now prohibited by default. The +iglx option is required to allow them. See [3] for more information on possible OpenGL configurations. '-nolisten tcp' is now the default, so the server only accepts local connections on a unix domain socket. A '-listen' option has been added which can be used to restore the previous behaviour. x86: c1627dff7c676a226e8030b63539c8d5 *xorg-server-1.17.1-2-src.tar.xz e9a7f22b6372d5bc223d6c98c4e8d3b3 *xorg-server-1.17.1-2.tar.xz 76c0622cbf4d6de6ddb6acc4365a4dcd *xorg-server-common-1.17.1-2.tar.xz 9c7ce33739bcea5276bf456431b04f81 *xorg-server-debuginfo-1.17.1-2.tar.xz 0ae3e9dcd500c92ed8cf9e75997a0be1 *xorg-server-devel-1.17.1-2.tar.xz 16fac69b92a437b9cd797d8bd856a74e *xorg-server-dmx-1.17.1-2.tar.xz ac62929f5789ed8080a55032fa34c03c *xorg-server-extra-1.17.1-2.tar.xz ec69ed455123c737eadd1122968bab29 *xwinclip-1.17.1-2.tar.xz x86_64: ff9942944ce5ccd4a1a994316e59b0f6 *xorg-server-1.17.1-2-src.tar.xz 532de5370f52a0c2c9777efcaef0a08e *xorg-server-1.17.1-2.tar.xz f841880ee0467f89f33ce0d8e4dbf1b4 *xorg-server-common-1.17.1-2.tar.xz 124e514d2d6c49b9672255330f946a0d *xorg-server-debuginfo-1.17.1-2.tar.xz bf27e40d7c78da0d0eeb1074c95377ed *xorg-server-devel-1.17.1-2.tar.xz 705ef8742d93226cbcdbba3d3cf63c88 *xorg-server-dmx-1.17.1-2.tar.xz 5c610c2a3a4cbba6ad79337d8a60fb36 *xorg-server-extra-1.17.1-2.tar.xz 69e2983e1cbca05134f5fd1098833c31 *xwinclip-1.17.1-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: Cygwin/X XDMCP Issue
On 20/02/2015 18:36, Maarten Hoes wrote: I am (again) experiencing some issues when running Cygwin/X in combination with XDMCP. Opening a cygwin prompt and running 'startxwin' works as expected. But when I try to connect to my remote Linux system with the command 'xwin -query 192.168.0.21' (or with the 'XLaunch' program and choose XDMCP) the screen stays black. Things used to work, but apparently something broke my setup. Im running the latest Cygwin/X, and applied all current updates on my Fedora 21 Linux system. Im running KDM. Any and all ideas are more than welcome, as I have no idea whats going on here. Package: version 1.16.3-1 built 2014-12-30 xwin -query 192.168.0.21 -logverbose 3 1 0.00 192.168.0.20 - 192.168.0.21 XDMCP 49 Query 2 0.013254 192.168.0.21 - 192.168.0.20 XDMCP 100 Willing 3 0.227426 192.168.0.20 - 192.168.0.21 XDMCP 360 Request 4 0.227831 192.168.0.21 - 192.168.0.20 XDMCP 94 Accept 5 0.227968 192.168.0.20 - 192.168.0.21 XDMCP 71 Manage Assuming your wireshark filter includes X11, you should be seeing a X11 connection request from 192.168.0.21 to the X server here. Since the same X server version was working for you before (to a different IP address), I can only suggest you examine what else has changed. You might want to check your firewall/network configuration. 6 2.225721 192.168.0.20 - 192.168.0.21 XDMCP 71 Manage 7 6.229538 192.168.0.20 - 192.168.0.21 XDMCP 71 Manage 8 14.230544 192.168.0.20 - 192.168.0.21 XDMCP 71 Manage 9 30.228625 192.168.0.20 - 192.168.0.21 XDMCP 71 Manage -- 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.17.1-1 (TEST)
On 18/02/2015 14:46, Angelo Graziosi wrote: Il 18/02/2015 15:23, Jon TURNEY ha scritto: This is an intentional change. NOTEWORTHY CHANGES IN 1.17 == '-nolisten tcp' is now the default, so the server only accepts local connections on a unix domain socket. A '-listen' option has been added which can be used to restore the previous behaviour. On 18/02/2015 14:12, Angelo Graziosi wrote: $ DISPLAY=127.0.0.1:0.0 ./libXbgi_helios_orbits.out I think you will need to write DISPLAY=:0.0, or add the new '-listen tcp' X server option. OK, $ DISPLAY=:0.0 ./libXbgi_mandelbrot.out works. This seems enough.. If I understand, the option '-listen tcp' is needed to make it backward compatible with DISPLAY=127.0.0.1:0. Right? That is correct. -- 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: ctrl-alt-{ ctrl-alt-[ ctrl-alt-] ctrl-alt-} not working as expected german keyboard on notebook
On 18/02/2015 23:07, Thomas Wolff wrote:
Am 18.02.2015 um 14:35 schrieb Jon TURNEY:
On 18/02/2015 02:54, rhofm...@rayed.de wrote:
Dell Latitude E6540, german keyboard.
I can type AltGr-{ ... and so on, but ctrl-alt-{ ... as labeled on the
keyboard gives something wrong.
It seems like when Alt is pressed Ctrl (Strg) is ignored, it gives the
same keys as without Ctrl.
I tried some things with setxkbmap, but no success.
Your description is quite inprecise; which terminal do you use (xterm?)
and what exactly do you expect and see in those cases?
I believe that '{' is on the 3rd shift level of 7 on a German keyboard.
So AltGr-7 gives '{', and (under Windows) Ctrl-LAlt-7 does the same.
Unfortunately, there doesn't currently seem to be a way to configure X
to act in this way.
What I meant to say is: There doesn't seem to be a simple way to
configure X to act in this way. You could make you own keyboard layout
which behaves in this way...
In xkeyboard-config language, you are trying to access the 3rd level
shift for a key (1st level is the normal key, 2nd is the shifted key)
I believe that the standard (DIN 2137) specifies that this 3rd level
is accessed by right alt.
ctrl + left alt being equivalent to right alt is a Windows-ism [1].
Again, not sure exactly what effect you suggest but in fact
Ctrl+Left-Alt and AltGr can be distinguished and it works in both xterm
and mintty. (It's a bit tricky and I don't recall the details right now,
it involves considering the sequence of events.)
The problem isn't that Ctrl-LAlt and AltGr aren't distinguished to X.
The problem is that the X keyboard layout doesn't map the Ctrl-LAlt-key
combination as Windows does.
Ideally, we would have something like 'setxkbmap -option
lv3:mswin_compat' to configure that mapping, but that doesn't exist at
the moment.
--
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: ctrl-alt-{ ctrl-alt-[ ctrl-alt-] ctrl-alt-} not working as expected german keyboard on notebook
On 18/02/2015 02:54, rhofm...@rayed.de wrote:
Dell Latitude E6540, german keyboard.
I can type AltGr-{ ... and so on, but ctrl-alt-{ ... as labeled on the
keyboard gives something wrong.
It seems like when Alt is pressed Ctrl (Strg) is ignored, it gives the
same keys as without Ctrl.
I tried some things with setxkbmap, but no success.
Unfortunately, there doesn't currently seem to be a way to configure X
to act in this way.
In xkeyboard-config language, you are trying to access the 3rd level
shift for a key (1st level is the normal key, 2nd is the shifted key)
I believe that the standard (DIN 2137) specifies that this 3rd level is
accessed by right alt.
ctrl + left alt being equivalent to right alt is a Windows-ism [1].
See the upstream bug [2], you might also find the discussion in [3] of
interest.
[1] http://en.wikipedia.org/wiki/AltGr_key#Control_.2B_Alt_as_a_substitute
[2] https://bugs.freedesktop.org/show_bug.cgi?id=37232
[3] https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/822872
--
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.17.1-1 (TEST)
This is an intentional change. NOTEWORTHY CHANGES IN 1.17 == '-nolisten tcp' is now the default, so the server only accepts local connections on a unix domain socket. A '-listen' option has been added which can be used to restore the previous behaviour. On 18/02/2015 14:12, Angelo Graziosi wrote: $ DISPLAY=127.0.0.1:0.0 ./libXbgi_helios_orbits.out I think you will need to write DISPLAY=:0.0, or add the new '-listen tcp' X server option. But with this 1.7.1 release, I get always: Cannot connect to X server even if the X server is running (the X icon on sys-tray, with all its items menu if one right clicks..) Reverting to 1.6 fixes the 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: weird xemacs crash
On 17/02/2015 20:35, Eliot Moss wrote:
Dear Cygwin X --
I have a situation where cygwin xemacs, both 21.4.23-1 and the newer
-2 crash when trying to open a file with certain content. (I copied
the file; opening it under the other name fails too.) It's a
relatively small file, some .c source. The characters used are all
reasonable ASCII: newline plus space through 175 octal. The length
is 2601 bytes.
Here is the stackdump:
Stack trace:
Frame Function Args
002899C4 61030F12 (02E0, EA60, 00A4, 00289A24)
00289AE4 610E468A (6119EE10, , 00289B18, )
What's the next step?
Assuming I have the same cygwin DLL as you...
$ cat stackdump | awk '/^[0-9]/{print $2}' | addr2line -asf -e
/usr/lib/debug/usr/bin/cygwin1.dbg | paste - - - | column -t
0x61030f12 _ZN7_cygtls19call_signal_handlerEv@4exceptions.cc:1490
0x610e468a _Z8sig_sendP6_pinfoR9siginfo_tP7_cygtls@12 sigproc.cc:714
But are you sure this isn't the problem mentioned in [1]?
[1] https://cygwin.com/ml/cygwin/2015-02/msg00339.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: Updated: xorg-server-1.17.1-1 (TEST)
On 15/02/2015 14:49, Michael DePaulo wrote: Unfortunately, I have experienced 2 regressions vs 1.16.3-1. (In the results below, I am assuming 1 and 2 are the same regression/issue, while 3 is separate.) Thanks for testing and reporting the problem. With the excellent detail in your email I was able to build a Centos 7 VM which reproduces the problem, which was due to the RANDR changes in 1.17.1-1 not being quite correct. I've had a go at fixing this and uploaded a snapshot [1]. Perhaps you could try that and see if it improves things for you? [1] ftp://cygwin.com/pub/cygwinx/x86/XWin.20150216-git-2323ff7b08e56b79.exe.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.17.1-1 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.17.1-1 These packages contain XWin and the other X.Org X11 servers. These packages are 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! In addition to upstream fixes [1], this contains the following cygwin-specific changes since 1.17.0-1: * Improve the RANDR data returned so a primary output exists (Fixes an issue with GDM, see [2]) * Make the XDMCP session options -query,-indirect,etc. imply -listen tcp NOTEWORTHY CHANGES IN 1.17 == The creation of indirect GLX contexts is now prohibited by default. The +iglx option is required to allow them. See [3] for more information on possible OpenGL configurations. '-nolisten tcp' is now the default, so the server only accepts local connections on a unix domain socket. A '-listen' option has been added which can be used to restore the previous behaviour. [1] http://lists.x.org/archives/xorg-announce/2015-February/002530.html [2] https://cygwin.com/ml/cygwin-xfree/2015-02/msg00024.html [3] http://x.cygwin.com/docs/ug/using-aiglx.html x86: f0cc6d377e4d52b54e9286fb665d2dd5 *xorg-server-1.17.1-1-src.tar.xz 46369cce24f4fb01e1a5d6b947f9c8bf *xorg-server-1.17.1-1.tar.xz 1e925528af6e77765030448f9434b549 *xorg-server-common-1.17.1-1.tar.xz 54cd4bed9029a855b8ba5a9cb880e43b *xorg-server-debuginfo-1.17.1-1.tar.xz a68b5924c9e1b1dcb9b18b4f8b484cf2 *xorg-server-devel-1.17.1-1.tar.xz dce2797a330cada451a36a38e4e7022d *xorg-server-dmx-1.17.1-1.tar.xz 67d2c1a3b181e343e0f95a40d912a780 *xorg-server-extra-1.17.1-1.tar.xz cd76dfb4641081b916fa0a6a54cafb83 *xwinclip-1.17.1-1.tar.xz x86_64: 80f80048c75f06609cb06020eb5dfa92 *xorg-server-1.17.1-1-src.tar.xz c2bc9b99f7df7fb4afaa3925984c6c3a *xorg-server-1.17.1-1.tar.xz 60d044e7bb11870d12a9778c8d85cbb1 *xorg-server-common-1.17.1-1.tar.xz d0b9bc28e6f76fca6c27bc3bfe878f86 *xorg-server-debuginfo-1.17.1-1.tar.xz 7cdd0c4e959a8a7e3827790c6a8b319b *xorg-server-devel-1.17.1-1.tar.xz 4693a172afc10d46d26b1e4774c0293d *xorg-server-dmx-1.17.1-1.tar.xz 4f66d78513d7b35870bf4a9d77f1594c *xorg-server-extra-1.17.1-1.tar.xz 206dc2956bc008582ff52d1f8ed3043b *xwinclip-1.17.1-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: Cygwin/X XDMCP Issue
On 13/02/2015 07:24, Maarten Hoes wrote: On 2-2-2015 16:20, Jon TURNEY wrote: If you can provide the details of the linux distribution and release you are using on your remote host, I can see if I can try to reproduce the problem. I was wondering if you managed to reproduce the issue ? Yes, I can reproduce it. It seems that the XRANDR data which XWin returns isn't quite complete, which tickles a bug in Gnome [1] primaryMonitor is undefined, which prevents the login greeter from being displayed. I've been testing a fix for that issue in XWin. This gets you the greeter login screen. Unfortunately there seem to be other bugs, which prevent login from working. These also occur when starting an XDMCP session from linux, so I don't think these are XWin issues. [1] https://bugzilla.gnome.org/show_bug.cgi?id=736054 -- 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: Cannot run Qt5 applications.
On 05/02/2015 01:40, Jon TURNEY wrote:
On 04/02/2015 23:20, David Stacey wrote:
I'm having difficulty running any Qt5 application. These are the
commands I'm issuing:
XWin -multiwindow
export DISPLAY=:0.0
xclock
and I see the clock, so X is up and running. Then:
/usr/lib/qt5/examples/gui/analogclock/analogclock
QXcbConnection: XCB error: 145 (Unknown), sequence: 162, resource
id: 0, major c
ode: 140 (Unknown), minor code: 20
Bad system call (core dumped)
Possibly you need to install and start cygserver (See [1])
If so, this is because Qt5 is assuming shared memory is available, which
could possibly be handled in a better way...
[1] http://x.cygwin.com/docs/ug/using-shared-memory.html
Yaakov,
This looks like a portability problem in Qt5, where it only handles
shmget() failing with a return value of -1, not with SIGSYS, to fallback
to using an image in unshared memory.
Patch attached.
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
---
origsrc/qtbase-opensource-src-5.3.2/src/plugins/platforms/xcb/qxcbbackingstore.cpp
2014-09-11 11:48:06.0 +0100
+++
src/qtbase-opensource-src-5.3.2/src/plugins/platforms/xcb/qxcbbackingstore.cpp
2015-02-13 17:30:11.410525500 +
@@ -75,6 +75,7 @@ public:
private:
void destroy();
+static bool isShmSupported();
xcb_shm_segment_info_t m_shm_info;
@@ -88,6 +89,44 @@ private:
QRegion m_dirty;
};
+static bool shmNotSupported = false;
+
+static void
+SigSysHandler(int signo)
+{
+shmNotSupported = true;
+}
+
+bool
+QXcbShmImage::isShmSupported()
+{
+static bool checked = false;
+if (!checked)
+ {
+void (*oldHandler)(int);
+int shmid = -1;
+
+/* If no SHM support in the kernel, the bad syscall will generate
SIGSYS */
+oldHandler = signal(SIGSYS, SigSysHandler);
+
+shmNotSupported = false;
+shmid = shmget(IPC_PRIVATE, 4096, IPC_CREAT);
+if (shmid != -1)
+ {
+/* Successful allocation - clean up */
+shmctl(shmid, IPC_RMID, NULL);
+ }
+else
+ {
+/* Allocation failed */
+shmNotSupported = true;
+ }
+signal(SIGSYS, oldHandler);
+checked = true;
+ }
+return (!shmNotSupported);
+}
+
QXcbShmImage::QXcbShmImage(QXcbScreen *screen, const QSize size, uint depth,
QImage::Format format)
: QXcbObject(screen-connection())
, m_gc(0)
@@ -116,7 +155,9 @@ QXcbShmImage::QXcbShmImage(QXcbScreen *s
if (!segmentSize)
return;
-int id = shmget(IPC_PRIVATE, segmentSize, IPC_CREAT | 0600);
+int id = -1;
+if (isShmSupported())
+ id = shmget(IPC_PRIVATE, segmentSize, IPC_CREAT | 0600);
if (id == -1)
qWarning(QXcbShmImage: shmget() failed (%d) for size %d (%dx%d),
errno, segmentSize, size.width(), size.height());
@@ -130,7 +171,7 @@ QXcbShmImage::QXcbShmImage(QXcbScreen *s
xcb_generic_error_t *error = NULL;
if (shm_present)
error = xcb_request_check(xcb_connection(),
xcb_shm_attach_checked(xcb_connection(), m_shm_info.shmseg, m_shm_info.shmid,
false));
-if (!shm_present || error) {
+if (!shm_present || error || (id == -1)) {
free(error);
shmdt(m_shm_info.shmaddr);
--
Unsubscribe info: http://cygwin.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.17.0-1 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.17.0-1 These packages contain XWin and the other X.Org X11 servers. This is the first release of the xserver 1.17 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.16, 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.16.3-1. NOTE: In X server 1.17, the creation of indirect GLX contexts is prohibited by default. The +iglx option is required to allow them. See [2] for more information on possible OpenGL configurations. x86: 3d31835b8e16c1ddbb402d5cc148c4f4 *xorg-server-1.17.0-1-src.tar.xz ce21cc0d9344eff10901d14071f6c6fa *xorg-server-1.17.0-1.tar.xz 83ea29033776ced106ad1d29350b08c8 *xorg-server-common-1.17.0-1.tar.xz d6f4c8e27e9a6d6fec18cb5f8e4af14a *xorg-server-debuginfo-1.17.0-1.tar.xz 8595b34461e7cbea33eb64fa88127e77 *xorg-server-devel-1.17.0-1.tar.xz ab8347dfed2be724c822c85e6712823e *xorg-server-dmx-1.17.0-1.tar.xz 4b239214006a5dc847ed57d869b0357b *xorg-server-extra-1.17.0-1.tar.xz e45d5f62b1b590d8bdb415f48081b3ff *xwinclip-1.17.0-1.tar.xz x86_64: 31a1897cda743879ce8c0ebab81b3fb8 *xorg-server-1.17.0-1-src.tar.xz 23c938c70dd336be76114e844947d6c0 *xorg-server-1.17.0-1.tar.xz 2a86b5a3bfbe3ec3fbc202f192451ad9 *xorg-server-common-1.17.0-1.tar.xz b5df0df74f07abe309573a205e11d8ea *xorg-server-debuginfo-1.17.0-1.tar.xz d8ea688910301bc5be52ce00a93892f2 *xorg-server-devel-1.17.0-1.tar.xz 25986a590b8e3d63f1e80df168db4417 *xorg-server-dmx-1.17.0-1.tar.xz be04df320dc18f9f8958a062ab0f6cf8 *xorg-server-extra-1.17.0-1.tar.xz 4a9f0cd094f36778f747a5e9092fa316 *xwinclip-1.17.0-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2015-February/002529.html [2] http://x.cygwin.com/docs/ug/using-aiglx.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: Cannot run Qt5 applications.
On 04/02/2015 23:20, David Stacey wrote: I'm having difficulty running any Qt5 application. These are the commands I'm issuing: XWin -multiwindow export DISPLAY=:0.0 xclock and I see the clock, so X is up and running. Then: /usr/lib/qt5/examples/gui/analogclock/analogclock QXcbConnection: XCB error: 145 (Unknown), sequence: 162, resource id: 0, major c ode: 140 (Unknown), minor code: 20 Bad system call (core dumped) Possibly you need to install and start cygserver (See [1]) If so, this is because Qt5 is assuming shared memory is available, which could possibly be handled in a better way... [1] http://x.cygwin.com/docs/ug/using-shared-memory.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: Cygwin/X XDMCP Issue
On 22/01/2015 07:46, Maarten Hoes wrote: Well I changed from GDM to KDM, and now everything is working as expected. Just one last question: are there any known issues with XDMCP and Gnome GDM ? Or is that combination supposed to just work ? Yes, XDMCP is supposed to work with GDM. No, there are no known issues, but we don't know about issues until someone reports them. :) If you can provide the details of the linux distribution and release you are using on your remote host, I can see if I can try to reproduce the 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: 64-bit xfree86 failing?
On 04/12/2014 02:53, l.w...@surrey.ac.uk wrote: working again. my mistake was in years of using startx -- -multiwindow -clipboard because /usr/bin/startx no longer starts x I'm kind of surprised this used to work at all, since this is requesting both the internal multiwindow mode window manager, and whatever default window manager xinitrc decides to run. Sorry about breaking that. If you want a multiwindow mode session, the documented way to start it would be using startxwin, or the Start Menu link we provide to run that (See [1]) -clipboard has been the default for a number of years now, you don't need to explicitly provide it. Once I switched to xinit -- -multiwindow -clipboard I was fine. Remember that startx doesn't startx, on either 32- or 64-bit cygwin (I did a fresh 32-bit install and checked) and you're good to go. I think that you will find that running 'startx' without options does work. While I'm sure sarcasm is very relieving for you, please don't use it here. [1] http://x.cygwin.com/docs/ug/using.html#using-starting-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: build error on 1.16.2-1
On 05/12/2014 14:19, Jon TURNEY wrote: On 01/12/2014 23:37, J. Offerman wrote: This is an obvious source-header discrepancy. The source file(auto-generated anyway) doesn't seem to be changed recently, while the header file(glext.h) has a timestamp of Nov 16 now. So it looks like only the header file got advanced here. Looking at the announcements, it should be the Mesa update on Nov 17 that renewed it. Should I just add the extra arguments for those 3 funcs in the source file as defined in the new header file? That looks like working. Thanks for drawing this to my attention. Yes, it seems that the the glext.h header file (which comes from Khronos via the w32api-headers package) now has the fix (svn r27313) to add the extra argument to the prototype, but the XML used for the generated code (which comes from Khronos via the khronos-opengl-registry package) is only on svn r27116. I'm afraid you'll have to fix this manually until I generate a new khronos-opengl-registry package This build issue should be resolved with khronos-opengl-registry 20141230_svn27684-1 and xorg-server 1.16.3-1 -- 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: Saved Xlaunch 'config.xlaunch' issue
On 22/01/2015 07:55, Maarten Hoes wrote: When I create and save a configuration with 'XLaunch', for example as 'config.xlaunch', I have the following behavior when double clicking the saved config file: It just launches XLaunch as if no configuration was saved at all. When I open up the saved configuration file in an text editor, all the right settings are there in the xml file. Is this expected behaviour, or am I running into a bug ? I'm expecting the saved configuration in the xml file to be used instead of having to fill it in again. Thanks for reporting this issue. It seems that this stopped working correctly a while ago due to some changes in run or cygwin argument parsing. I've uploaded an updated xlaunch-20150130-1 today which should fix this. -- 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-20150130-1
*** xlaunch-20150130-1 * Fix Open/Edit actions on .xlaunch files to use 'run --quote' * Workaround an issue with invalid binary being produced due to embedded manifest x86: ee9a6c1ed383eff1a476ca3748397bbd *xlaunch-20150130-1-src.tar.xz f17834c7968e1eec0ff056b88b3abc28 *xlaunch-20150130-1.tar.xz x86_64: 8a30e69ba76751e0f5b8d59dbf978ead *xlaunch-20150130-1-src.tar.xz b9e3390a9c075ebb5c29ac77bbf2707b *xlaunch-20150130-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/
[ANNOUNCEMENT] Updated: xorg-server-1.16.3-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.3-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], the following cygwin-specific changes have been made since 1.16.2-1: * Defend against and report crashes while checking Windows OpenGL capabilities at startup * Add a tentative entry for the Korean keyboard to the list of known keyboards (Thanks to Colin Harrison for the patch) * Typo fix in Fix a crash which could occur when a client exits without deleting it's GL contexts * Improve WGL thunks code generator to deal with Khronos OpenGL registry XML since svn r27498 * Enable GLX TLS * Remove the workaround for binutils bug #16807 x86: 2000b777841da8ddbbed3f6f2c162a59 *xorg-server-1.16.3-1-src.tar.xz d35d98ee574d31c3a0f1eb383cd311ca *xorg-server-1.16.3-1.tar.xz 8affa3343b245ca39ea5ad045c8b0e31 *xorg-server-common-1.16.3-1.tar.xz 437ec870e16be593eb439dd4bb4a7fde *xorg-server-debuginfo-1.16.3-1.tar.xz 32794401f82dab76451d9ff1ca0c57b8 *xorg-server-devel-1.16.3-1.tar.xz 1d7b2d9fdd0eb05f2df53210440ba6d1 *xorg-server-dmx-1.16.3-1.tar.xz 2607bda544ef688c55f62ea7d803f551 *xorg-server-extra-1.16.3-1.tar.xz 7c441cebf48a31e78475f4c8bd631ec9 *xwinclip-1.16.3-1.tar.xz x86_64: da45f5fefd155bb604747157bfc3be7a *xorg-server-1.16.3-1-src.tar.xz 95700ab99e07e7317cd435c9ddae4db2 *xorg-server-1.16.3-1.tar.xz a5ae0aeb3c58b32815c0b592a759a276 *xorg-server-common-1.16.3-1.tar.xz 0c86cff698c11c342a3a34302ecfe39d *xorg-server-debuginfo-1.16.3-1.tar.xz 3d9380e8b77e4642becc0dfcd641fcae *xorg-server-devel-1.16.3-1.tar.xz f9cb68a0f918a7e95958fb0fae75bbf1 *xorg-server-dmx-1.16.3-1.tar.xz 916bb76e182feb846a28c0a26077fc08 *xorg-server-extra-1.16.3-1.tar.xz bd8a9b7ef2a922df47fce2879085c23c *xwinclip-1.16.3-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2014-December/002506.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: remote xterm's can't open display after upgrade
On 11/12/2014 18:31, Don Webster wrote: I needed to upgrade gs to gs 9.15, so I ran setup yesterday. It wanted to update a whole bunch of stuff, including X. OK, fine, I hadn't updated cygwin in quite a while, and I had other stuff to do. After the upgrade, I can't display remote xterms. OK, my old X shortcut didn't work, but I found XWin Server and pinned it to my task bar. I launch that and I have the X server running, and a local xterm pops up. I ssh into my linux server, and run my xterm, and get can't open display. I did these steps. - turned off my Windows Firewall (I am on a safe, local network). - launched XWin Server. In the xterm that popped up: dcw@dcwdt02 ~ $ xhost + access control disabled, clients can connect from any host dcw@dcwdt02 ~ $ ssh centos6 Last login: Wed Dec 10 16:31:16 2014 from dcwdt02 centos6% setenv DISPLAY 10.11.22.33:0.0# I use tcsh centos6% xterm xterm Xt error: Can't open display: 10.11.22.33:0.0 centos6% Is there something obvious? https://cygwin.com/ml/cygwin-xfree/2014-11/msg00029.html The relevant part is startx and startxwin now pass '-nolisten tcp' to the server by default, which increases security in the X server by not opening a port to TCP connections. The '-listen' flag can be passed as a server argument to override this. Your choices are to add the '-listen' flag to the startxwin invocation, or (better) to use 'ssh -Y' and not explicitly set DISPLAY (See http://x.cygwin.com/docs/ug/using-remote-apps.html#using-remote-apps-ssh) -- 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: xinit-1.3.4-1 (Major overhaul of X session handling)
On 29/11/2014 20:19, Nem W Schlecht wrote: On Fri, Nov 28, 2014 at 8:46 PM, Marco Atzeri wrote: On 11/29/2014 3:05 AM, Nem W Schlecht wrote: * User-defined ~/.startxwinrc files must now be executable, the final command therein must be run in the foreground, and that command's exiting will end the X session, just like with startx and ~/.xinitrc or ~/.Xclients. In most UNIX systems, this last command would be the window manager. I'm not liking fbpanel (although I will give it a try) and I don't like using an XTerm as my last command, since I often close/reopen them all when making changes to my .bashrc/.bash_profile. Are there any suggestions from the list for some *other* program that won't use any resources that I can use as my final foreground command? I don't want it to do anything, just not let X11 exit. I just want X11 to *not* launch fbpanel and to *not* quit. For now, I've settled on just calling 'sleep' for 10 years. If you previously had an empty ~/.startxwinrc, I'd suggest putting 'sleep infinity' or even 'exec sleep infinity' into 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: Sunday's update broke startx - crash on clipboard (winCpliboardProc trapped WM_QUIT
On 02/12/2014 15:53, Gulliver Smith wrote: This has happened on two different computers in different locations, one with 32 bit and one with 64 bit cygwin. Latter cygcheck attached. xwin log attached. I guess you have an empty ~/.startxwinrc, the behaviour of which has unfortunately changed. See https://cygwin.com/ml/cygwin-xfree/2014-12/msg00012.html I can still run /usr/bin/X -multiwindow but I really like to have the clipboard. You should have clipboard integration with that command line, since it's on by default for the past few years :) -- 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: build error on 1.16.2-1
On 01/12/2014 23:37, J. Offerman wrote: This is an obvious source-header discrepancy. The source file(auto-generated anyway) doesn't seem to be changed recently, while the header file(glext.h) has a timestamp of Nov 16 now. So it looks like only the header file got advanced here. Looking at the announcements, it should be the Mesa update on Nov 17 that renewed it. Should I just add the extra arguments for those 3 funcs in the source file as defined in the new header file? That looks like working. Thanks for drawing this to my attention. Yes, it seems that the the glext.h header file (which comes from Khronos via the w32api-headers package) now has the fix (svn r27313) to add the extra argument to the prototype, but the XML used for the generated code (which comes from Khronos via the khronos-opengl-registry package) is only on svn r27116. I'm afraid you'll have to fix this manually until I generate a new khronos-opengl-registry package Since keeping these things in sync is kind of a pain, and limits it to handling GL functions which are known about at build time, I'd like to replace this compile-time thunk generation with something which does it dynamically at run-time, but I haven't found the time to do 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: [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/
[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: 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/
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/
[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: 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-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: 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 Xm/Xm.h
#include GL/GLwDrawA.h
#include stdio.h
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 Xm/Xm.h
#include stdio.h
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/
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: 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/
[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: 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/
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: 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: 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: [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/
[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: 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 X11/Xwindows.h
#include X11/Xcursor/Xcursor.h
int main()
{
Display *dpy = XOpenDisplay(NULL);
int c = XcursorGetDefaultSize(dpy);
printf(XcursorGetDefaultSize = %d\n, c);
printf(GetSystemMetrics(SM_CXCURSOR) = %d\n,
GetSystemMetrics(SM_CXCURSOR));
printf(GetSystemMetrics(SM_CYCURSOR) = %d\n,
GetSystemMetrics(SM_CYCURSOR));
}
$ gcc cursor.c -o cursor -lXcursor -lX11
$ ./cursor
XcursorGetDefaultSize = 22
GetSystemMetrics(SM_CXCURSOR) = 32
GetSystemMetrics(SM_CYCURSOR) = 32
[1] http://cgit.freedesktop.org/xorg/lib/libXcursor/tree/src/display.c#n168
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: xinit hangs on XWin infinite loop when using -displayfd
On 29/07/2014 00:57, Matt D. wrote: Doh! I was so blind! Windows XP does not have an IPv6 protocol installed by default. I added it and the problem went away. This sounds like a bug. XWin should verify whether a device which supports the target protocol exists before attempting to open a socket on it. Yes, it shouldn't fail like this if IPv6 isn't installed I suspect the same problem will occur if you use X -displayfd built with IPv6 on linux kernel without IPv6 support What is this used for? Sharing a local X session with someone else? Logging onto an existing X session at work from home? I've only ever used X locally or through ssh forwarding. It's used to allow remote X clients to connect to an X server without using a ssh tunnel (e.g. [1]) [1] http://x.cygwin.com/docs/ug/using-remote-apps.html#using-remote-apps-telnet -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
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: 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: 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: XWin ignores all parameters related to multiple monitors
On 09/05/2014 21:25, Lukas Haase wrote: On 2014-05-09 3:15, Jon TURNEY wrote: On 09/05/2014 00:27, Lukas Haase wrote: On 2014-05-08 5:15, Jon TURNEY wrote: I've built a snapshot [1], which adds a heuristic which ignores a 'program specified location' hint if the location is the origin, which you might like to try and see if that fixes your problem, but I'm not sure if that is the correct solution. I have just the issue that the exe does not seem to work for me. Is there anything special I need to consider? Sorry, my snapshot building script went wrong and the snapshot was broken. Try this one instead. ftp://cygwin.com/pub/cygwinx/x86/XWin.20140509-git-c4a16a6606868d3e.exe.bz2 Can't believe it, great! Works exactly as it should (just with the standard configuration, X :0 -multiwindow)!! Now I just hope that this 'patch' somehow finds its way into the trunk ;-) This fix is included is 1.15.1-3. On reflection, I think a better approach would be to look at _NET_WM_WINDOW_TYPE and if it's _NET_WM_TYPE_NORMAL or absent, ignore PPosition and place the window as we like, but that is not quite as straightforward to implement. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: compiling xwin 1.15.1-2
On 12/06/2014 23:54, Jon TURNEY wrote: On 12/06/2014 22:49, J. Offerman wrote: Can you help me resolve this compile error that I'm seeing now? Thanks. Please use the mailing list for these kinds of questions. === In file included from /usr/src/xorg-server-1.15.1-2/src/xserver-cygwin-1.15.1-2/hw/xwin/glx/glthunk.c:87:0: ./generated_gl_thunks.c: In function 'glTexturePageCommitmentEXTWrapper': ./generated_gl_thunks.c:10560:3: error: too many arguments to function 'proc' RESOLVED_PROC(PFNGLTEXTUREPAGECOMMITMENTEXTPROC)( texture_, target_, level_, xoffset_, yoffset_, zoffset_, width_, height_, depth_, resident_ ); Thanks for drawing this to my attention. This fails because the description of glTexturePageCommitmentEXT() in /usr/share/opengl/api/gl.xml from (khronos-opengl-registry) needs to match it's prototype in /usr/include/w32api/GL/glext.h (from w32api-headers) There was an upstream bug where an extra 'target' parameter was erroneously added. The latest w32api-headers have updated GL headers that have that fixed, but it seems I haven't updated khronos-opengl-registry Until I make an updated package, you'll have to fix gl.xml yourself, like this: --- gl.xml~ 2013-08-08 18:07:23.0 +0100 +++ gl.xml 2014-05-02 17:35:52.000120700 +0100 @@ -22968,7 +22968,6 @@ command protovoid nameglTexturePageCommitmentEXT/name/proto paramptypeGLuint/ptype nametexture/name/param -paramptypeGLenum/ptype nametarget/name/param paramptypeGLint/ptype namelevel/name/param paramptypeGLint/ptype namexoffset/name/param paramptypeGLint/ptype nameyoffset/name/param I've uploaded an updated khronos-opengl-registry-20140619_svn27116-1 package, which includes this fix. Due to other changes it includes, an additional change is needed to compile xorg-server with it, which is included in 1.15.1-3. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 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: compiling xwin 1.15.1-2
On 12/06/2014 22:49, J. Offerman wrote: Can you help me resolve this compile error that I'm seeing now? Thanks. Please use the mailing list for these kinds of questions. === In file included from /usr/src/xorg-server-1.15.1-2/src/xserver-cygwin-1.15.1-2/hw/xwin/glx/glthunk.c:87:0: ./generated_gl_thunks.c: In function 'glTexturePageCommitmentEXTWrapper': ./generated_gl_thunks.c:10560:3: error: too many arguments to function 'proc' RESOLVED_PROC(PFNGLTEXTUREPAGECOMMITMENTEXTPROC)( texture_, target_, level_, xoffset_, yoffset_, zoffset_, width_, height_, depth_, resident_ ); Thanks for drawing this to my attention. This fails because the description of glTexturePageCommitmentEXT() in /usr/share/opengl/api/gl.xml from (khronos-opengl-registry) needs to match it's prototype in /usr/include/w32api/GL/glext.h (from w32api-headers) There was an upstream bug where an extra 'target' parameter was erroneously added. The latest w32api-headers have updated GL headers that have that fixed, but it seems I haven't updated khronos-opengl-registry Until I make an updated package, you'll have to fix gl.xml yourself, like this: --- gl.xml~ 2013-08-08 18:07:23.0 +0100 +++ gl.xml 2014-05-02 17:35:52.000120700 +0100 @@ -22968,7 +22968,6 @@ command protovoid nameglTexturePageCommitmentEXT/name/proto paramptypeGLuint/ptype nametexture/name/param -paramptypeGLenum/ptype nametarget/name/param paramptypeGLint/ptype namelevel/name/param paramptypeGLint/ptype namexoffset/name/param paramptypeGLint/ptype nameyoffset/name/param -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[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: 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/
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: 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: 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: xterm crashing when trying to access Ctrl-mouse click 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-mouse button 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 0x4 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: 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/
