>
> > > 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
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.
> >
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:
-
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
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
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
>
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
> > > 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
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
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
>
> > 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
> 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
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
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
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,
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
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
>
> 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
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
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
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.
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
>
> 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
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.
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
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
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
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
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
>
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
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
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.
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
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
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
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
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:
> > > >
> > > >
> 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,
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
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
> >
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
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
