Re: Updated: XFree86-xserv-4.3.0-31

Re: Updated: XFree86-xserv-4.3.0-31

[Dr. Volker Zell]

>>>>> "Harold" == Harold L Hunt writes:

    Harold> 1) General - Everything up to the last three entries describes the
    Harold> new clipboard handling system that does not steal ownership of the X11
    Harold> selection each time that something is selected; this seems to work
    Harold> fine, but it needs to be tested.

Hi Harold
You made my day !!!! The selection ownership problem really went away.
I'm running the X version of XEmacs since half a day now and no
problems with selection and copy/paste between X and Windows.

Ciao
  Volker

Re: Updated: XFree86-xserv-4.3.0-31

[Dr. Volker Zell]

>>>>> "Volker" == Volker Zell writes:

    Volker> Hi Harold
    Volker> You made my day !!!! The selection ownership problem really went away.
    Volker> I'm running the X version of XEmacs since half a day now and no
    Volker> problems with selection and copy/paste between X and Windows.

A couple of hours later it stopped working, now my XWin.log fills up
with

 winProcSetSelectionOwner - OpenClipboard () failed: 00000578
 winProcSetSelectionOwner - OpenClipboard () failed: 00000578
 winProcSetSelectionOwner - OpenClipboard () failed: 00000578

Ciao
  Volker

Re: Updated: XFree86-xserv-4.3.0-31

[Harold L Hunt II]

Volker,

Dr. Volker Zell wrote:

>>>>>>"Volker" == Volker Zell writes:
> 
> 
>     Volker> Hi Harold
>     Volker> You made my day !!!! The selection ownership problem really went away.
>     Volker> I'm running the X version of XEmacs since half a day now and no
>     Volker> problems with selection and copy/paste between X and Windows.
> 
> A couple of hours later it stopped working, now my XWin.log fills up
> with
> 
>  winProcSetSelectionOwner - OpenClipboard () failed: 00000578
>  winProcSetSelectionOwner - OpenClipboard () failed: 00000578
>  winProcSetSelectionOwner - OpenClipboard () failed: 00000578

Hmm... that is not something I had seen before.  Did an earlier entry in 
the XWin.log say anything about the clipboard manager shutting down? 
Want to bzip2 it and send XWin.log to me privately?

Harold

Re: Updated: XFree86-xserv-4.3.0-31

[Dr. Volker Zell]

>>>>> "Harold" == Harold L Hunt, <Harold> writes:

    Harold> Hmm... that is not something I had seen before.  Did an earlier entry
    Harold> in the XWin.log say anything about the clipboard manager shutting
    Harold> down? Want to bzip2 it and send XWin.log to me privately?

Sorry, I'm reading this mail from my home. So I already booted my
laptop and XWin.log got overwritten. If I see the error again I'll send it to you.....

    Harold> Harold

Ciao
  Volker

Re: Updated: XFree86-xserv-4.3.0-31

[Harold L Hunt II]

Volker,

Dr. Volker Zell wrote:

>>>>>>"Harold" == Harold L Hunt writes:
> 
> 
>     Harold> 1) General - Everything up to the last three entries describes the
>     Harold> new clipboard handling system that does not steal ownership of the X11
>     Harold> selection each time that something is selected; this seems to work
>     Harold> fine, but it needs to be tested.
> 
> Hi Harold
> You made my day !!!! The selection ownership problem really went away.
> I'm running the X version of XEmacs since half a day now and no
> problems with selection and copy/paste between X and Windows.

Great!  I was sort of afraid to test it really hard... I didn't want to 
find out for myself that it had major bugs.  :)  That is great to hear 
that it is holding up.

Harold

RE: Updated: XFree86-xserv-4.3.0-31

[Andrew Braverman]

I just tried running this version and it crashes.  I get a normal looking
stuff at the beginning of the XWin.log file and then get one line telling
me:
	winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
Then I get 64K + lines (total size of log file is 65072 lines) of:
	winProcSetSelectionOwner - We changed ownership, aborting.

Does anyone have any ideas?


