How about WebM?
http://www.webmproject.org/
Sounds like it could be useful :)
Best Regards,
Attila Sukosd
-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk
On Thu, Jun 23, 2011 at 1:58 AM, John A.
Hi,
I assume this libspice will contain spice/common + spice-protocol? Or do
you envision the protocol bits to go elsewhere?
I like this idea more than merging keeping the current moduleset and
merging spice-gtk in spice, but I was under the impression that turning
common/ into a library was
Hi,
On 06/22/2011 08:01 PM, Alon Levy wrote:
On Wed, Jun 22, 2011 at 08:14:57PM +0300, Uri Lublin wrote:
snip snip
What will you do with other components that require spice-protocol,
such as spice-vdagent.
we will still package spice-protocol as an rpm, and if you want to build from
git
According to spice.proto the smartcard channel can receive acks and any
other message defined in BaseChannel. While the spicec implementation didn't
send an ACK spice-gtk does, so handle it.
---
server/smartcard.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git
---
server/smartcard.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/server/smartcard.c b/server/smartcard.c
index f948e5b..7830c9a 100644
--- a/server/smartcard.c
+++ b/server/smartcard.c
@@ -538,6 +538,10 @@ void smartcard_channel_init(void)
{
Channel
On Thu, Jun 23, 2011 at 11:16:48AM +0200, Alon Levy wrote:
---
server/smartcard.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/server/smartcard.c b/server/smartcard.c
index f948e5b..7830c9a 100644
--- a/server/smartcard.c
+++ b/server/smartcard.c
@@ -538,6
On Thu, Jun 23, 2011 at 11:16:47AM +0200, Alon Levy wrote:
According to spice.proto the smartcard channel can receive acks and any
other message defined in BaseChannel. While the spicec implementation didn't
send an ACK spice-gtk does, so handle it.
---
server/smartcard.c |6 ++
1
Dne 23.6.2011 11:49, Alon Levy napsal(a):
On Thu, Jun 23, 2011 at 10:50:57AM +0300, Yaniv Kaul wrote:
We could throw many more into the thread.
When comparing video encodings, we must take into account:
- speed of encoding (many of the encoders are not fast enough for
real time, they may decode
On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
Hi All,
Ok, take two with Gerd's and Hans's and Uri's comments.
(1) spice-protocol - keep it, move code generation stuff here
(spice_codegen.py, python_modules, spice*.proto), and have the dist tarball
contain the cpp and c files
On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
Hi All,
Ok, take two with Gerd's and Hans's and Uri's comments.
(1) spice-protocol - keep it, move code generation stuff here
(spice_codegen.py, python_modules,
Hi,
On 06/23/2011 12:18 PM, Alon Levy wrote:
On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
Hi All,
Ok, take two with Gerd's and Hans's and Uri's comments.
(1) spice-protocol - keep it, move code generation stuff here
(spice_codegen.py, python_modules, spice*.proto), and
Hi,
(1) spice-protocol - keep it, move code generation stuff here
(spice_codegen.py, python_modules, spice*.proto), and have the dist tarball
contain the cpp and c files resulting from running it.
Compile them into a small shared library?
(2) spice-server - new repo from
On Thu, Jun 23, 2011 at 12:28:31PM +0200, Christophe Fergeau wrote:
On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
Hi All,
Ok, take two with Gerd's and Hans's and Uri's comments.
(1) spice-protocol - keep it,
On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
Hi All,
Ok, so take three:
(1) spice-protocol - remains unchanged. specifically, despite the name, will
not contain the .proto nor the python codegen bits nor the
Ok, so take three:
(1) spice-protocol - remains unchanged. specifically, despite the
name, will not contain the .proto nor the python codegen bits nor the
generated files.
(2) spice-common (repository spice/common) - new repository,
contains: spice*.proto spice_codegen.py and friends
On Thu, Jun 23, 2011 at 12:10:31PM +0200, Christophe Fergeau wrote:
On Thu, Jun 23, 2011 at 11:16:47AM +0200, Alon Levy wrote:
According to spice.proto the smartcard channel can receive acks and any
other message defined in BaseChannel. While the spicec implementation didn't
send an ACK
Hi
On Thu, Jun 23, 2011 at 1:10 PM, Alon Levy al...@redhat.com wrote:
On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
Hi All,
Ok, so take three:
(1) spice-protocol - remains unchanged. specifically, despite the name,
On Thu, Jun 23, 2011 at 01:10:01PM +0200, Alon Levy wrote:
On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
Hi All,
Ok, so take three:
(1) spice-protocol - remains unchanged. specifically, despite the name, will
On Thu, Jun 23, 2011 at 01:56:19PM +0200, Marc-André Lureau wrote:
Hi
On Thu, Jun 23, 2011 at 1:10 PM, Alon Levy al...@redhat.com wrote:
On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
Hi All,
Ok, so take three:
On Thu, Jun 23, 2011 at 01:56:19PM +0200, Marc-André Lureau wrote:
(6) spice-all - convenience repository that has the rest as submodules and
has a helpful makefile to build them all.
Well, why not just use jhbuild? it does the job fine..
Though the moduleset might have bitrotten a
Hi
2011/6/23 Alon Levy al...@redhat.com:
On Thu, Jun 23, 2011 at 01:56:19PM +0200, Marc-André Lureau wrote:
On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
(1) spice-protocol - remains unchanged. specifically, despite the name,
will
not contain the .proto nor the python
On 06/23/2011 02:15 PM, Marc-André Lureau wrote:
Hi
2011/6/23 Alon Levyal...@redhat.com:
On Thu, Jun 23, 2011 at 01:56:19PM +0200, Marc-André Lureau wrote:
On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
(1) spice-protocol - remains unchanged. specifically, despite the name,
hi
On Thu, Jun 23, 2011 at 2:21 PM, Hans de Goede hdego...@redhat.com wrote:
For people who want to build for example the windows driver from source
having to first install (and maybe even build, so as to be able to do
make install) -common is a bit of a pain.
Would that be enough for windows
Hi,
We can't rely on distributions packaging, we want our tarballs to be easy to
use.
spice-protocol as is is small, and contains what is required by drivers, agent,
activeX and xpi. So no reason to make it larger. Common will contain what is
required
by the client and server.
Can also be
On 06/23/2011 02:10 PM, Alon Levy wrote:
On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
Hi All,
Ok, so take three:
(1) spice-protocol - remains unchanged. specifically, despite the name, will
not contain the
On Thu, Jun 23, 2011 at 3:06 PM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
We can't rely on distributions packaging, we want our tarballs to be easy
to use.
spice-protocol as is is small, and contains what is required by drivers,
agent,
activeX and xpi. So no reason to make it larger.
I thought I had seen this in a previous email but could not find it. S.
When attempting to make spice-gtk against the gtk-osx project after
executing:
./autogen.sh --with-audio=gstreamer --without-python
--with-coroutine=gthread --with-gtk=2.0 --enable-smartcard=no
I get the following
On Wed, Jun 22, 2011 at 10:46:06AM +0200, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/qxl.c | 134
--
hw/qxl.h |3 +
2 files changed, 133 insertions(+), 4 deletions(-)
diff --git a/hw/qxl.c
On Wed, Jun 22, 2011 at 10:45:59AM +0200, Gerd Hoffmann wrote:
Hi,
This patch series introduces non-blocking versions of the qxl io port
commands to avoid blocking qemu and the guest vcpu. Needs guest driver
updates. Patches for spice-protocol and xf86-video-qxl follow.
Tested with
On Wed, Jun 22, 2011 at 10:46:18AM +0200, Gerd Hoffmann wrote:
Add async versions of the I/O commands which do not block and instead
raise the new QXL_INTERRUPT_IO_CMD when done.
Looks good, ACK.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
spice/qxl_dev.h |9 +
1
---
miniport/qxl.inf |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/miniport/qxl.inf b/miniport/qxl.inf
index bb7f582..6527075 100644
--- a/miniport/qxl.inf
+++ b/miniport/qxl.inf
@@ -20,18 +20,22 @@ qxl.Display = 11; system32
; WinXP x86 and up
[q.NTx86]
Fixes same issue in RHBZ#700134, but for a windows guest. Requires a revision 3
pci device, that will be introduced with qemu patches. If the revision is 2 the
old behavior is maintained, namely using the non asynchronous io ports.
qxl revision 3 (QXL_REVISION_V10) gains support for async io
---
display/driver.c |1 +
display/qxldd.h |2 ++
include/qxl_driver.h |2 ++
miniport/qxl.c |4
4 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/display/driver.c b/display/driver.c
index f82c744..2c88cc5 100644
--- a/display/driver.c
+++
I thought I had seen this in a previous email but could not find it. S.
When attempting to make spice-gtk against the gtk-osx project after
executing:
./autogen.sh --with-audio=gstreamer --without-python
--with-coroutine=gthread --with-gtk=2.0 --enable-smartcard=no
I get the following
34 matches
Mail list logo
