So I sent my comments on patch 04/20 before this one, but this is
obviously very closely related. This spice protocol message type is
being added to support that new vdagent message. This is a pretty
significant change (from a protocol point of view), because in addition
to adding the new id data p
I'm wondering if this new message is strictly necessary. We *could*
still support the vgpu scenario with the old message, couldn't we?
(By the way, I'm not asking whether the old message is *better* or not,
just whether this change is absolutely necessary to support the
scenario we're trying to su
On Thu, 2018-08-16 at 18:26 +0200, Lukáš Hrázký wrote:
> The StreamInfo message contanis information about the new stream,
> e.g.
> the guest (xrandr) output ID of the monitor that is being streamed.
>
> Signed-off-by: Lukáš Hrázký
> ---
> configure.ac | 2 +-
> src/spice-strea
On Tue, 2018-08-21 at 17:35 +0200, Christophe Fergeau wrote:
> Hey,
>
> On Thu, Aug 02, 2018 at 11:43:58AM +0200, Jakub Jelen wrote:
> > diff --git a/tests/hwtests.c b/tests/hwtests.c
> > index 7beebac..bd8e439 100644
> > --- a/tests/hwtests.c
> > +++ b/tests/hwtests.c
> > @@ -268,6 +268,85 @@ sta
On Tue, 2018-08-21 at 14:51 +0200, Marc-André Lureau wrote:
> Hi
>
> On Tue, Aug 21, 2018 at 2:08 PM Lukáš Hrázký
> wrote:
> >
> > On Tue, 2018-08-21 at 13:09 +0200, Marc-André Lureau wrote:
> > > The API & protocol abstracted away the channel ID/monitor ID
> > > details
> > > for the client. Yo
Hey,
On Thu, Aug 02, 2018 at 11:43:58AM +0200, Jakub Jelen wrote:
> diff --git a/tests/hwtests.c b/tests/hwtests.c
> index 7beebac..bd8e439 100644
> --- a/tests/hwtests.c
> +++ b/tests/hwtests.c
> @@ -268,6 +268,85 @@ static void test_get_response_hw(void) {
> test_get_response();
> }
>
>
Hey,
I've been trying to cut a spice-server release for a long time now, it's
one of the patches I'd prefer to punt to after the release (which I was
supposed to be doing today, but while testing it I hit these unrelated
libcacard issues... :-/ )
Christophe
On Mon, Aug 20, 2018 at 03:51:41PM +02
On Tue, 2018-08-21 at 17:03 +0200, Christophe Fergeau wrote:
> hex_dump() callers can theoretically provide the destination buffer
> for the hexdump'ed string, but nothing in libcacard uses that
> feature.
> This commit removes it.
The initial idea was to create some g_debug_hex function that coul
So, could this mean next releases are somewhat close by now, by any chance?
Thanks again.
2018-08-08 9:41 GMT-05:00 Christophe Fergeau :
> Adding Yuri to cc: in case he missed that email.
>
> Christophe
>
> On Fri, Aug 03, 2018 at 12:15:03PM +0200, Victor Toso wrote:
> > Hi,
> >
> > On Wed, Aug
It has elements from 0 to num_applets-1, and we were using elements from
0 to num_applets when iterating in cac_aca_get_applet_acr_coid()
Signed-off-by: Christophe Fergeau
---
src/cac-aca.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cac-aca.c b/src/cac-aca.c
index 3e
Signed-off-by: Christophe Fergeau
---
src/card_7816.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/card_7816.c b/src/card_7816.c
index ccb63b6..298c0c5 100644
--- a/src/card_7816.c
+++ b/src/card_7816.c
@@ -17,7 +17,7 @@
/* Global Platform Card Manager applet AID */
s
vcard_emul_make_key() allocates memory for the VCardKey structure, but
vcard_emul_delete_key never frees that memory. Since VCardKey definition
is private to vcard-emul-nss.c, there are no users which could use a
stack-allocated VCardKey.
Signed-off-by: Christophe Fergeau
---
src/vcard_emul_nss.
gp_card_init() has a prototype similar to cac_card_init() but does not
use most of its parameters. This commit removes these.
Signed-off-by: Christophe Fergeau
---
src/gp.c | 7 +--
src/gp.h | 5 +
src/vcard_emul_type.c | 5 ++---
3 files changed, 4 insertions(+
Signed-off-by: Christophe Fergeau
---
src/cac-aca.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/cac-aca.c b/src/cac-aca.c
index 778772e..87b0911 100644
--- a/src/cac-aca.c
+++ b/src/cac-aca.c
@@ -131,7 +131,7 @@ struct acr_table {
* 00
When printing the hexdump output, the hex_dump() function prints 5
visible chars at a time, but since it's using sprintf, it will also
print a '\0'. Since its output string are sized to be 5*number_of_chars,
this means we will overflow the output string by one character on the
last iteration. This
hex_dump() is not going to modify it.
Signed-off-by: Christophe Fergeau
---
src/common.c | 2 +-
src/common.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/common.c b/src/common.c
index 6f835df..0e90b0e 100644
--- a/src/common.c
+++ b/src/common.c
@@ -56,7 +56,7 @@ s
hex_dump() callers can theoretically provide the destination buffer
for the hexdump'ed string, but nothing in libcacard uses that feature.
This commit removes it.
Signed-off-by: Christophe Fergeau
---
src/cac-aca.c | 10 +-
src/cac.c | 8
src/common.c | 19 +---
This test is currently failing under ASAN, the next commit will fix
this.
Signed-off-by: Christophe Fergeau
---
Actually there are more failing tests with ASAN, I'll try to send
patches to fix these too...
tests/libcacard.c | 21 +
1 file changed, 21 insertions(+)
diff --gi
hex_dump in git master currently has a 1 byte buffer overflow which
valgrind is not able to catch, but asan detects it.
Signed-off-by: Christophe Fergeau
---
.gitlab-ci.yml | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 4174e11..
>
> Hi,
>
> On Tue, Aug 21, 2018 at 02:53:59PM +0200, Javier Celaya wrote:
> > > Yes, not against merging the fix. But if we can get it fixed
> > > inGlib, it is matter to help other projects that port code
> > > towindows to be fixed as well, etc.
> > > Please open a bug in Glib and add a refere
Hi,
On Tue, Aug 21, 2018 at 02:53:59PM +0200, Javier Celaya wrote:
> > Yes, not against merging the fix. But if we can get it fixed
> > inGlib, it is matter to help other projects that port code
> > towindows to be fixed as well, etc.
> > Please open a bug in Glib and add a reference to it in the
Hi,
El mar, 21-08-2018 a las 09:29 +0200, Victor Toso escribió:
> Hi,
> On Tue, Aug 21, 2018 at 03:18:35AM -0400, Frediano Ziglio wrote:
>
> Hi,On Fri, 2018-08-17 at 15:24 +0200, Victor Toso wrote:
> Hi,
> On Fri, Aug 17, 2018 at 03:12:35PM +0200, jorge.olmos@flexvdi.comwrot
> e:
> From: Jorge Olm
Hi
On Tue, Aug 21, 2018 at 2:08 PM Lukáš Hrázký wrote:
>
> On Tue, 2018-08-21 at 13:09 +0200, Marc-André Lureau wrote:
> > The API & protocol abstracted away the channel ID/monitor ID details
> > for the client. You want to expose it now, but the reasons aren't well
> > justified, and you are pus
On Tue, 2018-08-21 at 13:09 +0200, Marc-André Lureau wrote:
> Hi
>
> On Tue, Aug 21, 2018 at 11:44 AM Lukáš Hrázký wrote:
> > > Well it's a switching point, you need to define it carefully. It may
> > > be simple or not, but it is just a condition, And the code to switch
> > > from one to the oth
Hi
On Tue, Aug 21, 2018 at 11:44 AM Lukáš Hrázký wrote:
> > Well it's a switching point, you need to define it carefully. It may
> > be simple or not, but it is just a condition, And the code to switch
> > from one to the other shouldn't be so terrible.
>
> It was also my first idea of a solution
Hi
On Tue, Aug 21, 2018 at 9:32 AM Frediano Ziglio wrote:
> User experience or not even with the switch implemented this can't
> work for the same reason that we want these patches.
> How the server knows which displays to show to the client?
I would say 1 vgpu associated with 1 optional qxl dev
Ping...
On Tue, 2018-07-10 at 16:51 +0200, Lukáš Hrázký wrote:
> Hi all,
>
> the refactor continues, in this series I introduce the InboundMessage
> and OutboundMessage classes for the StreamPort I/O.
>
> 2/3 is heavily based on a previously posted patch by Christophe de
> Dinechin. It is a carb
On Mon, 2018-08-20 at 23:11 +0200, Marc-André Lureau wrote:
> Hi
>
> On Mon, Aug 20, 2018 at 9:00 PM Jonathon Jongsma wrote:
> >
> > On Mon, 2018-08-20 at 16:21 +0200, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Fri, Aug 17, 2018 at 9:48 PM Jonathon Jongsma > > > wrote:
> > > >
> > > > O
> Hi
>
> On Mon, Aug 20, 2018 at 9:00 PM Jonathon Jongsma wrote:
> >
> > On Mon, 2018-08-20 at 16:21 +0200, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Fri, Aug 17, 2018 at 9:48 PM Jonathon Jongsma > > > wrote:
> > > >
> > > > On Fri, 2018-08-17 at 16:53 +0200, Marc-André Lureau wrote:
> >
Hi,
On Tue, Aug 21, 2018 at 03:18:35AM -0400, Frediano Ziglio wrote:
> >
> > Hi,
> > On Fri, 2018-08-17 at 15:24 +0200, Victor Toso wrote:
> > > Hi,
> > >
> > > On Fri, Aug 17, 2018 at 03:12:35PM +0200, jorge.ol...@flexvdi.com
> > > wrote:
> > > > From: Jorge Olmos
> > > >
> > > > When buildin
>
> Hi,
> On Fri, 2018-08-17 at 15:24 +0200, Victor Toso wrote:
> > Hi,
> >
> > On Fri, Aug 17, 2018 at 03:12:35PM +0200, jorge.ol...@flexvdi.com
> > wrote:
> > > From: Jorge Olmos
> > >
> > > When building spice-gtk for windows:
> > > - libusb uses __stdcall calling convention when compiled fo
Instead of keeping 2 fields for the conversion monotonic time ->
multimedia time compute a single offset.
Signed-off-by: Frediano Ziglio
---
src/spice-session.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/spice-session.c b/src/spice-session.c
index b1aeb8
32 matches
Mail list logo
