This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] RE: Ghost cursors (was: RE: alt-tab: client window receives tab / pressing both...)


> My solution for the time is 
> pragmatic, but
> I'd like to get to the bottom of this eventually.  For now I 
> just reopen the
> log file handle in OsVendorInit if it was opened in 
> ddxProcessArgument:

Okay - a few ErrorF()'s, bit of stracing and recompiles later ...

What kills the file handle is fclose(stdio) in os/osinit.c.

Why? Well, X, like many programs, makes assumptions about stdio, stdout
and stderr (it assumes that they are on fd's 0, 1 and 2).  This is
bad.

Now, what must have happened is that when XWin.exe is started without
the /B flag the file descriptor we get when we open our log file is 0
(namely stdin).  Why would we get this?  Well, why not?  XWin doesn't have
a console when it starts (is used to according to Harold so this is most
likely when it last worked!) so we just get the first FD.  Why we don't
get this FD when we start XWin.exe with /B is another matter (erm - windows
experts out there ... maybe windows does something special with them)

The real fix?  Well - the bug is in core X and not the cygwin port.

Attached is a patch which stops OsInit() from closing stdin and stdout
if compiling for cygwin.  I still contend that those closes shouldn't be
there at all - but that's for an XFree86 developer to decide as it will
effect all platforms.  This patch just fixes it for cygwin.


Stuart



Attachment: log.patch
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]