Bug 690164

Summary: Feature Request: handle INCR copy to guest
Product: Red Hat Enterprise Linux 6 Reporter: Alon Levy <alevy>
Component: spice-vdagentAssignee: Hans de Goede <hdegoede>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.2CC: cmeadors, dblechte, lkocman
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: spice-vdagent-0.8.1-1.el6 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-06 12:01:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 722477    
Bug Blocks: 613078, 747120    

Description Alon Levy 2011-03-23 13:53:41 UTC
Description of problem:

there is no handling of INCR currently when copying to the guest. This is required for large buffer copying to the guest (large meaning beyond the size of a screen shot in 1920x1080, more like multiple megabytes). Right now we try to send a single XChangeProperty regardless of buffer size.

Comment 2 Suzanne Logcher 2011-03-28 20:31:31 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains 
unresolved, it has been rejected as it is not proposed as an 
exception or blocker.  It has been moved to RHEL 6.2 since 
it is a FutureFeature request.

Comment 3 Hans de Goede 2011-03-30 10:57:27 UTC
I just pushed a patch set to upstream git fixing this.

Comment 5 Cameron Meadors 2011-06-15 14:50:36 UTC
How do we test this?

Comment 6 Alon Levy 2011-06-15 17:17:14 UTC
try a paste that is large enough. If you use xsel, it does INCR if the paste is larger then 4000 bytes iirc, so doing something like:

dd if=/dev/zero bs=1024 count=100 | xsel -b

and then pasting in the guest, should do the trick (-b is to use the CLIPBOARD selection which we use instead of the default).

Comment 7 Cameron Meadors 2011-06-15 17:23:00 UTC
What client/guest combinations are affected by this change?

Comment 8 Hans de Goede 2011-06-16 12:52:19 UTC
(In reply to comment #7)
> What client/guest combinations are affected by this change?

Any client together with a Linux guest with the Linux agent. The example / instructions Alon gave to reproduce would be done from an x-terminal running on the same desktop as the client and thus requires the use of the Linux client.

Comment 9 Hans de Goede 2011-07-18 07:52:03 UTC
This is fixed in the just build spice-vdagent-0.8.1-1.el6, moving to modified.

Comment 11 Lubos Kocman 2011-07-20 12:00:52 UTC
Hello what exactly means "more like multiple megabytes":

I was able to copy&paste /usr/share/dict/linux.words (4.8M) between client and guest, but when I tried to copy 4times more data, nothing happened and Bug 723154 occurred.

Not sure If I can mark bug as verified based on previous experience.

Comment 12 Hans de Goede 2011-07-20 13:15:56 UTC
(In reply to comment #11)
> Hello what exactly means "more like multiple megabytes":
> 
> I was able to copy&paste /usr/share/dict/linux.words (4.8M) between client and
> guest, but when I tried to copy 4times more data, nothing happened and Bug
> 723154 occurred.
> 
> Not sure If I can mark bug as verified based on previous experience.

Hi,

Note this bug is about copying data from the client machine (ie from gedit running next to the client on the client machine), to an app (for example again gedit) inside the guest. Reading bug 723154, you are trying it to do in the other direction (from guest to client), which is unsupported with the old client, and likely will stay unsupported (see bug 690161). Although the result which you got is unexpected, rather then a backtrace I would expect an Xerror, followed by an abort by the client.

Regards,

Hans

Comment 15 Lubos Kocman 2011-07-26 10:33:06 UTC
Verified on spice-vdagent-0.8.1-1.el6

Comment 16 errata-xmlrpc 2011-12-06 12:01:53 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1577.html