> -----Original Message-----
> From: cygwin-xfree-announce-owner@cygwin.com
> [mailto:cygwin-xfree-announce-owner@cygwin.com]On Behalf Of Harold L
> Hunt II
> Sent: Monday, January 05, 2004 2:09 AM
> To: cygxannounce
> Subject: Updated: XFree86-xserv-4.3.0-31
>
>
> Announcement
> ============
>
> The XFree86-xserv-4.3.0-31 package has been updated in the Cygwin
> distribution.
>
>
> Links
> =====
>
> Server source, direct link:
> http://www.msu.edu/~huntharo/xwin/devel/server/xwin-20040105-0
105.tar.bz2
> (131 KiB)
>
> xc/programs/Xserver/hw/xwin (all files) diff against 4.3.0-29
> (yes, the
> file has the wrong name, just live with it) source code:
> http://www.msu.edu/~huntharo/xwin/devel/server/xwin-4.3.0-30-t
> o-4.3.0-31.diff
> (39 KiB)
>
> xc/programs/Xserver/Imakefile diff against XFree86 CVS:
> http://www.msu.edu/~huntharo/xwin/devel/server/xc-programs-Xse
rver-Imakefile-20040105-0105.diff
> (1 KiB)
>
>
> Changes
> =======
>
> 1) General - Everything up to the last three entries describes the
> new clipboard handling system that does not steal ownership of the X11
> selection each time that something is selected; this seems to work
> fine, but it needs to be tested.  The last three entries describe my
> nearly complete attempt at generating a MIT-MAGIC-COOKIE-1, adding it
> to the list of cookies that the X Server recognizes, and using it when
> the clipboard client tries to connect during an XDMCP connection.
> This authentication approach should work, but I need a break from
> trying to figure out which of the function calls has a minor error in
> its parameters; thus, it does not currently work.  However, feel free
> to examine the source code and let me know if any of my calls to
> GenerateAuthorization, AddResource, or XauWriteAuth are incorrect.  I
> would really like to get this automatic authorization working as soon
> as possible.  Until then I will mark this release (and all releases
> based upon it) as 'test'.
>
> 2) InitInput.c - Add a function, winProcSetSelectionOwner, and wrap
> the generic function ProcVector[X_SetSelectionOwner] with it.  This
> allows us to get a notification each time the selection (clipboard)
> owner changes.  Call SetClipboardData (foo, NULL) so that the
> WM_RENDERFORMAT message will be posted when a Win32 app requests the
> clipboard contents.  (Harold L Hunt II, Alexander Gottwald)
>
> 3) winclipboardxevents.c/winClipboardFlushXEvents/SelectionNotify -
> No longer steal ownership of the selection each time it changes in
> X11.  We can do this because we have notification when
> SetSelectionOwner is called (see above).  (Harold L Hunt II)
>
> 4) winclipboardxevents.c/winClipboardFlushXEvents/SelectionClear -
> Remove handling, it is no longer needed; it used to request the
> contents of the selection that we lost ownership of.  (Harold L Hunt
> II)
>
> 5) winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DESTROY
> - Add information to be used on each call to a window property.
> (Harold L Hunt II)
>
> 6)
> winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DEST
> ROY,WM_CHANGECBCHAIN,WM_DRAWCLIPBOARD
> - Add ourselves to the clipboard viewer chain so that we receive
> notification when the clipboard contents are changed by a Win32
> application.  Our normal response to this is to call
> XSetSelectionOwner, but we specifically do nothing if we currently own
> the Win32 clipboard.  (Harold L Hunt II)
>
> 7)
> winclipboardwndproc.c/winClipboardWindowProc/WM_RENDERFORMAT,W
> M_RENDERALLFORMATS
> - Request the contents of the X11 selection.  Use XPeekIfEvent to wait
> until the response is added to our event queue (this could probably
> lead to a dead-lock of a client exists before responding), then call
> winClipboardFlushXEvents to handle the SelectionNotify event.  UTF8
> and CompoundText targets require that we call XConvertSelection from
> the SelectionNotify event, which will cause another SelectionNotify
> event to be fired; be careful to check for this and do the
> XPeekIfEvent/winClipboardFlushXEvents thing again if this is the
> case (this is untested because I did not see any UTF8 or CompoundText
> targets that needed conversion).  Copy the returned contents to the
> Win32 clipboard with SetClipboardData ().  (Harold L Hunt II)
>
> 8) winscrinit.c/winFinishScreenInitFB - Generate a
> MIT-MAGIC-COOKIE-1 cookie and add it to the server's list of cookies.
> (Harold L Hunt II)
>
> 9) winclipboardthread.c/winClipboardSaveXauthData - Add the generated
> MIT-MAGIC-COOKIE-1 cookie to the Xauthority file.  Beware that this is
> hard-coded to 127.0.0.1:0 and that the entry is not cleaned up upon
> exit; this will force the host-based access to be disabled in some
> cases and could cause problems starting X Clients until this is fixed.
> (Harold L Hunt II)
>
> 10) xc/programs/Xserver/Imakefile - Add $(OS) to the XWINLIBS just
> after libXwin.a is included, which allows us to call unreferenced
> functions in libXau.a, such as XauWriteAuth.  (Harold L Hunt II)
>
> --
> Harold Hunt
>
> To update your installation, click on the "Install Cygwin now" link on
> the http://cygwin.com/ web page.  This downloads setup.exe to your
> system.  Once you've downloaded setup.exe, run it and select "XFree86"
> and then click on the appropriate field until the above announced
> version number appears if it is not displayed already.
>
> If your mirror doesn't yet have the latest version of this
> package after
> 24 hours, you can either continue to wait for that site to be
> updated or
> you can try to find another mirror.
>
> Please send questions or comments to the Cygwin/X mailing list at:
> cygwin-xfree@cygwin.com
>
> If you want to subscribe go to:
> http://cygwin.com/ml/cygwin-xfree/
>
> I would appreciate if you would use this mailing list rather than
> emailing me directly.  This includes ideas and comments about
> the setup
> utility or Cygwin/X in general.
>
> If you want to make a point or ask a question the Cygwin/X mailing
> list is the appropriate place.
>

