Re: xwinclip dies with select failure
I don't know how many people use the -nolisten tcp option with XWin for security. I do and have found that the option conflicts with the -clipboard option as well as the -T option for xterm. This may be something only on my wish list, but is there any possibility of resolving this incompatibility issue, especially since there may not be further updates to the standalone xwinclip program? Raymond Harold Hunt wrote: Jeff, Most people are using the -clipboard command-line parameter for XWin.exe now... which provides the functionality of xwinclip.exe running in a seperate thread in XWin.exe. I don't know that I will ever make any new releases of the stand-alone xwinclip.exe. Thanks for the patch anyway, Harold
Re: Title changing is unimplemented in MultiWindow mode
I have found perhaps something interesting. 1. If I start the Xserver with start XWin-4.2.0-20 -multiwindow -nolisten tcp I can change the xterm window title using -T option on the command line. 2. If I start the Xserver with start XWin-4.2.0-28 -multiwindow again I can change the xterm window title using -T option. However, 3. If I start the Xserver with start XWin-4.2.0-28 -multiwindow -nolisten tcp then I cannot change the xterm window title using -T option. It will always remain "Cygwin/XFree86 X rl" Any explanations? Raymond Harold Hunt wrote: There seems to be some questions about why the title on the Windows-window does not change when running with "-multiwindow". The answer is simply this: title changes are a feature of X Window Managers that the MultiWindow Window Manager does not yet implement. Would it be easy to implement this feature? Probably. Any volunteers? Harold
Re: two new -multiwindow bugs
As I said in my earlier post, with XWin-4.2.0-20, xterm -T "my title" will set the xterm window title to "my title". With later versions, including XWin-4.2.0-28, xterm -T "any string" always produces the following window title: Cygwin/XFree86 X rl The title on the root window entry at the bottom shows "Cygwin/XFree86 rl". Is this situation peculiar to me, or do others get these titles as well? Raymond Kensuke Matsuzaki wrote: XWin set window title when that window is shown, and never update. So -T option works, PROMPT_COMMAND doesn't work. Kensuke Matsuzaki
Re: two new -multiwindow bugs
I have also experience the repeated keystroke bug.
As for the window title bug, it was possible to give a new xterm a
different title under XWin-4.2.0-20. If you run xterm -T "my title" -e
bash, the xterm will have "my title" as the title. Versions after
XWin-4.2.0-20 don't seem to allow this anymore.
Raymond
Jack Tanner wrote:
(By "new", I mean not discussed here before, not "new" as in only present
in the most recent release.)
Thank you for your time and effort, Kensuke, Harold, et. al.
I have two monitors, monitor 2 is physically left of monitor 1.
XFree86-xserv 4.2.0-28.
0) the repeated keystrokes bug is still present in this release
http://www.cygwin.com/ml/cygwin-xfree/2003-03/msg00059.html
1) window positioning bug
# Xwin -rootless -multiplemonitors -clipboard
# xterm -geometry +34+5
The xterm is positioned in the upper left-hand corner of monitor 2.
# Xwin -multiwindow -multiplemonitors -clipboard
# xterm -geometry +34+5
The xterm is positioned in the upper left-hand corner of monitor 1.
Presumably, the xterm should get positioned on the same monitor regardless
whether I use -rootless or -multiwindow.
2) window title bug
# Xwin -rootless -multiplemonitors -clipboard
# xterm -geometry +34+5
# TERM=xterm; export TERM
# xterm -e bash -i -c "ssh -X user at remote"
The xterm window gets a title like "user at remote:~". This is very pretty
and very useful when you open a gazillion xterms, like I do. (The remote
machine has an /etc/bashrc that sets up $PROMPT_COMMAND appropriately. For
my stock RedHat 8 install, it's PROMPT_COMMAND='echo -ne "\033]0;${USER} at
${HOSTNAME%% dot *}:${PWD/#$HOME/~}\007"'.)
# Xwin -multiwindow -multiplemonitors -clipboard
[snip. same xterm, TERM and ssh setup as above, but note -multiwindow, not
-rootless Xwin invocation]
The xterm window gets the title "bash". Awful, boring title.
Best,
JT
Re: Test server 79 and JSPager
I echo the sentiment expressed by Ed. I reported also the problems that Ed referred to, especially when I was using the virtual desktop programs virtuawin and deskwin. The only virtual desktop program that I have used that did not exhibit the automatic focus switching phenomenon is multidesk. With Server Test79, all of these problems are gone. Many thanks to all the XWin developers, especially Kensuke and Harold. Raymond Kwong >To All Whom It May Concern: >The fixes that Kensuke put into Test Server 79 have fixed ongoing errors >I've had with running xfree86 in multiwindow mode under virtual >dekstop/pagers such as Nvidia's Nview and JSPager. These symptoms included >but were not limited to parts of xterms not refreshing properly, programs >not refreshing properly when the window was resized, the dreaded automatic >focus switching phenomenon, etc. >Thanks again, Harold, Kensuke. This program is muy excellente. >-ed
Re: Some undesirable behaviour in Test 77
Yadin, No, I am not running any X window manager with the problems encountered. I emailed Harold my startup script file earlier. The peculiar thing is that Xwin-4.2.0-20 (pre -clipboard release) does not suffer from these problems when I run it in multiwindow mode. It seems to me that this perhaps has to do with how the clipboard code affects the multiwindow mode. I want to mention also that with XWin-4.2.0-25, sometimes I would not get the overlapping xterm transparency right away, but after virtual desktop switching, it will invariably come on. Raymond
Re Some undesirable behaviour in Test 77
Harold: I downloaded XWin-4.2.0-21, and ran only XWin -multiwindow. The same 2 problems arose. I notice that the size of XWin-4.2.0-20 is significantly larger than XWin-4.2.0-21. Was some code removed? Raymond
Some undesirable behaviour in Test77
Harold: The latest X server, Test 77, does not crash with -multiwindow -clipboard for me also. Thanks for the good work. There is, however, some undesirable behaviour with Test 77, which is not present in XWin-4.2.0-20. 1. I use the virtual desktop virtuawin. When I switch from another desktop to the one containing the xterms, I get incessant switching between xterms if there is more than one. This behaviour was reported by others, I think. 2. I have 2 xterms, one partially covering the other. If I click the one underneath to bring it to the front, the overlap area comes up only in outline. I can still see the material in the other xterm underneath. It is as if the xterm brought up is transparent on the overlap area! These 2 problems are not observed with XWin-4.2.0-20. Let me know what details you need to know in connection with these two problems. Because of them, I normally still use XWin-4.2.0-20, manually starting xwinclip if necessary. Although I am not 100% sure, but I think every X server later than XWin-4.2.0-20 that I tried exhibits similar problems. Raymond
RE XWin multiwindow clipboard
Harold: I guess curosity got me going to try your suggestions on my laptop. The bottom line is: the X server still crashed. I used Test 76 this time. The script is: ___ @echo off REM SET DISPLAY=:0.0 SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/XFree86, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=\cygwin SET PATH=%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%CYGWIN_ROOT%\usr\local\bin;%PATH% REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM Startup the X Server, the twm window manager, and an xterm. REM REM Notice that the window manager and the xterm will wait for REM the server to finish starting before trying to connect; the REM error "Cannot Open Display: 127.0.0.1:0.0" is not due to the REM clients attempting to connect before the server has started, rather REM that error is due to a bug in some versions of cygwin1.dll. Upgrade REM to the latest cygwin1.dll if you get the "Cannot Open Display" error. REM See the Cygwin/XFree86 FAQ for more information: REM http://xfree86.cygwin.com/docs/faq/ REM REM The error "Fatal server error: could not open default font 'fixed'" is REM caused by using a DOS mode mount for the mount that the Cygwin/XFree86 REM fonts are accessed through. See the Cygwin/XFree86 FAQ for more REM information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof REM if "%OS%" == "Windows_NT" goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP echo startxwin.bat - Starting on Windows NT/2000/XP :STARTUP REM REM Startup the programs REM REM Startup the X Server. start XWin -multiwindow -clipboard REM Startup an xterm, using bash as the shell. run xterm -sl 1024 -sb -font 9x15 -fg black -bg white -title xterm -e bash REM run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash REM Startup the twm window manager. REM run twm REM run openbox REM Set a background color. run xsetroot -solid aquamarine4 __ Here is the XWinrl.log file: _ ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Multi Window => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1024 h: 768 winCreateBoundingWindowWindowed - Current w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 740 1024 winAdjustForAutoHide - Adjusted WorkArea: 0 0 740 1024 winCreateBoundingWindowWindowed - WindowClient w 1024 h 740 r 1024 l 0 b 740 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1024 height: 740 depth: 16 winAllocateFBShadowGDI - Dibsection width: 1024 height: 740 depth: 16 size image: 1515520 winAllocateFBShadowGDI - Created shadow stride: 1024 winFinishScreenInitFB - Masks: f800 07e0 001f winInitVisualsShadowGDI - Masks f800 07e0 001f BPRGB 6 d 16 bpp 16 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. winFinishScreenInitFB - Calling winInitClipboard. winInitClipboard () winFinishScreenInitFB - returning winScre
RE Xwin multiwindow clipboard
Harold: While the script I sent contained -nolisten tcp, I had deleted it before and it did not make any difference: X still crashed. However, I have to say that I have had my DISPLAY variable set to :0.0 in place of 127.0.0.1:0.0 for quite some time. If that can cause a problem, I can test without -nolisten tcp and DISPLAY=127.0.0.1:0.0. I'll send you the log file. To be consistent, I'll have to test on the office machine, which is the one I have used earlier. Raymond
Re XWin multiwindow clipboard
Harold: I normally don't have xwinclip in my startup script. I just start it manually if I need it. In any case, here is the startup script, a straightforward modification of startxwin.bat: @echo off SET DISPLAY=:0.0 REM SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/XFree86, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=\cygwin SET PATH=%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%CYGWIN_ROOT%\usr\local\bin;%PATH% REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM Startup the X Server, the twm window manager, and an xterm. REM REM Notice that the window manager and the xterm will wait for REM the server to finish starting before trying to connect; the REM error "Cannot Open Display: 127.0.0.1:0.0" is not due to the REM clients attempting to connect before the server has started, rather REM that error is due to a bug in some versions of cygwin1.dll. Upgrade REM to the latest cygwin1.dll if you get the "Cannot Open Display" error. REM See the Cygwin/XFree86 FAQ for more information: REM http://xfree86.cygwin.com/docs/faq/ REM REM The error "Fatal server error: could not open default font 'fixed'" is REM caused by using a DOS mode mount for the mount that the Cygwin/XFree86 REM fonts are accessed through. See the Cygwin/XFree86 FAQ for more REM information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof REM if "%OS%" == "Windows_NT" goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP echo startxwin.bat - Starting on Windows NT/2000/XP :STARTUP REM REM Startup the programs REM REM Startup the X Server. REM start XWin -multiwindow -clipboard start XWin -multiwindow -nolisten tcp REM Startup an xterm, using bash as the shell. run xterm -sl 1024 -sb -font 9x15 -fg black -bg white REM run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash REM Startup the twm window manager. REM run twm REM run openbox REM Set a background color. run xsetroot -solid aquamarine4 By the way, I am using Windows 2000, cygwin 1.3.19-1. Raymond
XWin multiwindow clipboard
_ Finally, I include the XWinrl.log file with the XWin-4.2.0-20.exe server, using only the multiwindow option. The server started fine: ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Multi Window => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - Initial w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 735 991 winAdjustForAutoHide - Adjusted WorkArea: 0 0 735 991 winCreateBoundingWindowWindowed - WindowClient w 991 h 735 r 991 l 0 b 735 t 0 winCreateBoundingWindowWindowed - Returning winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winScreenInit - returning (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null)" DISPLAY=:0.0 _________ I hope these files may be of use to someone. I use both the rootless mode and the multiwindow mode everyday. Thanks for all the good work! Raymond Kwong
Re: SSH & XFree86
I have several setups of cygwin and XFree86. With the latest Cygwin 1.3.16-1, ssh 3.5p1-2 (or ssh 3.5p1-1), and XWin 4.2.0-16 (or 4.2.0-15), I am getting the same warning message as John: Warning: No xauth data; using fake authentication data for X11 forwarding. However, my X clients do work fine, and I haven't found any other problem. With Cygwin 1.3.15-2, ssh 3.5p1-1, and XWin 4.2.0-16, however, there is no such warning message. This seems to suggest there is some problem involving something other than just ssh and XFree86 which generates the warning message. When I ran ssh -v, I get with Cygwin 1.3.15-2, ssh 3.5p1-1, XWin 4.2.0-16, the following as part of the startup message debug1: Entering interactive session. debug1: ssh_session2_setup: id 0 debug1: channel request 0: pty-req debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: x11-req debug1: channel request 0: shell debug1: fd 4 setting TCP_NODELAY With Cygwin 1.3.16-1, ssh 3.5p1-2, XWin 4.2.0-16, the additional warning message appears just before the debug1: Requesting X11 forwarding with authentication spoofing message. I hope this may help in identifying the source of the warning message. Raymond Kwong
Difference between installing Xfree-4.2.0 using setup and install.sh
Thank you for shedding light on the question. The problem is indeed with the .Xauthority file. I created a .Xauthority file with my recent install using setup. I had tried doing the same earlier when I did the installation using install.sh, but it turned out that the .Xauthority file was never created. If I delete the .Xauthority file from my recent install, I am able to ssh to a remote host and display results, just as before. Now I decided to try xauth a bit further. I found interestingly that if I just ran the startx script from my linux box on cygwin Xfree-4.2.0, I could create succesfully a .Xauthority file, start the X server, and display results from a remote host via ssh, without adding xhost +localhost to my .xinitrc file. In other words, the same behaviour as starting the X server on linux is now obtained. I guess it works because mcookie is now part of cygutils. I hope my experience may be useful to others who want to set up the .Xauthority file. Raymond
Difference between installing Xfree-4.2.0 using setup and install.sh
I have previously installed Xfree 4.2.0 when it first came out on cygwin, using the old method of running install.sh. Everything worked fine. Recently, I installed Xfree 4.2.0 using setup.exe on another computer (both computers run Windows 2000). On the new computer, if I ssh to another computer using "ssh -X hostname", I get the following error message Xlib: connection to "localhost:10.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key Application initialization failed: couldn't connect to display "localhost:10.0" % This error does not occur with the older installation using install.sh. The cygwin1.dll version is the same, and the ssh version is the same. Fortunately, the error is readily eliminated by adding the line xhost +127.0.0.1 to .xinitrc. on the new computer. Then everything works fine. A similar difference can also be reproduced with 2 Windows 98 machines. Is there a reason for this apparent difference? Raymond Kwong
