>
> > > Another lousely related thing: While debugging another issue I've
> > > noticed that QXLMonitorsConfig has a surface_id field. What this is
> > > intended for? Map non-primary surface to a head?
> >
> > I just did a brief investigation, I am not sure. It seems the field is
> > not used
Hi,
> - We're going to try to implement you suggestion of identifying the
> monitors in the guest basically according to your outline in
> https://lists.freedesktop.org/archives/spice-devel/2018-August/045465.html
Ok. I'll stay tuned. Cc'ing me on patches you send out would be great.
> > Ano
Hello,
On Wed, 2018-09-19 at 11:24 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > this is the reworked second version of the Monitor ID series.
>
> Ping. What is the status here? v3 coming?
Sorry about the radio silence. We discussed the possibilities and came
up with roughly the following:
- Fro
Hi,
> this is the reworked second version of the Monitor ID series.
Ping. What is the status here? v3 coming?
Another lousely related thing: While debugging another issue I've
noticed that QXLMonitorsConfig has a surface_id field. What this is
intended for? Map non-primary surface to a he
On Tue, Aug 28, 2018 at 05:26:15PM +0200, Lukáš Hrázký wrote:
> 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.
> >
>
> > > 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 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, "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,
> This would work for the channel_id + monitor_id formula, but not for
> the channel_id ? channel_id : monitor_id one. AFAIK channel_id ?
> channel_id : monitor_id is used only in spice-gtk and channel_id +
> monitor_id is used in virt-viewer and spicy.
[ ... ]
> And we still need to fix t
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 does it fit into the picture btw? I
> > guess there will be two c
>
> > struct {
> > ...
> > uint8_t channel_id:4;
> > uint8_t monitor_id:4;
> > ...
> > };
> >
> > at this point however both the client and server have to be changed,
>
> Server side yes, because it assigns the numbers.
> Why the client side too?
>
The display_id is crafted by the clie
> struct {
> ...
> uint8_t channel_id:4;
> uint8_t monitor_id:4;
> ...
> };
>
> at this point however both the client and server have to be changed,
Server side yes, because it assigns the numbers.
Why the client side too?
> this new schema is just introducing a limitation (16 channels a
On Fri, 2018-08-24 at 13:49 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Long-term there should be no need to have a separate QXL device for
> > > boot messages.
> >
> > Interesting, why do you think so?
>
> Well, there is the vnc console for the nvidia vgpu. Which wasn't
> mentioned in this thr
On Mon, 2018-08-27 at 16:30 +0200, Gerd Hoffmann wrote:
> On Mon, Aug 27, 2018 at 03:34:54PM +0200, Lukáš Hrázký wrote:
> > On Mon, 2018-08-27 at 14:27 +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > 1. The IDs sent from the client in VDAgentMonitorsConfig and
> > > > MousePosition messages
> On Mon, Aug 27, 2018 at 03:34:54PM +0200, Lukáš Hrázký wrote:
> > On Mon, 2018-08-27 at 14:27 +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > 1. The IDs sent from the client in VDAgentMonitorsConfig and
> > > > MousePosition messages are equal to either `channel_id + monitor_id` or
> > > >
On Mon, Aug 27, 2018 at 03:34:54PM +0200, Lukáš Hrázký wrote:
> On Mon, 2018-08-27 at 14:27 +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > 1. The IDs sent from the client in VDAgentMonitorsConfig and
> > > MousePosition messages are equal to either `channel_id + monitor_id` or
> > > `channel_id ?
On Mon, 2018-08-27 at 14:27 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > 1. The IDs sent from the client in VDAgentMonitorsConfig and
> > MousePosition messages are equal to either `channel_id + monitor_id` or
> > `channel_id ? channel_id : monitor_id`. This is under the assumption
> > that there is
Hi,
> 1. The IDs sent from the client in VDAgentMonitorsConfig and
> MousePosition messages are equal to either `channel_id + monitor_id` or
> `channel_id ? channel_id : monitor_id`. This is under the assumption
> that there is either only one display_channel or more display channels
> each with
Hi,
> > > > Really? Can you describe how the guest could read that? Thanks.
> > >
> > > It's QXLRom->id (see /usr/include/spice-1/spice/qxl_dev.h).
> >
> > That's from the driver, right?
>
> Yes.
Scratch that. It's a different ID. In a typical setup they happen to
be equal by pure luck, bu
Hi,
> > Is there a high-level overview of the changes planned? For starters I'm
> > mostly interested in spice-protocol and qxl guest interface changes. We
> > need to get the concepts right before implementing the stuff. And I
> > think its easier if we bundle the changes into one protocol u
Hi,
> > Hmm, why? I fail to see the point given that qxl wouldn't be able to
> > use it unless you change it too, and all other qemu display devices are
> > either single-head anyway (stdvga, cirrus, ...) or use one channel per
> > head.
>
> To support streaming of multiple outputs with a sing
>
> Hi,
>
> > > > Having a single frame buffer for channel is a current implementation
> > > > limit which can be relaxed.
> > >
> > > But I don't think this is possible without changing spice protocol and
> > > qxl device. Which opens the question whenever this is worth the trouble
> > > or wh
Hi,
> > > Having a single frame buffer for channel is a current implementation
> > > limit which can be relaxed.
> >
> > But I don't think this is possible without changing spice protocol and
> > qxl device. Which opens the question whenever this is worth the trouble
> > or whenever we should
> On Fri, Aug 24, 2018 at 09:16:09AM -0400, Frediano Ziglio wrote:
> > >
> > > On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> > > > > Yes, we want this for sure. One channel per display.
> > > >
> > > > For sure? This deserves a justification.
> > >
> > > That is the way modern
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 Hoffmann wrote:
> > > > Hi,
> > > >
> > > > > "we only support"
On Fri, Aug 24, 2018 at 09:16:09AM -0400, Frediano Ziglio wrote:
> >
> > On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> > > > Yes, we want this for sure. One channel per display.
> > >
> > > For sure? This deserves a justification.
> >
> > That is the way modern display archite
On Fri, 2018-08-24 at 14:39 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Yes, we want this for sure. One channel per display.
> >
> > Maybe you cut too much context. Who is "we" in the above sentence?
> > Why "we want"?
>
> See other reply.
>
> > > Yes. *That* is the underlying problem. There
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 Hoffmann wrote:
> > > Hi,
> > >
> > > > "we only support" seems to just state the use cases before adding
> > > > vGPU but we are tr
>
> On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> > On Thu, 2018-08-23 at 22:42 +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > "we only support" seems to just state the use cases before adding
> > > > vGPU but we are trying to support vGPU cases.
> > > > If even we decide
Hi,
> > Yes, we want this for sure. One channel per display.
>
> Maybe you cut too much context. Who is "we" in the above sentence?
> Why "we want"?
See other reply.
> > Yes. *That* is the underlying problem. There is no guest-visible link
> > between display device and spice channel. Exc
On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> On Thu, 2018-08-23 at 22:42 +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > "we only support" seems to just state the use cases before adding
> > > vGPU but we are trying to support vGPU cases.
> > > If even we decide that for vGPU ca
Hi,
> > Long-term there should be no need to have a separate QXL device for
> > boot messages.
>
> Interesting, why do you think so?
Well, there is the vnc console for the nvidia vgpu. Which wasn't
mentioned in this thread yet, how does it fit into the picture btw? I
guess there will be two
>
> Hi,
>
> > "we only support" seems to just state the use cases before adding
> > vGPU but we are trying to support vGPU cases.
> > If even we decide that for vGPU cards we always have monitor_id == 0
>
> Yes, we want this for sure. One channel per display.
>
Maybe you cut too much context.
On Thu, 2018-08-23 at 22:42 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > "we only support" seems to just state the use cases before adding
> > vGPU but we are trying to support vGPU cases.
> > If even we decide that for vGPU cards we always have monitor_id == 0
>
> Yes, we want this for sure. One c
Hi Gerd,
On Thu, 2018-08-23 at 22:56 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > 1. The logic used to switch something for something and when - You need
> > to define somehow you have this QXL device that is showing the boot in
> > client display 1 and then you start X and want to replace client
>
Hi,
> Note that if all we want to support with the associated QXL device is
> text console, we may perhaps just drop the QXL device and use
> console/VT directly using spice ports, like I proposed in virt-viewer
> "[PATCH 00/22] Add QEMU-like UI: VT console & basic VM state" series.
Not going t
Hi,
> 1. The logic used to switch something for something and when - You need
> to define somehow you have this QXL device that is showing the boot in
> client display 1 and then you start X and want to replace client
> display 1 with X monitor 1. Then the user switches VTs and you need to
> swi
Hi,
> There's not a new channel type, but there is a new channel, because
> there are two devices. Both the QXL device and the vGPU have their own
> Display channels.
> * channel #0 is the QXL device and only displays stuff at boot time
>(or when switching to a VT)
> * channel #1 is the n
Hi,
> "we only support" seems to just state the use cases before adding
> vGPU but we are trying to support vGPU cases.
> If even we decide that for vGPU cards we always have monitor_id == 0
Yes, we want this for sure. One channel per display.
> (that is multiple DisplayChannels for each vGPU
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
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
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 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:
> > > > On Thu, Aug 16, 20
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:
> > > On Thu, Aug 16, 2018 at 6:26 PM Lukáš Hrázký
> > > wrote:
> > > >
> > > > Hello list,
> > > >
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:
> > On Thu, Aug 16, 2018 at 6:26 PM Lukáš Hrázký
> > wrote:
> > >
> > > Hello list,
> > >
> > > this is the reworked second version of the Monitor ID series. The
> > > goal
> On Fri, 2018-08-17 at 16:53 +0200, Marc-André Lureau wrote:
> > On Thu, Aug 16, 2018 at 6:26 PM Lukáš Hrázký
> > wrote:
> > >
> > > Hello list,
> > >
> > > this is the reworked second version of the Monitor ID series. The
> > > goal
> > > of this series is to make the identification of monitor
On Fri, 2018-08-17 at 16:53 +0200, Marc-André Lureau wrote:
> On Thu, Aug 16, 2018 at 6:26 PM Lukáš Hrázký
> wrote:
> >
> > Hello list,
> >
> > this is the reworked second version of the Monitor ID series. The
> > goal
> > of this series is to make the identification of monitors in the
> > monit
On Thu, Aug 16, 2018 at 6:26 PM Lukáš Hrázký wrote:
>
> Hello list,
>
> this is the reworked second version of the Monitor ID series. The goal
> of this series is to make the identification of monitors in the
> monitors_config exchange and in the MousePosition messages more robust,
> as well as fi
Hello list,
this is the reworked second version of the Monitor ID series. The goal
of this series is to make the identification of monitors in the
monitors_config exchange and in the MousePosition messages more robust,
as well as fix the case of guest-side streaming via the
spice-streaming-agent,
57 matches
Mail list logo