RE: Updated: XFree86-xserv-4.3.0-31

[Alexander Gottwald]

On Mon, 5 Jan 2004, Andrew Braverman wrote:

> I just tried running this version and it crashes.  I get a normal looking
> stuff at the beginning of the XWin.log file and then get one line telling
> me:
> 	winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
> Then I get 64K + lines (total size of log file is 65072 lines) of:
> 	winProcSetSelectionOwner - We changed ownership, aborting.
> 
> Does anyone have any ideas?

Noticed this too. It happend after sever reset.

bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723

Re: Updated: XFree86-xserv-4.3.0-31

[Harold L Hunt II]

Alexander Gottwald wrote:

> On Mon, 5 Jan 2004, Andrew Braverman wrote:
> 
> 
>>I just tried running this version and it crashes.  I get a normal looking
>>stuff at the beginning of the XWin.log file and then get one line telling
>>me:
>>	winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
>>Then I get 64K + lines (total size of log file is 65072 lines) of:
>>	winProcSetSelectionOwner - We changed ownership, aborting.
>>
>>Does anyone have any ideas?
> 
> 
> Noticed this too. It happend after sever reset.

Hmm... I guess I didn't tell you guys that server resets were not 
supported, right?  :)

I already had a fix in my code base for this last night.  The problem is 
that the server functions vectors are only setup once, but I keep 
wrapping the function each time the server resets.  I added an if 
(serverGeneration == 1) to my local code last night, just after I posted 
the 4.3.0-31 release.  That should stop the multiple wrapping from 
happening, which is causing the crash.

Harold

Re: Updated: XFree86-xserv-4.3.0-31

[Alexander Gottwald]

Harold L Hunt II wrote:

> I already had a fix in my code base for this last night.  The problem is
> that the server functions vectors are only setup once, but I keep
> wrapping the function each time the server resets.  I added an if
> (serverGeneration == 1) to my local code last night, just after I posted
> the 4.3.0-31 release.  That should stop the multiple wrapping from
> happening, which is causing the crash.

how about
if (ProcVector[X_SetSelectionOwner] != winSetSelectionOwner)
{
    oldSetSelectionOwner = ProcVector[X_SetSelectionOwner];
    ProcVector[X_SetSelectionOwner] = winSetSelectionOwner;
}

bye
    ago
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: Updated: XFree86-xserv-4.3.0-31

[Harold L Hunt II]

Alexander Gottwald wrote:

> On Mon, 5 Jan 2004, Andrew Braverman wrote:
> 
> 
>>I just tried running this version and it crashes.  I get a normal looking
>>stuff at the beginning of the XWin.log file and then get one line telling
>>me:
>>	winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
>>Then I get 64K + lines (total size of log file is 65072 lines) of:
>>	winProcSetSelectionOwner - We changed ownership, aborting.
>>
>>Does anyone have any ideas?
> 
> 
> Noticed this too. It happend after sever reset.

Here is a dumb question: if the clipboard client is attached, how did 
you cause a server reset?  Is there a way to force the server to reset 
when there are clients still attached?  I need to be able to do this in 
order to test my fix... and it sounds like there is a way to do this, 
since I don't think it could happen automatically.

Harold

Re: Updated: XFree86-xserv-4.3.0-31

[Alexander Gottwald]

Harold L Hunt II wrote:

> > Noticed this too. It happend after sever reset.
>
> Here is a dumb question: if the clipboard client is attached, how did
> you cause a server reset?

good question. I've started a session and stopped the windowmanager. The
log showed signs of another server generation. I'll check tomorrow.

Maybe the clipboard client died before.

I've also noticed different behaviour (crash or segfault) depending on
which side (X11, Win32) has changed the clipboard last but had no time
to examine this further. I can test it tomorrow.

> is there a way to force the server to reset
> when there are clients still attached?  I need to be able to do this in
> order to test my fix... and it sounds like there is a way to do this,
> since I don't think it could happen automatically.

I'm quite sure there are similar functions to TerminateServer.

bye
    ago
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: Updated: XFree86-xserv-4.3.0-31

[Harold L Hunt II]

Andrew,

Yup, this happens when you are using -query and there are no entries in 
your .Xauthority file.  You can alleviate this by running it again after 
it crashes, since the previous entries are left in the file.  This is 
something that still has to be fixed or worked around and that is why 
these are 'test' releases.  Sorry for not describing this particular 
failure mode in the announcement.

Harold

Andrew Braverman wrote:

> I just tried running this version and it crashes.  I get a normal looking
> stuff at the beginning of the XWin.log file and then get one line telling
> me:
> 	winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
> Then I get 64K + lines (total size of log file is 65072 lines) of:
> 	winProcSetSelectionOwner - We changed ownership, aborting.
> 
> Does anyone have any ideas?
> 
> 
> 
>>-----Original Message-----
>>From: cygwin-xfree-announce-owner@cygwin.com
>>[mailto:cygwin-xfree-announce-owner@cygwin.com]On Behalf Of Harold L
>>Hunt II
>>Sent: Monday, January 05, 2004 2:09 AM
>>To: cygxannounce
>>Subject: Updated: XFree86-xserv-4.3.0-31
>>
>>
>>Announcement
>>============
>>
>>The XFree86-xserv-4.3.0-31 package has been updated in the Cygwin
>>distribution.
>>
>>
>>Links
>>=====
>>
>>Server source, direct link:
>>http://www.msu.edu/~huntharo/xwin/devel/server/xwin-20040105-0
> 
> 105.tar.bz2
> 
>>(131 KiB)
>>
>>xc/programs/Xserver/hw/xwin (all files) diff against 4.3.0-29
>>(yes, the
>>file has the wrong name, just live with it) source code:
>>http://www.msu.edu/~huntharo/xwin/devel/server/xwin-4.3.0-30-t
>>o-4.3.0-31.diff
>>(39 KiB)
>>
>>xc/programs/Xserver/Imakefile diff against XFree86 CVS:
>>http://www.msu.edu/~huntharo/xwin/devel/server/xc-programs-Xse
> 
> rver-Imakefile-20040105-0105.diff
> 
>>(1 KiB)
>>
>>
>>Changes
>>=======
>>
>>1) General - Everything up to the last three entries describes the
>>new clipboard handling system that does not steal ownership of the X11
>>selection each time that something is selected; this seems to work
>>fine, but it needs to be tested.  The last three entries describe my
>>nearly complete attempt at generating a MIT-MAGIC-COOKIE-1, adding it
>>to the list of cookies that the X Server recognizes, and using it when
>>the clipboard client tries to connect during an XDMCP connection.
>>This authentication approach should work, but I need a break from
>>trying to figure out which of the function calls has a minor error in
>>its parameters; thus, it does not currently work.  However, feel free
>>to examine the source code and let me know if any of my calls to
>>GenerateAuthorization, AddResource, or XauWriteAuth are incorrect.  I
>>would really like to get this automatic authorization working as soon
>>as possible.  Until then I will mark this release (and all releases
>>based upon it) as 'test'.
>>
>>2) InitInput.c - Add a function, winProcSetSelectionOwner, and wrap
>>the generic function ProcVector[X_SetSelectionOwner] with it.  This
>>allows us to get a notification each time the selection (clipboard)
>>owner changes.  Call SetClipboardData (foo, NULL) so that the
>>WM_RENDERFORMAT message will be posted when a Win32 app requests the
>>clipboard contents.  (Harold L Hunt II, Alexander Gottwald)
>>
>>3) winclipboardxevents.c/winClipboardFlushXEvents/SelectionNotify -
>>No longer steal ownership of the selection each time it changes in
>>X11.  We can do this because we have notification when
>>SetSelectionOwner is called (see above).  (Harold L Hunt II)
>>
>>4) winclipboardxevents.c/winClipboardFlushXEvents/SelectionClear -
>>Remove handling, it is no longer needed; it used to request the
>>contents of the selection that we lost ownership of.  (Harold L Hunt
>>II)
>>
>>5) winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DESTROY
>>- Add information to be used on each call to a window property.
>>(Harold L Hunt II)
>>
>>6)
>>winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DEST
>>ROY,WM_CHANGECBCHAIN,WM_DRAWCLIPBOARD
>>- Add ourselves to the clipboard viewer chain so that we receive
>>notification when the clipboard contents are changed by a Win32
>>application.  Our normal response to this is to call
>>XSetSelectionOwner, but we specifically do nothing if we currently own
>>the Win32 clipboard.  (Harold L Hunt II)
>>
>>7)
>>winclipboardwndproc.c/winClipboardWindowProc/WM_RENDERFORMAT,W
>>M_RENDERALLFORMATS
>>- Request the contents of the X11 selection.  Use XPeekIfEvent to wait
>>until the response is added to our event queue (this could probably
>>lead to a dead-lock of a client exists before responding), then call
>>winClipboardFlushXEvents to handle the SelectionNotify event.  UTF8
>>and CompoundText targets require that we call XConvertSelection from
>>the SelectionNotify event, which will cause another SelectionNotify
>>event to be fired; be careful to check for this and do the
>>XPeekIfEvent/winClipboardFlushXEvents thing again if this is the
>>case (this is untested because I did not see any UTF8 or CompoundText
>>targets that needed conversion).  Copy the returned contents to the
>>Win32 clipboard with SetClipboardData ().  (Harold L Hunt II)
>>
>>8) winscrinit.c/winFinishScreenInitFB - Generate a
>>MIT-MAGIC-COOKIE-1 cookie and add it to the server's list of cookies.
>>(Harold L Hunt II)
>>
>>9) winclipboardthread.c/winClipboardSaveXauthData - Add the generated
>>MIT-MAGIC-COOKIE-1 cookie to the Xauthority file.  Beware that this is
>>hard-coded to 127.0.0.1:0 and that the entry is not cleaned up upon
>>exit; this will force the host-based access to be disabled in some
>>cases and could cause problems starting X Clients until this is fixed.
>>(Harold L Hunt II)
>>
>>10) xc/programs/Xserver/Imakefile - Add $(OS) to the XWINLIBS just
>>after libXwin.a is included, which allows us to call unreferenced
>>functions in libXau.a, such as XauWriteAuth.  (Harold L Hunt II)
>>
>>--
>>Harold Hunt
>>
>>To update your installation, click on the "Install Cygwin now" link on
>>the http://cygwin.com/ web page.  This downloads setup.exe to your
>>system.  Once you've downloaded setup.exe, run it and select "XFree86"
>>and then click on the appropriate field until the above announced
>>version number appears if it is not displayed already.
>>
>>If your mirror doesn't yet have the latest version of this
>>package after
>>24 hours, you can either continue to wait for that site to be
>>updated or
>>you can try to find another mirror.
>>
>>Please send questions or comments to the Cygwin/X mailing list at:
>>cygwin-xfree@cygwin.com
>>
>>If you want to subscribe go to:
>>http://cygwin.com/ml/cygwin-xfree/
>>
>>I would appreciate if you would use this mailing list rather than
>>emailing me directly.  This includes ideas and comments about
>>the setup
>>utility or Cygwin/X in general.
>>
>>If you want to make a point or ask a question the Cygwin/X mailing
>>list is the appropriate place.
>>
> 
> 
> 
> 

