Is we are not able to get source bo object from handle we free
destination bo object and call cleanup code however destination
object was already inserted in reloc_info array (num_relocs was
already incremented) so on cleanup we free destination again.
Signed-off-by: Frediano Ziglio
Only EBUSY error was handled. This could cause code to believe
reserve was successful while it failed.
Signed-off-by: Frediano Ziglio fzig...@redhat.com
---
qxl/qxl_cmd.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/qxl/qxl_cmd.c b/qxl/qxl_cmd.c
index
qxl_bo structure has two reference counters, one in the GEM object and
another in the TTM object. The GEM object keep a counter to the TTM object
so when GEM counter reached zero the TTM counter (using qxl_bo_unref) was
decremented. The qxl object is fully freed (both GEM and TTM part are cleaned)
This function return handle to allocated release object which is an int.
Signed-off-by: Frediano Ziglio fzig...@redhat.com
---
qxl/qxl_release.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qxl/qxl_release.c b/qxl/qxl_release.c
index d9b2568..6fd8e50 100644
---
This function could return a NULL pointer in case of handle not
present and in case of out of memory conditions however caller
function always returned EINVAL error hiding a possible ENOMEM.
This patch change the function to return the error instead to
be able to propagate the error instead of
reloc_info[i] is not still initialized in the print statement.
Signed-off-by: Frediano Ziglio fzig...@redhat.com
---
qxl/qxl_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qxl/qxl_ioctl.c b/qxl/qxl_ioctl.c
index e8b5207..230ab84 100644
--- a/qxl/qxl_ioctl.c
+++
In qxlhw_handle_to_bo we incremented counters twice, one time for release object
and one for reloc_info.
In the main function however reloc_info references was drop much earlier than
release so keeping the pointer only on release is safe and make cleaning
process easier.
Signed-off-by: Frediano
Free resources correctly if function fails
Signed-off-by: Frediano Ziglio fzig...@redhat.com
---
qxl/qxl_release.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/qxl/qxl_release.c b/qxl/qxl_release.c
index 6fd8e50..00604ed 100644
--- a/qxl/qxl_release.c
+++
If objects are moved back from system memory to VRAM (and spice id
created again) memory is already initialized so we need to set flag
to not clear memory.
If you don't do it after a while using desktop many images turns to
black or transparents.
Signed-off-by: Frediano Ziglio fzig...@redhat.com
This set of patches mainly contains fix for some memory issues
using quite aggressively surfaces and other minor problems like
images going black after a while.
Frediano Ziglio (11):
Do not cause spice-server to clean our objects
Do not leak memory if qxl_release_list_add fails
Fix print
If the function fails reference counter to the object is not decremented
causing leaks.
This is hard to spot as it happens only on very low memory situations.
Signed-off-by: Frediano Ziglio fzig...@redhat.com
---
qxl/qxl_ioctl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
---
Hey,
As suggested by poma, it might be a good time to have a 0.16.0 release of
spice-vdagent. Let me know what you think :)
Christophe
Makefile.am | 1 +
NEWS | 10 ++
configure.ac | 2 +-
3 files changed, 12 insertions(+), 1 deletion(-)
create mode 100644 NEWS
diff
---
This is needed if we are to do a spice-vdagent release. There are a few pending
patches on the mailing list doing more additions to that file, but we can aim
at making a 0.12.9 release soon after they are merged.
Christophe
NEWS | 5 +
1 file changed, 5 insertions(+)
diff --git a/NEWS
On Wed, May 27, 2015 at 8:47 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
On Wed, May 27, 2015 at 6:03 AM, Frediano Ziglio fzig...@redhat.com wrote:
This set of patches mainly contains fix for some memory issues
using quite aggressively surfaces and other minor problems like
images going
On Wed, May 27, 2015 at 6:03 AM, Frediano Ziglio fzig...@redhat.com wrote:
This set of patches mainly contains fix for some memory issues
using quite aggressively surfaces and other minor problems like
images going black after a while.
Frediano Ziglio (11):
Do not cause spice-server to
On Wed, May 27, 2015 at 8:47 AM, Josh Boyer jwbo...@fedoraproject.org
wrote:
On Wed, May 27, 2015 at 6:03 AM, Frediano Ziglio fzig...@redhat.com
wrote:
This set of patches mainly contains fix for some memory issues
using quite aggressively surfaces and other minor problems like
Provide a special authentication error message for too long passwords.
Also check for too long passwords before sending them over the wire.
---
Diff to v1:
* Added a check in spice_channel_send_spice_ticket
* moved spice_channel_failed_authentication before
spice_channel_send_spice_ticket
This patch simply replaces the mjpeg_encoder_xxx() call points with a more
object oriented design.
---
Changes since take 1:
- I fixed the width/height comments and they now state that they always
match src. Unless some reason not to is discovered, I'll submit a
separate patch to remove
It is redundant with the corresponding callbacks.
---
As far as I can tell this patch was ok in the previous round so no
change this time around.
server/mjpeg_encoder.c | 22 +-
server/mjpeg_encoder.h | 2 +-
server/red_worker.c| 4 ++--
3 files changed, 16
---
Thanks to Fabio Fantoni for noticing that spice.proto needed updating
too. I think I did not notice the issue because the top-level autogen.sh
keeps rechecking out spice-protocol so spice-protocol/spice/enums.h
ended up always being newer than spice.proto.
spice.proto | 1 +
1 file
The video encoder preferences can be expressed by building a semi-colon
separated list of encoder:codec pairs. For instance 'gstreamer:vp8;spice:mjpeg'
to pick first the GStreamer VP8 video encoder first and used the original MJPEG
video encoder one as a fallback.
The server has a default
Clients that support multiple codecs should advertise the
SPICE_DISPLAY_CAP_MULTI_CODEC capability and one SPICE_DISPLAY_CAP_CODEC_XXX
per supported codec.
---
As far as I can tell this patch was ok in the previous round so no
change this time around.
spice/enums.h| 1 +
spice/protocol.h
The GStreamer video encoder is quite primitive and mostly meant to introduce,
test and debug the basic infrastructure.
The main limitation is the lack of rate control: the bitrate is set at startup
and will not react to changes in the network conditions. Still it should work
fine on LANs.
---
On Thu, 21 May 2015, Fabio Fantoni wrote:
[...]
Thanks for improving spice, I tried your patches, I applied the
spice-gtk, spice-protocol and I updated the git submodule to use right
spice-protocol but make of spice-common/common generate a new enum.h and
override the spice-protocol patch
In addition, the name has a typo :)
ACK
On Wed, 2015-05-27 at 16:21 +0200, Francois Gouget wrote:
---
This struct was introduced in the first commit, c1b79eb0, about 6 years
ago, but has never been used. So I think it's safe to remove.
server/red_dispatcher.c | 10 --
1 file
---
This struct was introduced in the first commit, c1b79eb0, about 6 years
ago, but has never been used. So I think it's safe to remove.
server/red_dispatcher.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/server/red_dispatcher.c b/server/red_dispatcher.c
index
Il 27/05/2015 15:13, Francois Gouget ha scritto:
The video encoder preferences can be expressed by building a semi-colon
separated list of encoder:codec pairs. For instance
'gstreamer:vp8;spice:mjpeg' to pick first the GStreamer VP8 video encoder
first and used the original MJPEG video
* [PATCH qemu 08/11] Add the ability to specify Spice video codecs.
http://lists.freedesktop.org/archives/spice-devel/2015-May/019771.html
Qemu patch have an error:
http://lists.freedesktop.org/archives/spice-devel/2015-May/019901.html
Yes, thanks. There is an error with spice-html5 as
This enables a kill of an Xorg process to propogate further.
Without this, the read masks would be set, and we could end up
blocking in an accept() call and not exiting from the signal.
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
src/spiceqxl_main_loop.c | 2 +-
1 file changed, 1
On 27 May 2015 at 20:04, Frediano Ziglio fzig...@redhat.com wrote:
Only EBUSY error was handled. This could cause code to believe
reserve was successful while it failed.
Signed-off-by: Frediano Ziglio fzig...@redhat.com
This has been there since I wrote qxl, so I expect I had some reason
for
On 27 May 2015 at 20:04, Frediano Ziglio fzig...@redhat.com wrote:
This function return handle to allocated release object which is an int.
Reviewed-by: Dave Airlie airl...@redhat.com
Signed-off-by: Frediano Ziglio fzig...@redhat.com
---
qxl/qxl_release.c | 2 +-
1 file changed, 1
On 27 May 2015 at 20:03, Frediano Ziglio fzig...@redhat.com wrote:
If objects are moved back from system memory to VRAM (and spice id
created again) memory is already initialized so we need to set flag
to not clear memory.
If you don't do it after a while using desktop many images turns to
On 27 May 2015 at 20:03, Frediano Ziglio fzig...@redhat.com wrote:
If the function fails reference counter to the object is not decremented
causing leaks.
This is hard to spot as it happens only on very low memory situations.
Signed-off-by: Frediano Ziglio fzig...@redhat.com
Looks good,
On 27 May 2015 at 20:04, Frediano Ziglio fzig...@redhat.com wrote:
Enable format string checks for qxl_io_log and remove resulting warnings
which could lead to memory errors on different platform or just printing
wrong information.
Signed-off-by: Frediano Ziglio fzig...@redhat.com
On 19 May 2015 at 19:54, Frediano Ziglio fzig...@redhat.com wrote:
This problem happens using KMS surfaces and QXL driver.
To easy reproduce use KDE Plasma (which use surfaces a lot) and assure
you are using KMS surfaces (QXL driver on Fedora/RedHat has a patch to
stop using them). Open some
On 27 May 2015 at 20:04, Frediano Ziglio fzig...@redhat.com wrote:
Free resources correctly if function fails
Signed-off-by: Frediano Ziglio fzig...@redhat.com
Reviewed-by: Dave Airlie airl...@redhat.com
___
Spice-devel mailing list
I was using a different repository with only QXL driver. I tested and all
patches apply and compile perfectly even with Linus master branch.
Lets only post patches people can apply, it makes it harder to figure
out stuff. I'll take a look at the patches, but it would be good to
get them resent
On 27 May 2015 at 20:04, Frediano Ziglio fzig...@redhat.com wrote:
qxl_bo structure has two reference counters, one in the GEM object and
another in the TTM object. The GEM object keep a counter to the TTM object
so when GEM counter reached zero the TTM counter (using qxl_bo_unref) was
On 27 May 2015 at 20:04, Frediano Ziglio fzig...@redhat.com wrote:
In qxlhw_handle_to_bo we incremented counters twice, one time for release
object
and one for reloc_info.
In the main function however reloc_info references was drop much earlier than
release so keeping the pointer only on
Add search strategy on USB3 controller, NUSB3
represents Renesas Electronics usb 3 controller, IUSB3 represents to Intel
USB 3 controller
Signed-off-by: Jay.Han ezzze...@gmail.com
---
UsbDk/FilterDevice.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On 27 May 2015 at 20:03, Frediano Ziglio fzig...@redhat.com wrote:
reloc_info[i] is not still initialized in the print statement.
Signed-off-by: Frediano Ziglio fzig...@redhat.com
Reviewed-by: Dave Airlie airl...@redhat.com
___
Spice-devel mailing
On 27 May 2015 at 20:03, Frediano Ziglio fzig...@redhat.com wrote:
Is we are not able to get source bo object from handle we free
destination bo object and call cleanup code however destination
object was already inserted in reloc_info array (num_relocs was
already incremented) so on cleanup
On 27 May 2015 at 20:04, Frediano Ziglio fzig...@redhat.com wrote:
This function could return a NULL pointer in case of handle not
present and in case of out of memory conditions however caller
function always returned EINVAL error hiding a possible ENOMEM.
This patch change the function to
43 matches
Mail list logo
