diff options
Diffstat (limited to 'hw/xwin/winclipboard/xwinclip.man')
| -rw-r--r-- | hw/xwin/winclipboard/xwinclip.man | 7 |
1 files changed, 4 insertions, 3 deletions
diff --git a/hw/xwin/winclipboard/xwinclip.man b/hw/xwin/winclipboard/xwinclip.man index a53dc3029..099f22281 100644 --- a/hw/xwin/winclipboard/xwinclip.man +++ b/hw/xwin/winclipboard/xwinclip.man @@ -39,8 +39,8 @@ XWin(1) .SH BUGS Only text clipboard contents are supported. -The INCR (Incrememntal transfer) clipboard protocol for clipboard contents larger than the maximum size of an -X request is not supported. +The INCR (Incremental transfer) clipboard protocol for clipboard contents larger than the maximum size of an X +request (approximately 256K) is only supported for X -> Windows clipboard transfers. Some X clients, notably ones written in Tcl/Tk, do not re-assert ownership of the PRIMARY selection or update it's timestamp when it's contents change, which currently prevents \fIxwinclip\fP from correctly noticing that @@ -49,7 +49,8 @@ the PRIMARY selection's contents have changed. Windows clipboard rendering is synchronous in the WM_RENDER*FORMAT message (that is, we must have placed the contents onto the clipboard by the time we return from processing this message), but we must wait for the X client which owns the selection to convert the selection to our requested format. This is currently achieved -using a fixed timeout of one second. +using a fixed timeout. After requesting conversion of the selection, if no events are received from the X +client which owns the selection for one second, the conversion is assumed to have failed. The XWin(1) server should indicate somehow (by placing an atom on the root window?) that it is running with it's internal clipboard integration enabled, and xwinclip should notice this and exit with an appropriate error. |