RE: Updated: XFree86-xserv-4.3.0-31

[Andrew Braverman]

No problem.  I understood it was a test release and just went back to the
old.

FYI -

I am not, however, using the -query parameter in my XWin invocation.  I am
using ssh tunnels and therefore am not doing a query.  The invocation looks
like this:





XWin -once -emulate3buttons -clipboard -multiwindow -lesspointer -clipupdate
s 5 &

Even running it multiple times gets me the same result.  I will check it
again the next time you put it out.  I would love to use it.  It sounds like
it will solve a bunch of problems.

As usual, sincere thanks go out to the crew of a half dozen or so of you who
do most of the work on this project.  If it were not for you guys
(especially Harold), this project would not go anywhere.  There are many
other contributors who deserve thanks, but they would not have something to
contribute to without the core group of you guys.  One of these days, when I
have some "free" time, I need to try to look more deeply at the code and try
to help out some more.  Thanks again to all for a wonderful product.

Andy

> -----Original Message-----
> From: cygwin-xfree-owner@cygwin.com
> [mailto:cygwin-xfree-owner@cygwin.com]On Behalf Of Harold L Hunt II
> Sent: Monday, January 05, 2004 2:31 PM
> To: cygwin-xfree@cygwin.com
> Subject: Re: Updated: XFree86-xserv-4.3.0-31
>
>
> Andrew,
>
> Yup, this happens when you are using -query and there are no
> entries in
> your .Xauthority file.  You can alleviate this by running it
> again after
> it crashes, since the previous entries are left in the file.  This is
> something that still has to be fixed or worked around and that is why
> these are 'test' releases.  Sorry for not describing this particular
> failure mode in the announcement.
>
> Harold
>
> Andrew Braverman wrote:
>
> > I just tried running this version and it crashes.  I get a
> normal looking
> > stuff at the beginning of the XWin.log file and then get
> one line telling
> > me:
> > 	winClipboardWindowProc - WM_DRAWCLIPBOARD -
> Initializing - Returning.
> > Then I get 64K + lines (total size of log file is 65072 lines) of:
> > 	winProcSetSelectionOwner - We changed ownership, aborting.
> >
> > Does anyone have any ideas?
> >
> >
> >
> >>-----Original Message-----
> >>From: cygwin-xfree-announce-owner@cygwin.com
> >>[mailto:cygwin-xfree-announce-owner@cygwin.com]On Behalf Of Harold L
> >>Hunt II
> >>Sent: Monday, January 05, 2004 2:09 AM
> >>To: cygxannounce
> >>Subject: Updated: XFree86-xserv-4.3.0-31
> >>
> >>
> >>Announcement
> >>============
> >>
> >>The XFree86-xserv-4.3.0-31 package has been updated in the Cygwin
> >>distribution.
> >>
> >>
> >>Links
> >>=====
> >>
> >>Server source, direct link:
> >>http://www.msu.edu/~huntharo/xwin/devel/server/xwin-20040105-0
> >
> > 105.tar.bz2
> >
> >>(131 KiB)
> >>
> >>xc/programs/Xserver/hw/xwin (all files) diff against 4.3.0-29
> >>(yes, the
> >>file has the wrong name, just live with it) source code:
> >>http://www.msu.edu/~huntharo/xwin/devel/server/xwin-4.3.0-30-t
> >>o-4.3.0-31.diff
> >>(39 KiB)
> >>
> >>xc/programs/Xserver/Imakefile diff against XFree86 CVS:
> >>http://www.msu.edu/~huntharo/xwin/devel/server/xc-programs-Xse
> >
> > rver-Imakefile-20040105-0105.diff
> >
> >>(1 KiB)
> >>
> >>
> >>Changes
> >>=======
> >>
> >>1) General - Everything up to the last three entries describes the
> >>new clipboard handling system that does not steal ownership
> of the X11
> >>selection each time that something is selected; this seems to work
> >>fine, but it needs to be tested.  The last three entries describe my
> >>nearly complete attempt at generating a MIT-MAGIC-COOKIE-1,
> adding it
> >>to the list of cookies that the X Server recognizes, and
> using it when
> >>the clipboard client tries to connect during an XDMCP connection.
> >>This authentication approach should work, but I need a break from
> >>trying to figure out which of the function calls has a
> minor error in
> >>its parameters; thus, it does not currently work.  However,
> feel free
> >>to examine the source code and let me know if any of my calls to
> >>GenerateAuthorization, AddResource, or XauWriteAuth are
> incorrect.  I
> >>would really like to get this automatic authorization
> working as soon
> >>as possible.  Until then I will mark this release (and all releases
> >>based upon it) as 'test'.
> >>
> >>2) InitInput.c - Add a function, winProcSetSelectionOwner, and wrap
> >>the generic function ProcVector[X_SetSelectionOwner] with it.  This
> >>allows us to get a notification each time the selection (clipboard)
> >>owner changes.  Call SetClipboardData (foo, NULL) so that the
> >>WM_RENDERFORMAT message will be posted when a Win32 app requests the
> >>clipboard contents.  (Harold L Hunt II, Alexander Gottwald)
> >>
> >>3) winclipboardxevents.c/winClipboardFlushXEvents/SelectionNotify -
> >>No longer steal ownership of the selection each time it changes in
> >>X11.  We can do this because we have notification when
> >>SetSelectionOwner is called (see above).  (Harold L Hunt II)
> >>
> >>4) winclipboardxevents.c/winClipboardFlushXEvents/SelectionClear -
> >>Remove handling, it is no longer needed; it used to request the
> >>contents of the selection that we lost ownership of.  (Harold L Hunt
> >>II)
> >>
> >>5) winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DESTROY
> >>- Add information to be used on each call to a window property.
> >>(Harold L Hunt II)
> >>
> >>6)
> >>winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DEST
> >>ROY,WM_CHANGECBCHAIN,WM_DRAWCLIPBOARD
> >>- Add ourselves to the clipboard viewer chain so that we receive
> >>notification when the clipboard contents are changed by a Win32
> >>application.  Our normal response to this is to call
> >>XSetSelectionOwner, but we specifically do nothing if we
> currently own
> >>the Win32 clipboard.  (Harold L Hunt II)
> >>
> >>7)
> >>winclipboardwndproc.c/winClipboardWindowProc/WM_RENDERFORMAT,W
> >>M_RENDERALLFORMATS
> >>- Request the contents of the X11 selection.  Use
> XPeekIfEvent to wait
> >>until the response is added to our event queue (this could probably
> >>lead to a dead-lock of a client exists before responding), then call
> >>winClipboardFlushXEvents to handle the SelectionNotify event.  UTF8
> >>and CompoundText targets require that we call XConvertSelection from
> >>the SelectionNotify event, which will cause another SelectionNotify
> >>event to be fired; be careful to check for this and do the
> >>XPeekIfEvent/winClipboardFlushXEvents thing again if this is the
> >>case (this is untested because I did not see any UTF8 or
> CompoundText
> >>targets that needed conversion).  Copy the returned contents to the
> >>Win32 clipboard with SetClipboardData ().  (Harold L Hunt II)
> >>
> >>8) winscrinit.c/winFinishScreenInitFB - Generate a
> >>MIT-MAGIC-COOKIE-1 cookie and add it to the server's list
> of cookies.
> >>(Harold L Hunt II)
> >>
> >>9) winclipboardthread.c/winClipboardSaveXauthData - Add the
> generated
> >>MIT-MAGIC-COOKIE-1 cookie to the Xauthority file.  Beware
> that this is
> >>hard-coded to 127.0.0.1:0 and that the entry is not cleaned up upon
> >>exit; this will force the host-based access to be disabled in some
> >>cases and could cause problems starting X Clients until
> this is fixed.
> >>(Harold L Hunt II)
> >>
> >>10) xc/programs/Xserver/Imakefile - Add $(OS) to the XWINLIBS just
> >>after libXwin.a is included, which allows us to call unreferenced
> >>functions in libXau.a, such as XauWriteAuth.  (Harold L Hunt II)
> >>
> >>--
> >>Harold Hunt
> >>
> >>To update your installation, click on the "Install Cygwin
> now" link on
> >>the http://cygwin.com/ web page.  This downloads setup.exe to your
> >>system.  Once you've downloaded setup.exe, run it and
> select "XFree86"
> >>and then click on the appropriate field until the above announced
> >>version number appears if it is not displayed already.
> >>
> >>If your mirror doesn't yet have the latest version of this
> >>package after
> >>24 hours, you can either continue to wait for that site to be
> >>updated or
> >>you can try to find another mirror.
> >>
> >>Please send questions or comments to the Cygwin/X mailing list at:
> >>cygwin-xfree@cygwin.com
> >>
> >>If you want to subscribe go to:
> >>http://cygwin.com/ml/cygwin-xfree/
> >>
> >>I would appreciate if you would use this mailing list rather than
> >>emailing me directly.  This includes ideas and comments about
> >>the setup
> >>utility or Cygwin/X in general.
> >>
> >>If you want to make a point or ask a question the Cygwin/X mailing
> >>list is the appropriate place.
> >>
> >
> >
> >
> >
>

