[ rdesktop-Patches-3011836 ] fix clipboard fails due to missing timestamp problem

Patches item #3011836, was opened at 2010-06-05 11:07
Message generated for change (Tracker Item Submitted) made by dfries
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=381349&aid=3011836&group_id=24366

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Fries (dfries)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix clipboard fails due to missing timestamp problem

Initial Comment:
Summary: Don't abort a clipboard operation on a failed timestamp transfer.

This way a clipboard can at least get through, not terribly useful
as the primary selection can't win if there is a clipboard, and
if there isn't, it doesn't bother with the timestamp.

X clients that register selections for clipboard and primary
selections are supposed to support the TIMESTAMP query to find out
the time that they acquired the selection.  Not all clients support
the timestamp query.  rdesktop will pull from either the primary or
clipboard selection when a Unix to Windows clipboard operation is
requested, if only one of the two is currently owned that one is
selected for a transfer.  If both are owned rdesktop sends both
selection owners a timestamp request and selects the newer of the two
for the clipboard operation.  Without this patch if both primary and
clipboard are owned, rdesktop aborts the transfer on the first failed
(not supported) timestamp query, this is very non-obvious and
difficult to clear.  The user just sees clipboard transfers fail
randomly and until the application that doesn't support timestamps
looses its selection clipboard operations Unix to Windows fail.

Currently if a client returns a timestamp of 0 it is set to 1 for the
purpose of comparing the to selection timestamp values.  rdesktop uses
0 to mean it has not yet received a timestamp for that application.  A
returned 0 timestamp value indicates the client supports timestamp,
but probably used 0 when acquiring the selection in the first place
even though clients are not supposed to.  This patch will set the
timestamp to 1 for any client that doesn't support timestamps so at
least a transfer can take place even though it can't know for sure
which selection is the newest and will select the clipboard over the
primary selection in the case of a tie.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=381349&aid=3011836&group_id=24366

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo