Hey,
Might have been worth splitting this a bit. Regardless of that, looks
goodh to me,
Acked-by: Christophe Fergeau
On Wed, Jan 10, 2018 at 08:51:16AM +, Frediano Ziglio wrote:
> Some additional header are needed to avoid undefined types.
> SOL_TCP and IPPROTO_TCP have the same value in Lin
On Mon, Jan 15, 2018 at 3:40 AM, 王杰东 wrote:
> Firstly, I installed UsbDk 1.0.19 and VirtViewer 6.0.256 , then i tried
> UsbDk 1.0.17 and VirtViewer 5.0.256 .
>
and i tried Sandisk and Kingston usb device , all of these aborted .
> But i never install libusb additionally , only find libusb-1.0.dll
Due to the way Qemu handle the device we must consume all pending
data inside the callback to read data from the device.
We need to consume all data from previous device dialog to avoid
that next device usage is still seeing old data.
This as Qemu return 0 if you call SpiceCharDeviceInterface::read
Changes since v3:
- add a test case.
Changes since v2:
- split first patch between fix and test;
- better wording (not code changes).
Frediano Ziglio (4):
stream-device: Avoid device to get stuck if multiple messages are
batched
test-stream-device: Better Qemu emulation for data reading
Qemu does not trigger a new data read if we don't read all data in
the buffer.
Signed-off-by: Frediano Ziglio
---
server/tests/test-stream-device.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/server/tests/test-stream-device.c
b/se
If messages are sent together by the agent the device is reading
only part of the data. This cause Qemu to not poll for new data and
stream_device_read_msg_from_dev won't be called again.
This can cause a stall. To avoid this continue handling data
after a full message was processed.
Signed-off-by
Test all batched (send together) messages are handled correctly
and device is not stuck.
Signed-off-by: Frediano Ziglio
---
server/tests/test-stream-device.c | 36
1 file changed, 36 insertions(+)
diff --git a/server/tests/test-stream-device.c
b/server/test
