Feature request: version report

Feature request: version report

[Ed Avis]

I hope the developers will consider adding the following features to
make bug reporting easier:

- Version number of the X server printed at the top of XWin.log

- xwinclip --version

-- 
Ed Avis <ed@membled.com>

Re: Feature request: version report

[Harold L Hunt II]

Ed Avis wrote:

> I hope the developers will consider adding the following features to
> make bug reporting easier:
> 
> - Version number of the X server printed at the top of XWin.log
> 
> - xwinclip --version

Ed,

We must think alike :)  I have just been thinking about how to have our 
own version numbers reported by 'xdpyinfo' and possibly other places 
(like the log file or an 'About' box).

Regarding xwinclip, you should really be using (XWin -clipboard) as it 
now works with Xdmcp connections and it no longer steals ownership of 
the selection in X everytime you highlight something in programs like emacs.

Harold

Re: Feature request: version report

[Ed Avis]

Harold L Hunt II <huntharo@msu.edu> writes:

>Regarding xwinclip, you should really be using (XWin -clipboard)

There are a couple of problems with -clipboard (discussed earlier on
this list) which have led me to switch back to xwinclip:

- Clipboard support seems to die, that is, the Windows clipboard and
  the X selection stop affecting one another.  xwinclip also tends to
  die occasionally but when this happens it can be restarted.

- Windows apps hanging when I try to paste into them.  This seems to
  have started since I began using two displays (though I am not 100%
  sure).  This bug reliably kills any Windows application so it is too
  dangerous for me to run XWin with clipboard enabled.  I have not
  seen this problem with xwinclip.

If you could add some means to manually kill and/or restart the
clipboard code inside the X server then I could switch back without
the risk of losing work, and I'd be happy to report the contents of
Xwin.log on the occasions when such a manual restart was necessary.

(In general, I think the clipboard support could be a bit noisier in
its logging since the contents of XWin.log never seems to give much
away about clipboard or selection change events - but maybe it is more
informative to you than to me.)

-- 
Ed Avis <ed@membled.com>

Re: Feature request: version report

[Harold L Hunt II]

Ed Avis wrote:

> Harold L Hunt II <huntharo@msu.edu> writes:
> 
> 
>>Regarding xwinclip, you should really be using (XWin -clipboard)
> 
> 
> There are a couple of problems with -clipboard (discussed earlier on
> this list) which have led me to switch back to xwinclip:
> 
> - Clipboard support seems to die, that is, the Windows clipboard and
>   the X selection stop affecting one another.  xwinclip also tends to
>   die occasionally but when this happens it can be restarted.
> 
> - Windows apps hanging when I try to paste into them.  This seems to
>   have started since I began using two displays (though I am not 100%
>   sure).  This bug reliably kills any Windows application so it is too
>   dangerous for me to run XWin with clipboard enabled.  I have not
>   seen this problem with xwinclip.
> 
> If you could add some means to manually kill and/or restart the
> clipboard code inside the X server then I could switch back without
> the risk of losing work, and I'd be happy to report the contents of
> Xwin.log on the occasions when such a manual restart was necessary.

I would add a manual kill/restart as a last resort in a few months. 
Until then I would prefer to swat bugs rather than try to work around 
the problem.

XFree86-xserv-4.3.0-49 has some changes that may help to recover from 
and/or to prevent the deadlock situations.  Please try it and let me 
know if it improves things or not.

> (In general, I think the clipboard support could be a bit noisier in
> its logging since the contents of XWin.log never seems to give much
> away about clipboard or selection change events - but maybe it is more
> informative to you than to me.)

The new source tree has support for specifying the verbosity of log 
messages... we should be releasing from that tree within a few weeks. 
Until then it is all or nothing and most users don't want logs measured 
in megabytes.  :)

Harold

Re: Feature request: version report

[Ed Avis]

Harold L Hunt II <huntharo@msu.edu> writes:

>>If you could add some means to manually kill and/or restart the
>>clipboard code inside the X server then I could switch back without
>>the risk of losing work,

>I would add a manual kill/restart as a last resort in a few months.
>Until then I would prefer to swat bugs rather than try to work around
>the problem.

I agree that fixing the bugs is better, but as well as testing XWin to
find bugs I also try to use it for work, and if Windows apps hang
unrecoverably then I can't use the clipboard support.  So you may be
able to swat bugs faster if users can use the software with less risk.

>XFree86-xserv-4.3.0-49 has some changes that may help to recover from
>and/or to prevent the deadlock situations.  Please try it and let me
>know if it improves things or not.

Thanks for looking at this - I will try 4.3.0-50.  (And try running
with -clipboard once again.)

-- 
Ed Avis <ed@membled.com>

Still clipboard deadlock with 4.3.0-50

[Ed Avis]

Ed Avis <ed@membled.com> writes:

>Harold L Hunt II <huntharo@msu.edu> writes:

>>XFree86-xserv-4.3.0-49 has some changes that may help to recover
>>from and/or to prevent the deadlock situations.  Please try it and
>>let me know if it improves things or not.
>
>Thanks for looking at this - I will try 4.3.0-50.

