RE: Cygwin/XWin - winkeybd.c/winKeybdBell(...) not being called?
John, *You* screwed up in two major ways, not me: 1) You emailed me directly. I do not appreciate email sent to me from people wishing to deal with the Cygwin/XFree86 project. I do not need your permission to forward such emails to the mailing list. 2) You did not inform me at the top of the email that you were protective of your email address. If you had, I would have simply deleted your email rather than forwarding it to the mailing list. You have to remember that with the Internet, you have to look out for yourself. If you are truly concerned about the protection of your email address, then you should be using temporary accounts for any emails that you SPAM project leaders with. Yup, you spammed me. You sent me an unsolicited personel email rather than sending it to the project that I work on. Thanks, now go away, Harold P.S. You will notice that I have taken the care to remove your email addresses from the bottom of this message. Harold, Thank you for your reply, however I would have appreciated it if you had *not* forwarded my query directly to the mailing list. I am quite capable of sending such an email myself. I've had very bad experiences with spam originating from www mailing list archives and I would not have included my signature which has now been archived onto the web: http://www.cygwin.com/ml/cygwin-xfree/2002-03/msg00266.html If you can now *remove* that message from the list archive, I would be most grateful. It includes my `' address quoted as-is, which I have tried *extremely* hard to keep from spammers. I'd assume that normally signatures are removed by the list, however you had quoted my message and so it remained. John. On Wed, Jul 24, 2002 at 12:20:58AM -0400, Harold Hunt wrote: John, You are asking a question of the Cygwin/XFree86 project. As such, you need to send all correspondence regarding Cygwin/XFree86 to [EMAIL PROTECTED] I cannot answer email sent directly to me. Note: I have forwarded your question to [EMAIL PROTECTED] Harold
RE: problems with XFree
Harold, thanks for the suggestions. I was hoping that oue of them would solve the problem. I checked and found only one cygwin1.dll on the system. It's dated 5 July. I update frequently using setup.exe. I agree with you assessment of Windows. However, my problem isn't the BSOD but XFree86 seg fault. Windows keeps on working and the (apparent) memory leak resolves itself after CFree86 croaks. Let me know if there is anything else I can do on my end to identify the problem. Thanks, Tom Tom, Have you sent in the contents of /tmp/XWin.log from a time when this problem happens? Harold
Re: Help with fixing x2x...
Hmmm. I tried your suggestion and the behavior has not changed. It's
still gobbling up 99% of the CPU. Suspecting that select() is not blocking
like it should, I inserted printf(Hello\n); just before the select()
function call. Now when I run x2x I get a continuous stream of Hellos on
STDOUT whether or not I'm moving the mouse or typing.
By comparison, I compiled x2x on my AIX workstation, including the Hello
addition. When I run x2x there, I observe that it only prints Hello when
I move the mouse or hit a key. This seems to me to be the appropriate
behavior.
This little experiment implicates the select() function call itself as being
the source of the trouble. Now the question is, is it a problem with how
select() is being used (and if so, is the problem at the Xserver or the
Xclient end), or is there a problem with the Cygwin implementation of it?
Are you aware of any Xclients which use select() and yet do not exhibit the
non-blocking behavior I'm seeing? Perhaps there is a minor tweak required
in how it is being called.
From: Harold L Hunt II [EMAIL PROTECTED]
To: Thomas Chadwick [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Help with fixing x2x...
Date: Tue, 23 Jul 2002 18:58:15 -0400
Thomas,
In x2x, the return value from ProcessEvent which indicates that everything
went normally is False, not True. The real intentions for the return value
of ProcessEvent can be described by the boolean variable called
``bAbortedDisconnect'' that is returned from ProcessMotionNotify. Much
more on that below but for now,
Ohmygodthatisfunny!!!
In the loop, the code does this:
1) Check for an event on fromDpy. XPending returns immediately.
2) Process the event for fromDpy if an event was pending. If we processed
an event successfully, continue looping. Else, the ProcessEvent function
returned True and we are supposed to shutdown, thus the ``break''.
3) Check for an event on toDpy. XPending returns immediately.
4) Process the event for toDpy if an event was pending. If we processed an
event successfully, continue looping. Else, the ProcessEvent function
returned True and we are supposed to shutdown, thus the ``break''.
5) Else, if we did not process an event from either screen, wait until one
or both o fthe file handles that represent the display event queues becomes
ready for reading.
I think that your infinite loop has to do with the fact that XPending
returns a count of events ready for reading in fromPending, rather than a
boolean value. I think that (!fromPending) had the desired effect on the
developer's platform of determining that (fromPending == 0), but that is a
highly compiler-dependent assumption on behalf of the original developer.
For clarity, I would rewrite the section as follows (notice the correction
in the ``else if''):
while (True) /* FOREVER */
{
/* Save the number of event ready for fromDpy */
fromPending = XPending(fromDpy);
/* Process any events ready for fromDpy */
if (fromPending != 0)
if (ProcessEvent(fromDpy, dpyInfo)) /* shutdown if True! */
break;
/* Process any events ready for toDpy */
if (XPending(toDpy))
{
if (ProcessEvent(toDpy, dpyInfo)) /* shutdown if True! */
break;
}
else if (fromPending == 0)
{
/* No events ready for either display. Wait for an event. */
FD_ZERO(fdset);
FD_SET(fromConn, fdset);
FD_SET(toConn, fdset);
select(nfds, fdset, NULL, NULL, NULL);
}
} /* END FOREVER */
Now, for the excitement about the bAbortedDisconnect variable from
ProcessMotionNotify:
It looks like the original programmer is using some sort of consistency
checking on MotionNotify events to determine that the X server is shutting
down. I will have to look into this further, but it looks promising from
my initial inspection. This is the final step that I need for xwinclip to
function properly on server resets and shutdowns. Needless to say,
hopefully I am seeing what I want to see :)
Harold
Thomas Chadwick wrote:
I recently discovered that when I run x2x, the Win2k Task Manager reports
that it's using 90-99% of the CPU.
While I have not noticed a slow down in performance when it's running, I'd
like to fix it if I can. I've poked around in the source and I don't like
the looks of the main loop:
while (True) { /* FOREVER */
if (fromPending = XPending(fromDpy))
if (ProcessEvent(fromDpy, dpyInfo)) /* done! */
break;
if (XPending(toDpy)) {
if (ProcessEvent(toDpy, dpyInfo)) /* done! */
break;
} else if (!fromPending) {
FD_ZERO(fdset);
FD_SET(fromConn, fdset);
FD_SET(toConn, fdset);
select(nfds, fdset, NULL, NULL, NULL);
}
It would appear to me that this constant polling for
RE: Help with fixing x2x...
I added a printf statement and sure enough, the return value of select is
-1. I then tried printf'ing the value returned by WSAGetLastError. To make
a long story short, I wound up having to comment out the includes for
sys/types.h and sys/time.h and include w32api/winsock.h instead to get
it to succesfully compile x2x.o; and I had to add -lwsock32 in the Makefile
to get it to successfully link x2x.exe.
After doing this, select is still non-blocking, returning -1, and the value
returned by WSAGetLastError() is 10038, which seems to correspond to the
#define WSAENOTSOCK in winsock.h.
Any idea what this error code means and what steps I might take to fix it?
From: Jean-Claude Gervais [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: Help with fixing x2x...
Date: Wed, 24 Jul 2002 11:58:41 -0400
Have you checked what select is returning?
I remember there were differences in how an FD_SET was used in Win32 and
UNIX.
Also, since select is probably returning -1, call WSAGetlastError and check
what the code is.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Thomas Chadwick
Sent: Wednesday, July 24, 2002 11:41 AM
To: [EMAIL PROTECTED]
Subject: Re: Help with fixing x2x...
Hmmm. I tried your suggestion and the behavior has not changed. It's
still gobbling up 99% of the CPU. Suspecting that select() is not blocking
like it should, I inserted printf(Hello\n); just before the select()
function call. Now when I run x2x I get a continuous stream of Hellos on
STDOUT whether or not I'm moving the mouse or typing.
By comparison, I compiled x2x on my AIX workstation, including the Hello
addition. When I run x2x there, I observe that it only prints Hello when
I move the mouse or hit a key. This seems to me to be the appropriate
behavior.
This little experiment implicates the select() function call itself as
being
the source of the trouble. Now the question is, is it a problem with how
select() is being used (and if so, is the problem at the Xserver or the
Xclient end), or is there a problem with the Cygwin implementation of it?
Are you aware of any Xclients which use select() and yet do not exhibit the
non-blocking behavior I'm seeing? Perhaps there is a minor tweak required
in how it is being called.
From: Harold L Hunt II [EMAIL PROTECTED]
To: Thomas Chadwick [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Help with fixing x2x...
Date: Tue, 23 Jul 2002 18:58:15 -0400
Thomas,
In x2x, the return value from ProcessEvent which indicates that
everything
went normally is False, not True. The real intentions for the return
value
of ProcessEvent can be described by the boolean variable called
``bAbortedDisconnect'' that is returned from ProcessMotionNotify. Much
more on that below but for now,
Ohmygodthatisfunny!!!
In the loop, the code does this:
1) Check for an event on fromDpy. XPending returns immediately.
2) Process the event for fromDpy if an event was pending. If we
processed
an event successfully, continue looping. Else, the ProcessEvent function
returned True and we are supposed to shutdown, thus the ``break''.
3) Check for an event on toDpy. XPending returns immediately.
4) Process the event for toDpy if an event was pending. If we processed
an
event successfully, continue looping. Else, the ProcessEvent function
returned True and we are supposed to shutdown, thus the ``break''.
5) Else, if we did not process an event from either screen, wait until
one
or both o fthe file handles that represent the display event queues
becomes
ready for reading.
I think that your infinite loop has to do with the fact that XPending
returns a count of events ready for reading in fromPending, rather than a
boolean value. I think that (!fromPending) had the desired effect on the
developer's platform of determining that (fromPending == 0), but that is
a
highly compiler-dependent assumption on behalf of the original developer.
For clarity, I would rewrite the section as follows (notice the
correction
in the ``else if''):
while (True) /* FOREVER */
{
/* Save the number of event ready for fromDpy */
fromPending = XPending(fromDpy);
/* Process any events ready for fromDpy */
if (fromPending != 0)
if (ProcessEvent(fromDpy, dpyInfo)) /* shutdown if True! */
break;
/* Process any events ready for toDpy */
if (XPending(toDpy))
{
if (ProcessEvent(toDpy, dpyInfo)) /* shutdown if True! */
break;
}
else if (fromPending == 0)
{
/* No events ready for either display. Wait for an event. */
FD_ZERO(fdset);
FD_SET(fromConn, fdset);
FD_SET(toConn, fdset);
select(nfds, fdset, NULL, NULL, NULL);
}
} /* END FOREVER */
Re: Help with fixing x2x...
Thomas Chadwick wrote: I added a printf statement and sure enough, the return value of select is -1. I then tried printf'ing the value returned by WSAGetLastError. To make a long story short, I wound up having to comment out the includes for sys/types.h and sys/time.h and include w32api/winsock.h instead to get it to succesfully compile x2x.o; and I had to add -lwsock32 in the Makefile to get it to successfully link x2x.exe. After doing this, select is still non-blocking, returning -1, and the value returned by WSAGetLastError() is 10038, which seems to correspond to the #define WSAENOTSOCK in winsock.h. Any idea what this error code means and what steps I might take to fix it? Thomas, Revert those include and Makefile changes. You do not want to use Winsock, you want to use Cygwin's sockets. Test the rewritten function that I just sent to the list. Harold
Re: Help with fixing x2x...
Thomas Chadwick [EMAIL PROTECTED] wrote: After doing this, select is still non-blocking, returning -1, and the value returned by WSAGetLastError() is 10038, which seems to correspond to the #define WSAENOTSOCK in winsock.h. Any idea what this error code means and what steps I might take to fix it? It would be (perhaps more) instructive to print out errno (rather than the WSA errno) since errno is what select(2) sets. As a matter of interest (since I'm currently fiddling around with some similar code), are the two file descriptors UNIX domain sockets? HTH // Conrad
RE: Help with fixing x2x...
Sounds like one of the sockets in the FD set is not a socket? Could you post enough of the code so we could see? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Conrad Scott Sent: Wednesday, July 24, 2002 3:28 PM To: [EMAIL PROTECTED] Subject: Re: Help with fixing x2x... Thomas Chadwick [EMAIL PROTECTED] wrote: After doing this, select is still non-blocking, returning -1, and the value returned by WSAGetLastError() is 10038, which seems to correspond to the #define WSAENOTSOCK in winsock.h. Any idea what this error code means and what steps I might take to fix it? It would be (perhaps more) instructive to print out errno (rather than the WSA errno) since errno is what select(2) sets. As a matter of interest (since I'm currently fiddling around with some similar code), are the two file descriptors UNIX domain sockets? HTH // Conrad
RE: problems with XFree
Jehan, Excellent summarization of the thread regarding how we can add /usr/X11R6/bin to the path. Looks like we had Dave Cook and Robert Collins discussing the best way to do things but then the thread died. I don't really think that I know how to implement the best solution here, so I will just have to leave this up to others. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jehan Sent: Tuesday, July 23, 2002 10:17 PM To: [EMAIL PROTECTED] Subject: Re: problems with XFree Harold L Hunt II wrote: Sylvain Petreolle wrote: Why not install a file in /etc/profile.d ? Sylvain, I am not sure why we didn't use /etc/profile.d. I remember discussing it, but when I searched the mailing list archives using the search function at the top of the archive page, all I got was a bunch of spam messages that I don't recall ever seeing on the mailing list (at least not on the dates mentioned). I will have to do a google search for profile.d on our site, but I haven't got time now. If you could do the search and summarize where the thread left off, that would be great. I seem to remember that a profile.d would work for some cases, but it wouldn't work for all cases... but I cannot give a specific example (might be the archives as well). There was some talk about that on this thread: http://sources.redhat.com/ml/cygwin-xfree/2001-q2/threads.html#01549 There they say that the path to X should be set before any call to /etc/profile.d/* to be more Unix like (i.e. near the top of /etc/profile). It was suggested to add if ! echo $PATH | /bin/grep -q /usr/X11R6/bin ; then PATH=$PATH:/usr/X11R6/bin fi at the top of /etc/profile. The comment was: Now the stock Cygwin /etc/profile (unlike the Linux one) actually sets a default PATH on the first line via PATH=/usr/local/bin:/usr/bin:/bin:$PATH Fortunately this puts the important system paths ahead of anything already defined, so it's OK to add /usr/X11R6/bin at the top. Post http://sources.redhat.com/ml/cygwin-xfree/2001-q2/msg01574.html; is supposed to give a patch but I don't see it. Anyway, it was for the cygwin install (with the assumption that Cygwin/XFree would soon use Cygwin's setup). It's probably better to have a post-install script to do it Jehan
RE: Obtaining Hummingbird-like behavior
-Original Message- From: Nicholas Wourms --- David Brusowankin [EMAIL PROTECTED] wrote: Hi, I would like Xfree86 under cygwin to display an app without the X desktop taking over over my windows, a la Hummingbird. Using Hummingbird one can either run in a mode where the X desktop rules or where the X desktop is invisible (or somehow not required) and the only thing that shows up is the application gui. David, Now why on earth would you want to get rid of the pretty X desktop? You know you don't have to use TWM, there is BlackBox, KDE, Afterstep... Assuming you're not speaking tongue in cheek, Nicholas, I can see a need for doing this ... and intend to demo it on some of haplass end users someday. I have users, they need the stuff (apps and scripts) we run on Unix. But they can't be bothered to either stroll across the room to an available terminal, or XDM into the system. I can either bitch and moan, or I can roll with the punches and make it easy for them ... they DO pay my salary after all. If they can launch $UNIX_APP from their Windows 2k Start Menu, they are happy and life goes on. They don't have to 'know' it's Unix, because everyone knows Unix is hard to use . . . ~brian
RE: Obtaining Hummingbird-like behavior
Brian, Assuming you're not speaking tongue in cheek, Nicholas, I can see a need for doing this ... and intend to demo it on some of haplass end users someday. Does this mean that you are working on a rootless mode for Cygwin/XFree86? Harold
Finally on Sylpheed
I say finally but of course the fun is just beginning for me:) I now have sylpheed (the X Mail Client) running under cygwin-X and it's very good, there are some items that could be beefed up/improved upon (and I shall offer whatever help I'm able to) but on the whole very good. So that this isn't one of those mails that just takes up bandwidth... To create it you need glib-1.2.10 and gtk.1.2.10 or above, also libiconv (this is already part of the main setup for cygwin, although you need to specifically select it), and of course you need sylpheed (current release is 0.8.0). You can get glib and gtk at ftp://ftp.gtk.org/pub/gtk/1.2 You can get sylpheed at http://sylpheed.good-day.net You need to make one alteration in the glib package for it to compile. Comment out line 705 of gstrfuncs.c and it will compile flawlessly. Can the lis let me know if there is interest in a X Mail Client for cygwin, in which case I'll investigate becoming a maintainter for the list? Cheers, Jim
Re: problems with XFree
Harold Hunt wrote: Harold, thanks for the suggestions. I was hoping that oue of them would solve the problem. I checked and found only one cygwin1.dll on the system. It's dated 5 July. I update frequently using setup.exe. I agree with you assessment of Windows. However, my problem isn't the BSOD but XFree86 seg fault. Windows keeps on working and the (apparent) memory leak resolves itself after CFree86 croaks. Let me know if there is anything else I can do on my end to identify the problem. Thanks, Tom Tom, Have you sent in the contents of /tmp/XWin.log from a time when this problem happens? Harold Harold Here it is: ddxProcessArgument () - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winDetectSupportedEngines () - Windows 95/98/Me winDetectSupportedEngines () - DirectDraw installed winDetectSupportedEngines () - DirectDraw4 installed winDetectSupportedEngines () - Returning, supported engines 0017 winSetEngine () - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL () - Using Windows display depth of 16 bits per pixel winAllocateFBShadowDDNL () - Not changing video mode winAllocateFBShadowDDNL () - lPitch: 2048 winInitVisualsShadowDDNL () - Masks 7c00 03e0 001f BPRGB 5 d 16 winCreateDefColormap () - Deferring to fbCreateDefColormap () winScreenInit () - returning winCloseScreenShadowDDNL () - Freeing screen resources winDetectSupportedEngines () - Windows 95/98/Me winDetectSupportedEngines () - DirectDraw installed winDetectSupportedEngines () - DirectDraw4 installed winDetectSupportedEngines () - Returning, supported engines 0017 winSetEngine () - Using Shadow DirectDraw NonLocking winAllocateFBShadowDDNL () - Not changing video mode winAllocateFBShadowDDNL () - lPitch: 2048 winInitVisualsShadowDDNL () - Masks 7c00 03e0 001f BPRGB 5 d 16 winCreateDefColormap () - Deferring to fbCreateDefColormap () winScreenInit () - returning Looks unremarkable to me, but I hope it tells you something useful. Regards, Tom