RE: Updated: XFree86-xserv-4.3.0-31

[Armbrust, Daniel C.]

I just upgraded my install, and now it reports a missing dll file (cygcygipc-2.dll).  Should the installer handle this automatically?

Re: Updated: XFree86-xserv-4.3.0-31

[Harold L Hunt II]

Daniel,

Armbrust, Daniel C. wrote:

> I just upgraded my install, and now it reports a missing dll file (cygcygipc-2.dll).  Should the installer handle this automatically?

You must have been going for a very long time before upgrading.  Yes, 
the cygipc package is a dependency of the X packages, but if you upgrade 
from an old version that did not require it, then it might not be 
automatically selected for installation.  The solution is to manually 
select the cygipc package.

Harold

RE: Updated: XFree86-xserv-4.3.0-31

[Armbrust, Daniel C.]

Yeah, it had been a couple of months.... I usually try to avoid upgrading it unless there is a new feature I want (if its not broke....)

I had to track down three missing dll files, but now the cut and paste upgrades are working great.

Thanks for your work yet again, Harold.

This was about the only thing on my "it would be nice if it was fixed" list.... For my uses of cygwin anyway.

Dan


-----Original Message-----
From: Harold L Hunt II [mailto:huntharo@msu.edu] 
Sent: Monday, January 05, 2004 1:53 PM
To: cygwin-xfree@cygwin.com
Subject: Re: Updated: XFree86-xserv-4.3.0-31


Daniel,

Armbrust, Daniel C. wrote:

> I just upgraded my install, and now it reports a missing dll file (cygcygipc-2.dll).  Should the installer handle this automatically?

You must have been going for a very long time before upgrading.  Yes, 
the cygipc package is a dependency of the X packages, but if you upgrade 
from an old version that did not require it, then it might not be 
automatically selected for installation.  The solution is to manually 
select the cygipc package.

Harold