Unfortunately even after updating with the setup program and
rebooting, running XWin.exe -clipboard can hang Windows apps when I
try to paste into them.  However I am not sure that I'm even running
the -50 release because I don't see any version banner in XWin.log.
The setup program says I have -50 installed, but is it telling the
truth?  The XWin.log follows.

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1280 h 1024
winInitializeDefaultScreens - Returning
OsVendorInit - Creating bogus screen 0
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0000001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
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: 00ff0000 0000ff00 000000ff
winInitVisualsShadowDDNL - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
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: "00000809" (00000809) 
(--) Using preset keyboard for "English (United Kingdom)" (809), type "4"
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc105" Layout = "gb" Variant = "(null)" Options = "(null)"
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
OsVendorReset - Hello
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0000001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winScreenInit - dwWidth: 1274 dwHeight: 971
winSetEngine - Using Shadow DirectDraw NonLocking
winCreateBoundingWindowWindowed - User w: 1280 h: 1024
winCreateBoundingWindowWindowed - Current w: 1274 h: 971
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
winClipboardProc - DISPLAY=127.0.0.1:0.0
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: 00ff0000 0000ff00 000000ff
winInitVisualsShadowDDNL - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
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: "00000809" (00000809) 
(--) Using preset keyboard for "English (United Kingdom)" (809), type "4"
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc105" Layout = "gb" Variant = "(null)" Options = "(null)"
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.
winClipboardProc - XOpenDisplay () returned and successfully opened the display.
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.winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1
winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Restore returned: 

-- 
Ed Avis <ed@membled.com>

Re: Still clipboard deadlock with 4.3.0-50

[Harold L Hunt II]

Ed,


Ed Avis wrote:
> Ed Avis <ed@membled.com> writes:
> 
> 
>>Harold L Hunt II <huntharo@msu.edu> writes:
> 
> 
>>>XFree86-xserv-4.3.0-49 has some changes that may help to recover
>>
>>>from and/or to prevent the deadlock situations.  Please try it and
>>
>>>let me know if it improves things or not.
>>
>>Thanks for looking at this - I will try 4.3.0-50.
> 
> 
> Unfortunately even after updating with the setup program and
> rebooting, running XWin.exe -clipboard can hang Windows apps when I
> try to paste into them.  However I am not sure that I'm even running
> the -50 release because I don't see any version banner in XWin.log.
> The setup program says I have -50 installed, but is it telling the
> truth?  The XWin.log follows.

Did you ever confirm for me that you are *not* also running xwinclip at 
the same time as using -clipboard?

The log that you show below confirms that you *do not* have 4.3.0-50 
installed, or that you are running some other version from your startup 
scripts.  There should be a 5 line block at the top of the log file 
since 4.3.0-49, but your log doesn't have it.  Don't know what to tell 
you... you must have some copies of XWin.exe laying around or maybe you 
copied certain versions and renamed them.  You'll have to help us by 
figuring that out.

> ddxProcessArgument - Initializing default screens
> winInitializeDefaultScreens - w 1280 h 1024
> winInitializeDefaultScreens - Returning
> OsVendorInit - Creating bogus screen 0

Harold

Re: Still clipboard deadlock with 4.3.0-50

[Ed Avis]

Harold L Hunt II <huntharo@msu.edu> writes:

>>>>XFree86-xserv-4.3.0-49 has some changes that may help to recover
>>>>from and/or to prevent the deadlock situations.

>>Unfortunately even after updating with the setup program and
>>rebooting, running XWin.exe -clipboard can hang Windows apps when I
>>try to paste into them.

>Did you ever confirm for me that you are *not* also running xwinclip
>at the same time as using -clipboard?

I have used -clipboard and I have used xwinclip, but never both at the
same time.

>The log that you show below confirms that you *do not* have 4.3.0-50
>installed, or that you are running some other version from your
>startup scripts.  There should be a 5 line block at the top of the
>log file since 4.3.0-49, but your log doesn't have it.

That's what I suspected, but the setup program is quite sure it
installed -50... I will check the timestamp on Xwin.exe and make sure
I'm not running an old copy.

-- 
Ed Avis <ed@membled.com>

Re: Still clipboard deadlock with 4.3.0-50

[Igor Pechtchanski]

On Mon, 8 Mar 2004, Ed Avis wrote:

> Harold L Hunt II <huntharo<at>msu<dot>edu> writes:
>
> >>>>XFree86-xserv-4.3.0-49 has some changes that may help to recover
> >>>>from and/or to prevent the deadlock situations.
>
> >>Unfortunately even after updating with the setup program and
> >>rebooting, running XWin.exe -clipboard can hang Windows apps when I
> >>try to paste into them.
>
> >Did you ever confirm for me that you are *not* also running xwinclip
> >at the same time as using -clipboard?
>
> I have used -clipboard and I have used xwinclip, but never both at the
> same time.
>
> >The log that you show below confirms that you *do not* have 4.3.0-50
> >installed, or that you are running some other version from your
> >startup scripts.  There should be a 5 line block at the top of the
> >log file since 4.3.0-49, but your log doesn't have it.
>
> That's what I suspected, but the setup program is quite sure it
> installed -50... I will check the timestamp on Xwin.exe and make sure
> I'm not running an old copy.

