> > > Now I'm mostly guessing here, but from what I understand, we could send
> > > the frames of multiple monitors in sync over a single display channel,
> > > but if we use multiple channels, they are not synchronized and would
> > > arrive rather arbitrarily on the client?
> >
> > With a single
On 08/28/2018 04:54 PM, Frediano Ziglio wrote:
>>
>> Now calculating the soversion the same way it is done by libtool,
>> instead of using the resulting number directly.
>>
>> Signed-off-by: Eduardo Lima (Etrunko)
>> ---
>> meson.build | 29 +++--
>> 1 file changed, 27 ins
>
> Now calculating the soversion the same way it is done by libtool,
> instead of using the resulting number directly.
>
> Signed-off-by: Eduardo Lima (Etrunko)
> ---
> meson.build | 29 +++--
> 1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/meson.bu
I have just sent a similar patch to spice-server, now calculating the
soversion the same way it is done by libtool, instead of using the
resulting number directly.
Signed-off-by: Eduardo Lima (Etrunko)
---
src/meson.build | 25 +++--
1 file changed, 23 insertions(+), 2 deleti
Now calculating the soversion the same way it is done by libtool,
instead of using the resulting number directly.
Signed-off-by: Eduardo Lima (Etrunko)
---
meson.build | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
ind
On Fri, 2018-08-24 at 17:21 +0200, Gerd Hoffmann wrote:
> On Fri, Aug 24, 2018 at 03:38:07PM +0200, Lukáš Hrázký wrote:
> > At this moment, the agent has no idea about channel_ids,
>
> I think this one should be solved.
>
> So, qemu knows which channel id belongs to which device (and head, in
> c
On Tue, 2018-08-28 at 15:46 +0200, Gerd Hoffmann wrote:
> > > > Ok, that makes some sense. You do however need some synchronization
> > > > mechanism between the different framebuffers? (Imagine a video playing
> > > > across two displays)
> > >
> > > The linux kernel kms drivers support atomic pa
> > > Ok, that makes some sense. You do however need some synchronization
> > > mechanism between the different framebuffers? (Imagine a video playing
> > > across two displays)
> >
> > The linux kernel kms drivers support atomic page flips for both
> > displays, and wayland actually uses that.
>
On Fri, 2018-08-24 at 17:21 +0200, Gerd Hoffmann wrote:
> On Fri, Aug 24, 2018 at 03:38:07PM +0200, Lukáš Hrázký wrote:
> > On Fri, 2018-08-24 at 14:25 +0200, Gerd Hoffmann wrote:
> > > On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> > > > On Thu, 2018-08-23 at 22:42 +0200, Gerd Hof
Hi,
> Well, so instead of tagging messages the protocol is tagging single fields,
> something like the difference between a plain text and XML (although there's
> no hierarchy in evdev schema). Is possible but this suggestion is more about
> base protocol change.
Yes.
If we have to add Mouse*V
>
> On Mon, Aug 27, 2018 at 12:13:47PM -0400, Frediano Ziglio wrote:
> > >
> > > Hi,
> > >
> > > > +typedef struct SpiceMsgcMousePositionV2 {
> > > > +uint32_t x;
> > > > +uint32_t y;
> > > > +uint32_t buttons_state;
> > > > +uint32_t channel_id;
> > > > +uint32_t monitor_id;
Hi,
> > Well, "vnc console" is how the nvidia guys name it, the term doesn't
> > really match. It's basically a simple framebuffer where the nvidia
> > driver renders the guest display, and a vfio interface for qemu to
> > access it. From spice point of view it looks very simliar to the qemu
>
On Tue, 2018-08-28 at 06:20 +0200, Gerd Hoffmann wrote:
> On Mon, Aug 27, 2018 at 05:08:43PM +0200, Lukáš Hrázký wrote:
> > On Fri, 2018-08-24 at 13:49 +0200, Gerd Hoffmann wrote:
> > >
> > > Well, there is the vnc console for the nvidia vgpu. Which wasn't
> > > mentioned in this thread yet, how
Hi,
On Tue, Aug 14, 2018 at 08:53:39PM +0200, Jakub Janků wrote:
> Add a set of helper functions built around GIO that can be used to
> easily write messages to and read from the given FD.
>
> Since VDAgentConnection uses GIO,
> it integrates well with GMainLoop.
>
> Read messages must begin wit
Hi,
On Tue, Aug 14, 2018 at 08:53:37PM +0200, Jakub Janků wrote:
> This is purely a preparatory patch as it renders
> the vdagentd non-functional.
I would rather not break it unless it really helps a lot. It was
possible to do it for vdagent code at 3fcf2e944ae3bf7, not sure
why we can't here.
I
Hi,
First of all, thanks for your work on this :)
I'm still looking into the glib-integration related patches so I
might still reply once more afterwards. To keep things easy to
review, I take we could split this series in three different set
of patches.
- The cleanup code patches, including usi
16 matches
Mail list logo
