Re: lesstif 0.93.94 and the attempt to add non-widget ... error
Done. 0.93.94-2 is now marked as curr. You know though... I thought I remember stumbling across another part of the lesstif lib that we forgot to add the dll-initialization patch too. I could be having a false memory here, but I think I remember seeing another such unpatched section and deciding to put off fixing it for a bit. Please be on the lookout for problems related to lesstif. Harold Volker Quetschke wrote: Hi Harold, I just posted lesstif-0.93.94-2 as a 'test' package. Please download it tomorrow and very that it works correctly. grace builds against it and works without the attempt to add non-widget ... error. Nedit also starts and behaves like an editor. If you get a chance, try it out with 'nedit'... if it works well with nedit then I might mark this as 'curr'. As I said two month ago, nedit and grace (and everything else) work well for me. Noone complained, can you mark it curr now? I'd like to release a grace-5.1.15 package. Thanks Volker
Moving
My wife and I just graduated with our final college degrees, her with her second bachelor's and I with my master's in computer science. We start moving from Michigan to California tomorrow and I will be losing my internet and computer access starting in about three hours. We will have internet access next week but it is unlikely that my computer will arrive for at least a week, so I will be unable to check email or perform any actions for the project for at least a week. I am starting my new job on May 24th and we are having a baby in July. As you can imagine, this means that I will be pretty busy. I am investigating handing the project over to Alexander Gottwald; this transition would likely occur about four weeks from now if it will occur at all. I just want to prep everyone for the idea that I might be moving on so that it does not come as a surprise if I do move on. That is it for now. I will probably be unsubscribed from the mailing list for the next week so that my mailbox does not overflow. Later, Harold
Re: Differnce between Xfree and Xorg
Thomas Dickey wrote: On Wed, 12 May 2004, Alexander Gottwald wrote: On Wed, 12 May 2004, aroushdi wrote: I am a little bit confused I see here that we have moved to Xorg distribution . I took a look at XFree.org and it seems they have Binaries for Cygwin till 4.4 . These binaries are likely to be very outdated. We moved to X.org because it was easier for Cygwin/X developers to get cvs access there. XFree only allowed cvs access for a few people from the core team. We had to ask them to include the changes into their cvs. As a result the XFree cvs was always a few weeks up to some months behind the Cygwin/X development. The cygwin part from XFree may now be about 7 or 8 months old. Many Before saying may be, it is proper to verify your statements. The 4.4 binaries are no older than the end of December. So they are old. Who cares? Harold
Re: Mouse/keyboard emulation
in the Xterm I opened an ssh session by typing ssh -l username remote server name and then entered the password when prompted You mentioned ssh, you probably need to see A1 in the following FAQ entry: http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding Harold
Re: XWin/Clipboard/Crash/Hang - Patch Take 2
Dan,
Thanks much for the patch. I'm glad Alexander committed it already.
I'll try to get a release out soon since I am moving on Friday and won't
have my computer for at least a week.
Thanks for contributing,
Harold
Wilks, Dan wrote:
Harold L Hunt II wrote:
I'm including the small fix from winclipboardwndproc.c in the next
release, but the changes to the debug messages should probably be
done using the newer logging functions that accept a log level and
verb.
I think the small fix got lost. At least I couldn't find it in
the clipboard window proc. No worries it gave me time to look into
the problem some more.
This patch should solve XWin crashing (silently quitting) while
copying or pasting after using another Windows application which
utilizes the clipboard chain. Remote desktop is one such application.
If further crashes occur using XWin -logverbose 3 will be able to generate
hopefully useful information from the clipboard.
ChangeLog:
* winclipboard.h: Add extern prototypes for winDebug, winErrorFVerb
copied from winmsg.h.
* winclipboardinit.c (winFixClipboardChain): Post rather than send the
reinit message to the clipboard window. Sending the message caused,
or possibly just exacerbated an existing, race condition that would
cause the X server to hang when coming back from a remote desktop
session.
* winclipboardwndproc.c (winProcessXEventsTimeout): switch to new
logging api's.
(winClipboardWindowProc): switch to new logging api's. Add some
additional debug logging. Make best effort to prevent our window
appearing twice in the clipboard chain. Also detect loops when they
occur and try to behave in a reasonable way.
Patch:
Index: winclipboard.h
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xwin/winclipboard.h,v
retrieving revision 1.1.4.1.2.14
diff -u -p -r1.1.4.1.2.14 winclipboard.h
--- winclipboard.h 23 Apr 2004 18:17:29 - 1.1.4.1.2.14
+++ winclipboard.h 7 May 2004 15:32:27 -
@@ -84,6 +84,8 @@
extern char *display;
extern void ErrorF (const char* /*f*/, ...);
+extern void winDebug (const char *format, ...);
+extern void winErrorFVerb (int verb, const char *format, ...);
/*
Index: winclipboardinit.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xwin/winclipboardinit.c,v
retrieving revision 1.1.4.1.2.8
diff -u -p -r1.1.4.1.2.8 winclipboardinit.c
--- winclipboardinit.c 23 Apr 2004 18:17:29 - 1.1.4.1.2.8
+++ winclipboardinit.c 7 May 2004 15:32:27 -
@@ -135,6 +135,6 @@ winFixClipboardChain (void)
if (g_fClipboard
g_hwndClipboard)
{
- SendMessage (g_hwndClipboard, WM_WM_REINIT, 0, 0);
+ PostMessage (g_hwndClipboard, WM_WM_REINIT, 0, 0);
}
}
Index: winclipboardwndproc.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xwin/winclipboardwndproc.c,v
retrieving revision 1.1.4.1.2.20
diff -u -p -r1.1.4.1.2.20 winclipboardwndproc.c
--- winclipboardwndproc.c 26 Apr 2004 19:53:49 - 1.1.4.1.2.20
+++ winclipboardwndproc.c 7 May 2004 15:32:27 -
@@ -102,8 +102,8 @@ winProcessXEventsTimeout (HWND hwnd, int
tv); /* No timeout */
if (iReturn = 0)
{
- ErrorF (winProcessXEventsTimeout - Call to select () failed: %d.
- Bailing.\n, iReturn);
+ winErrorFVerb (1, winProcessXEventsTimeout - Call to select ()
+ failed: %d. Bailing.\n, iReturn);
break;
}
@@ -145,9 +145,7 @@ winClipboardWindowProc (HWND hwnd, UINT
{
case WM_DESTROY:
{
-#if 0
- ErrorF (winClipboardWindowProc - WM_DESTROY\n);
-#endif
+ winDebug (winClipboardWindowProc - WM_DESTROY\n);
/* Remove ourselves from the clipboard chain */
ChangeClipboardChain (hwnd, s_hwndNextViewer);
@@ -161,24 +159,61 @@ winClipboardWindowProc (HWND hwnd, UINT
case WM_CREATE:
{
-#if 0
- ErrorF (winClipboardWindowProc - WM_CREATE\n);
-#endif
+ winDebug (winClipboardWindowProc - WM_CREATE\n);
/* Add ourselves to the clipboard viewer chain */
s_hwndNextViewer = SetClipboardViewer (hwnd);
+ if (s_hwndNextViewer == hwnd)
+ {
+ s_hwndNextViewer = NULL;
+ winErrorFVerb (1, winClipboardWindowProc - WM_CREATE:
+ attempted to set next window to ourselves.);
+ }
}
return 0;
case WM_CHANGECBCHAIN:
{
+ static Bool s_fProcessingChangeCBChain = FALSE;
+ winDebug (winClipboardWindowProc - WM_CHANGECBCHAIN: wParam(%x)
+ lParam(%x) s_hwndNextViewer(%x)\n,
+ wParam, lParam, s_hwndNextViewer);
+
+
+ /*
+ * We've occasionally seen a loop in the clipboard chain. Break
+ * it on the first hint of recursion.
+ */
+ if (! s_fProcessingChangeCBChain)
+ {
+ s_fProcessingChangeCBChain = TRUE;
+ }
+ else
+ {
+ winErrorFVerb (1, winClipboardWindowProc - WM_CHANGECBCHAIN -
+ Nested calls detected. Bailing.\n);
+ winDebug (winClipboardWindowProc - WM_CHANGECBCHAIN: Exit\n
Re: Remote X clients (xterm, nedit, ...) dying
Mark, Halpaap, Mark wrote: anyone any idea? Yes, this is a common issue that is very easy to work around and has an entry in the FAQ: http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding Harold
Re: basic imake problem on cygwin
Steve, Steve Kelem wrote: There seems to be a disconnect in the generated Makefile on cygwin. I searched the mailing list archives, but wasn't able to find anything relevant. With the following Imakefile, my AllTarget is hello, as the Imakefile is supposed to be portable, and not know about cygwin's .exe extension for the compiled binary. You need to use the ProgramTargetName macro in your AllTarget: AllTarget(ProgramTargetName(hello)) On non-Cygwin platforms this turns into: all:: hello On Cygwin this turns into: all:: hello.exe Hope that helps, Harold
Re: -mwextwm works but -multiwindow does not
Bob, Bob White wrote: I am running the latest version of Cygwin/X on a Windows 2000 machine. I launch it from a cygwin shell as follows: export DISPLAY=:4 Xwin :4 -multiwindow I then ssh to my remote linux box and launch kde. I find that this gives a multitude of errors such as: MIT-SHM extension disabled due to lack of kernel support and X Error: BadWindow (invalid Window parameter) 3 Then, when I try to open almost any kde application, the app fails to appear (almost always) and gives the following error: KLauncher could not be reached via DCOP. But when I use the -mwextwm switch instead of -multiwindow... no problems. No, you are not supposed to be using -mwextwm nor -multiwindow. Both of these parameters are intended to be used with a Windows-based window manager; -multiwindow starts this window manager automatically while -mwextwm relies on you to manually launch xwinwm (available in the xwinwm package for Cygwin) and since you are probably not launching xwinwm you are not having problems with trying to run two window managers in that case. You need to be using either -rootless or -nodecoration (try each and decide which you like). You may also be having a little trouble if you are using Cygwin's OpenSSH with ssh -X, in that case you need to switch to ssh -Y. More information on that here (see A1): http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding Harold
Re: RemoteDesktop/Clipboard Crash Patch
Dan, I'm including the small fix from winclipboardwndproc.c in the next release, but the changes to the debug messages should probably be done using the newer logging functions that accept a log level and verb. Maybe Alexander could comment on how this should be used. Thanks for the patch, Harold
Re: cygGNOME2
Christopher Faylor wrote: On Fri, Apr 30, 2004 at 04:22:42PM +0200, Alessandro Lendaro wrote: I can't make GNOME2 work on cygwin. I installed the packages found at cygnom2.sourceforge.net/install but I don't knowh which commands must be issued to start a GNOME2 session. When I try to launch apps like Gaim or Bluefish I get a win32 error saying the app is unable to locate the cygfontconfig-1.dll which is not installed in my cygwin folder. Is somebody able to give me a clue? Why are you asking about this here rather than using the resources at the web site where you downloaded the package? I agree, this new logic defies me. Tell me again how sheeps' bladders can be used to prevent earthquakes... :) Harold
Re: cygGNOME2
Christopher Faylor wrote: On Fri, Apr 30, 2004 at 09:36:01PM -0400, Harold L Hunt II wrote: Christopher Faylor wrote: On Fri, Apr 30, 2004 at 04:22:42PM +0200, Alessandro Lendaro wrote: I can't make GNOME2 work on cygwin. I installed the packages found at cygnom2.sourceforge.net/install but I don't knowh which commands must be issued to start a GNOME2 session. When I try to launch apps like Gaim or Bluefish I get a win32 error saying the app is unable to locate the cygfontconfig-1.dll which is not installed in my cygwin folder. Is somebody able to give me a clue? Why are you asking about this here rather than using the resources at the web site where you downloaded the package? I agree, this new logic defies me. Tell me again how sheeps' bladders can be used to prevent earthquakes... :) See: http://sheepsbladdr.com/problems.html . Damn, I actually went to that thinking it would be some sort of Monty Python fan site. Bummer it was a sham URL :) Harold
Re: 'GLX missing on display' Problems
http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding Brian Ford wrote: Wrong list: http://cygwin.com/lists.html This is a Cygwin/X specific question. Redirecting... On Wed, 28 Apr 2004, eti1 wrote: I use cygwin from home (on a Windows box) to ssh into my machine at work (Linux box). I get the following error when I try to run programs that use opengl libs for displaying: [EMAIL PROTECTED] cubit90]$ glxgears Xlib: extension GLX missing on display localhost:10.0. Error: couldn't get an RGB, Double-buffered visual When I ssh, I use the -X option so that graphics get forwarded to my local machine. I am aware that this error is usually manifested because opengl libs are not installed on the local machine, but I know I have them on my local machine because if I go a 'glxgears' before ssh-ing the gears graphics window displays just fine. It appears that after ssh-ing into my work machine, display information is lost. What is very troubling with this problem is that sometimes the problem altogether disappears. For example, if I ssh into my work machine and let the terminal sit for a while, it sometimes works, sometimes not. Other times after ssh-ing in, if I edit a file with vim I can run glxgears after, but not always. Nothing is reproducable to get it to work. But once it starts displaying, it usually doesn't stop. I tried a complete uninstall/reinstall of cygwin but it didn't do anything. Help! --Corey Please also see: Problem reports: http://cygwin.com/problems.html We need more information to help you.
Re: Color support added to HW accelerated cursor
Alexander Gottwald wrote: On Sun, 25 Apr 2004, Earle F. Philhower III wrote: My CVS commit emails are in limbo, Are you subscribe to xorg-commit or xorg-commit-diffs? The script which generates messages for xorg-commit-diffs was disabled since it does not work stable. But xorg-commit has all your commit logs. For generating the diffs, Egbert Eich has created a script which fetches the cvs diff for all files in the logmessage. Yeah, he is subscribed just like you and I are subscribed. The options on his account are identical to ours. In fact, maybe it is a problem that his [EMAIL PROTECTED] account is subscribed because every account that is subscribed is marked for moderation, yet your posts and my posts go right through. The only current difference I can see is that neither of us have our [EMAIL PROTECTED] accounts subscribed while Earle does. Maybe we should try deleting the [EMAIL PROTECTED] account subscription and see if that lets his posts go through immediately. Harold
Re: need help - X11/Xlib.h
xorg-x11-devel Sergiy Zuban wrote: Hello there, I'll be appreciate if you help me: What cygwin package I should install to get X11/Xlib.h installed (i can't find it now)?? Thanks. Best regards, Sergiy Zuban
Re: Icons in 6.7-6
Earle F. Philhower III wrote: PNG icon support would be neat and easy too, but it doesn't look like libpng is standard in the X tree and I wouldn't want to add dependencies... I'd say go for it, as long as we can turn it on or off with a flag in cygwin.cf... so just #ifdef everything so that we can compile without PNG support. Harold
Re: Small tweak to HW accelerated cursor committed
Okay, just released that tweak as xorg-x11-xwin-6.7-6. Thanks, Harold Earle F. Philhower III wrote: As usual my CVS commit emails are in limbo, but just a heads up that I've checked in a small change to the HW accelerated cursor routines. Before it would set the cursor no matter where the mouse was, even in the title bar. (Drag an xterm in multiwindow mode quickly and see the Windows cursor change to the X root cursor or the insertion bar depending on where you're dragging over on the X hidden root window...it's a race condition so sometimes it will show, sometimes not.) The new changes check to see if the current cursor position is outside of a window's client rect, and if so then it creates the cursor (for later WM_SETCURSOR events) but does not SetCursor() it. The WM_SETCURSOR handler will take care of it when the mouse moves back into the client region. It's also possible to create color Win32 cursors dynamically, not just black and white ones, through the use of CreateIcon (really!). I don't have any way of testing this at all so I haven't done any work on it. Are there any apps that compile under cygwin that set the X11 cursor color? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: numlock
JS, J S wrote: Harold, This is simply a bug report. The FACT is that if you start XFree with the numlock key on, the keyboard doesn't work properly. There have been plenty of other posts about this in the past so I'm not the first to report this. Even if you don't care about it, and it doesn't affect you, I think you'll find a lot of users (who don't necessarily post here) have come across the numlock issue. I know my users have, and everyone agrees this is a BUG. I don't agree that it is a bug. I believe that this is simply the side effect of changes made to how numlock is handled in the X Window System; those changes were beyond our control and not all libraries and applications have been updated in the 5 or more years since those changes to handle numlock properly. Thus, anything that we do to turn numlock off will only be a partial work-around, not a bug fix. If it was a bug fix then it would apply all the time, but it can't be applied all the time because the majority of users that don't use LessTif or Motif applications will wonder why their numlock key keeps turning off. No one has asked you to do the work for this though - If I can, I'll provide the patch using Thomas' code, but as the one in charge of this project, you're the man who says whether such a patch goes into the build. I was just trying to get some involvement from you, maybe encouragement. Yeah you did ask me to do the work, you sent me a private message asking if I was interested. I'm not saying it wouldn't go in. I think it is farely obvious that it something doesn't change the default behavior then it goes in almost automatically. I say go for it. Now, you might still be wondering why I'm not interested. I'm not interested in writing it myself because I spent about five minutes thinking about it and came up with various questions about how this should behave when Cygwin/X loses or regains keyboard focus. I also don't particularly like changing the keyboard state. Then I started thinking that maybe a better way to do this would be to make a command-line parameter that causes numlock to not be specified as a mask key. I also figured that an even better way may be an option on the tray menu that lets you toggle a numlock-override during your session that just makes numlock look like it is off without actually changing the keyboard state. See what I mean about how I don't think this has been completely thought out? Somebody needs to make this one their own and it sounds like you are interested, so go for it. I personally liked the idea of adding a flag to the XWin command line e.g. Xwin -numlockoff but if you're saying this is a non-starter I won't bother. I never said it was a non-starter. I just said I'm not the man for the job because it sounded like you were asking me to write the code for you. Harold
xterm-186 build bustage
If anyone wants to help me with something, grab the xterm-186 original source (google for 'xterm', you'll find it), grab the -src package for our xterm-185 package, copy and rename xterm-185-*.sh to xterm-186-1.sh and try 'xterm-186-1.sh mkdirs xterm-186-1.sh conf xterm-186-1.sh'. You'll quickly note that 'X.Org Foundation' is somehow getting into CFLAGS as a raw string, causing gcc to bork. It seems that this may be somehow caused by macros in xterm's configure scripts that copy the CFLAGS set by the imake configuration files. I haven't got a heck of a lot of time to look into this, so I would appreciate it if anyone with a little understanding of auto* and shell scripts could take a peek at why xterm is failing to build under Cygwin/X at the moment. Harold
xorg-x11-xwin-6.7-5 is huge!
Check out all of those changes in xorg-x11-xwin-6.7-5! http://x.cygwin.com/devel/server/changelog-150.html I'm really proud to say that I hardly did a thing for this release. I have added a news item thanking our developers and welcoming Dan Wilks: http://x.cygwin.com/ Harold
Re: Fix - Occasional Paste Problem
Dan, This looks cool. The diff looks fine for this time. Might have some tips later, but don't worry about it for now. I'll try to look at this in a couple of days. Harold Wilks, Dan wrote: I've just recently started using Cygwin/X but occasionally paste from Win32 to X fails. I'm using -multiwindow and -clipboard. I tracked down one source of the failures: XP's remote desktop. Remote desktop does not properly restore the clipboard chain when it shuts down. Result is that XWin no longer sees clipboard messages when you copy in a Win32 app. The fix is rather simple although a bit forceful. Just reinitialize the clipboard chain each time the app is activated or deactivated - on each WM_ACTIVATEAPP message. Here's a proposed patch. Sorry, not from CVS since I can't get external cvs access from work at the moment. They are from the most recent install from cygwin.com though (6.7.0.0-7). If not obvious this is the first time I've sent in a patch so please let me know if there's anything you'd like done differently (other than using the CVS sources - sorry).
Re: how do you decorate a fullscreen root window?
[EMAIL PROTECTED] wrote: Not so long ago, on another Windows machine, X opened it's fullscreen root window within a Windows window, allowing me to resize or drag it to partially display both the X root and Windows desktop. This was convenient. Currently, I am unable to duplicate this behavior: -fullscreen opens without decoration, requiring ALT-TAB to reveal any other windows; -fullscreen -scrollbars (a guess) fails. Just don't use -fullscreen at all. That opens in the default single window mode that has a title bar that will allow you to drag the window around. -scrollbars should allow you to resize the window in the default single window mode, but it hasn't been tested in a long time, so it may be broken. Harold
Re: numlock
I don't have time for it, don't have a need for it, and don't think that anyone has done a complete job of specifying exactly what it is that they would want this to do. As such, I'm not the right man for that job. Harold J S wrote: Harold/Alex? Can you comment on Thomas' email below? Would you be able to add the numlockoff code into the XFree build? Could this code be added into the XFree build? [snip] Not sure. That's a question for Harold, et. al. to answer. The options would be to (1) incorporate this code into the XWin codebase and activate it via a command-line switch, or (2) include it as a separate executable in the xorg-x11-bin package, and call it from the startxwin script. _ Check out MSN PC Safety Security to help ensure your PC is protected and safe. http://specials.msn.com/msn/security.asp _ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger
Re: how to keep XWin menu open when clicking on an item
Jack Tanner wrote: vdu wrote: yes, I do ! try this : shift+click on an item in all programs menu. Do you see ? the menu stays open. I've been using Windows since version 3.0 and had no idea that existed... Actually, it doesn't work in NT 4, at least. Anyone care to try in 2000? Do you propose that this work on all Windows versions, or only on the ones that have this shift+click behavior in the Start menu? Anyhow, if this sounds like an even remotely plausible piece of functionality for the tray menu, it makes an ever stronger case for moving the program list from the tray menu to the Start menu. Right now we have a menu in both places, if you install the X-start-menu-icons package. Why would we want to remove the functionality that allows a program list in the tray icon menu when the default behavior for that list is to be empty and to not be shown? Only people that want to use it are using it. Harold
Re: libc
Darryl Scott wrote: Hi! I cannot find any reference to a problem with this in the Cygwin docs, redhat site etc. Libc has as a standard catgets. But catgets and catopen are absent from the cygwin implementation and gencat and nl_types are not to be found. So where can I find either the source for these or a technical spec? I am reluctant to simply incorporate a libc containing these as this may interfere with the workings of Cygwin. True or False? I have asked this before but received no reply as I guess the question was considered either stupid or off topic. My my perspective the question is neither. Can I have some input please? Wrong mailing list. This question has nothing to do with the X Window System. Harold
Gone for the weekend
I will be gone until Sunday evening. Please try to answer questions while I am gone. I may make a release in the next 30 minutes, but I may not have enough time. Later, Harold
Re: Package Updates
Oops, it is on its way now. Harold Colin Harrison wrote: Hi, I can find the xorg-x11-xwin-6.7.0.0-4 package on mirror sites but not the xorg-x11-xwin-gl-6.7.0.0-4. Was It loaded to them? Thanks Colin Harrison
Re: Root window shimmers with new nVidia graphic card
[EMAIL PROTECTED] wrote: I just got a replacement PC: HP xw4100 with nVidia Quadro4 980XGL graphic card. The previously PC was a Compaq DeskPro300 with an nVidia Quadro2 MXR. I re-installed cygwin as usual, and it operates properly. However, I've noticed something unusual in the display of the root window and scroll bars. They both shimmer as if the refresh rate was bad. Changing the refresh rate had no affect. All other windows (CygWin X or MS Windows) and their contents are fine. If I use multi-window (integrated window manager - no root window) the scroll bars still shimmer/vibrate. If I use xdmcp, the problem is not present at all. It's only a nuisance, but I would like to address it. Maybe a driver setting? I'm using 52.16. CygWin version is 1.5.5.1. However, I did try the latest (1.5.9.1). Problem is unchanged. Any recommendations? Yup, it has nothing to do with Cygwin/X. I wish you would have told us more about your monitor. Is it an LCD panel connected via a VGA (standard video for computers) cable, or is it something else? This problem occurs in the circuitry or cabling when you use certain combinations of video cards and monitors over VGA cables. For example, I have five old video cards and a 19 1280x1024 LCD panel; if I run it with four of the five video cards over VGA cables I get the shimmering you speak of, while the fifth video card does not cause the problem. Oddly enough, the one that does not cause the problem is one of my oldest video cards. You will almost always be able to notice a very small amount of that shimmering affect with any video card over VGA cables, but you'll have to look very closely to be able to see it sometimes. This problem doesn't usually occur when using CRT monitors and I believe this is because the shimmering is caused by a combination of the video card, VGA cable, and the circuitry in the LCD panel that changes the analog VGA signal back to a digital signal to drive the LCD; this conversion is a lossy sort of process and it would make sense that small variations in the incoming signal could get amplified during the conversion process thus causing the shimmering. So, if you have an LCD panel and you've got it hooked up with VGA cables, then hope and pray that your LCD panel also has a DVI (digital video interface, or whatever they have renamed it these days) connector. If it does, you're in luck though you may have to get a new video card if your current one does not have a DVI output; if it doesn't, get used to the shimmering or steal one of your co-workers hardware :) Good luck, Harold
Re: Starting with startxwin.bat
You probably just need to grab the xterm package. Harold Sterling Baker wrote: Anyone know why when I start cygwin with /usr/X11R6/bin/startxwin.bat all I get is an 'X' in the tray but no actual window. This worked correctly until I applied the latest updates which change to the Xorg-X instead of the XFree86. I can still start cygwin in terminal mode and then use /usr/X11R6/bin/startxwin.sh and it works correctly (although having to have the extra window is a little annoying), both .sh and .bat are set to the same options. The only options from default I use are; run XWin run openbox run xsetroot -solid aquamarine4 I don't know what setting may need to be different or added to get this to work the way I've always used it before. Thanks Sterling Baker
Re: Starting with startxwin.bat
Sterling Baker wrote: You probably just need to grab the xterm package. Harold Already had it. startxwin now starts XWin in multiwindow mode. If you want the old behaviour edit /usr/X11R6/bin/startxwin.bat snip and remove the -multiwindow option bye ago Oh, sorry, that is because a problem with the way that XWin and 'run' interact. In other words, you can't use 'run' with XWin in certain modes, one of which is the mode that you are using. Instead use 'start /B' if you are on an NT-based platform, else, you're stuck with a shell script for the time being. Sorry. Harold
Re: netscape 4.8 crashed on Cygwin/X
Where did you look for a solution for this? I ask because this is brought up almost daily on our mailing list (today even) and is in our FAQ. The problem has nothing to do with Cygwin/X and everything to do with OpenSSH and the solution is trivial. The answer is at the following URL, but where were you looking without finding it (or did you even look before reporting it?): http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding Harold dcyspm wrote: I tried to X11-forward a netscape 4.8 browser window using Cygwin/X from a Solaris 8 (recent patches applied) server and I got the following error: $ ./netscape X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 73 (X_GetImage) Resource id in failed request: 0x3a Serial number of failed request: 78 Current serial number in output stream: 78 and no browser window. It worked under Exceed, so it does not appear to be a problem with the netscape binary. I did not see any other instances of this problem on the list. I don't need a resolution, considering the quality of the Solaris implementation of netscape (and netscape's implementation of Mozilla) I'm happier forwarding the ports I need and using my local browser. Just thought I'd bring it up, I'm not going to debug it (don't code much under Windows). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Problem with X forwarding by openssh-3.8p1
See A1: http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding [EMAIL PROTECTED] wrote: I have installed the lastest X11 binaries, including xorg-x11-xwin 6.7.0.0-3, together with openssh-3.8p1. The rest of my cygwin installation is also up-to-date, including cygwin1.dll version 1.5.9-1. I use startxwin.bat to start XWin using -multiwindow -clipboard. I login to a remote Linux server using ssh -X and start a Matlab session. The Matlab flash screen comes up, but when the flash screen disappears, there is only a menu bar located at the top left corner of the screen. If I choose maximize, the Matlab command window comes up but I am not able to type in any commands. If I downgrade to openssh-3.7.1p2-2, the problem disappears. The sshd_config file is identical in both cases. There are other problems with X forwarding under openssh-3.8p1, but since I am now using openssh-3.7.1p2-2, I cannot reproduce the error messages. I don't know whether this is considered an openssh-3.8p1 problem or a X server problem, but there appears to be some incompatibility issue here. Raymond Kwong
Re: Problem with xterm and cygxft-2.dll after update
Mark Arnold wrote: Hi All, I was hoping to get some help with a problem I am now having with my installation. Prior to yesterday I hadn't updated my cygwin installation for about about 3 weeks or so. I updated by running the setup application and initially downloaded everything locally from my favourite mirror, then ran setup again and installed what needed to be updated. I noticed in the process of updating that the heirarchy changed with the addition of the X11 category and I now have the xorg-x11-XXX packages installed (versions 6.7.0.0-X) The problem is now that when I start X and try to run things suck as xclock and xterm I get a windows dialog box appearing telling me that xterm is unable to locate the DLL cygXft-2.dll in the specified path and lists the search path which includes C:\cygwin\bin, C:\cygwin\usr\X11R6\bin plus a whole lot of other windows directories. You need the libXft and libXft2 packages. I'm not sure why libXft2 was not selected automatically. Harold
Re: Mailinglist for cygwin
Alexander Gottwald wrote: Keith Packard wrote: But, I think xwinwm belongs in xapps. We added it to xserver because of two reasons: - It is very closely bound to the Cygwin/X server - I only have access to xserver and xorg I you decide it belongs to xapps then we will move the module to xapps. There are at least 3 persons who need access to xapps then: me (ago), Kensuke Matsuzaki (zakki) and Takuma Murakami (takuma). Harold Hunt seem to already have access. Oh, I could turn on that access in a matter of minutes if we needed it... you didn't mention this concern to me before, so I thought you were aware that I could do that. Self management is one of the perks of working at freedesktop.org :) Harold
Re: Errors in XWin.man.new
Rodrigo Medina wrote: Hi all, I have found a couple of typing errors in the XWin.man.new I have previously attached. 2- To include items in the menu which is associated with the \fIWindows\fP window that \fIXWin -mulwindow\fP produces for each top-level X-window. ^^^ 3- To change the icon that is associated to the \fIWindows\fP window that \fIXWin -mulwindow\fP produces for each top-level X-window. Again, that ^^ Fixed them in my copy. Thanks. Do you want to work on anything else? We could give you access to our documentation source code if you want to update the User's Guide or anything like that. Harold
Re: ttmkfdir no longer needed
Nicholas Wourms wrote: Harold L Hunt II wrote: It looks like we no longer need ttmkfdir in order to expose the fonts installed with Windows to X11. The mkfontscale utility that is included with out distribution was inspired by ttmkfdir and essentially replaces it: That's not what it says, at least it makes no claim to be a full replacement. It mentions only that it is inspired from the original ttmkfdir, but I don't think it in the same class as the latest version (ttmkfdir-3.x) from RedHat. In fact, RedHat still retains and uses it to this day, even in the bleeding-edge Fedora's (which, BTW, are also using xorg-x11 for X11). IIRC, Mike Harris says in specfile that while mkfontscale is adequate for latin font encodings, it doesn't work all that well with unicode and other complex encodings. Since I speak English, I can't confirm nor deny if this is true, but if Mike is still using it for RedHat's TTF's, then I'd have to say there is some truth to it. Well, since we've never had a ttmkfdir package we aren't missing anything that we previously had. You can do something like the following right now (well, not with Cygwin 1.5.9 since mkfontscale will core dump, you have to use snapshot of cygwin1.dll for the moment): 1) mkfontscale /cygdrive/c/WINDOWS/Fonts 2) mkfontdir /cygdrive/c/WINDOWS/Fonts 3) Launch Cygwin/X 4) In a bash shell under Cygwin/X, run: xset fp+ /cygdrive/c/WINDOWS/Fonts 5) Run xfontsel and observe that picking 'microsoft' from the 'rgstry' category exposes 'microsoft sans serif', 'tahoma', and 'verdana' among others under the 'fmly' category. Note also that valid chartacters appear when you select these fonts. Due to this I am going to pull the link to ttmkfdir from our 'Ported Software' page. Perhaps someone would like to write a postinstall script that creates symlinks to the Fonts folder for Windows under /usr/X11R6/lib/X11/fonts/windows, then runs mkfontscale and mkfontdir in that folder (since we can not guarantee that we have permissions to create files in the actual Fonts folder for Windows). Then it would take a minor adjustment of our startup scripts to pass this additional font folder to Cygwin/X on startup. Any takers? I'll package it if somebody works the kinks out of it. I would *strongly* advise against any action which would work directly in and/or on a user's system's FONTS dir. Let me clarify, I meant that we should create symlinks to the Windows fonts (think lndir here, not a single link to the folder containing the fonts) and that we should run mkfontscale and mkfontdir in our directory that just contains linkes to the Windows fonts. Please address your comments to that scenario. Harold
Re: Hang related to clipboard processing
David Arnstein wrote: I am having a problem with the latest Cygwin/X11 software suite. I'm using it with Windows 2000. Your problem is irrelavent until you tell us exactly what the latest means. The best way to do this is to grab the top few lines from /tmp/XWin.log and send them in. There are various things that could cause your version of the latest to in fact be quite old, so we need to get this information before your problem will be looked into further. Harold
Re: Pseudocolor emulation in 6.7.0.0-3?
Michael, Michael Sadd wrote: First off, thanks very much for the new Xorg server. For some time I have been using XWin to display an well-known EDA program that requires pseudo-color visuals. After updating to the new xserver on April 11,2004, my old configuration seems to break. Below is the output of /tmp/XWin.log and xdypinfo. The interesting lines seems to be: winSetEngine - Multi Window or Rootless = ShadowGDI winAdjustVideoModeShadowGDI - Command line bpp: 8, using bpp: 32 Interesting. The 6.7-3 release was supposed to include a fix for this problem (which was introduced sometime before 6.7-3) but it appears that the fix didn't make it into the release, instead it will be in 6.7-4 (see the release notes for 6.7-3 via the About... menu on the tray icon, you'll see that it claims this was fixed already). Thanks for the heads up, Harold
Re: Updated: xorg-x11-[base,bin,bin-dlls,fenc,fscl,nest,vfb,xwin,xwin-gl]
Dr. Volker Zell wrote: Harold L Hunt, writes: The following packages have been updated in the Cygwin distribution: *** xorg-x11-bin-6.7.0.0-3 *** xorg-x11-xwin-gl-6.7.0.0-2 /usr/X11R6/bin/XWin_GL.exe is found in both archives. Thanks, that'll be fixed soon. Harold
CVS account for htdocs for Alexander Gottwald
I would like Alexander Gottwald to get an account on sources.redhat.com so that he can upload compiled versions of our documentation (User's Guide, Contributor's Guide, FAQ) to our portion of the website. I'll have him send a preferred user name and ssh public key in response to this request. Harold
Re: Updated XWin.man
Rodrigo, Thanks for your work. I'm looking at this now and adding some changes of my own. I hope to get this out in the next release. Thanks again, Harold Rodrigo Medina wrote: Hi all, I have finally finished the new XWin.man. It is attached. The only points that I left over were the updating of the list of collaborators and the first line of the file. I hope that there are not too many English errors! If I have time in rest of the week I will try to do also the XWinrc.man bye Rodrigo Medina
Re: CVS account for htdocs for Alexander Gottwald
Fascinating: Thank you. This request will now be processed by: None. Request was 7229068.2513 Harold Harold L Hunt II wrote: Ah, here is the URL: http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi I looked on the Cygwin pages but didn't find it linked anywhere... looks like it is only linked to from the sources.redhat.com pages proper, which explains why I didn't see it. Harold Christopher Faylor wrote: On Sat, Apr 10, 2004 at 01:46:30PM -0400, Harold L Hunt II wrote: I would like Alexander Gottwald to get an account on sources.redhat.com so that he can upload compiled versions of our documentation (User's Guide, Contributor's Guide, FAQ) to our portion of the website. I'll have him send a preferred user name and ssh public key in response to this request. Please use the standard form for this.
Windows keys in the keymap?
Some of you may have noticed that Takuma and I added a -keyhook option to XWin.exe that allows Alt+Tab to be trapped on NT-based OSes and passed to X apps as a normal key event. We can also do the same for the Windows keys on the keyboard, but there are a few problems at this time: 1) Mod4Mask was used for XK_Super_L and XK_Super_R in the information I could find about the Windows key in X keymaps. However, we currently use Mod4Mask for XK_Kana_Lock and XK_Kana_Shift. My first question is does the XK_Kana_Lock and XK_Kana_Shift thing even work right now? If not, then we can just switch these. If it does work, then we will have to change the modifier map if a Japanese keyboard layout is loaded... but I wonder if that is done already? 2) The Windows keys are typically mapped to XK_Super_L and XK_Super_R for VK_LWIN and VK_RWIN, repsectively. I am seeing scan codes of 0x5B and 0x5C for the VK_LWIN and VK_RWIN keys, respectively again (note: yes, these are the same as the virtual key code for these keys for some reason). If we want to map these keys to XK_Super_L and XK_Super_R we need some sort of entry in our default key map since it currently contains nothing about these keys. I have tried adding an entry, but xev never seemed to pick up a valid key press from the Windows key when I was trapping and passing it through, though I do know that the trapping and passing was working correctly. So, who can help me figure out how to modify our default key map so that the Windows key will be useable under X? Harold
Re: mkfontdir and mkfontscale segfault
Look at the latest release notes that I sent this morning. Harold Frédéric L. W. Meunier wrote: When I run 'mkfontscale .' or 'mkfontdir .' in C:\WINDOWS\Fonts, both segfault: $ mkfontdir . Couldn't determine full name for 8514fix.fon Couldn't determine slant for 8514fix.fon Couldn't determine weight for 8514fix.fon Couldn't get family name for 8514fix.fon Couldn't determine full name for 8514fixe.fon Couldn't determine slant for 8514fixe.fon Couldn't determine weight for 8514fixe.fon Couldn't get family name for 8514fixe.fon Couldn't determine full name for 8514fixg.fon Couldn't determine slant for 8514fixg.fon Couldn't determine weight for 8514fixg.fon Couldn't get family name for 8514fixg.fon Couldn't determine full name for 8514fixr.fon Couldn't determine slant for 8514fixr.fon Couldn't determine weight for 8514fixr.fon Couldn't get family name for 8514fixr.fon Couldn't determine full name for 8514fixt.fon Couldn't determine slant for 8514fixt.fon Couldn't determine weight for 8514fixt.fon Couldn't get family name for 8514fixt.fon Couldn't determine full name for 8514oem.fon Couldn't determine slant for 8514oem.fon Couldn't determine weight for 8514oem.fon Couldn't get family name for 8514oem.fon Couldn't determine full name for 8514oeme.fon Couldn't determine slant for 8514oeme.fon Couldn't determine weight for 8514oeme.fon Couldn't get family name for 8514oeme.fon Couldn't determine full name for 8514oemg.fon Couldn't determine slant for 8514oemg.fon Couldn't determine weight for 8514oemg.fon Couldn't get family name for 8514oemg.fon Couldn't determine full name for 8514oemr.fon Couldn't determine slant for 8514oemr.fon Couldn't determine weight for 8514oemr.fon Couldn't get family name for 8514oemr.fon Segmentation fault (core dumped) $ mkfontscale . Segmentation fault (core dumped) I also tried only with the *.ttf. fc-cache works fine. mkfontdir -e /usr/X11R6/lib/X11/fonts/encodings -e /usr/X11R6/lib/X11/fonts/encodings/large . also segfaults.
Website changed from HTML 4.01 to XHTML 1.0
I have translated all of the hand-generated files on the Cygwin/X website (http://x.cygwin.com/) from HTML 4.01 Transitional to XHTML 1.0 Transitional. I used Tidy UI to do this. Tidy UI just provides a nice interface in Windows to HTML Tidy, which cleans up and translates HTML. Tidy UI can be obtained here: http://users.rcn.com/creitzel/tidy.html#tidyui Let me know if anything seems messed up on the website. Be aware that the documentation (FAQ, User's Guide, and Contributor's Guide) are generated from DocBook and are thus not part of this conversion. Harold
ttmkfdir no longer needed
It looks like we no longer need ttmkfdir in order to expose the fonts installed with Windows to X11. The mkfontscale utility that is included with out distribution was inspired by ttmkfdir and essentially replaces it: http://freedesktop.org/~xorg/X11R6.7.0/doc/mkfontscale.1.html You can do something like the following right now (well, not with Cygwin 1.5.9 since mkfontscale will core dump, you have to use snapshot of cygwin1.dll for the moment): 1) mkfontscale /cygdrive/c/WINDOWS/Fonts 2) mkfontdir /cygdrive/c/WINDOWS/Fonts 3) Launch Cygwin/X 4) In a bash shell under Cygwin/X, run: xset fp+ /cygdrive/c/WINDOWS/Fonts 5) Run xfontsel and observe that picking 'microsoft' from the 'rgstry' category exposes 'microsoft sans serif', 'tahoma', and 'verdana' among others under the 'fmly' category. Note also that valid chartacters appear when you select these fonts. Due to this I am going to pull the link to ttmkfdir from our 'Ported Software' page. Perhaps someone would like to write a postinstall script that creates symlinks to the Fonts folder for Windows under /usr/X11R6/lib/X11/fonts/windows, then runs mkfontscale and mkfontdir in that folder (since we can not guarantee that we have permissions to create files in the actual Fonts folder for Windows). Then it would take a minor adjustment of our startup scripts to pass this additional font folder to Cygwin/X on startup. Any takers? I'll package it if somebody works the kinks out of it. Harold
Re: XWin glitch: cut-and-paste
In response to both of your messages, I will use my psychic powers to figure out: 1) your command-line options, 2) the version of xorg-x11-xwin that you have installed, 3) whether or not you are running xwinclip (you should not be), and 4) the method you are using to start XWin.exe. Get it? You gotta tell us stuff in order for us to be able to help you. What you are describing does not sound normal, but I can't figure out what you are doing unless you tell us. Harold Keith Thompson wrote: When I highlight a range of text in an xterm or rxvt window running under XWin, the text is highlighted only for a fraction of a second. It still seems to work (I can still paste the selected text into the same or another window), but it would be nice if it stayed highlighted as it does with every other X server I've used, including Exceed under MS Windows.
Re: SHM extension fails to start
Charles L. Werner wrote: I tried the suggested command from the Cygwin bash command line and the SHM extension still fails: I tried to find documentation on cygserver, but all there is dead links in the cygwin users guide. I assume the CYGWIN environment variable is being set by suggested command. There is no info for this option in the users guide for the CYGWIN environment variable... Since it had no effect is the environment variable setting incorrect? You have to launch cygserver just like you launch ipc-daemon2, except cygserver is in /usr/sbin instead of /usr/bin so you have to explicitly reference it unless /usr/sbin has been manually added to your path: /usr/sbin/cygserver Then launch CYGWIN=server XWin. Harold
Re: Problem with truetype fonts caused by not building FreeType module?
Lev S Bishop wrote: (Replying to my own message) I messed about with the host.def.in and got it to sort of work. My host.def.in is: #define BuildFreeType YES #define BuildServersOnlyYES #define XnestServer NO #define XVirtualFramebufferServer NO #define BuildXWinMultiWindowExtWM NO #define EtcX11Directory @sysconfdir@ #define ProjectRoot @prefix@ I also had to grab xc/lib/font/FreeType from the freedesktop cvs (tag CYGWIN if that's relevant). (Using the latest src packages from setup for the other sources). Now you are getting somewhere... the implication of BuildFreeType NO is that you are going to use the installed version since we set HasFreeType YES, but this does not appear to be the case. We'll either have to fix the build rules or just set BuildFreeType to YES but not actually include it in our distribution, just as we do for Xft. Harold
Re: Problem with truetype fonts caused by not building FreeType module?
Lev, Lev S Bishop wrote: Harold wrote: Now you are getting somewhere... the implication of BuildFreeType NO is that you are going to use the installed version since we set HasFreeType YES, but this does not appear to be the case. We'll either have to fix the build rules or just set BuildFreeType to YES but not actually include it in our distribution, just as we do for Xft. I think you have the wrong idea about FreeType backend. My understanding is that this is one of the modules which implement server-side truetype (the other being X-TrueType, the xtt module - only one of the two is allowed, and X-TrueType is scheduled for demolition in the next release). It's built *around* the FreeType library (which is what we say we have by asserting HasFreeType YES...) but it's not the same thing as having the library. I think all we need to do is set BuildFreeType to yes Hmm... I was thinking we were setting BuildFreetype to NO and BuildFontconfig to NO in cygwin.cf to prevent these already installed libraries from being compiled, when in fact we were not doing so. You are correct that no longer including xorg.cf (or xfree86.cf) caused the default for BuildFreetype and BuildFontconfig to flip from YES to NO and you are correct that these signal if programs should link against these libraries. There are separate flags call BuildFreetype2Library and BuildFontconfigLibrary that we need to set to NO to prevent just the library from being built, but those should actually pickup the correct defaults from X11.tmpl since we set HasFreetype2 and HasFontconfig to YES. - the resulting module gets statically linked into libXfont.a (rather than being a loadable module, as it would be in many other X servers, since we don't do loadable modules on cygwin/x), and from there gets linked into XWin.exe and xfs.exe (I understand xfs.exe is currently non-functional, though), and perhaps some other places? Regarding the static linking, that is not correct. I had noticed recently that XWin.exe was no longer linked to cygfreetype-6.dll (do a 'cygcheck XWin.exe' to find out what DLLs are being linked to) and was wondering what happened. I could be wrong about all this but the release notes seem to back me up: http://freedesktop.org/~xorg/X11R6.7.0/doc/RELNOTES6.html#41 No, you're not wrong, you helped me find the correct flags we need to set and you helped find the reason why the defaults for some of these flags has changed. Yay, now I can do a complete rebuild. :) Harold
Re: Do I need XFree86 now that XOrg-x11 is the default X-windowing system?
Anybody wrote: Do I need XFree86 now that XOrg-x11 is the default X-windowing system? When I do a fresh install, I see that a couple of packages in the removed packages section are still selected. These are XFree86-base and XFree86-bin. Are these really necessary is I install xorg-x11-base and xorg-xll-bin? Those packages are all empty, they are just used to force removal of the files from those packages before the files from the xorg-x11-* packages are installed. If we didn't do this and you later removed the XFree86-* packages you'd end up deleting files from the xorg-x11-* packages, which you don't want to do. In other words, just ignore the XFree86-* packages in the ZZZRemovedPackages category, they contain no files and don't matter to you anymore. Harold
Re: 6.7.0.0 XWin w/out -nodecoration running in background doesn't display anything
Yeah, you can't use run in the batch file... you have to use start instead. I noticed this right before the release, but I don't have a permanent solution yet. We had to switch from start to run because start doesn't prevent a DOS box from being displayed and because we switched XWin.exe from not displaying a DOS box by default to displaying a DOS box by default. The reason for this is that the new logging facility allows sending messages both to standard output and to a log file if one is opened sometime after the server starts (message have to be cached until that point since they would otherwise be lost since the log file isn't open yet). The nicest thing about this is that people running XWin -help will now see the help output instead of having to open /tmp/XWin.log to see the output. What is the permanent solution to the problem? I don't know. I think it may be time to finish writing the batch file that just launches a bash shell script, but I haven't got time to work on that today. Harold Rudolf Kollien wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, i just upgraded to the new X11 (X.org) version of cygwin/X (Release 6.7.0.0-1. I use XWin to connect via XDMCP to several linux server. My previous used startup script is a MS-DOS batch file in which i fire-up XWin.exe with start XWin.exe -fp and so on. This is all ok. I get an connection and can work. But with this new X11 release i get a additional window with all the status and error messages from XWin. Until now XWin run in background when startet by the DOS start-command. When i try the new cygwin command run, as used in the sample startxdmcp.bat, i'm only can do this by supplying the -nodecoration parm. Without this param, i do not see any X-client nor the login screen from kde (in my case). Even XWin runs an has a connection to the server. I see the X in the systray, right clicking an choosing Exit reminds me that three clients connected. Shortly said: when you want to run X in a M$-Windows Window (let - -nodecorations away) then you can't run XWin in background. As i use up to 6 XDMCP connections to different linux servers with different screen sizes and resolutions, i now have 12 Windows on the desk (or taskbar, when minimized). Is there a way to get the old behavor back? Testcase: - - run XWin.exe -query HOST = you see the X in the systray but nothing else. - - run XWin.exe -query HOST -nodecorations = you get a fullscreen login screen to the server - - start XWin.exe -query HOST = you get the servers login screen in a Windooze window and an _additional_ console window with the text messages from XWin.exe - - start /b XWin.exe -query HOST = same as run XWin Regards - -- Rudolf Kollien email: [EMAIL PROTECTED] * Never trust a operating system you have no sources for * Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. * -BEGIN PGP SIGNATURE- iD8DBQFAdaMqzOHTWsKaqE0RAjBzAJ4nmwvsiRCfJsPwd78r2V/F9B3MKgCfa/R9 1WgN4gBq5vhfKrE6ALKSbQ8= =OCSD -END PGP SIGNATURE-
Re: Problem with truetype fonts caused by not building FreeType module?
Lev S Bishop wrote: Harold wrote: Lev S Bishop wrote: - the resulting module gets statically linked into libXfont.a (rather than being a loadable module, as it would be in many other X servers, since we don't do loadable modules on cygwin/x), and from there gets linked into XWin.exe and xfs.exe (I understand xfs.exe is currently non-functional, though), and perhaps some other places? Regarding the static linking, that is not correct. I had noticed recently that XWin.exe was no longer linked to cygfreetype-6.dll (do a 'cygcheck XWin.exe' to find out what DLLs are being linked to) and was wondering what happened. No, I am sure that I am correct about the static linking, but I was not very clear what I was saying. There are *two* things called freetype under discussion. There is the freetype library (the thing that is available from www.freetype.org, is independent of X, and is contained in cygfreetype-6.dll from the package libfreetype26-2.1.5-1) and there is the freetype module (aka FreeType backend, formerly known as xfsft, this is the thing that's part of the x server). From now on I'll call the former freetype the freetype2 library and the latter the freetype backend. Uhh... you could have just called it the freetype backend in the font library. Yes, the font library is always statically linked into the server due to a limitation in the way it was implemented. I don't disagree that there is a freetype portion of the font library and that it was not being built. The freetype backend deals with making truetype fonts look and feel to the rest of the x server like all other x core fonts, XLFDs, fonts.dir, fonts.alias, etc) but to do the actual rendering it calls upon the freetype2 library. You can think of it as a wrapper for the freetype2 library. There is a version of the freetype2 library in the xc source tree, but we don't want to use it because we prefer to use a seperately installed (more up to date) version, so we set HasFreeType2 YES (typo in my earlier email, missed off the 2 on HasFreeType2). The freetype2 library can be dynamically linked (its cygfreetype6.dll). Yup. Now, here's what I was really getting at: the server architecture is such that certain parts of the X server are loadable modules -- whether or not they get loaded into the server is configured *at runtime* by looking in the Module section of the config file (xorg.conf), for lines like 'Load type1' to load the type 1 font rasterizer, etc (this is as opposed to load time dynamic linking, which is what cygcheck tells you about). See: http://freedesktop.org/~xorg/X11R6.7.0/doc/xorg.conf.5.html#sect5 However, cygwin/x doesn't support loadable modules like that (we don't set DoLoadableServer YES, and we don't have a config file to read even if we did) so the freetype backend gets built statically into libXfont.a, and libXfont.a is linked into XWin.exe. Right, I don't dispute that, but your earlier message was really confusing the names of things and we were not talking about the same thing. Whether or not we use the freetype backend is controlled by the build switch: BuildFreeType (note capitalization). The freetype2 library is controlled by the switch HasFreetype2. We already have HasFreetype2 YES, but we need to add BuildFreeType YES. The switches control the building of completely orthogonal branches of the source tree. Right, that is what I said. I said that no longer including xorg.cf some time ago caused the BuildFreeType flag to start defaulting to NO instead of its previous YES. And I also credited you with discovering that the flag doesn't control building the library but instead controls whether the other clients and libraries in the tree use freetype and whether or not any code dependent upon freetype is built. What more do you want? You must not have read the end of my last message very clearly. Harold: you mentioned something about BuildFontconfig. There is no such switch. I don't care, you know what I meant. I don't have time to read ten files for each sentence I write in these really long and trying emails. That is why I would prefer that we just converse in IRC about this... it is a lot easier on me. Harold
Re: Problems when try to start cygwin
Did you read the message? You should be looking at /tmp/XWin.log and if you expect us to help you should be sending in /tmp/XWin.log. Harold Paulo Coelho wrote: Hi, i tried to start cygwin but I am find some fatal problems. When I try to start with startx command a message is appearing: A fatal error has occurred and Cygwin/X will now exit Please open /tmp/XWin.log for more information Vendor: The Cygwin/X project Release: 6.7.0.0-1 Contact:[EMAIL PROTECTED] Xwin was started with the following command-line X :0 Could you help me on this ensue Thanks a lot Paulo Coelho Support Engineer Mobile: +55 21 8153 9227 Fax: +551 21 2532 9219 e-mail:[EMAIL PROTECTED]
Re: hangs and other pblms with 6.7.0.0-1 release
Why don't you try some troubleshooting... try without -clipboard and without -multiwindow and see what happens. Harold Carl Holmberg wrote: Hi, Updated today to 6.7.0.0-1 using setup, resulting in a nearly useless XWin: 1. XTerms do not respect sizing/minimize buttons (nothing happens), nor toolbar tab (cannot minimize). 2. XTerm freezes easily (a right-mouse click seems to trigger hang 100% of time). In this state cannot bring to foreground - window is totally non-responsive, X icon in tray is non- responsive. 3. Alt-F4 does not close XWin in this hung state (have to kill based on PID). 4. Alt-F4 does not work when not in hung-state either. Right- click on X icon to kill XWin server (when not in hung state and no open XTerms) results in an illegal operation: XWIN caused an invalid page fault in module CYGWIN1.DLL at 025f:610885ba. Registers: EAX=0267 CS=025f EIP=610885ba EFLGS=00010202 EBX=0202 SS=0267 ESP=031fedb0 EBP=031ff048 ECX=100e05a0 DS=0267 ESI=0020 FS=6717 EDX= ES=0267 EDI=007606c8 GS=70fe Bytes at CS:EIP: ff 77 20 53 66 8b 47 24 8e c0 66 8b 47 28 8e e8 Stack dump: Tail of XWin.log after this fault is: winAboutDlgProc - WM_COMMAND - IDOK or IDCANCEL winDeinitMultiWindowWM - Noting shutdown in progress ddxBeforeReset - Hello winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. winClipboardProc - XDestroyWindow succeeded. ddxBeforeReset - Clipboard thread has exited. winClipboardIOErrorHandler! winDeinitMultiWindowWM - Noting shutdown in progress. Am using on Win98SE system with STB Velocity 128 (NVidia Riva 128) card. Previous XWin worked fine, and am starting up using latest startxwin.sh with no modifications. Shutting down anti- virus and ZoneAlarm makes no difference. No custom startups, and verified mounts are binmode. cygcheck -cv shows no problems (all installed Cygwin SW is current). XWin.log follows when in hung state and had to terminate with a kill -9 (very little activity - xterm came up on startup, a right-click froze the system): Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 6.7.0.0-1 Contact: [EMAIL PROTECTED] XWin was started with the following command line: XWin -multiwindow -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winValidateArgs - Returning. (II) XF86Config is not supported. See http://x.cygwin.com/docs/faq/cygwin-xfree-faq.html for more information winDetectSupportedEngines - Windows 95/98/Me winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1280 dwHeight: 1024 winSetEngine - Multi Window or Rootless = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1280 h: 1024 winCreateBoundingWindowWindowed - Current w: 1280 h: 1024 winAdjustForAutoHide - Original WorkArea: 0 0 1024 1280 winAdjustForAutoHide - Taskbar is auto hide winAdjustForAutoHide - Found BOTTOM auto-hide taskbar winAdjustForAutoHide - Adjusted WorkArea: 0 0 1023 1280 winCreateBoundingWindowWindowed - WindowClient w 1280 h 1023 r 1280 l 0 b 1023 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 1023 depth: 16 winAllocateFBShadowGDI - Dibsection width: 1280 height: -1023 depth: 16 size image: 2618880 winAllocateFBShadowGDI - WEIRDNESS - biHeight still negative: - 1023 winAllocateFBShadowGDI - WEIRDNESS - Flipping biHeight sign winAllocateFBShadowGDI - Created shadow stride: 1280 winFinishScreenInitFB - Masks: 7c00 03e0 001f winInitVisualsShadowGDI - Masks 7c00 03e0 001f BPRGB 5 d 15 bpp 16 winRandRInit () 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. winMultiWindowXMsgProc - Hello winInitMultiWindowWM - Hello winFinishScreenInitFB - returning winMultiWindowXMsgProc - Calling pthread_mutex_lock () winInitMultiWindowWM - Calling pthread_mutex_lock () winScreenInit - returning InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=250, rate=15 (--) winConfigKeyboard - Layout: 0409 (0409) (EE) Keyboardlayout United States 101 (0409) is unknown Rules = xorg Model = pc101 Layout = us Variant = (null)
Re: 6.7.0.0 XWin w/out -nodecoration running in background doesn't display anything
Rudolf Kollien wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Harold, sorry, if my question sounds stupid, but... when i can't use run in a batch why there is run used in the startxdmcp.bat? It does the job as requested. But only with -nodecorations. Why can a window without border and titlebar can be used, but a normal window not? I don't want to compare to the old XFree86 (i'm glad about the new project) but once upon a time there where the same problem but was gone long ago. I didn't want to get into the details of what works and what doesn't work. You are right that it seems to work fine with -query, but it doesn't work with other options. I don't know what is going on, but I suspect we can probably fix it by modifying either run.exe or XWin.exe... but the other solution is to just use bash so we can do XWin instead of using start or run. Find whatever solution you need for the time being until it can be fixed properly. Harold
Re: Crash when remote desktop changes screen resolutions
Pass -engine 1 to XWin.exe and see what happens. Harold Ed Avis wrote: Here is another example log file showing this crash: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.66 Contact: [EMAIL PROTECTED] XWin was started with the following command line: /usr/X11R6/bin/XWin -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1280 dwHeight: 1024 winSetEngine - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1280 h: 1024 winCreateBoundingWindowWindowed - Current w: 1280 h: 1024 winAdjustForAutoHide - Original WorkArea: 0 0 996 1280 winAdjustForAutoHide - Adjusted WorkArea: 0 0 996 1280 winCreateBoundingWindowWindowed - WindowClient w 1274 h 971 r 1274 l 0 b 971 t 0 winCreateBoundingWindowWindowed - Returning winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 5096 winAllocateFBShadowDDNL - Created shadow pitch: 5096 winAllocateFBShadowDDNL - Created shadow stride: 1274 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winRandRInit () winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=250, rate=31 (--) winConfigKeyboard - Layout: 0809 (0809) (--) Using preset keyboard for English (United Kingdom) (809), type 4 Rules = xfree86 Model = pc105 Layout = gb Variant = (null) Options = (null) Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! winPointerWarpCursor - Discarding first warp: 637 485 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. winProcSetSelectionOwner - Clipboard not yet started, aborting. winProcSetSelectionOwner - Clipboard not yet started, aborting. winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt failure message maximum (10) reached. No more failure messages will be printed. winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList list_return is NULL. winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList list_return is NULL. winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 8 winWindowProc - WM_DISPLAYCHANGE - new width: 1024 new height: 720 winWindowProc - Disruptive change in depth winDisplayDepthChangeDialog - DialogBox returned: 1840476 winDisplayDepthChangeDialog - GetLastError: 6 winReleasePrimarySurfaceShadowDDNL - Hello winReleasePrimarySurfaceShadowDDNL - Detached clipper winReleasePrimarySurfaceShadowDDNL - Released primary surface winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Could not create primary surface: 8876024e winChangeDelthDlgProc - wParam == s_pScreenInfo-dwBPP winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 8, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 1024 winReleasePrimarySurfaceShadowDDNL - Hello winReleasePrimarySurfaceShadowDDNL - Released primary surface winCreatePrimarySurfaceShadowDDNL - Creating primary surface
Re: XWin.log
winCheckDisplayNumber - Cygwin/X is already running on display 0 Fatal server error: InitOutput - Duplicate invocation on display number: 0. Exiting. winDeinitMultiWindowWM - Noting shutdown in progress You can't launch two instances on the same display number. Harold
Re: Window Movement after display settings change
Ben Jackson wrote: In the latest release I have the following problem (after changing display settings): - Open any x app (eg nedit, xterm) - Move the window Then updates are only applied to the rect where the window used to be, and the mouse will not move into the new area (into which it has moved). Anyone else getting this? Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.67 Contact: [EMAIL PROTECTED] XWin was started with the following command line: XWin -multimonitors -multiwindow -clipboard -nodecoration How is this even working? You aren't supposed to be able to use -nodecoration and -multiwindow together and you should not. I swear I checked for this combination in my command-line argument validation that I added sometime last month... Harold
Special Windows keys (Alt+Tab, Windows key, etc.)
I've got trapping and passing of Alt+Tab working correctly in CVS. The Windows key is almost ready to go; I trap it correctly but we don't have XK_Super_L or XK_Super_R in our keymap yet, nor do we have these being marked as modifiers. It seems that we can use Mod4Mask for these in place of the Kana keys since the Kana keys are not in our keyboard map either... or is that not correct if a Japanese keyboard layout is ever loaded? If the Kana modifier is used then we will have to conditionally use modifier 4 for the Windows key or the Kana key, depending on whether or not a Japanese keyboard layout is loaded. Are there any other key combos people want passed before I release this tomorrow? I think that Ctrl+Esc and Alt+Esc should probably get passed as well. Anything else? Harold
Re: /usr/bin/xterm
[EMAIL PROTECTED] wrote: On 1 Apr, Igor Pechtchanski wrote: I don't have time to fix this. I would appreciate it if someone else would grab the -src package for X-start-menu-icons via setup.exe and work on fixing it; I don't want a half-assed untested patch either, I want one that has been thoroughly tested (you know, tough stuff like clicking at least one of the tree classes of shortcuts: /usr/bin X programs, /usr/X11R6/bin X programs, and /usr/X11R6/bin terminal programs) since the sort of changes required may break the other links that the scripts create (this is part of the Catch-22 I was talking about). I don't recall any discussion or a heads-up that xterm now resides in /usr/bin... Any particular reason for this decision? I'm certainly interested to hear more. I got some ridicule dumped on me (in my role of Cygwin evangelist) when I mentioned this to an old-time Unix guy here. All of the old school X guys (Jim Gettys, Keith Packard, I think Kaleb Keithley, etc.) all say that /usr/X11R6 is an abomination and the sooner it goes away the better. You can now go back to your old school Unix guy and tell him he needs to get with the times on what people in the X Window System community are advocating. ;) Harold
Re: Error starting Xclock and Xterm
Grab the libXft package, you don't have it. Harold Wright, David L wrote: I recently installed all of the new XFree86 packages to a working cygwin installation. Now when I start the X-server, the server starts but I can't start Xclock or Xterm. I get the following message: This application has failed to start because cygXft-2.dll was not found. Re-installing the application may fix this problem. I don't know what package this dll is in so that I can re-download and re-install. Can you help? Thank You, David Wright
Re: Possible bug trying to run Eclipse GTK?
Craig, [EMAIL PROTECTED] wrote: OK. I'm fine with all of the FAQ items specified. (Running an older OpenSSH on Redhat Linux 9). Here is my XWin.log. No, you are not fine unless you tried ssh -Y instead of ssh -X. Why? Well, I might just say, why the heck don't people believe us when we try to help them?. Here it is: OpenSSH has *supported* trusted X11 tunelling for many versions; it was changed to be the *default* in the OpenSSH 3.8 *client*. So, you can be running an older version of sshd on your Linux box and you're still might have trusted X11 tunnelling turned on by default since you are using OpenSSH 3.8 as your client. Another interesting thing to note is that you can use an ssh client that doesn't support trusted X11 tunelling and you won't have any problems, such as PuTTY (free) or SSH Secure Shell (not free). So, would you please clarify if you actually tried ssh -Y instead of ssh -X? Harold
Re: Various starting X problems
Igor Pechtchanski wrote: Harold, On Thu, 1 Apr 2004, Harold L Hunt II wrote: Igor, Igor Pechtchanski wrote: On Thu, 1 Apr 2004, Harold L Hunt II wrote (irrelevant parts snipped): Phil Betts wrote: Luke said: In my .xinitrc I *don't* have an explicit path for xterm. However, I see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other Slightly OT: I noticed that the start menu entry for xterm no longer works. Entering the command from the shortcut directly into the cmd.exe shell returns without an error or any output (that I can find). From bash, the command works fine. The other shortcuts that I've tried (e.g.. xcalc) all worked, so there is presumably something unusual about the way that xterm starts that causes a silent exit when started from a vanilla DOS/Windows shell. My guess is that it's relying on some env var. I'm aware of this. I don't remember the exact details, but there is a sort of Catch-22 situation for setting the start in folder for the xterm shortcut; neither '/usr/bin' nor '/usr/X11R6/bin' work for different reasons. Furthermore, I believe that the script that creates the shortcuts needs to be modified to be able to support shortcuts to programs that live in /usr/bin. You'll notice that the emacs shortcut also does not work for the same reason. I don't recall any discussion or a heads-up that xterm now resides in /usr/bin... Any particular reason for this decision? It wasn't a change... the xterm package has always been this way since its inception a couple weeks ago. It was a change from the users' point of view. Their xterm used to be in /usr/X11R6/bin, and now it's in /usr/bin all of a sudden. The fact that it also moved into a separate package is incidental. Chris and I discussed on cygwin-apps that there was no reason to put new X packages in /usr/X11R6 so I have not been doing this for most new X packages; barring those that do broken things and need to be stuck in /usr/X11R6, like libXft. For new packages -- sure, but moving something as fundamental as xterm is not something to be taken lightly. There *is* a reason to put X11 binaries (and especially libraries) in the same directory. The reason is Windows dynamic linking. By default, Windows apps look for DLLs in the current directory before looking in the PATH. So, for apps that are in /usr/X11R6/bin, all the X DLLs are found automatically. Once xterm moves into /usr/bin, either all the DLLs it requires should also move there, or /usr/X11R6/bin should be *added* to the PATH (it wasn't required before). Also, moving xterm to /usr/bin breaks all sorts of existing scripts (those that hardcode the path to it as /usr/X11R6/bin, because it's not usually in the Windows PATH by default). At the very least there should have been an announcement declaring in large friendly letters that xterm won't work anymore unless you (a) change all your scripts that expect to find it in /usr/X11R6/bin, and (b) add /usr/X11R6/bin to your Windows system path, otherwise the necessary DLLs won't be found. Frankly, I think that moving 1 app to /usr/bin doesn't solve the problem, it only creates more. If you want to be rid of /usr/X11R6/bin, first move all the libraries to /usr/bin, and then move all the apps in one fell swoop. Until then, you'll only be causing users unnecessary anguish'. Just my 2c. Well, then don't feel upset that I'm disregarding your 2c. [...] breaks all sorts of existing scripts [...] is pretty hard to believe since it took the collective mailing list two weeks to even notice the move. Harold
Re: X under full keyboard control
Takuma, Takuma Murakami wrote: Michael, I don't know what you mean with hook DLL though. I'm not sure if we need a separate DLL... See this article and follow links in it for details. http://sources.redhat.com/ml/cygwin-xfree/2004-02/msg00149.html Here is why we don't need a separate DLL for hooking these keyboard messages, from MSDN: A global hook monitors messages for all threads in the same desktop as the calling thread. A thread-specific hook monitors messages for only an individual thread. A global hook procedure can be called in the context of any application in the same desktop as the calling thread, so the procedure must be in a separate dynamic-link library (DLL) module. A thread-specific hook procedure is called only in the context of the associated thread. If an application installs a hook procedure for one of its own threads, the hook procedure can be in either the same module as the rest of the application's code or in a DLL. If the application installs a hook procedure for a thread of a different application, the procedure must be in a DLL. For information, see Dynamic-Link Libraries. You see, we are only hooking messages in our own thread, so this approach works fine. The reason we keep mentioning a hook DLL is that we also want to hook mouse messages when our application is not receiving mouse events; in those cases the hook is processed in the context of whatever process/thread is currently receiving mouse events, which is why those global hooks need to be DLLs. The only problem with the hook approach for the key combinations in question is that it will only work for NT-based platforms and for only those running NT 4.0 SP3 or later; we will need to check for this before we turn on this hook and we need to make sure that all of this is conditional on whether or not this feature is enabled at runtime or not. I would go ahead and make this the default, but I would add a runtime option called -nokeyhook that allows it to be turned off on platforms that support it. Harold
Re: License for X-startup-scripts package
Dick, startx and xinitrc come from the X Window System Sample Implementation tree that follows the rule of including a license at the top of each file; these two files did not have a license in that tree, so they do not have a license in this package. startxwin.bat, startxwin.sh, and startxdmcp.bat originate from this project and have similarly never had a license. The run utility was written by Charles S. Wilson, and is licensed under the GNU General Public License as you can see from downloading the source package and looking at the top of /usr/src/x-startup-scripts-1.0.6/run/run.c. Hope that helps, Harold
Re: Cygwin/X11 forwarding ques.
Rosenstrauch, David wrote: -Original Message- From: Alexander Gottwald [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:30 AM To: [EMAIL PROTECTED] Subject: Re: Cygwin/X11 forwarding ques. On Thu, 1 Apr 2004, Rosenstrauch, David wrote: Is is possible, though, to do the opposite: i.e., use X11 forwarding to have GUI apps from my Windows box run remotely on my Windows box? No. This is not possible with X11 Forwarding. bye ago Thanks for the response. Your answer probably still stands, but I just wanted to point out a typo of mine, just in case it threw anyone off. That should have read: Is is possible, though, to do the opposite: i.e., use X11 forwarding to have GUI apps from my Windows box run remotely on my *LINUX* box? No, but you can use either VNC or RDP (Remote Desktop Protocol) to accomplish this. VNC will work on pretty much any version of Windows, while RDP would require Windows XP Professional or Windows Server 2003 (set to remote admin mode, which allows a max of two remote sessions at a time). There are VNC and RDP clients for X systems, including those running Linux. Hope that helps, Harold
Re: Cygwin/X11 forwarding ques.
Rosenstrauch, David wrote: -Original Message- From: Harold L Hunt II [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:58 AM To: [EMAIL PROTECTED] Subject: Re: Cygwin/X11 forwarding ques. No, but you can use either VNC or RDP (Remote Desktop Protocol) to accomplish this. Thanks for the response, but ... from my original post: P.S. Yes, I already know about VNC and the like. But I want to run individual Windows apps remotely, not the whole desktop. Didn't see it. I rarely read past the signature line now because of the gigantic BS quasi-legal disclaimers at the bottoms of most messages... like the one in yours :) Harold
Re: Shouldn't we put [Cygwin] or [CygXwin] here depending on the question?
Okay, I think I asked that this email help thing not be discussed here. Harold
Re: Updated: XFree86-xserv-4.3.0-66
Lev, 1) winclipboardxevents.c/winClipboardFlushXEvents/SelectionRequest - Change the 'format' value for the first call to XChangeProperty from 8 to 32 since we are passing a data array of Atoms, which are 32 bits long. (Lev Bishop) TARGETS still doesn't work right. Now, a request for TARGETS puts the following in XWin.log (once for each request): winMultiWindowXMsgProcErrorHandler - ERROR: BadValue (integer parameter out of range for operation) I can't find the above change in the CVS (is it there?) No, it was missing. When I applied the patch I got a complaint about the diff that followed the winclipboardxevents.c file, so I applied that following one by hand; but it turns out that the diff for the winclipboardxevents.c file was ignored as well, despite there not being an error indicating this. So, I have applied the patch again and committed it to CVS. but perhaps you need to change from sizeof(atomTargetArr) to sizeof(atomTargetArr)/sizeof(Atom) ?? Yup, that looks correct to me. I don't think the TARGETS support has ever worked... it is pretty easy to see that the call to XChangeProperty was not correct by just looking at the next call to XChangeProperty about a hundred lines down in the file, and the docs make it obvious that it was wrong as well. I thank you for catching this because no one noticed this until now and I don't think anyone else was looking for it either. Sorry I can't compile my own versions to test these things but I don't even have room on my HD for the X sources... Hmm... actually, you might. I think you would only need the following source packages: -base -bin -prog -xserv Those packages total only 12 MiB in bzip2 form. Uncompressed they take 68.2 MiB but 84.1 MiB on a disk with 4 KiB clusters. You'd need the Cygwin packages listed on the following page (except I think you can skip perl since we aren't going to build the fonts): http://x.cygwin.com/docs/cg/prog-build-native.html Then you would edit /usr/src/xc/CYGWIN-PATCHES/host.def.in and add these lines to minimize the amount of code built: === #define BuildServersOnlyYES #define XnestServer NO #define XVirtualFramebufferServer NO === Then you are just three simple steps away from a build of XWin.exe: == $ cd /usr/src $ cp xc/CYGWIN-PATCHES/XFree86-4.3.0.sh . $ ./XFree86-4.3.0.sh mkdirs \ ./XFree86-4.3.0.sh conf \ ./XFree86-4.3.0.sh build build.log 21 == Then you can find your own XWin.exe at: /usr/src/xc/.build/programs/Xserver/XWin.exe You can just copy this to /usr/X11R6/bin/XWin.exe and start testing the changes you have made. After the initial build you can remake only the server by: = $ cd /usr/src/xc/.build/programs/Xserver make XWin.exe = The total amount of data generated by the build was 30 MiB requiring 60 MiB on a disk with 4 KiB clusters. The build took 12 minutes on my machine. So, unless you have less than 250 MiB of free disk space, then I think that you actually can do your own builds and probably should. Note: I tested the above build steps and confirmed that they work; the numbers presented are from an actual build, not just guesses. Harold
Re: Various starting X problems
Phil, Phil Betts wrote: Hi Harold, Firstly, it's generally bad form to quote verbatim email addresses - although Luke did so in his original posting, so he can't complain if a spam harvester latches onto him ;-). You know, I know that, but as you said, if they did it to themself first then I'm not going to lose sleep over it, nor am I going to waste my time confirming that I'm not reposting something that has already been posted since the cat is already out of the bag. Now... Luke said: In my .xinitrc I *don't* have an explicit path for xterm. However, I see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other X applications also move into there?My system does not have a problem finding xterm in /usr/bin because /usr/bin should always be in your Cygwin shell path... something else is wrong with your Cygwin setup if that is not the case. Slightly OT: I noticed that the start menu entry for xterm no longer works. Entering the command from the shortcut directly into the cmd.exe shell returns without an error or any output (that I can find). From bash, the command works fine. The other shortcuts that I've tried (e.g.. xcalc) all worked, so there is presumably something unusual about the way that xterm starts that causes a silent exit when started from a vanilla DOS/Windows shell. My guess is that it's relying on some env var. I'm aware of this. I don't remember the exact details, but there is a sort of Catch-22 situation for setting the start in folder for the xterm shortcut; neither '/usr/bin' nor '/usr/X11R6/bin' work for different reasons. Furthermore, I believe that the script that creates the shortcuts needs to be modified to be able to support shortcuts to programs that live in /usr/bin. You'll notice that the emacs shortcut also does not work for the same reason. I don't have time to fix this. I would appreciate it if someone else would grab the -src package for X-start-menu-icons via setup.exe and work on fixing it; I don't want a half-assed untested patch either, I want one that has been thoroughly tested (you know, tough stuff like clicking at least one of the tree classes of shortcuts: /usr/bin X programs, /usr/X11R6/bin X programs, and /usr/X11R6/bin terminal programs) since the sort of changes required may break the other links that the scripts create (this is part of the Catch-22 I was talking about). Maybe keep the exec wmaker and set display to :1 ... No, startx -multiwindow -- :1 triggers the no program named /usr/X11R6/bin/xterm in PATH crash. So I don't quite see how to achieve that. I tried xinit -multiwindow but that started up a full desktop. Seriously, the easiet way is to use startxwin.bat and modify it according to the instructions in that file. Or, if you really want to start from a Cygwin shell, use startxwin.sh and modify it accorinding to its instructions. There are pre-made lines that are just commented out that start a window manager etc. Lets have you try these things first and see where it goes. Harold Harold, I'm quickly coming to the opinion that .bat should really be spelled .bad !! My / is the recommended C:\cygwin, but /usr is mounted on D:\cygwin\usr. This means that the all of the %CYGWIN_ROOT%\usr based paths in the script are all wrong. There is no way (major kludges aside) to generate the correct paths in a generic .bat file. Consequently, every time I install a newer version, I need to hack the new .bat file (or patch my own script with any changes you've made). I wrote a short utility called find_cygwin using Open Watcom but I haven't finished it yet. The problems I ran into were that I could get the paths I needed, but exposing them to the batch file as a variable of some sort was darn near impossible. If you'd be interested in a unified approach, where the .bat just runs bash -c startxwin.sh (which will probably in turn be just a wrapper for startx) I might be able to make time for this. Yes, I think that may be the way to go at this point since we are starting to waste a lot of cycles trying to do things in batch files that are easily supported in shell scripts using *nix-style utilities. Give it a try. Download the X-startup-scripts -src package via setup.exe and hack away. I don't think it would be too hard... the batch file will basically be just like /cygwin.bat but it will launch a given script instead of displaying a console... you might have to use run to prevent it from popping up a console that sticks around until all of the spawned processes finish, but maybe not. The ultimate goal being to make any configuration of startup parameters external to the scripts and therefore remove ANY need for users to hack the scripts themselves. I wouldn't go for the gold yet... just make a batch file that runs the shell script first so that people can still create Windows shortcuts to the batch file, then we can go from there. There was mention a while ago of making multiwindow
Re: Various starting X problems
Igor, Igor Pechtchanski wrote: On Thu, 1 Apr 2004, Harold L Hunt II wrote (irrelevant parts snipped): Phil Betts wrote: Luke said: In my .xinitrc I *don't* have an explicit path for xterm. However, I see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other Slightly OT: I noticed that the start menu entry for xterm no longer works. Entering the command from the shortcut directly into the cmd.exe shell returns without an error or any output (that I can find). From bash, the command works fine. The other shortcuts that I've tried (e.g.. xcalc) all worked, so there is presumably something unusual about the way that xterm starts that causes a silent exit when started from a vanilla DOS/Windows shell. My guess is that it's relying on some env var. I'm aware of this. I don't remember the exact details, but there is a sort of Catch-22 situation for setting the start in folder for the xterm shortcut; neither '/usr/bin' nor '/usr/X11R6/bin' work for different reasons. Furthermore, I believe that the script that creates the shortcuts needs to be modified to be able to support shortcuts to programs that live in /usr/bin. You'll notice that the emacs shortcut also does not work for the same reason. I don't have time to fix this. I would appreciate it if someone else would grab the -src package for X-start-menu-icons via setup.exe and work on fixing it; I don't want a half-assed untested patch either, I want one that has been thoroughly tested (you know, tough stuff like clicking at least one of the tree classes of shortcuts: /usr/bin X programs, /usr/X11R6/bin X programs, and /usr/X11R6/bin terminal programs) since the sort of changes required may break the other links that the scripts create (this is part of the Catch-22 I was talking about). I don't recall any discussion or a heads-up that xterm now resides in /usr/bin... Any particular reason for this decision? It wasn't a change... the xterm package has always been this way since its inception a couple weeks ago. Chris and I discussed on cygwin-apps that there was no reason to put new X packages in /usr/X11R6 so I have not been doing this for most new X packages; barring those that do broken things and need to be stuck in /usr/X11R6, like libXft. I wrote a short utility called find_cygwin using Open Watcom but I haven't finished it yet. The problems I ran into were that I could get the paths I needed, but exposing them to the batch file as a variable of some sort was darn near impossible. How about the macro replace in a postinstall script approach I suggested earlier? Also, postinstall scripts already run *in* Cygwin, so there should be no reason to detect it, right? Just use cygpath... Still don't like that approach... it makes scripts that are dependent upon the setup of a machine at one point in time. I can just see the complaints rolling in when users cut d:\cygwin and paste it to c:\cygwin, fix their mount points, and see that X fails to start. The reason I wrote a find_cygwin utility was because the assumption was that you don't know where cygwin1.dll is, nor do you know where cygpath is, not do I want the utility to be dependent upon any Cygwin utilities at all. Of course, it isn't totally finished and probably never will be, but it was satisfying to see a 34 KiB program that could answer my question. Another thing that the utility would be useful for is for launching programs from the start menu... if the Cygwin mount points change, all of the menu links are invalidated because cygwin1.dll can't be found, nor can anything else. With a utility like find_cygwin you can have it look up where cygwin1.dll is via the mount points in the registry, then set the path to include that directory. Course, this sort of doesn't work because batch files suck. If you'd be interested in a unified approach, where the .bat just runs bash -c startxwin.sh (which will probably in turn be just a wrapper for startx) I might be able to make time for this. Yes, I think that may be the way to go at this point since we are starting to waste a lot of cycles trying to do things in batch files that are easily supported in shell scripts using *nix-style utilities. Perhaps you're right. As long as you run bash --login -c ..., so that the PATH is set properly. Yup, it seems time to do this. Harold
Re: Updated: XFree86-xserv-4.3.0-66
Lev, Lev Bishop wrote: Harold:I tried the build method you described, but I get an error: I get: ... making all in programs/Xserver/xkb... make[1]: Entering directory `/usr/src/xc/.build/programs/Xserver/xkb' make[1]: *** No rule to make target `/xkmread.c', needed by `xkmread.c'. Stop. make[1]: Leaving directory `/usr/src/xc/.build/programs/Xserver/xkb' make: *** [xkb] Error 2 Seems to be something to do with the BuildXKBlib macro. Probably caused by the lines in config/cf/X11.tmpl: #define BuildXKBfilelib (BuildXKB !BuildServersOnly) #if BuildXKBlib XKBFILELIBSRC = $(LIBSRC)/xkbfile I tried adding the line: XKBFILELIBSRC = $(LIBSRC)/xkbfile To xc/CYGWIN-PATCHES/hosts.def.in and building again. Which gives me an XWin.exe that appears to work (I haven't tested it much yet). Yeah, that will work for now. It appears that this has been fixed in the version that we will begin distributing next week sometime, so there is no need to fix this permanently in our current tarballs. I find the X build system (like many other build systems) completely bewildering so that's as far as I got. Did I do the right thing? Yup, you should be good to go... all you needed to do in this case was to shut up the compiler and make, which you did just fine if you got an XWin.exe in the end. Now you can start sending me patches instead of instructions on what to do. Send a few good patches and you'll get a cvs account to start doing things directly yourself. I think that the things you are working on for making the clipboard support more robust and reliable are very worthwhile and I appreciate that you are looking into them. For making patches, let me suggest using the little makefile I stuck in /usr/src/xc/programs/Xserver/hw/xwin. If you want to make a backup of just the files in hw/xwin (most likely this is all you'll be sending patches for, or all that you'll want to backup before you make big changes), then just do the following: cd /usr/src/xc/programs/Xserver/hw/xwin make -f backup.mk VERSION=MMDD-HHMM The scripts will make a backup of all relevent files in hw/xwin while ignoring stupid files created by emacs like foo~ and #foo#, or other backup files. It will create a directory called /usr/src/xc/programs/Xserver/hw/xwin-MMDD-HHMM (of course, substitute the date and time there, in that ISO-style format so that sorting works properly). I do this right before I make a big change and right after I am done, then I do the following to make a patch (where * marks the previous version and ^ marks the current version): cd /usr/src/xc/programs/Xserver/hw diff -upN xwin-MMDD-HHMM* xwin-MMDD-HHMM^ \ xwin-MMDD-HHMM^.diff Hope that helps, Harold
Re: Fwd: Re: Various starting X problems
Luke,
[EMAIL PROTECTED] wrote:
cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory
xinit: No such file or directory (errno 2): no program named
/usr/X11R6/bin/xterm in PATH
Something else must be wrong with your path.
I don't think so. FWIW, here is my full and ugly PATH, wrapped for
easy reading but no other changes:
Oh no, once again I am right on this one... read on for a full
explanation of what you need to tell us in the future when you have such
problems.
I think you have a custom ~/.xinitrc or your /etc/X11/xinit/xinitrc has
been modified. Or, you might have ~/.xserverrc or
/etc/X11/xinit/xserverrc (which are not installed by anything I have
written). Please send in any of these files if you find them so that we
can see what they are doing. For starters, they are obviously starting
a window manager, which is not something that the version from
X-startup-scripts-1.0.5-1 does.
I definitely have a custom .xinitrc file. In fact part of our site
post-install process was to create a default one, since initially
Cygwin's XFree didn't include it. I hadn't realised it was colliding
with one from Cygwin. Our standard site post-install creates the
~/.xinitrc. Sounds like I'd better try to back that out.
/etc/X11/xinit/xinitrc can be copied to ~/.xinitrc, but your copy looks
pretty close to stock except for the window manager that you are running.
How much does Cygwin's XFree depend on the (traditionally)
user-controlled .xinitrc file, to work properly? Does it also depend
on specific Cygwin things in ~/.Xresources?
Not sure what you are asking here... I don't think the things you are
worried about matter in this case.
I'll zip up and attach the files, anyway. I've included an XWin.log
from a failure when started with -multiwindow.
Archive: /u/luke/xwin.zip
Length Date TimeName
1698 04-01-04 14:22 .xinitrc
509 11-06-02 17:31 .Xresources
688 03-17-04 14:53 cygwin/startx.bat
3857 04-01-04 14:25 cygwin/tmp/XWin.log
---
6752 4 files
So if I remove the exec wmaker from .xinitrc, X starts and stops
instantly. So I add an xterm at the end of .xinitrc (since X doesn't
realise the wmaker would have started lots of windows from its saved
workspace state if it had been given a few seconds to run).
Yeah, you have to have a magic client that is started with an exec at
the end of your .xinitrc, otherwise the behavior that you described is
exactly what is supposed to happen.
Yep, I recognised the behaviour.
I think you can override the defaultserverargs in your .xinitrc so that
you could have a .xinitrc that both starts its own wm and prevents
startx from passing -multiwindow to XWin.exe. I'm not an xinit/startx
expert, so you'll have to look for docs on that elsewhere.
Are there any docs on -multiwindow and using the Windows desktop as
your window manager?
It looks like no window manager is running at all.
I wonder how I can run multiwindow with wmaker as my window manager?
Maybe keep the exec wmaker and set display to :1 ... No, startx
-multiwindow -- :1 triggers the no program named
/usr/X11R6/bin/xterm in PATH crash. So I don't quite see how to
achieve that. I tried xinit -multiwindow but that started up a full
desktop.
Seriously, the easiet way is to use startxwin.bat and modify it
according to the instructions in that file. Or, if you really want to
start from a Cygwin shell, use startxwin.sh and modify it accorinding to
its instructions. There are pre-made lines that are just commented out
that start a window manager etc.
Ah, yes, I knew there were some new startup scripts but I couldn't
remember what they were. I'm still using the version of /startx.bat
that I modified, and pointed to from a desktop shortcut I've set up.
Lets have you try these things first and see where it goes.
Absolutely. Thanks, Harold.
I tried startxwin.sh without a lot of joy. I can't see where it gets
its starting set of windows, and I can't see how to start up any
windows conveniently either. (Currently it has -multiwindow and
-clipboard hardwired in - it doesn't seem to do any argument
processing.)
I may change that and send you a revised one, if you'd be interested.
Perhaps my question is, why would anyone choose to run multiwindow
using the Windows desktop? There seems to be no easy way to start X
applications, except presumably from the command line.
It doesn't seem to use .xinitrc how I'd expect. Sure, if I add an
exec wmaker then it all fails because it thinks a window manager (the
Windows desktop) is running, and bails out. But if instead I add an
xmessage Quit X at the end instead, that never appears. I just end
up with the console window with yellow text on black background, and
an icon in the Windows tray, that I can use to exit X or unhide the
root window.
If I unhide the root window, then the X cursor
Computer upgrade complete and a nice biography treat
I've been meaning to inform the list that I was able to purchase an Athlon XP 2100+ for my system and it works great. Unfortunately, the low price of $50 that I was seeing was for a Thoroughbred chip while I needed a Palomino which ended up costing my $90. Thankfully the chip worked and my build times are down over 30% from my Athlon 1.2 GHz; the CPU is still pegged at 100% during builds so I know the speed is not being limited by memory throughput or hard drive throughput. A friend built the entire Cygwin/X distribution on his Pentium 4 2.8 GHz machine in just over 45 minutes; my relatively cheap upgrades have gotten me a 65 minute build time, which is great for me. Before I spoil the rest of the story, I was going to take some pictures of my upgraded system, and instead ended up doing a sort of mini biography of myself and my toys: http://msu.edu/~huntharo/bio/ Check it out, I hope you enjoy all of the pictures... oh yeah, there is a picture of me for all of you that are just starving to know what I look like after all of these years. ;) Harold
Re: startx crashes, xinit works
Luke, [EMAIL PROTECTED] wrote: I find that after installing the latest version of Cygwin just now, X crashes if I try to start it via startx (not starting with -rootless or -multiwindow), with the error There is only one way to prove that: send us the top of your /tmp/XWin.log from such a failed session. The top of XWin.log has a print out of the command-line parameters that reached the server, which will prove for good whether -multiwindow is reaching the server or not. wmaker fatal error: it seems that there is already a window manager running waiting for X server to shut down xterm: fatal IO error 104 (Connection reset by peer) or KillClient on X server :0.0 The Xwin.log ends with: winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. winClipboardProc - Call to select () failed: -1. Bailing. winClipboardProc - XDestroyWindow succeeded. ddxBeforeReset - Hello winClipboardIOErrorHandler! Oh yeah, -multiwindow reached the server all right... we wouldn't be starting multi-window mode if it didn't. Yet I can start it up if I run xinit. From 'startx': defaultserverargs=-multiwindow -clipboard You see, it is startx that sets the default arugments, not xinitrc. You can always just do startx -- :0, which provides server args of :0, thus overriding the defaultserverargs, thus preventing -multiwindow from being passed to XWin.exe. Give that a try. Note: The :0 doesn't change anything if you were already running on display number 0 before (this is the default), it is just used here as a dummy argument so that defaultserverargs are ignored. You could just as easily change this to startx -- :1 if you were always starting on display number 1 instead. Harld
Re: (patch seq: 5725) [Egbert Eich - Please review] Patch for makedepend/Imakefile when cross compiling
Well, that is about as worthless as tits on a boar. Harold Marc Aurele La France wrote: On Thu, 31 Jul 2003, Harold L Hunt II wrote: 1) Don't use canned default for PreIncDir when cross compiling. 2) Make a more sophisticated cannded default for StdIncDir when cross compiling: #define StdIncDir Concat(CrossCompileDir,/../include) Both from Alexander Gottwald (Cygwin/XFree86 project contributor). Attached are patches for both HEAD and xf-4_3-branch. Please apply both. I've just committed this to CVS HEAD. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals.
Re: Various starting X problems
Luke, [EMAIL PROTECTED] wrote: Now with the workaround of knowing to run startx -- :0 to get X to start, I thought I'd have a poke about to see what exactly makes it crash. I came up with several interesting problems. In my .xinitrc I *don't* have an explicit path for xterm. However, I see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other X applications also move into there? My system does not have a problem finding xterm in /usr/bin because /usr/bin should always be in your Cygwin shell path... something else is wrong with your Cygwin setup if that is not the case. I only noticed that xterm had moved because when I start X with -multiwindow (or with -clipboard), it complains like this and exits: $ PATH=$PATH:/usr/X11R6/bin startx -multiwindow -- :0 You shouldn't have to set the PATH to include /usr/X11R6/bin... as you said, it cannot find /usr/bin/xterm. XCOMM: not found Oops... that isn't supposed to be in the startx script. Those XCOMMs are supposed to be replaced with # signs at the beginning of the line. I've fixed this in a new version of the script. cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory xinit: No such file or directory (errno 2): no program named /usr/X11R6/bin/xterm in PATH Something else must be wrong with your path. However if I start it the same way, but without the -multiwindow, X starts successfully. (PATH=$PATH:/usr/X11R6/bin startx -- :0) If I try to start it with a plain startx (no --), I get the usual illegal option messages (related to having some kind of traditional Chinese or Japanese font installed, I vaguely think), and then it dies because it thinks a window manager is already running: $ PATH=$PATH:/usr/X11R6/bin startx cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory : illegal option -- t : illegal option -- r : illegal option -- a : illegal option -- d : illegal option -- i : illegal option -- t : illegal option -- i : illegal option -- o : illegal option -- n : illegal option -- a DISPLAY is :0 wmaker fatal error: it seems that there is already a window manager running xinit: Bad file descriptor (errno 9): can't send HUP to process group 3904 waiting for X server to shut down I think you have a custom ~/.xinitrc or your /etc/X11/xinit/xinitrc has been modified. Or, you might have ~/.xserverrc or /etc/X11/xinit/xserverrc (which are not installed by anything I have written). Please send in any of these files if you find them so that we can see what they are doing. For starters, they are obviously starting a window manager, which is not something that the version from X-startup-scripts-1.0.5-1 does. So if I remove the exec wmaker from .xinitrc, X starts and stops instantly. So I add an xterm at the end of .xinitrc (since X doesn't realise the wmaker would have started lots of windows from its saved workspace state if it had been given a few seconds to run). Yeah, you have to have a magic client that is started with an exec at the end of your .xinitrc, otherwise the behavior that you described is exactly what is supposed to happen. I think you can override the defaultserverargs in your .xinitrc so that you could have a .xinitrc that both starts its own wm and prevents startx from passing -multiwindow to XWin.exe. I'm not an xinit/startx expert, so you'll have to look for docs on that elsewhere. It looks like no window manager is running at all. I wonder how I can run multiwindow with wmaker as my window manager? Maybe keep the exec wmaker and set display to :1 ... No, startx -multiwindow -- :1 triggers the no program named /usr/X11R6/bin/xterm in PATH crash. So I don't quite see how to achieve that. I tried xinit -multiwindow but that started up a full desktop. Seriously, the easiet way is to use startxwin.bat and modify it according to the instructions in that file. Or, if you really want to start from a Cygwin shell, use startxwin.sh and modify it accorinding to its instructions. There are pre-made lines that are just commented out that start a window manager etc. Lets have you try these things first and see where it goes. Harold
Re: test case for clipboard hang?
Lev, Lev Bishop wrote: Well, I've kicked the -63 server around a fair bit this weekend and it seems to be holding up very well. That is good. No crashes, and generally no unpleasant surprises. I have still managed to activate the 2 second timeout code, though, by doing some pathological things, that are probably impossible to work around due to the incompatibilities between the X and Windows conceptions of the clipboard. No, this is because I didn't really fix the problem, as I mentioned in my release notes. The way I fixed it only happens if the X app you were using just happens to set only the PRIMARY selection; a slightly different form of the problem probably still exists if an X app sets only the CLIPBOARD selection. I know xterm sets only the PRIMARY seleciton, perhaps the app you were using sets only the CLIPBOARD selection. Also, there is no fundamental incompatibility here, only an imperfect handling of all of the cases that we need to handle. We can do this perfectly, it is just confusing and takes time to get it correct. So I am going to release 4.3.0-66 and you're going to test it. :) Harold: In winClipboardFlushXEvents, I think the line: iReturn = XChangeProperty (pDisplay, event.xselectionrequest.requestor, event.xselectionrequest.property, event.xselectionrequest.target, 8, PropModeReplace, (char *) atomTargetArr, sizeof (atomTargetArr)); should have 32 instead of 8. Seems logical to me. I changed it. I also changed the cast from (char *) to (unsigned char*) since that is what XChangeProperty is expecting. Also, re the following, changelog, can you tell me where to find the changes. I see no calls to XSync or select at http://pdx.freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xwin/winclipboardxevents.c?rev=1.1.4.1.2.15root=xorgonly_with_tag=CYGWINview=auto and I'd like to see the code that does this. Simple: I dropped that patch on the floor somewhere so it never got into CVS. I fixed it now. Thanks for the heads up. Its amazing that everything compiled and future patches kept applying even without those changes in there. Harold
Re: test case for clipboard hang?
Lev, Lev Bishop wrote: Also, there is no fundamental incompatibility here, only an imperfect handling of all of the cases that we need to handle. We can do this perfectly, it is just confusing and takes time to get it correct. So I am going to release 4.3.0-66 and you're going to test it. :) I think there is a fundamental incompatibility, due to the following. Windows thinks of the clipboard as a fixed, centralized thing, that doesn't change or delete data without specific user action (a useful conception from a user-friendliness point of view). X allows selections to change, get dropped due to the client getting disconnected, because the clipboard is not centralized but kept with each client (a useful conception when clients are accross a network from each other). Windows allows apps to delay rendering of clipboard data, but only insofar as from the user's point of view the behaviour is the same as if the data were saved to the clipboard in their final form at the time of the copy/cut action. That last sentence is not correct. Here is how delayed rendering works: http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/dataexchange/clipboard/clipboardoperations.asp?frame=true#_win32_Delayed_Rendering You'll notice in the clipboard integration source code that we advertise support for a format, but we only paste the data if it is still there; if the data is not there anymore, then we paste null data to satisfy the requirement that we paste something. This handles all of the cases were the X selection is lost for some reason or another and we are not notified about it synchronously. An implication of this is that if the clipboard holds the same data in multiple formats, all the formats should still be the same data, eg, the same string in unicode and ascii. No, that is not correct. I can advertise CF_TEXT and CF_BITMAP and have a text that says goat and a bitmap rendering of a frog if I want. There is no requirement that the formats all contain the same data. Can you see a problem? It is possible (and I have done it) for there to be 4 different conceptions of the clipboard, all holding different data! To demonstrate this, do something like: assert the PRIMARY selection by selecting text in an xterm; assert the CLIPBOARD selection by running xclipboard; type some text into xlipboard and paste the text as unicode into windows, eg edit-paste in excel; change the text in xclipboard and paste the text as plain text, eg using paste special in excel; finally change the text in xclipboard. At this point, there are 4 different clipbaord contents, no two of them the same. X clients that ask for PRIMARY get one thing, ones that ask for CLIPBOARD get another, windows apps get 2 different things depending on whether they ask for unicode or plain text. This breaks the windows clipboard idiom of the data being fixed and immutable, and the clipboard being a consistent concept with just one thing in it, stored in different formats. I think part of what is happening here is that you are getting confused by the feature I added that intentionally lets PRIMARY and CLIPBOARD be different in X and only advertises the most recently changed one to Windows. However, it sounds like you may have found some sort of bug in the unicode handling... could you elaborate on what gets pasted if a in the cases were a Win32 app requests non-unicode and another Win32 app requests unicode text? Another issue is that in windows, data doesn't get deleted from the clipboard unless you specifically ask it to be, or replace it with something new. No, it does when you use delayed rendering, which is part of the reason we use delayed rendering. This is not a big deal: we advertised something, it disappeared, *important* no other X or Win32 app placed something on the clipboard after we did, and we say oops, the data is missing, sorry. What is the problem there? We owned the clipboard and didn't disrupt any other application from using it. Especially, if you've successfully pasted something, demonstrating that the clipboard has the data you want, that data won't disappear unless you do something to get rid of it. You must not have worked with applications that give you the famous you have copied a large amount of data to the clipboard, would you like to remove it to same memory dialog box that pops up a few minutes after copying large data to the clipboard; some apps that use delayed rendering do the same thing when they exit but without warning: they just don't paste anything when they get a WM_RENDERALLFORMATS on exit. Now, the x PRIMARY selection is much more ephemeral than this, and it gets dropped all the time. The recent patches in -63 mean that the windows clipboard (correctly) gets cleared at the same time as the selection is dropped, if the text has not yet been rendered. Yes, that is correct. However, after pasting from X to windows, the clipboard doesn't
Re: lesstif 0.93.94 and the attempt to add non-widget ... error
Volker,
Thanks, I'll try to make a new 'test' lesstif release soon.
Harold
Volker Quetschke wrote:
Sorry I can't be more helpful than this right now. LtXmFixupVendorShell
is not working. Find out why.
Thanks Brian,
there was a patch to lib/Xm/Vendor.c that corrects for the (shared)
library loading mechanism, but it was missing for lib/Xm-2.1/Vendor.c.
I attach the changed lesstif-0.93.94-2.patch and lesstif-0.93.94-2.sh
files, the lesstif.README is already updated, so it should be zero
work to produce a new release ;)
The changes in the build script are the ones previously
described plus:
cd ${topdir} \
diff -urN -x '.build' -x '.inst' -x '.sinst' \
-x 'configure' -x 'Makefile.in' -x 'aclocal.m4' -x 'depcomp' \
+-x 'compile' -x 'config.*' -x 'ltmain.sh' -x 'missing' -x '*~' \
${PKG}-${VER}-orig ${PKG}-${VER} \
${srcinstdir}/${src_patch_name} ; \
rm -rf ${PKG}-${VER}-orig )
Oh, I forgot to say, this lesstif version not only fixes the
attempt to add non-widget ... error, but also fixes the
crash of grace 5.1.14 when double-clicking on the axes :-)
Volker
Re: lesstif 0.93.94 and the attempt to add non-widget ... error
Just send them to me privately. Harold Volker Quetschke wrote: Harold L Hunt II wrote: Thanks, I'll try to make a new 'test' lesstif release soon. Hmm, I wonder where my second mail is, I forgot to attach the patch and shell scipt to my first mail, but the second with zip attachment is missing ?! Volker
Re: lesstif 0.93.94 and the attempt to add non-widget ... error
Volker, I just posted lesstif-0.93.94-2 as a 'test' package. Please download it tomorrow and very that it works correctly. If you get a chance, try it out with 'nedit'... if it works well with nedit then I might mark this as 'curr'. Harold
Re: invalid Window parameter error through ssh X forwarding
Replace 'ssh -X' with 'ssh -Y'. Harold Richard Gourdeau wrote: I have just upgraded my xfree-cygwin setup (Xwin serv Release 4.3.0-64, etc.). Some apps that worked through ssh without any problem with my previous setup (Xwin serv Release 4.3.0-58, etc.) are now exiting with errors messages related to an invalid Window parameter. For example, in a xterm after an ssh connect with X forwarding, gftp starts but as soon as I try to select a menu item, I get the following error: === [EMAIL PROTECTED] gourdeau]$ gftp [1] 13684 [EMAIL PROTECTED] gourdeau]$ Gdk-ERROR **: BadWindow (invalid Window parameter) serial 3647 error_code 3 request_code 38 minor_code 0 Gdk-ERROR **: BadAccess (attempt to access private resource denied) serial 3648 error_code 10 request_code 102 minor_code 0 [1]+ Exit 1 gftp === I have notice that the mouse cursor remains as an X and does not change to an arrow when moved over the gftp application. I am using the startxwin.sh script from the distribution (unmodified) to start Xwin in multiwindow mode. Should I specify some optional parameters or is this a known problem ?
Re: test case for clipboard hang?
Ed, Ed Avis wrote: Harold L Hunt II huntharo at msu.edu writes: 1) Reboot 2) start a fresh xwin, xterm, notepad, and put some text in the xterm and notepad 3) select, ^C copy from notepad, middle-click in xterm. it pastes successfully 4) select in xterm, leave the text reverse-videoed 5) ^V paste into notepad (successfully) 6) drop the selection in xterm (by left clicking somewhere) 7) ^V paste into notepad (successfully, even though the selection is dropped) 8) select a different piece of text in xterm. 9) drop the selection in xterm 10) ^V paste into notepad: it hangs for a few seconds and doesn't paste. (The paste menu option is NOT greyed out at this point). I'd really appreciate some feedback on the new fix in XFree86-xserv-4.3.0-63, which should be hitting mirrors within a few hours. Yes, I can reproduce the hang with 4.3.0-50 (actually, I used xemacs not xterm) but it does not hang in 4.3.0-63. After I drop the X selection it is no longer in the Windows clipboard, so that I cannot paste into Notepad. Thank you. It is good to know that this is confirmed as fixed for the time being. I don't know if this is consistent with cut and paste on a native X desktop, but it is a massive improvement over hanging. Thanks! I'm willing to be it is consistent. We monitor the PRIMARY and CLIPBOARD selections... most apps set one or the other. We still advertise to Win32 that we have data to paste if either PRIMARY or CLIPBOARD is owned by an X application other than the clipboard integration manager. The problem before was that we didn't stop advertising data to paste when both PRIMARY and CLIPBOARD were not owned by valid X applications; the reason for this is that the clipboard manager looked like a valid X app and it owned at least one of PRIMARY and CLIPBOARD still, so we kept advertising data to paste. The failure mode for this was inconsistent: the first time seemed to grab data from the X application that used to own the selection while the second time might have tried grabbing data from the clipboard manager for the clipboard manager to paste, which lead to a deadlock. Simple test case: don't use -clipboard, select some text in a xterm, unselect it, then right-click in another xterm... I don't think you'll see any text pasted unless there is a clipboard manager of some sort running (i.e. don't do this in Xdmcp). Harold
Re: A suggestion (XWin.n) and a question (run.exe).
Rodrigo, Rodrigo Medina wrote: I can do the patch, but I need to know from where to obtain the exact information. The file to patch is here: http://pdx.freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xwin/XWin.man?root=xorgonly_with_tag=CYGWIN There are instructions for pulling down our CVS tree here: http://x.cygwin.com/devel/server/ The User's Guide documentation will be helpful (the man page should contain at least the information in the User's Guide section on command-line parameters): http://x.cygwin.com/docs/ug/configure-cygwin-x-options.html The definitive resource for command-line parameters specific to XWin.exe is in winprocarg.c: http://pdx.freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xwin/Attic/winprocarg.c?root=xorgonly_with_tag=CYGWIN A helpful guide for which parameters cannot be used together is in winvalargs.c: http://pdx.freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xwin/Attic/winvalargs.c?root=xorgonly_with_tag=CYGWIN Finally, I usually describe how to use a new command-line parameter in the Change Log when the new parameter was introduced. So, go to the change log and do a quick search for a particular parameter that you see in winprocarg.c to get some information about what it does. Here is the full change log: http://x.cygwin.com/devel/server/changelog-full.html I hope that helps. I will really appreciate an updated man page. Harold
Re: Documentaiton of .XWinrc?
David, David Arnstein wrote: I'm searching for documentation of the file .XWinrc. I have no man page for this file, although the man page for XWin refers to a man page in section 5 for .XWinrc. I could not find any mention of .XWinrc in the cygwin-xfree users guide. See the second-to-last item: http://x.cygwin.com/devel/todo.html I suggest that both of the above two sources of information should be updated. I found an old posting to this mailing list that referenced http://www.msu.edu/~huntharo/xwin/devel/server/example.XWinrc. Is this the only documentation that is available? For now, until somebody writes the additional documentation that you would like. Harold
Re: Modal and AOT exit dialog
Takuma, Takuma Murakami wrote: I have been considering to change the exit confirmation dialog to a modal and always-on-top one (shown by MessageBox()). I know that a MessageBox won't work well because it interrupts our message processing and blocks our main thread until the user clicks the box. Think if they clicked it on accident then went to get coffe. They would come back and XWin.exe would be terminated because its message queue overflowed. Not good :) The benefits of this change are: - We can easily change the message at runtime. I want to print the number of connected clients each time it is shown. This can easily be done in the curent dialog box. It is easy to set text in a control on a dialog box. You would do it in windialogs.c/winExitDlgProc/WM_INITDIALOG using the function SetDlgItemInt() from the Win32 API. It is really easy. - We won't lose the dialog since it remains on the top. This can be done already with the dialog too... we just have to change the style of the window. - We can let Windows place it instead of winCenterDialog(). The position will be intrinsically correct (winCenterDialog() gives different position in multi-monitor settings). I think we can tweak winCenterDialog to make it show the same position as MessageBox would put it in. Shouldn't be hard. In fact, it might be really easy. I ask this because I don't know the reason why it was implemented as a separate non-modal window. I will start this change if there is no particular reason. Well, it was originally done with a MessageBox (I don't know if I ever released it that way) and the shortcomings became apparent quite quickly. Please don't make this change, lets just modify the current dialog box and other functions to achieve your goals. Harold
Re: About box
Igor, Igor Pechtchanski wrote: [snip] Harold, In many applications, the Exit? box is modal and AOT, which is fine, because it's not expected to stay on the screen for a long time. Thus, it doesn't need a taskbar entry, IMO. That is an alternative. The situation is different with the About box, since it depends on the intent of that box. If it's intended for the users to just quickly see what the version is, it should probably also be modal and AOT with no taskbar entry. However, if you intend people to copy information out of this box, or open other windows while this box is visible (especially now that there are links in it), that box should probably have a taskbar entry. FWIW, Exceed's one is non-modal, not AOT, and has no taskbar entry, which is rather annoying. I think the window may get left open, especially since it will be annoying to use the links if it is AOT. That seems to indicate that it needs a taskbar entry to me. One more thing that Exceed does that the Cygwin/X server doesn't is detect when display resolution has changed, and offer to perform a server reset, like this (also see the attached PNG file): [snip] IMO, this is not very useful when changing resolutions, and, despite the warning, I've noticed no problems with always refusing the server reset, but I suspect that with more serious changes (e.g., changes in color depth) it may be necessary. Actually, we do have a dialog box that indicates when you have made a dangerous display change (such as color depth going from 32 bpp to 256 color). The only change I would make here would be to finally support RANDR to allow resizing the root window to match the new screen resolution. Harold
Re: Modal and AOT exit dialog
Takuma, I just checked in a framework for you to display the number of connected clients in the Exit box. All that is left for you to do is to go to windialogs.c/winExitDlgProc/WM_INITDIALOG and set the value to iConnectedClients to whatever the number of connected clients is. :) Harold
Change log split again
For anyone paying attention, the change log has been split again: http://x.cygwin.com/devel/server/changelog.html Versions 4.3.0-62 through 4.3.0-38 are now on their own page as are versions 4.3.0-63+. The default changelog link above is for 4.3.0-63+ and all older sets of changes are linked to from there, as well a a Full change log that has all sets of changes in proper order all the way back to March 2001. Wow, a week ago was the three year aniversary of my first test releases using shadow framebuffer to work on non-NT platforms. Harold
LinuxWorld Expo - San Francisco - August 2-5, 2004
I will most likely be attending at least part of the LinuxWorld Expo in San Francisco coming up in the beginning of August: http://www.linuxworldexpo.com/linuxworldny/V40/index.cvn?ID=10029 There will be a lot of X folks there (most likely Jim Gettys, Keith Packard, Egbert Eich (I hope), and more); I estimate the number at over 10. We will be having discussions and there will most likely be time to grab dinner or lunch as a group a few times and possibly even drink a few beers for those with proof of age. :) I'm going to be living in San Jose from the end up May, which means I'll be passing through Sunnyvale, Palo Alto (I think), Stanford, and the southern part of San Francisco on my drive up. Contact me privately if the only reason you couldn't make it would be because you have no way to get up there for the day (I'll most likely be driving home each night that I go up). Alternatively, if there are a lot of us maybe we can all ride the train together... I think there is one that goes up to San Francisco from San Jose. Mark your calenders if you are interested and start looking into a cheap way to get there... I'd love to see as many Cygwin/X folks there as possible, especially developers that can come to any meetings and have a say in the future of X if they want to. Harold
Re: twm dying with multi-byte font handling?
Haro, [EMAIL PROTECTED] wrote: [snip] My problem seems to be same as other thread with subject: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support When I stopped the 'cygserver' service, everything seems to run OK. Thanks for your input, Oh, Corinna is working on the cygserver-related crashes. Please continue to follow her announcements for information on when this problem is fixed. Harold
Re: About box
Earle, Earle F. Philhower III wrote: Howdy Harold, At 01:49 PM 3/26/2004 -0500, Harold wrote: Earle F. Philhower, III wrote: ...I can submit some simple code that does the overridden windowproc (makes the pointer a little hand when you've over the icon, too!), but don't want to push the issue since it's more of a style than substance issue... By all means, please just commit code that does blue links in the dialog box. I was aiming to do that and didn't see a way to do it the first time through. Done, but for some reason the CVS commit list has put me back in the requires moderator approval class of user (the last change I did, the commit email came back just fine w/o moderator intervention AFAICT)... Thanks. I made a small change to your accounts. The nodupes flag was set in mailman, while a lot of other people (myself, Takuma, Kensuke, and Alexander included) don't have it set. I doubt it was related, but it was the only difference between our accounts that I could find. Let me know if it helps, otherwise I will ask around for more help. As long as you ping me I can go in and approve the messages that are held for moderation. Harold
xorg-commit-diffs list available
For anyone that doesn't know, there is now another mailing list on freedesktop.org that sends complete diffs for CVS commit message as the old xorg-commit list used to do. The name of the list is xorg-commit-diffs and you can subscribe here: http://freedesktop.org/mailman/listinfo/xorg-commit-diffs Harold
Re: About box
Earle, Earle F. Philhower III wrote: Howdy Harold, At 01:49 PM 3/26/2004 -0500, Harold wrote: Earle F. Philhower, III wrote: ...I can submit some simple code that does the overridden windowproc (makes the pointer a little hand when you've over the icon, too!), but don't want to push the issue since it's more of a style than substance issue... By all means, please just commit code that does blue links in the dialog box. I was aiming to do that and didn't see a way to do it the first time through. Done, but for some reason the CVS commit list has put me back in the requires moderator approval class of user (the last change I did, the commit email came back just fine w/o moderator intervention AFAICT)... Part of me wonders if our About box and possibly our Exit box should get taskbar entries... without them they are easy to lose behind other windows and then they are difficult to retrieve. What do you think? Harold
Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support
Corinna Vinschen wrote: On Mar 25 13:38, Harold L Hunt II wrote: Volker, Using the Cygwin Way-Back Machine (http://cygwin.get-software.com/release/XFree86/XFree86-xserv/) I have retrieved a copy of XFree86-xserv-4.3.0-55 which is immediately prior to the change from cygserver to cygipc. I would like you to test this version and verify whether you can or cannot reproduce the problem with cygipc. It is always possible that this is just a bug in the big font extension that we have not noticed before. To retrieve the -55 version, point setup.exe to: http://www.egr.msu.edu/~huntharo/cygwin_old/ That's a good idea, thank you. No problem. Other than that, I'm not at all familar with that stuff. How can I set up a minimal test system, so that it uses the bigfont extension and, especially, IPC? Yesterday I just started cygserver, XWin and uxterm, and it doesn't use IPC by default, apparently. As long as you have cygserver started and CYGWIN=server defined in a way that XWin can see it from however you are starting it, then you should *not* see the following around line 40 in /tmp/XWin.log: MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel If those lines are missing then shared memory is being used. There is no positive indication in the log that shared memory is being used, just the absence of the negative indication. Hope that helps, Harold
Re: Pathnames for X server app-defaults etc.
Ruth Ivimey-Cook wrote: On Thu, 2004-03-25 at 16:39, Harold L Hunt II wrote: Please look at my message about your installation being out of date. Harold I had previously tried a setup.exe 'reinstall' and also uninstalling xserv and installing it from the easynet.be mirror, neither worked. However, last night I tried deleting everything cygwin - not as easy as it sounds as there are some 'undeletable' link files - and reinstalling it all from uni-erlangen.de. This worked. So I must conclude that mirror.ac.uk at least, and possibly easynet.be, are poor mirror choices :-( Both of those mirrors look to be up to date to me. It would be rather nice if setup had a way of verifying that the packages it loads are self-consistent. No, I think your 'undeletable' link files is a clue... there had to be something messed up with your installation. It probably won't happen again since you deleted and reinstalled. Harold
Re: About box
Christopher Faylor wrote: On Thu, Mar 25, 2004 at 10:44:42PM -0500, Harold L Hunt II wrote: Okay, I did it myself. We now have an About box that can be opened from the tray icon menu. The About box contains four buttons that link to our website (x.cygwin.com), our User's Guide on the website, our FAQ on the website, and our ChangeLog that is installed locally with the XFree86-xserv package. I would like to modify this slightly in the future to check if the User's Guide and FAQ have been installed locally (via the cygwin-x-doc package) and to open those local documents instead of going out to the web everytime. The About box is neat, check it out in XFree86-xserv-4.3.0-62 when it hits mirrors soon. Sounds cool. Any chance that it could also contain a link to the main cygwin web site, too? Yeah, I think that could be done. I was also just talking to some people that frequently visit the Cygwin web site, but had no idea that the Cygwin/X web site even existed. It seems that it would be useful to add a short blurb on the main Cygwin site that says something like Try Cygwin/X for a full-featured free X Server for Windows including clipboard integration, desktop integration, and more. I don't want to add that right away, but do you see a problem with my doing so in the near future? Harold
Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)
Earle, Earle F. Philhower III wrote: Howdy Harold, At 12:00 AM 3/26/2004 -0500, Harold wrote: Nope, not going to beat you to it. This issue is what I was referring to when I said that Earle should probably look at the PixmapBytePad patch to make sure it was complete. :) There's a saying I've learned from my verification engineers: If you don't test it, it won't work! WinXP doesn't list 24bpp mode anymore, VICE doesn't compile under cygwin w/o work, and I'm not likely to shell out $$M to buy an Oracle DB. :) To top it off, freedesktop's CVS /tmp disk is out of space so CVS isn't working. Ouch! I did some unit-testing of the undocumented BitsPerPixel() macro, and it seems to be what's needed. Changing line 74 to effXBPP = BitsPerPixel(pixmap-drawable.depth); will set it to 32 when given a 24-bpp drawable, giving a pixel stride of 4 bytes as desired. It also doesn't break any of the 1-, 16-, or 32-bit icons that I was able to test (the return values of BPP() match expected there too), but I still have no 24-bpp icons to try. I'll try the commit again tomorrow morning, but if Fabrizio wants to beat up his local copy before then and report back it'd be appreciated! Okay, sounds good to me. Also, I think you mentioned that 1 bit pixmaps were messed up. If that is still the case, it is because the GDI DIB 1 bit bitmap has a reversed byte order. So, you'll have to swap the byte order for 1 bit pixmaps when you convert them. Give that a try and let me know if it works... ping me as soon as you look into it cause I'm really wondering if that will fix it. This was way back when I was first writing it, IIRC. I don't think I've seen any 1-bit icon problems or heard of any (except for the complaint that xcalc's scaled icon was ugly) since. If someone has a specific problem I'll look into it, but 1-bit is working 100% AFAIK... Huh... okay. I thought the xcalc icon problem was probably due to byte ordering, but if it is just scaling then my suggestion obviously has nothing to do with it. I was going to suggest writing a super-duper anti-aliasing icon scaler, but it would seem like a waste of effort for 1 bit icons. There are so many other things that would not be a waste of effort... Harold
Re: About box
Christopher Faylor wrote: On Fri, Mar 26, 2004 at 11:04:27AM -0500, Christopher Faylor wrote: On Fri, Mar 26, 2004 at 10:24:41AM -0500, Harold L Hunt II wrote: Christopher Faylor wrote: On Thu, Mar 25, 2004 at 10:44:42PM -0500, Harold L Hunt II wrote: Okay, I did it myself. We now have an About box that can be opened from the tray icon menu. The About box contains four buttons that link to our website (x.cygwin.com), our User's Guide on the website, our FAQ on the website, and our ChangeLog that is installed locally with the XFree86-xserv package. I would like to modify this slightly in the future to check if the User's Guide and FAQ have been installed locally (via the cygwin-x-doc package) and to open those local documents instead of going out to the web everytime. The About box is neat, check it out in XFree86-xserv-4.3.0-62 when it hits mirrors soon. Sounds cool. Any chance that it could also contain a link to the main cygwin web site, too? Yeah, I think that could be done. I was also just talking to some people that frequently visit the Cygwin web site, but had no idea that the Cygwin/X web site even existed. It seems that it would be useful to add a short blurb on the main Cygwin site that says something like Try Cygwin/X for a full-featured free X Server for Windows including clipboard integration, desktop integration, and more. I don't want to add that right away, but do you see a problem with my doing so in the near future? There is a link at the side to X11. If you think that's unclear then change it to something clearer. If you want to advertise releases in the news page that's fine, too. I don't think special dispensation for the Cygwin/X project is appropriate for the main page. And, if this seems inconsistent with my asking for a cygwin link in the About box, then feel free to ignore my request... Yes, it seems inconsistent to me. Cygwin/X is different than a port of package foo to Cygwin: Cygwin/X is an integral piece of Cygwin and runs *only* on Cygwin; it is much more important than a port. The reason I brought it up is that I had three people telling me they had been using Cygwin for years and never even thought that a Cygwin/X page existed. They all requested that a blurb be put on the main Cygwin page so that people will actually see it. Their complaint about the link in the left bar is that it looked like just another part of the Cygwin pages, not an entire web site by itself. Harold