Ed,

Please configure your mailer to not quote raw e-mail addresses in replies
-- the spam harvesters have it too easy as it is.

Also, if you had a copy of XWin.exe running at the time you did the
install, setup was not able to replace it, but instead scheduled a
replace-on-reboot for it.  Search /var/log/setup.log for "Scheduled reboot
replacement".  There are two ways of fixing this: one is, of course, to
reboot :-), and there was a recipe posted to the main cygwin list for
doing the replacements without rebooting.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: Still clipboard deadlock with 4.3.0-50

[Ed Avis]

Igor Pechtchanski writes:

>>>The log that you show below confirms that you *do not* have 4.3.0-50
>>>installed,

>>That's what I suspected, but the setup program is quite sure it
>>installed -50...

>Please configure your mailer to not quote raw e-mail addresses in
>replies -- the spam harvesters have it too easy as it is.

As far as I know it quotes only the From header of the previous
message, which is already publicly readable?  I have hidden your
address in this case but I don't think you can require others to keep
hidden something which you have publicly disclosed.

If you're referring to the web archive, and the fact that it applies
some simple obfuscation to From: but not to message bodies, then I'll
change my mailer's behaviour if the list owner requests it.

>Also, if you had a copy of XWin.exe running at the time you did the
>install, setup was not able to replace it, but instead scheduled a
>replace-on-reboot for it.  Search /var/log/setup.log for "Scheduled
>reboot replacement".

Yes, I see it.  But I did reboot my machine, as the setup program
suggested.

Anyway I moved XWin.exe.new to XWin.exe and I am now running the
latest version.

-- 
Ed Avis <ed@membled.com>

Really still clipboard deadlock with 4.3.0-50

[Ed Avis]

I upgraded to XFree86-xserv-4.3.0-50, but I still get the problem of
Windows apps hanging when I paste into them.  Here is the XWin.log
after that had happened a couple of times.

(Looking at the changelog for -51 I didn't see anything related to the
clipboard problem so I haven't tried the new version before reporting
this bug, but I will if you want.)

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 4.3.0.50
Contact: cygwin-xfree@cygwin.com

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 00000007
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: 00ff0000 0000ff00 000000ff
winInitVisualsShadowDDNL - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
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: "00000809" (00000809) 
(--) Using preset keyboard for "English (United Kingdom)" (809), type "4"
Rules = "xfree86" Model = "pc105" Layout = "gb" Variant = "(null)" Options = "(null)"
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.
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.winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1
winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Restore returned: winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1
winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Restore returned: winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1
winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Restore returned: winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1
winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Restore returned: winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1
winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Restore returned: winProcSetSelectionOwner - OpenClipboard () failed: 00000000
winProcSetSelectionOwner - OpenClipboard () failed: 00000000
winProcSetSelectionOwner - OpenClipboard () failed: 00000000
winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1
winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Restore returned: 

-- 
Ed Avis <ed@membled.com>

Re: Really still clipboard deadlock with 4.3.0-50

[Harold L Hunt II]

Ed,

Okay, I have another idea about how to fix this, or at least how to work 
around it.  The following information helps:

 > winProcSetSelectionOwner - OpenClipboard () failed: 00000000
 > winProcSetSelectionOwner - OpenClipboard () failed: 00000000
 > winProcSetSelectionOwner - OpenClipboard () failed: 00000000

It seems that whatever X11 application that we are requesting text from 
is not fulfilling that request, which means that we never write to the 
clipboard like we are supposed to (which causes the other Win32 
application to close the clipboard).

I'll try to come up with a way to detect when this is happening and just 
write some bogus text to the clipboard to fulfill our obligation.

Of course, I reserve the right to change my mind later when I have had 
more time to think about this.  :)

Harold

Re: Really still clipboard deadlock with 4.3.0-50

[Ed Avis]

Harold L Hunt II <huntharo@msu.edu> writes:

>Okay, I have another idea about how to fix this, or at least how to
>work around it.  The following information helps:
>
> > winProcSetSelectionOwner - OpenClipboard () failed: 00000000
> > winProcSetSelectionOwner - OpenClipboard () failed: 00000000
> > winProcSetSelectionOwner - OpenClipboard () failed: 00000000
>
>It seems that whatever X11 application that we are requesting text
>from is not fulfilling that request,

The only X11 application I run is xemacs-21.4.8, shipped with Red Hat
Linux 8.0.  However I just tried pasting some text from gedit into
Windows and that hanged too.

>I'll try to come up with a way to detect when this is happening and
>just write some bogus text to the clipboard to fulfill our
>obligation.

Great, that will make XWin -clipboard a lot safer to use... even if it
doesn't work yet ;-).

-- 
Ed Avis <ed@membled.com>