Re: [Spice-devel] [PATCH 1/3] qxl: disable image cache for KMS
On Fri, 2013-07-05 at 14:49 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
Currently this code can't work with KMS, need to work out how
the image cache could be effectively used with KMS enabled.
ACK All 3 patches.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/qxl_image.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/qxl_image.c b/src/qxl_image.c
index 40798b3..6c39214 100644
--- a/src/qxl_image.c
+++ b/src/qxl_image.c
@@ -50,7 +50,7 @@ static unsigned int
hash_and_copy (const uint8_t *src, int src_stride,
uint8_t *dest, int dest_stride,
int bytes_per_pixel, int width, int height,
-uint32_t hash)
+uint32_t hash, Bool do_hashing)
{
int i;
@@ -63,7 +63,8 @@ hash_and_copy (const uint8_t *src, int src_stride,
if (dest)
memcpy (dest_line, src_line, n_bytes);
- MurmurHash3_x86_32 (src_line, n_bytes, hash, hash);
+ if (do_hashing)
+ MurmurHash3_x86_32 (src_line, n_bytes, hash, hash);
}
return hash;
@@ -165,7 +166,7 @@ qxl_image_create (qxl_screen_t *qxl, const uint8_t *data,
chunk-data_size = n_lines * dest_stride;
hash = hash_and_copy (data, stride,
chunk-data, dest_stride,
- Bpp, width, n_lines, hash);
+ Bpp, width, n_lines, hash, !qxl-kms_enabled);
if (tail_bo)
{
@@ -230,8 +231,9 @@ qxl_image_create (qxl_screen_t *qxl, const uint8_t *data,
qxl-bo_funcs-bo_decref(qxl, head_bo);
/* Add to hash table if caching is enabled */
- if ((fallback qxl-enable_fallback_cache)||
- (!fallback qxl-enable_image_cache))
+ if (!qxl-kms_enabled
+ ((fallback qxl-enable_fallback_cache) ||
+ (!fallback qxl-enable_image_cache)))
{
if ((info = insert_image_info (hash)))
{
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Il 04/07/2013 12:32, Wei Liu ha scritto:
On Thu, Jul 04, 2013 at 12:16:43PM +0200, Fabio Fantoni wrote:
Il 04/07/2013 12:12, Wei Liu ha scritto:
On Thu, Jul 04, 2013 at 12:05:59PM +0200, Fabio Fantoni wrote:
Usage: spiceusbredirection=1|0 (default=0)
Enables spice usbredirection. The Spice usbredirection creates usb2
controller and 4 usbredirection channels for redirection of up to 4
usb devices from spice client to domU's qemu.
Signed-off-by: Fabio Fantoni fabio.fant...@m2r.biz
---
docs/man/xl.cfg.pod.5 |8
tools/libxl/libxl_create.c |1 +
tools/libxl/libxl_dm.c | 18 ++
tools/libxl/libxl_types.idl |1 +
tools/libxl/xl_cmdimpl.c|2 ++
5 files changed, 30 insertions(+)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 766862d..a450800 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1134,6 +1134,14 @@ requires vdagent service installed on domU o.s. to work.
The default is 0.
=back
+=item Bspiceusbredirection=BOOLEAN
+
+Enables spice usbredirection. The Spice usbredirection creates usb2
+controller and 4 usbredirection channels for redirection of up to 4 usb
+devices from spice client to domU's qemu. The default is 0.
+
+=back
+
=head3 Miscellaneous Emulated Hardware
=over 4
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8db5460..58df106 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -289,6 +289,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
false);
libxl_defbool_setdefault(b_info-u.hvm.spice.agent_mouse, true);
libxl_defbool_setdefault(b_info-u.hvm.spice.vdagent, false);
+libxl_defbool_setdefault(b_info-u.hvm.spice.usbredirection,
false);
}
libxl_defbool_setdefault(b_info-u.hvm.nographic, false);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bc605e4..4f625e0 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -471,6 +471,24 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
virtserialport,chardev=vdagent,name=com.redhat.spice.0,
NULL);
}
+
+if (libxl_defbool_val(b_info-u.hvm.spice.usbredirection)) {
+flexarray_vappend(dm_args,*-device,ich9-usb-ehci1,id=usb,
+bus=pci.0,addr=0x1d.0x7, -device,ich9-usb-uhci1,
+masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,
+addr=0x1d.0x0,
-device,ich9-usb-uhci2,masterbus=usb.0,
+firstport=2,bus=pci.0,addr=0x1d.0x1, -device,
+ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,
+addr=0x1d.0x2, -chardev,spicevmc,name=usbredir,
+id=usbrc1,-device,usb-redir,chardev=usbrc1,id=usbrc1,
+bus=usb.0, -chardev,spicevmc,name=usbredir,id=usbrc2,
+-device,usb-redir,chardev=usbrc2,id=usbrc2,bus=usb.0,
+-chardev,spicevmc,name=usbredir,id=usbrc3,-device,
+usb-redir,chardev=usbrc3,id=usbrc3,bus=usb.0, -chardev,
+spicevmc,name=usbredir,id=usbrc4,-device,usb-redir,
+chardev=usbrc4,id=usbrc4,bus=usb.0*, NULL);
Any reason for so many hardcoded options?
I searched and requested for one year on spice-devel and qemu-devel
about alternative methods but nothing found for now.
Already tried usb=1 which creates usb1 controller that is not
working with usb redirection.
What if QEMU upstream changes and these options don't work any more? In
that case this functionality is broken and users have no way to
workaround it. IMHO unless they are clearly documented we should not
consider adding in theses hardcoded options in libxl.
Added to cc spice-devel and qemu-devel for ask again if there is a
better solution to do this.
@spice-devel and qemu-devel:
Can someone help to improve qemu options above for enable usb
redirection please?
Thanks for any reply.
+}
+
}
switch (b_info-u.hvm.vga.kind) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 14425d1..80aa2b8 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -173,6 +173,7 @@ libxl_spice_info = Struct(spice_info, [
(passwd, string),
(agent_mouse, libxl_defbool),
(vdagent, libxl_defbool),
+(usbredirection, libxl_defbool),
])
libxl_sdl_info = Struct(sdl_info, [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 44a632c..5dab898 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1493,6 +1493,8 @@ skip_vfb:
b_info-u.hvm.spice.agent_mouse, 0);
xlu_cfg_get_defbool(config, spicevdagent,
b_info-u.hvm.spice.vdagent, 0);
+
Re: [Spice-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Please don't use HTML in emails
On Thu, 4 Jul 2013, Fabio Fantoni wrote:
Il 04/07/2013 12:32, Wei Liu ha scritto:
On Thu, Jul 04, 2013 at 12:16:43PM +0200, Fabio Fantoni wrote:
Il 04/07/2013 12:12, Wei Liu ha scritto:
On Thu, Jul 04, 2013 at 12:05:59PM +0200, Fabio Fantoni wrote:
Usage: spiceusbredirection=1|0 (default=0)
Enables spice usbredirection. The Spice usbredirection creates usb2
controller and 4 usbredirection channels for redirection of up to 4
usb devices from spice client to domU's qemu.
Signed-off-by: Fabio Fantoni fabio.fant...@m2r.biz
---
docs/man/xl.cfg.pod.5 |8
tools/libxl/libxl_create.c |1 +
tools/libxl/libxl_dm.c | 18 ++
tools/libxl/libxl_types.idl |1 +
tools/libxl/xl_cmdimpl.c|2 ++
5 files changed, 30 insertions(+)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 766862d..a450800 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1134,6 +1134,14 @@ requires vdagent service installed on domU o.s. to
work. The default is 0.
=back
+=item Bspiceusbredirection=BOOLEAN
+
+Enables spice usbredirection. The Spice usbredirection creates usb2
+controller and 4 usbredirection channels for redirection of up to 4 usb
+devices from spice client to domU's qemu. The default is 0.
+
+=back
+
=head3 Miscellaneous Emulated Hardware
=over 4
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8db5460..58df106 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -289,6 +289,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
false);
libxl_defbool_setdefault(b_info-u.hvm.spice.agent_mouse, true);
libxl_defbool_setdefault(b_info-u.hvm.spice.vdagent, false);
+libxl_defbool_setdefault(b_info-u.hvm.spice.usbredirection,
false);
}
libxl_defbool_setdefault(b_info-u.hvm.nographic, false);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bc605e4..4f625e0 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -471,6 +471,24 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
virtserialport,chardev=vdagent,name=com.redhat.spice.0,
NULL);
}
+
+if (libxl_defbool_val(b_info-u.hvm.spice.usbredirection)) {
+flexarray_vappend(dm_args, -device,ich9-usb-ehci1,id=usb,
+bus=pci.0,addr=0x1d.0x7, -device,ich9-usb-uhci1,
+masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,
+addr=0x1d.0x0,
-device,ich9-usb-uhci2,masterbus=usb.0,
+firstport=2,bus=pci.0,addr=0x1d.0x1, -device,
+ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,
+addr=0x1d.0x2, -chardev,spicevmc,name=usbredir,
+
id=usbrc1,-device,usb-redir,chardev=usbrc1,id=usbrc1,
+bus=usb.0,
-chardev,spicevmc,name=usbredir,id=usbrc2,
+-device,usb-redir,chardev=usbrc2,id=usbrc2,bus=usb.0,
+-chardev,spicevmc,name=usbredir,id=usbrc3,-device,
+usb-redir,chardev=usbrc3,id=usbrc3,bus=usb.0,
-chardev,
+spicevmc,name=usbredir,id=usbrc4,-device,usb-redir,
+chardev=usbrc4,id=usbrc4,bus=usb.0, NULL);
Any reason for so many hardcoded options?
I searched and requested for one year on spice-devel and qemu-devel
about alternative methods but nothing found for now.
Already tried usb=1 which creates usb1 controller that is not
working with usb redirection.
What if QEMU upstream changes and these options don't work any more? In
that case this functionality is broken and users have no way to
workaround it. IMHO unless they are clearly documented we should not
consider adding in theses hardcoded options in libxl.
Added to cc spice-devel and qemu-devel for ask again if there is a better
solution to do this.
@spice-devel and qemu-devel:
Can someone help to improve qemu options above for enable usb redirection
please?
Thanks for any reply.
It's not about improving qemu options for usb redirection (even though
they could use a simplification), it's whether they are guaranteed to be
stable. Are you sure that a future QEMU release is going to work with
these options?
For example, is libvirt using something similar to this?
Usually QEMU cmdline options are considered a stable interface, so I
wouldn't worry too much about it.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Qemu-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Am 04.07.2013 14:46, schrieb Stefano Stabellini:
On Thu, 4 Jul 2013, Fabio Fantoni wrote:
Il 04/07/2013 12:32, Wei Liu ha scritto:
On Thu, Jul 04, 2013 at 12:16:43PM +0200, Fabio Fantoni wrote:
Il 04/07/2013 12:12, Wei Liu ha scritto:
On Thu, Jul 04, 2013 at 12:05:59PM +0200, Fabio Fantoni wrote:
Usage: spiceusbredirection=1|0 (default=0)
Enables spice usbredirection. The Spice usbredirection creates usb2
controller and 4 usbredirection channels for redirection of up to 4
usb devices from spice client to domU's qemu.
Signed-off-by: Fabio Fantoni fabio.fant...@m2r.biz
---
docs/man/xl.cfg.pod.5 |8
tools/libxl/libxl_create.c |1 +
tools/libxl/libxl_dm.c | 18 ++
tools/libxl/libxl_types.idl |1 +
tools/libxl/xl_cmdimpl.c|2 ++
5 files changed, 30 insertions(+)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 766862d..a450800 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1134,6 +1134,14 @@ requires vdagent service installed on domU o.s. to
work. The default is 0.
=back
+=item Bspiceusbredirection=BOOLEAN
+
+Enables spice usbredirection. The Spice usbredirection creates usb2
+controller and 4 usbredirection channels for redirection of up to 4 usb
+devices from spice client to domU's qemu. The default is 0.
+
+=back
+
=head3 Miscellaneous Emulated Hardware
=over 4
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8db5460..58df106 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -289,6 +289,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
false);
libxl_defbool_setdefault(b_info-u.hvm.spice.agent_mouse,
true);
libxl_defbool_setdefault(b_info-u.hvm.spice.vdagent, false);
+libxl_defbool_setdefault(b_info-u.hvm.spice.usbredirection,
false);
}
libxl_defbool_setdefault(b_info-u.hvm.nographic, false);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bc605e4..4f625e0 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -471,6 +471,24 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
virtserialport,chardev=vdagent,name=com.redhat.spice.0,
NULL);
}
+
+if (libxl_defbool_val(b_info-u.hvm.spice.usbredirection)) {
+flexarray_vappend(dm_args,
-device,ich9-usb-ehci1,id=usb,
+bus=pci.0,addr=0x1d.0x7, -device,ich9-usb-uhci1,
+
masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,
+addr=0x1d.0x0,
-device,ich9-usb-uhci2,masterbus=usb.0,
+firstport=2,bus=pci.0,addr=0x1d.0x1, -device,
+ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,
+addr=0x1d.0x2, -chardev,spicevmc,name=usbredir,
+
id=usbrc1,-device,usb-redir,chardev=usbrc1,id=usbrc1,
+bus=usb.0,
-chardev,spicevmc,name=usbredir,id=usbrc2,
+
-device,usb-redir,chardev=usbrc2,id=usbrc2,bus=usb.0,
+-chardev,spicevmc,name=usbredir,id=usbrc3,-device,
+usb-redir,chardev=usbrc3,id=usbrc3,bus=usb.0,
-chardev,
+
spicevmc,name=usbredir,id=usbrc4,-device,usb-redir,
+chardev=usbrc4,id=usbrc4,bus=usb.0, NULL);
Any reason for so many hardcoded options?
I searched and requested for one year on spice-devel and qemu-devel
about alternative methods but nothing found for now.
Already tried usb=1 which creates usb1 controller that is not
working with usb redirection.
What if QEMU upstream changes and these options don't work any more? In
that case this functionality is broken and users have no way to
workaround it. IMHO unless they are clearly documented we should not
consider adding in theses hardcoded options in libxl.
Added to cc spice-devel and qemu-devel for ask again if there is a better
solution to do this.
@spice-devel and qemu-devel:
Can someone help to improve qemu options above for enable usb redirection
please?
Thanks for any reply.
It's not about improving qemu options for usb redirection (even though
they could use a simplification), it's whether they are guaranteed to be
stable. Are you sure that a future QEMU release is going to work with
these options?
For example, is libvirt using something similar to this?
Usually QEMU cmdline options are considered a stable interface, so I
wouldn't worry too much about it.
I'm not sure if pci.0 bus name of i440fx should be considered stable?
Also if at some point you try to use, e.g., q35 rather than i440fx
machine, it might have EHCI by default and the snippet would be
instantiating a duplicate one. I.e., the three levels of dependency
could be separated more clearly: PCI,
Re: [Spice-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Il 04/07/2013 19:17, Andreas Färber ha scritto: Also if at some point you try to use, e.g., q35 rather than i440fx machine, it might have EHCI by default and the snippet would be instantiating a duplicate one. I.e., the three levels of dependency could be separated more clearly: PCI, USB, redirection. At least you could start specifying the USB desired version (1.1, 2.0 with companion controllers, 3.0) as an extension of the usb=1 that is already supported. Paolo Stating the obvious, a loop would be a more readable solution for adding 4 devices only differing in device/chardev id. ;) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Il 04/07/2013 22:09, Paolo Bonzini ha scritto: Il 04/07/2013 19:17, Andreas Färber ha scritto: Also if at some point you try to use, e.g., q35 rather than i440fx machine, it might have EHCI by default and the snippet would be instantiating a duplicate one. I.e., the three levels of dependency could be separated more clearly: PCI, USB, redirection. At least you could start specifying the USB desired version (1.1, 2.0 with companion controllers, 3.0) as an extension of the usb=1 that is already supported. Paolo Thanks and sorry, I found only now that is working also with only -device usb-ehci,id=usb. I'll post a new patch version. Stating the obvious, a loop would be a more readable solution for adding 4 devices only differing in device/chardev id. ;) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Il 05/07/2013 11:02, Paolo Bonzini ha scritto: - Messaggio originale - Da: Fabio Fantoni fabio.fant...@m2r.biz A: Paolo Bonzini pbonz...@redhat.com Cc: Andreas Färber afaer...@suse.de, Stefano Stabellini stefano.stabell...@eu.citrix.com, xen-de...@lists.xensource.com, Wei Liu wei.l...@citrix.com, Ian Campbell ian.campb...@citrix.com, Ian Jackson ian.jack...@eu.citrix.com, qemu-de...@nongnu.org, Hans de Goede hdego...@redhat.com, spice-devel@lists.freedesktop.org Inviato: Venerdì, 5 luglio 2013 10:42:30 Oggetto: Re: [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu Il 04/07/2013 22:09, Paolo Bonzini ha scritto: Il 04/07/2013 19:17, Andreas Färber ha scritto: Also if at some point you try to use, e.g., q35 rather than i440fx machine, it might have EHCI by default and the snippet would be instantiating a duplicate one. I.e., the three levels of dependency could be separated more clearly: PCI, USB, redirection. At least you could start specifying the USB desired version (1.1, 2.0 with companion controllers, 3.0) as an extension of the usb=1 that is already supported. Paolo Thanks and sorry, I found only now that is working also with only -device usb-ehci,id=usb. I'll post a new patch version. With only the EHCI you might have problems redirecting USB 1.1 devices. The EHCI+UHCI magic is the right thing to do for USB 2.0 support on x86. What Andreas and I were suggesting was to split the patch in two parts: first adding support for USB 2.0/3.0, and only then adding redirection (perhaps with the possibility to customize how many redirected devices to support). Paolo What is the best parameters for adding usb2 controller, those who had already done? About usb1 controller implementation parameter in xen is only with -usb, is correct or need something better? About usb3 controller implementation what is the best parameters? About possibility to customize how many redirection channel I'll do it, if I remember good on Hans post on spice-devel I seen that max working is 4, is correct? About different usb controller implementation on xen can be good change xl parameter usb from 0|1 (usb1 controller added or not) to 0|1|2|3 where 0 is none, 1 is usb1, 2 is usb2 and 3 is usb3 or is better keep usb=0|1 and add usb_version=1|2|3 parameter? Thanks for any reply and sorry for my bad english. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
- Messaggio originale - Da: Fabio Fantoni fabio.fant...@m2r.biz A: Paolo Bonzini pbonz...@redhat.com Cc: Andreas Färber afaer...@suse.de, Stefano Stabellini stefano.stabell...@eu.citrix.com, xen-de...@lists.xensource.com, Wei Liu wei.l...@citrix.com, Ian Campbell ian.campb...@citrix.com, Ian Jackson ian.jack...@eu.citrix.com, qemu-de...@nongnu.org, Hans de Goede hdego...@redhat.com, spice-devel@lists.freedesktop.org Inviato: Venerdì, 5 luglio 2013 10:42:30 Oggetto: Re: [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu Il 04/07/2013 22:09, Paolo Bonzini ha scritto: Il 04/07/2013 19:17, Andreas Färber ha scritto: Also if at some point you try to use, e.g., q35 rather than i440fx machine, it might have EHCI by default and the snippet would be instantiating a duplicate one. I.e., the three levels of dependency could be separated more clearly: PCI, USB, redirection. At least you could start specifying the USB desired version (1.1, 2.0 with companion controllers, 3.0) as an extension of the usb=1 that is already supported. Paolo Thanks and sorry, I found only now that is working also with only -device usb-ehci,id=usb. I'll post a new patch version. With only the EHCI you might have problems redirecting USB 1.1 devices. The EHCI+UHCI magic is the right thing to do for USB 2.0 support on x86. What Andreas and I were suggesting was to split the patch in two parts: first adding support for USB 2.0/3.0, and only then adding redirection (perhaps with the possibility to customize how many redirected devices to support). Paolo ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Xen-devel] [PATCH] libxl: Spice usbredirection support for upstream qemu
Il 05/07/2013 11:27, Fabio Fantoni ha scritto: What is the best parameters for adding usb2 controller, those who had already done? About usb1 controller implementation parameter in xen is only with -usb, is correct or need something better? -usb is USB 1.0 on pc and USB 2.0 on q35. The device name for USB 1.0 is piix3-usb-uhci. About usb3 controller implementation what is the best parameters? The device name is nec-usb-xhci. Only USB 2.0 has the complication of companion controllers. About possibility to customize how many redirection channel I'll do it, if I remember good on Hans post on spice-devel I seen that max working is 4, is correct? I don't know. Paolo ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH qxl-win] display: apply the fix in fc314927bc48835e to Alpha Bitmaps
On Fri, 2013-07-05 at 11:25 -0400, Yonit Halperin wrote:
rhbz#968050
Looks great to me, ACK.
In contrast to Microsoft Msdn documentation, the iUniq of a SURFOBJ doesn't
always change when the surface changes. However, it seems that the
iUniq of the associated color_trans (XLATEOBJ) changes, while its
flXlate=XO_TRIVIAL. Since we tried to retrieve the alpha bitmap key
only by the surface iUniq, we fetched the wrong bitmap, and it looked
like parts of the screen haven't been rendered.
The patch modifies QXLGetAlphaBitmap so that it will use GetCacheImage
instead of duplicating its code. GetCacheImage was already fixed in
fc314927bc48835e to combine the iUniq of the surace and the
color_trans.
---
xddm/display/res.c | 55
++
xddm/display/res.h | 2 +-
xddm/display/rop.c | 2 +-
3 files changed, 16 insertions(+), 43 deletions(-)
diff --git a/xddm/display/res.c b/xddm/display/res.c
index 6f04475..bfb3571 100644
--- a/xddm/display/res.c
+++ b/xddm/display/res.c
@@ -2070,7 +2070,8 @@ BOOL QXLCheckIfCacheImage(PDev *pdev, SURFOBJ *surf,
XLATEOBJ *color_trans)
return FALSE;
}
-static CacheImage *GetCacheImage(PDev *pdev, SURFOBJ *surf, XLATEOBJ
*color_trans, int high_bits_set, UINT32 *hash_key)
+static CacheImage *GetCacheImage(PDev *pdev, SURFOBJ *surf, XLATEOBJ
*color_trans,
+ BOOL has_alpha, BOOL high_bits_set, UINT32
*hash_key)
{
CacheImage *cache_image;
UINT64 gdi_unique;
@@ -2085,6 +2086,10 @@ static CacheImage *GetCacheImage(PDev *pdev, SURFOBJ
*surf, XLATEOBJ *color_tran
return FALSE;
}
+if (has_alpha) {
+ASSERT(pdev, surf-iBitmapFormat == BMF_32BPP);
+format = SPICE_BITMAP_FMT_RGBA;
+}
if (!ImageKeyGet(pdev, surf-hsurf, gdi_unique, key)) {
key = GetHash(surf-pvScan0, surf-sizlBitmap.cx,
surf-sizlBitmap.cy, format,
high_bits_set, line_size, surf-lDelta, color_trans);
@@ -2225,7 +2230,7 @@ BOOL QXLGetBitmap(PDev *pdev, QXLDrawable *drawable,
QXLPHYSICAL *image_phys, SU
high_bits_set)
!high_bits_set) {
return QXLGetAlphaBitmap(pdev, drawable, image_phys,
- surf, area, surface_dest);
+ surf, area, surface_dest, color_trans);
}
}
@@ -2238,7 +2243,7 @@ BOOL QXLGetBitmap(PDev *pdev, QXLDrawable *drawable,
QXLPHYSICAL *image_phys, SU
surf-iBitmapFormat));
if (use_cache) {
-cache_image = GetCacheImage(pdev, surf, color_trans, high_bits_set,
hash_key);
+cache_image = GetCacheImage(pdev, surf, color_trans, FALSE,
high_bits_set, hash_key);
if (cache_image cache_image-image) {
DEBUG_PRINT((pdev, 11, %s: cached image found %u\n,
__FUNCTION__, cache_image-key));
internal = cache_image-image;
@@ -2331,7 +2336,7 @@ BOOL QXLGetBitmap(PDev *pdev, QXLDrawable *drawable,
QXLPHYSICAL *image_phys, SU
}
BOOL QXLGetAlphaBitmap(PDev *pdev, QXLDrawable *drawable, QXLPHYSICAL
*image_phys,
- SURFOBJ *surf, QXLRect *area, INT32 *surface_dest)
+ SURFOBJ *surf, QXLRect *area, INT32 *surface_dest,
XLATEOBJ *color_trans)
{
Resource *image_res;
InternalImage *internal;
@@ -2347,10 +2352,11 @@ BOOL QXLGetAlphaBitmap(PDev *pdev, QXLDrawable
*drawable, QXLPHYSICAL *image_phy
area-top = 0 area-bottom = surf-sizlBitmap.cy);
DEBUG_PRINT((pdev, 11, %s: iUniq=%x DONTCACHE=%x w=%d h=%d cx=%d cy=%d
- hsurf=%x format=%u\n, __FUNCTION__, surf-iUniq,
+ hsurf=%x format=%u color_trans-iUniq=%x\n, __FUNCTION__,
surf-iUniq,
surf-fjBitmap BMF_DONTCACHE, width, height,
surf-sizlBitmap.cx, surf-sizlBitmap.cy, surf-hsurf,
- surf-iBitmapFormat));
+ surf-iBitmapFormat,
+ color_trans ? color_trans-iUniq : 0));
if (surf-iType != STYPE_BITMAP) {
UINT32 alloc_size;
@@ -2381,30 +2387,9 @@ BOOL QXLGetAlphaBitmap(PDev *pdev, QXLDrawable
*drawable, QXLPHYSICAL *image_phy
}
ASSERT(pdev, surf-iBitmapFormat == BMF_32BPP surf-iType ==
STYPE_BITMAP);
+cache_image = GetCacheImage(pdev, surf, color_trans, TRUE, FALSE, key);
-//todo: use GetCacheImage
-
-// NOTE: Same BMF_DONTCACHE issue as in QXLGetBitmap
-if (!surf-iUniq || (surf-fjBitmap BMF_DONTCACHE)) {
-gdi_unique = 0;
-} else {
-gdi_unique = surf-iUniq;
-}
-
-if (!ImageKeyGet(pdev, surf-hsurf, gdi_unique, key)) {
-key = GetHash(surf-pvScan0, surf-sizlBitmap.cx,
surf-sizlBitmap.cy, SPICE_BITMAP_FMT_RGBA,
- FALSE, surf-sizlBitmap.cx 2, surf-lDelta, NULL);
-
Re: [Spice-devel] [PATCH qxl-win] display: apply the fix in fc314927bc48835e to Alpha Bitmaps
On 07/05/2013 06:25 PM, Yonit Halperin wrote:
rhbz#968050
In contrast to Microsoft Msdn documentation, the iUniq of a SURFOBJ doesn't
always change when the surface changes. However, it seems that the
iUniq of the associated color_trans (XLATEOBJ) changes, while its
flXlate=XO_TRIVIAL. Since we tried to retrieve the alpha bitmap key
only by the surface iUniq, we fetched the wrong bitmap, and it looked
like parts of the screen haven't been rendered.
The patch modifies QXLGetAlphaBitmap so that it will use GetCacheImage
instead of duplicating its code. GetCacheImage was already fixed in
fc314927bc48835e to combine the iUniq of the surace and the
color_trans.
Ack.
---
xddm/display/res.c | 55 ++
xddm/display/res.h | 2 +-
xddm/display/rop.c | 2 +-
3 files changed, 16 insertions(+), 43 deletions(-)
diff --git a/xddm/display/res.c b/xddm/display/res.c
index 6f04475..bfb3571 100644
--- a/xddm/display/res.c
+++ b/xddm/display/res.c
@@ -2070,7 +2070,8 @@ BOOL QXLCheckIfCacheImage(PDev *pdev, SURFOBJ *surf,
XLATEOBJ *color_trans)
return FALSE;
}
-static CacheImage *GetCacheImage(PDev *pdev, SURFOBJ *surf, XLATEOBJ *color_trans, int high_bits_set, UINT32 *hash_key)
+static CacheImage *GetCacheImage(PDev *pdev, SURFOBJ *surf, XLATEOBJ
*color_trans,
+ BOOL has_alpha, BOOL high_bits_set, UINT32
*hash_key)
{
CacheImage *cache_image;
UINT64 gdi_unique;
@@ -2085,6 +2086,10 @@ static CacheImage *GetCacheImage(PDev *pdev, SURFOBJ
*surf, XLATEOBJ *color_tran
return FALSE;
}
+if (has_alpha) {
+ASSERT(pdev, surf-iBitmapFormat == BMF_32BPP);
+format = SPICE_BITMAP_FMT_RGBA;
+}
if (!ImageKeyGet(pdev, surf-hsurf, gdi_unique, key)) {
key = GetHash(surf-pvScan0, surf-sizlBitmap.cx,
surf-sizlBitmap.cy, format,
high_bits_set, line_size, surf-lDelta, color_trans);
@@ -2225,7 +2230,7 @@ BOOL QXLGetBitmap(PDev *pdev, QXLDrawable *drawable,
QXLPHYSICAL *image_phys, SU
high_bits_set)
!high_bits_set) {
return QXLGetAlphaBitmap(pdev, drawable, image_phys,
- surf, area, surface_dest);
+ surf, area, surface_dest, color_trans);
}
}
@@ -2238,7 +2243,7 @@ BOOL QXLGetBitmap(PDev *pdev, QXLDrawable *drawable, QXLPHYSICAL *image_phys, SU
surf-iBitmapFormat));
if (use_cache) {
-cache_image = GetCacheImage(pdev, surf, color_trans, high_bits_set,
hash_key);
+cache_image = GetCacheImage(pdev, surf, color_trans, FALSE,
high_bits_set, hash_key);
if (cache_image cache_image-image) {
DEBUG_PRINT((pdev, 11, %s: cached image found %u\n, __FUNCTION__,
cache_image-key));
internal = cache_image-image;
@@ -2331,7 +2336,7 @@ BOOL QXLGetBitmap(PDev *pdev, QXLDrawable *drawable,
QXLPHYSICAL *image_phys, SU
}
BOOL QXLGetAlphaBitmap(PDev *pdev, QXLDrawable *drawable, QXLPHYSICAL *image_phys,
- SURFOBJ *surf, QXLRect *area, INT32 *surface_dest)
+ SURFOBJ *surf, QXLRect *area, INT32 *surface_dest,
XLATEOBJ *color_trans)
{
Resource *image_res;
InternalImage *internal;
@@ -2347,10 +2352,11 @@ BOOL QXLGetAlphaBitmap(PDev *pdev, QXLDrawable
*drawable, QXLPHYSICAL *image_phy
area-top = 0 area-bottom = surf-sizlBitmap.cy);
DEBUG_PRINT((pdev, 11, %s: iUniq=%x DONTCACHE=%x w=%d h=%d cx=%d cy=%d
- hsurf=%x format=%u\n, __FUNCTION__, surf-iUniq,
+ hsurf=%x format=%u color_trans-iUniq=%x\n, __FUNCTION__,
surf-iUniq,
surf-fjBitmap BMF_DONTCACHE, width, height,
surf-sizlBitmap.cx, surf-sizlBitmap.cy, surf-hsurf,
- surf-iBitmapFormat));
+ surf-iBitmapFormat,
+ color_trans ? color_trans-iUniq : 0));
if (surf-iType != STYPE_BITMAP) {
UINT32 alloc_size;
@@ -2381,30 +2387,9 @@ BOOL QXLGetAlphaBitmap(PDev *pdev, QXLDrawable
*drawable, QXLPHYSICAL *image_phy
}
ASSERT(pdev, surf-iBitmapFormat == BMF_32BPP surf-iType == STYPE_BITMAP);
+cache_image = GetCacheImage(pdev, surf, color_trans, TRUE, FALSE, key);
-//todo: use GetCacheImage
-
-// NOTE: Same BMF_DONTCACHE issue as in QXLGetBitmap
-if (!surf-iUniq || (surf-fjBitmap BMF_DONTCACHE)) {
-gdi_unique = 0;
-} else {
-gdi_unique = surf-iUniq;
-}
-
-if (!ImageKeyGet(pdev, surf-hsurf, gdi_unique, key)) {
-key = GetHash(surf-pvScan0, surf-sizlBitmap.cx, surf-sizlBitmap.cy,
SPICE_BITMAP_FMT_RGBA,
- FALSE, surf-sizlBitmap.cx 2, surf-lDelta, NULL);
-ImageKeyPut(pdev, surf-hsurf, gdi_unique, key);
-DEBUG_PRINT((pdev, 11, %s: ImageKeyPut %u\n,
Re: [Spice-devel] [PATCH] Use RING_FOREACH_SAFE in red_channel.c functions which are missing it
On 07/05/2013 03:45 PM, David Gibson wrote: On Fri, Jul 05, 2013 at 08:35:21AM -0400, Yonit Halperin wrote: Ack. Thanks! We have recently associated this problem with some opened bugs we have. I believe Uri is working on a patch for a similar fix to the red_pipes.* routines in red_worker. https://bugzilla.redhat.com/show_bug.cgi?id=887775 for example? This is exactly the bug I was looking into. I have a patch-set replacing some FOREACH macros to SAFE. In addition to red_channel, some changes are needed in red_worker too. I'll send patches soon. Since the cost of using SAFE macros is insignificant (a local pointer variable and one more assignment per iteration), maybe it's better to always use SAFE macros. Thanks, Uri. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] on usbredir function of virtviewer
USB is certainly supported on Windows what version of the client are you running? - Original Message - From: letterdove letterd...@yeah.net To: spice-devel@lists.freedesktop.org Sent: Sunday, June 30, 2013 10:35:41 PM Subject: [Spice-devel] on usbredir function of virtviewer Dear Mr/Miss, I am experiencing spice-client software virtviewer for sevral months.Here is my idea of it that I found usbredir capcability of the virtviewer is unavailable on Microsoft Windows. I've noticed that the virtviewer developers dedicated to the project seemed to have no idea to make up for this deficiency even though the software has been updated for many times.I wonder whether there are any other approaches to experience the function of usbredirec on Windows platform? Thank you! nb sp; sincerely Yours ; July 1st,2013 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
