+spice-devel for awareness
Context: there is a lot of work there on video streaming for SPICE, mostly
done ATM through proprietary APIs.
> On 9 Dec 2019, at 15:19, Dmitry Sepp wrote:
>
> Hello,
>
> I'd like to invite everyone to share ideas regarding required encoder
> features
> in this sep
h, I can understand how this could have been hard to find.
Still, even if I now understand where you come from, and even if I know
that your patch does not really hurt in practice given what is currently
known of the support platforms, I still see that patch as going somewhat
in the wrong direction
>> >>
>> >
>> > I don't understand. Do you mean the capabilities inside the HELLO packet?
>> > In this case it's just the confusion about the "handle" above, the HELLO
>> > is sent to the guest.
>>
>> Actually, I was simply incorrectly assuming some other client could
>> refer to spice_usbredir_write_callback directly. I find it's not
>> appropriately named, since it's not really used as a callback, but
>> called directly, and because it has a "spice_" prefix that (to me)
>> implies it his "closer to the public API" than usbredir_write_callback,
>> when in fact it's further away from the public interface.
>>
>>
>> >
>> >> (Also, to be clear, I don't think this invalidates the patch at all, I'm
>> >> really asking questions to make sure I understand the logic and that the
>> >> way the code is organized is fully intentional).
>> >>
>>
>> --
>> Cheers,
>> Christophe de Dinechin (IRC c3d)
>>
--
Cheers,
Christophe de Dinechin (IRC c3d)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
irectly, and because it has a "spice_" prefix that (to me)
implies it his "closer to the public API" than usbredir_write_callback,
when in fact it's further away from the public interface.
>
>> (Also, to be clear, I don't think this invalidates the patch at
break;
> @@ -433,7 +432,7 @@ int cd_usb_bulk_msd_read(UsbCdBulkMsdDevice *cd, uint32_t
> max_len)
> break;
>
> default:
> - SPICE_ERROR("Unexpected read state: %s, len %" G_GUINT32_FORMAT,
> +SPICE_ERROR("Unexpected read state: %s,
GTK client provides the
logic for emulating devices. Is that a good way to describe it?
Would another theoretical client using the library never run into the
case because it would not expose the capabilities? Or is it just a case
that nobody cares about?
(Also, to be clear, I don't think
> On 28 Aug 2019, at 12:16, Frediano Ziglio wrote:
>
>> Side comment: usbredir_write_callback used to be a mere wrapper around
>> spice_usbredir_write_callback. Now, it has a whole lot of logic in it.
>> Is it intentional, or should some of that logic be moved to shared code?
>>
>
> Yes, inte
t;> > g_test_add_data_func("/cd-emu/multiple", GUINT_TO_POINTER(128),
>> > multiple);
>> > +g_test_add_data_func("/cd-emu/attach_no_auto", GUINT_TO_POINTER(0),
>> > attach);
>> > +g_test_add_data_func("/cd-emu/attach_auto", GUINT_TO_POINTER(1),
>> > attach);
>> >
>> > return g_test_run();
>> > }
>>
>
> Frediano
--
Cheers,
Christophe de Dinechin (IRC c3d)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
meson --buildtype=release --prefix=/usr
> +- mingw64-meson --buildtype=release --prefix=/usr --werror
> - ninja install
>
>script:
> - cd $CI_PROJECT_DIR
> - mkdir build-win64 && cd build-win64
> -- mingw64
and creation of parser
> +usbredirhost_write_guest_data(ch->usbredirhost);
> +}
> +} else {
> +// no physical device support, only emulated, create the
> +// parser
> +ch->parser = create_parser(ch);
> +if (ch
ultiple", GUINT_TO_POINTER(128),
> multiple);
> +g_test_add_data_func("/cd-emu/attach_no_auto", GUINT_TO_POINTER(0),
> attach);
> +g_test_add_data_func("/cd-emu/attach_auto", GUINT_TO_POINTER(1), attach);
>
> return g_test_run();
> }
g_test_add_data_func("/cd-emu/attach_no_auto", ATTACH_PARAM(0, 1),
> attach);
> +g_test_add_data_func("/cd-emu/attach_auto", ATTACH_PARAM(1, 1), attach);
> + g_test_add_data_func("/cd-emu/attach_no_auto_no_libusb", ATTACH_PARAM(0,
> 0), a
> -DATA_SEND;
> +> usb_redir_interface_info,
> +> usb_redir_ep_info,
> +> usb_redir_device_connect
>
> -if (!attach_on_connect) {
> -g_assert_true(spice_usb_backend_channel_attach(usb_ch, device,
> &err));
> -g_assert_null(err);
> -}
> -g_assert_cmpint(hellos_sent, ==, 1);
> -g_assert_cmpint(messages_sent, >, 1);
> +< usb_redir_reset
> +< usb_redir_control_packet
> +
> +> usb_redir_control_packet
> +
> +*/
>
> // cleanup
> spice_usb_backend_device_unref(device);
--
Cheers,
Christophe de Dinechin (IRC c3d)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Kevin Pouget writes:
> On Wed, Jul 31, 2019 at 11:59 AM Christophe de Dinechin
> wrote:
>>
>> I don't really like the way option parsing is implemented, because I
>> think it leads to somewhat counter-intuitive user behaviors.
>>
>> For example, if I
7;" + value + "' for
> option 'gst.codec'.");
> +}
> +
> +auto plugin = std::make_shared();
> +plugin->ParseOptions(agent->Options(), codec_type);
> +agent->Register(plugin);
> +}
> +}
Because of this second loop, you presently loop multiple times over the
same options.
>
> -agent->Register(plugin);
> +// no default value at the moment
> +// (used to be h264, see GstreamerEncoderSettings::codec)
>
> return true;
> }
--
Cheers,
Christophe de Dinechin (IRC c3d)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
og,
> ConcreteAgent &agent)
> syslog(LOG_ERR, "Empty device display info from the plugin");
> }
>
> - while (!quit_requested && streaming_requested) {
> +while (!quit_requested && streaming_requested &&
gt;#
> http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
>spice_client_gtk_current = 5
>spice_client_gtk_revision = 0
Trivial change.
Acked-by: Christophe de Dinechin
--
Cheers,
Christophe de Dinechin (IRC c3d)
___
Spice-devel
IDEO_BITRATE_MARGIN) {
> +} else if ((bit_rate - encoder->video_bit_rate) >
> encoder->video_bit_rate * SPICE_GST_VIDEO_BITRATE_MARGIN) {
> encoder->video_bit_rate = bit_rate;
> set_pipeline_changes(encoder, SPICE_GST_VIDEO_PIPELINE_BITRATE);
>
> On 3 May 2019, at 15:31, Daniel P. Berrangé wrote:
>
> On Fri, May 03, 2019 at 03:21:09PM +0200, Christophe de Dinechin wrote:
>> Hi Frediano,
>>
>>
>> We discussed GPL vs LGPL for the recorder library.
>>
>> I made a mistake in commit e7df1
Hi Frediano,
We discussed GPL vs LGPL for the recorder library.
I made a mistake in commit e7df1041176eda88aea6102d1c4ecd9f144321a6 of the
recorder library trying to “renormalize” the headers before submitting the
Fedora package (the “norm” being that each file should contain the license
blur
> On 26 Apr 2019, at 09:13, Frediano Ziglio wrote:
>
>>>
>>> On 25 Apr 2019, at 11:42, Frediano Ziglio wrote:
>>>
>>> ping 2
>>>
ping
>
> Allows the plugins to add information to the log.
>
> Signed-off-by: Frediano Ziglio
> ---
> Not entirely hap
features
> - git clean -xfd
> +- git submodule foreach --recursive git clean -xfd
> - ./autogen.sh --enable-static
> --enable-lz4=no
> --enable-webdav=no
Acked-by: Christophe de Dinechin
> --
> 2.20.1
>
>
> On 25 Apr 2019, at 11:42, Frediano Ziglio wrote:
>
> ping 2
>
>>
>> ping
>>
>>>
>>> Allows the plugins to add information to the log.
>>>
>>> Signed-off-by: Frediano Ziglio
>>> ---
>>> Not entirely happy to export a kind of C function, any suggestion
>>> welcome
>>> ---
>>> include/spic
Hey team,
I get a build failure that looks like this:
char-device.c:906:52: error: too many arguments to function call, expected
single argument 'm', have 2 arguments
m2 = spice_marshaller_get_ptr_submarshaller(m, 0);
~~^
/Users/ddd/Work/spic
> On 29 Jan 2019, at 10:23, Christophe Fergeau wrote:
>
> On Mon, Jan 28, 2019 at 02:28:36PM -0500, Frediano Ziglio wrote:
>>> On Wed, Jan 23, 2019 at 10:09:25AM +, Frediano Ziglio wrote:
This fixes Gitlab issue #9
(cfr https://gitlab.freedesktop.org/spice/usbredir/issues/9).
Hey team,
It’s still time to wish you a happy new year, I guess… :-)
While looking for illustrations for an upcoming DevConf.cz talk, I cam across
the following article that compares three remote desktop protocols:
http://www.diva-portal.org/smash/get/diva2:530960/FULLTEXT01.pdf.
It was poste
> On 29 Nov 2018, at 18:23, Frediano Ziglio wrote:
>
>> Hey,
>>
>> On Thu, Nov 29, 2018 at 08:50:47AM -0500, Frediano Ziglio wrote:
>>>>
>>>> On Wed, Nov 28, 2018 at 11:23:17AM +0100, Christophe de Dinechin wrote:
>>>>>> On 2
> On 27 Nov 2018, at 15:38, Christophe Fergeau wrote:
>
> On Thu, Nov 22, 2018 at 05:58:01AM -0500, Frediano Ziglio wrote:
>>>
>>> Hey,
>>>
>>> On Mon, Nov 19, 2018 at 08:46:04PM +, Frediano Ziglio wrote:
>>>> From: Christophe d
> On 20 Nov 2018, at 13:49, Frediano Ziglio wrote:
>
>>
>> Thanks Frediano,
>>
>>
>> Reviewed-by: Christophe de Dinechin
>>
>>
>>> On 19 Nov 2018, at 21:46, Frediano Ziglio wrote:
>>>
>>> From: Christophe de D
Thanks Frediano,
Reviewed-by: Christophe de Dinechin
> On 19 Nov 2018, at 21:46, Frediano Ziglio wrote:
>
> From: Christophe de Dinechin
Replace with “Suggested-by: “ :-)
>
> Allow to use recorder library. See https://github.com/c3d/recorder for
> details.
> The
> On 1 Oct 2018, at 09:20, Christophe Fergeau wrote:
>
> On Fri, Sep 28, 2018 at 06:23:48PM +0200, Christophe de Dinechin wrote:
>>>>> On Fri, Sep 28, 2018 at 2:19 PM Christophe Fergeau
>>>>> wrote:
>>>>>> We just added meson support
> On 28 Sep 2018, at 16:46, Marc-André Lureau
> wrote:
>
> Hi
>
> On Fri, Sep 28, 2018 at 6:14 PM Christophe de Dinechin
> wrote:
>>
>> Just curious, how does Meson address / plan to address the top-level build
>> issue?
>
> What do you m
>
>> Christophe
>>
>>
>> On Thu, Sep 27, 2018 at 05:33:37PM +0200, Christophe de Dinechin wrote:
>>> From: Christophe de Dinechin
>>>
>>> Make-it-Quick is a make-only build system that uses makefiles
>>> for autoconfiguration. For
From: Christophe de Dinechin
This is a new repository that makes it easier to build all
of SPICE with a single 'make' command. It also optimizes
the build of 'common' and 'protocol', which are built only once
and then used by both spice-gtk and spice-server. Thi
From: Christophe de Dinechin
This is the 'streaming-agent' part of a make-only build system that
can normally coexist with the existing two build systems.
This RFC follows similar ones for protocol, common, spice-gtk and server.
Christophe de Dinechin (1):
streaming-agent: Make-It-
From: Christophe de Dinechin
Make-it-Quick is a make-only build system that uses makefiles
for autoconfiguration. For SPICE, it provides a faster, easier to
maintain and more flexible build system.
A key feature made possible by this build system is top-level builds.
Top-level builds are made
From: Christophe de Dinechin
Make-it-Quick is a make-only build system that uses makefiles
for autoconfiguration. For SPICE, it provides a faster, easier to
maintain and more flexible build system.
A key feature made possible by this build system is top-level builds.
Top-level builds are made
From: Christophe de Dinechin
This is a placeholder patch to remind you that you need to apply
the corresponding RFC version of spice-common for this to work.
Signed-off-by: Christophe de Dinechin
---
subprojects/spice-common | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
From: Christophe de Dinechin
This is the 'spice-gtk' part of a make-only build system that
can normally coexist with the existing two build systems.
This RFC follows a similar one for protocol and a patch for common,
and will be followed by similar RFCs for server and streaming-age
From: Christophe de Dinechin
Make-it-Quick is a make-only build system that uses makefiles
for autoconfiguration. For SPICE, it provides a faster, easier to
maintain and more flexible build system.
A key feature made possible by this build system is top-level builds.
Top-level builds are made
From: Christophe de Dinechin
Make-it-Quick is a make-only build system that uses makefiles
for autoconfiguration. For SPICE, it provides a faster, easier to
maintain and more flexible build system.
A key feature made possible by this build system is top-level builds.
Top-level builds are made
From: Christophe de Dinechin
Github review link: https://github.com/c3d/spice-protocol/commits/c3d-build
This is the protocol part of a make-only build system that
can normally coexist with the existing two build systems.
The primary benefit of the proposed approach is top-level build,
i.e. a
From: Christophe de Dinechin
This is the protocol part of a make-only build system that
can normally coexist with the existing two build systems.
The primary benefit of the proposed approach is top-level build,
i.e. a way to make it easier to build all of SPICE with correct
dependency tracking
From: Christophe de Dinechin
The [[noreturn]] attribute must be visible from call sites.
This is a hard error in clang:
cursor-updater.cpp:77:3: error: function declared '[[noreturn]]' after its
first declaration
[[noreturn]] void CursorUpdater::operator()()
^
./cursor-updater.hpp:2
From: Christophe de Dinechin
Using errno requires . Some platforms/compilers
are stricter than others in this respect.
frame-log.cpp:27:96: error: use of undeclared identifier 'errno'
throw Error(std::string("Failed to open log file '") + log_name +
"&#
From: Christophe de Dinechin
Christophe de Dinechin (2):
Fix clang build error on [[noreturn]]
Fix clang build error on missing
src/cursor-updater.cpp | 2 +-
src/cursor-updater.hpp | 2 +-
src/frame-log.cpp | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
--
2.13.5 (Apple
From: Christophe de Dinechin
Clang complains about:
1. [[noreturn]] used on implementation instead of header
2. errno used without
Details:
clang complains about [[noreturn]] not being on the first declaration.
cursor-updater.cpp:77:3: error: function declared '[[noreturn]]' after
> On 5 Jul 2018, at 15:14, Jonathon Jongsma wrote:
>
> On Mon, 2018-07-02 at 11:35 -0400, Frediano Ziglio wrote:
>>>
On 2 Jul 2018, at 09:43, Frediano Ziglio
wrote:
As the value is never used we can pass NULL in CreateThread.
Signed-off-by: Frediano Ziglio
>>>
> On 3 Jul 2018, at 16:58, Christophe Fergeau wrote:
>
> On Tue, Jul 03, 2018 at 04:31:10PM +0200, Christophe de Dinechin wrote:
>> I think we never had a discussion of what we really want in each case, and
>> that’s causing the confusion.
>>
>> First, a me
There is a lot of debate, distributed across a large number of patches,
regarding similar SPICE and glib facilities. For a number of things, there are
two sets of parallel APIs with slightly different behaviour. This is
undesirable, as it introduces confusion.
Pros: this lets us customize the b
> On 3 Jul 2018, at 15:51, Christophe Fergeau wrote:
>
> On Tue, Jul 03, 2018 at 03:16:19PM +0200, Christophe de Dinechin wrote:
>>>> diff --git a/common/canvas_base.c b/common/canvas_base.c
>>>> index 6bf6e5d..bbaaf96 100644
>>>> --- a/common/
> On 3 Jul 2018, at 15:29, Frediano Ziglio wrote:
>
>>
>> From: Christophe de Dinechin
>>
>> The spice_ variants simply mirror the glib API,
>> without adding significant value.
>>
>> Signed-off-by: Christophe de Dinechin
>> --
>&g
> On 3 Jul 2018, at 12:11, Frediano Ziglio wrote:
>
>>
>> On Fri, Jun 29, 2018 at 05:21:22PM +0200, Christophe de Dinechin wrote:
>>> From: Christophe de Dinechin
>>>
>>> In some error cases, canvas_get_image may return NULL.
>>>
Acked-by: Christophe de Dinechin
> On 2 Jul 2018, at 09:43, Frediano Ziglio wrote:
>
> Signed-off-by: Frediano Ziglio
> ---
> vdagent/vdagent.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/vdagent/vdagent.cpp b/vdagent/vdagent.cpp
> in
> On 3 Jul 2018, at 11:47, Christophe Fergeau wrote:
>
> On Fri, Jun 29, 2018 at 05:21:22PM +0200, Christophe de Dinechin wrote:
>> From: Christophe de Dinechin
>>
>> In some error cases, canvas_get_image may return NULL.
>> When this happens, calls like
From: Christophe de Dinechin
The spice_ variants simply mirror the glib API,
without adding significant value.
Signed-off-by: Christophe de Dinechin
--
Follow up a comment from Christophe Fergeau:
>I'd favour g_return_if_fail(), I'd really like to kill these various
> spice_*
From: Christophe de Dinechin
The spice_ variants simply mirror the glib API,
without adding significant value.
Signed-off-by: Christophe de Dinechin
--
Following up on Christophe Fergeau's comment:
> I'd favour g_return_if_fail(), I'd really like to kill these vario
> On 2 Jul 2018, at 18:23, Frediano Ziglio wrote:
>
>
>
> - Original Message -
>> From: "Christophe de Dinechin"
>> To: "Eduardo Lima (Etrunko)"
>> Cc: spice-devel@lists.freedesktop.org
>> Sent: Monday, 2 July, 2018 3
> On 2 Jul 2018, at 09:43, Frediano Ziglio wrote:
>
> Do not assume we allocated the handle doing the cleanup.
Comment seems misleading: CloseHandle seems to accept INVALID_HANDLE_VALUE as
input, although the MS documentation is not entirely clear.
Otherwise,
Acked-by: Chri
> On 2 Jul 2018, at 09:43, Frediano Ziglio wrote:
>
> As the value is never used we can pass NULL in CreateThread.
>
> Signed-off-by: Frediano Ziglio
> ---
> vdagent/vdagent.cpp | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/vdagent/vdagent.cpp b/vdagent/vdagent.cp
> On 2 Jul 2018, at 09:43, Frediano Ziglio wrote:
>
> For some reason kernel handles in Windows have 2 invalid values
> depending on the type. For files/devices are INVALID_HANDLE_VALUE
suggestion: “File / devices use INVALID_HANDLE_VALUE, while…"
> (-1) while others use NULL (0). As _vio_ser
> On 2 Jul 2018, at 09:43, Frediano Ziglio wrote:
>
> The strings in the registry are usually NUL-terminated but this
> is not a requirement.
> Handle the case when the string, considering the terminator, fit
> into the reading buffer. In this case accept the string. In the
> case the string fi
> On 29 Jun 2018, at 21:33, Eduardo Lima (Etrunko) wrote:
>
> Signed-off-by: Eduardo Lima (Etrunko)
> ---
> v2: - Remove unecessary setup steps
>- Dump meson-log.txt in case of error.
>
> .gitlab-ci.yml | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/.gitlab-ci.yml b/
From: Christophe de Dinechin
In some error cases, canvas_get_image may return NULL.
When this happens, calls like pixman_image_get_width(s)
will crash. Add additional error paths to deal with
these cases.
Signed-off-by: Christophe de Dinechin
---
common/canvas_base.c | 38
From: Christophe de Dinechin
The error functions are supposed to not return. Using the attribute
documents that in the interface, and is better for the compiler
because most noreturn-related optimizations and spurious warning
eliminations happen at the call site.
Signed-off-by: Christophe de
if (strcmp(name, node->name) == 0) {
> pthread_mutex_unlock(&stat_file->lock);
> return ref;
> }
> +ref = node->next_sibling_index;
> }
> for (ref = 0; ref < stat_file->max_nodes; ref++)
= 0};
>
> if (size == 0) {
> return 0;
> }
>
> if (!block) {
> +struct pollfd pollfd = {.fd = fd, .events = POLLIN, .revents = 0};
> while ((ret = poll(&pollfd, 1, 0)) == -1) {
> if (errno == EINTR) {
>
LInstance *qin, int
> level)
>
> static void get_init_info(QXLInstance *qin, QXLDevInitInfo *info)
> {
> -bzero(info, sizeof(*info));
> +memset(info, 0, sizeof(*info));
> info->num_memslots = 1;
> info->num_memslots_groups = 1;
> info->mems
Hey Frediano,
Glad you found the bug, but a bit puzzled by the explanation. Three things
confuse me:
- You seem to imply that self_bitmap and QXL_DRAW_COPY don’t make sense
together, but it’s not clear from the description why not, and looking at the
code, it was not entirely obvious to me. N
> On 22 Jun 2018, at 14:13, Lukáš Hrázký wrote:
>
> On Fri, 2018-06-22 at 12:05 +0200, Christophe de Dinechin wrote:
>>> On 20 Jun 2018, at 11:45, Lukáš Hrázký wrote:
>>>
>>> On Tue, 2018-06-19 at 17:06 +0200, Christophe de Dinechin wrote:
>>>
> On 22 Jun 2018, at 14:25, Lukáš Hrázký wrote:
>
> On Fri, 2018-06-22 at 11:35 +0200, Christophe de Dinechin wrote:
>>> On 20 Jun 2018, at 13:56, Lukáš Hrázký wrote:
>>>
>>> On Wed, 2018-06-20 at 04:34 +0200, Christophe de Dinechin wrote:
>>>>
> On 22 Jun 2018, at 11:52, Lukáš Hrázký wrote:
>
>>
>> What speculation are you talking about? By listing precise use cases and
>> data sources, I was trying to remove that speculation, so I’m confused as to
>> why you still think it’s speculative.
>
> You did list them, but AFAICS you did
> On 20 Jun 2018, at 11:45, Lukáš Hrázký wrote:
>
> On Tue, 2018-06-19 at 17:06 +0200, Christophe de Dinechin wrote:
>> Hi Lukas,
>>
>>
>> Please don’t be disturbed by the many comments. Overall, looks like really
>> good progress, and insightful
> On 20 Jun 2018, at 13:56, Lukáš Hrázký wrote:
>
> On Wed, 2018-06-20 at 04:34 +0200, Christophe de Dinechin wrote:
>>> On 19 Jun 2018, at 17:30, Lukáš Hrázký wrote:
>>>
>>> On Tue, 2018-06-19 at 15:41 +0200, Christophe de Dinechin wrote:
>>>&g
> On 21 Jun 2018, at 14:40, Lukáš Hrázký wrote:
>
> On Thu, 2018-06-21 at 13:42 +0200, Christophe de Dinechin wrote:
>>> On 20 Jun 2018, at 14:14, Lukáš Hrázký wrote:
>>>
>>> On Tue, 2018-06-19 at 21:55 +0200, Christophe de Dinechin wrote:
>>>
> On 20 Jun 2018, at 14:14, Lukáš Hrázký wrote:
>
> On Tue, 2018-06-19 at 21:55 +0200, Christophe de Dinechin wrote:
>>> On 19 Jun 2018, at 17:54, Jonathon Jongsma wrote:
>>>
>>> On Tue, 2018-06-19 at 15:46 +0200, Christophe de Dinechin wrote:
>>>
> On 19 Jun 2018, at 17:30, Lukáš Hrázký wrote:
>
> On Tue, 2018-06-19 at 15:41 +0200, Christophe de Dinechin wrote:
>>> On 5 Jun 2018, at 17:30, Lukáš Hrázký wrote:
>>>
>>> To keep compatibility with old endpoints (any of client, server,
>>> vd_a
> On 19 Jun 2018, at 17:54, Jonathon Jongsma wrote:
>
> On Tue, 2018-06-19 at 15:46 +0200, Christophe de Dinechin wrote:
>>> On 19 Jun 2018, at 14:11, Frediano Ziglio
>>> wrote:
>>>
>>>>
>>>> On Fri, 2018-06-15 at 15:12 +0200, M
> On 7 Jun 2018, at 10:55, Lukáš Hrázký wrote:
>
> On Wed, 2018-06-06 at 12:56 -0400, Frediano Ziglio wrote:
>>>
>>> Signed-off-by: Lukáš Hrázký
>>> ---
>>> src/vdagent/x11-randr.c | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/src/vdagent/x11-randr.c b/src/vdagent/x11-ran
I thought I had already commented on this one, but can’t find my comments
anywhere. Sorry if duplicate.
> On 5 Jun 2018, at 17:30, Lukáš Hrázký wrote:
>
> If the output_id is set, it is the true xrandr guest ID to use for the
> mouse motion event. If it's not present, keep relying on the wacky
Hi Lukas,
Please don’t be disturbed by the many comments. Overall, looks like really good
progress, and insightful analysis of the problem. Probably will require several
more iterations, but that’s entirely expected. Thanks a lot.
> On 5 Jun 2018, at 17:30, Lukáš Hrázký wrote:
>
> The code
Moving "[Spice-devel] [PATCH 0/0] Add support for h265/HEVC video codec” to a
separate thread for clarity.
> On 19 Jun 2018, at 11:50, Frediano Ziglio wrote:
>
>>
>> Hi,
>>
>>
>> On 06/18/2018 05:27 PM, Christophe de Dinechin wrote:
>>>
> On 19 Jun 2018, at 14:11, Frediano Ziglio wrote:
>
>>
>> On Fri, 2018-06-15 at 15:12 +0200, Marc-André Lureau wrote:
>>> Hi
>>>
>>> On Fri, Jun 15, 2018 at 1:01 PM, Lukáš Hrázký wrote:
On Fri, 2018-06-15 at 12:24 +0200, Marc-André Lureau wrote:
> Hi
>
> On Fri, Jun 15, 20
> On 5 Jun 2018, at 17:30, Lukáš Hrázký wrote:
>
> To keep compatibility with old endpoints (any of client, server,
> vd_agent), we need to copy the message to add the output_id field.
>
> The output_id is the guest-side id of the xrandr output (to be precise,
> it is the index in the list of
_
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
Acked-by: Christophe de Dinechin
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
As a follow up to the question I asked during the weekly meeting, what is the
plan for selecting between codecs?
Easy case: client and agent have only one shared codec combination. We have to
pick that one.
More complicated: say both sides support h264, vp9 and h265. Which one do we
pick?
Rig
> On 15 Jun 2018, at 12:24, Marc-André Lureau
> wrote:
>
> Hi
>
> On Fri, Jun 15, 2018 at 12:16 PM, Lukáš Hrázký wrote:
>> On Thu, 2018-06-14 at 21:12 +0200, Marc-André Lureau wrote:
>>> Hi
>>>
>>> On Tue, Jun 5, 2018 at 5:30 PM, Lukáš Hrázký wrote:
Hi everyone,
following i
> On 14 Jun 2018, at 15:03, Uri Lublin wrote:
>
> On 06/14/2018 12:56 PM, Frediano Ziglio wrote:
>>>
>>> SPICE expect to have each frame in a single message.
>>> So far the stream-device did not do that.
>>> That works fine for H264 streams but not for mjpeg.
>>> The client handles by itself m
> On 13 Jun 2018, at 14:06, Lukáš Hrázký wrote:
>
> The FrameLog class provides RAII for the FILE and encapsulates the
> logging functionality.
>
> Signed-off-by: Lukáš Hrázký
> ---
> While I retained all the behaviour of the original implementation, I
> don't like it as it is.
>
> 1. The cl
> On 16 May 2018, at 11:13, Lukáš Hrázký wrote:
>
> On Tue, 2018-05-15 at 16:42 -0400, Frediano Ziglio wrote:
>>>
>>> Update the interface to not return the size written, as it is not needed
>>> anymore.
>>>
>>> Signed-off-by: Lukáš Hrázký
>>> ---
>>> src/error.cpp | 3 ++-
>
> On 16 May 2018, at 11:25, Frediano Ziglio wrote:
>
>>
>> On Tue, 2018-05-15 at 16:37 -0400, Frediano Ziglio wrote:
Introduces an exception hierarchy up to a ReadError class, which is
thrown from read_all().
Signed-off-by: Lukáš Hrázký
---
src/Makefile.am
> On 16 May 2018, at 10:59, Lukáš Hrázký wrote:
>
> On Tue, 2018-05-15 at 16:37 -0400, Frediano Ziglio wrote:
>>>
>>> Introduces an exception hierarchy up to a ReadError class, which is
>>> thrown from read_all().
>>>
>>> Signed-off-by: Lukáš Hrázký
>>> ---
>>> src/Makefile.am
> On 10 May 2018, at 18:08, Jonathon Jongsma wrote:
>
> On Sat, 2018-05-05 at 16:43 +0100, Frediano Ziglio wrote:
>> This change does not affect generated code but make source more
>> readable. Also document in a single location the range of this
>> type.
>>
>> Signed-off-by: Frediano Ziglio
> On 7 May 2018, at 11:40, Frediano Ziglio wrote:
>
> ping
Several minor enhancements were suggested. Could you share the updated text for
review?
Thanks
Christophe
>
>>
>>>
On 23 Mar 2018, at 17:20, Frediano Ziglio wrote:
>
> Thank you for that. Looks good after tw
> On 24 Apr 2018, at 18:21, Christophe Fergeau wrote:
>
> On Tue, Apr 24, 2018 at 05:01:33PM +0200, Christophe de Dinechin wrote:
>> But we still have the capability to reject a plugin (in a well
>> defined, non-crashing way) for other reasons.
>> [...]
>>
> On 28 Mar 2018, at 17:20, Christophe Fergeau wrote:
>
> On Wed, Mar 28, 2018 at 11:10:36AM +0200, Christophe de Dinechin wrote:
>>
>>
>>> On 26 Mar 2018, at 19:06, Christophe Fergeau wrote:
>>>
>>> On Fri, Mar 23, 2018 at 01:05:23PM
> On 20 Apr 2018, at 12:51, Christophe Fergeau wrote:
>
> On Fri, Apr 20, 2018 at 10:10:17AM +0200, Christophe de Dinechin wrote:
>> There is no easy way to test if a method is there. There is, however,
>> an easy way to test if a C entry point is there in a shared li
:
https://github.com/c3d/spice-streaming-agent/commit/65ce0c9d747baaa81a4789d7f7c18f6a4f49732c.
Mostly clarifying binary compatibility guidelines.
With or without the changes above, OK with me.
Christophe
> On 19 Apr 2018, at 18:48, Frediano Ziglio wrote:
>
> From: Christophe de
t to do that for all components. I like
the way they test, it clearly also covers subtle cases such as .git being in a
parent directory, etc ;-)
(I noticed that with my top-level spice build, where all the components are
submodules).
Thanks
Chirstophe
>
> Christophe
>
> On Wed, A
> On 18 Apr 2018, at 17:04, Christophe Fergeau wrote:
>
> On Tue, Apr 17, 2018 at 06:39:05PM +0200, Christophe de Dinechin wrote:
>> When does this kind of scenario happen? Imagine we added support for
>> loading/unloading plugins. Version 13 adds a new interface to unl
1 - 100 of 835 matches
Mail list logo
