On Thu, 2017-02-23 at 16:25 +0200, Snir Sheriber wrote:
> Hi,
>
> On 01/31/2017 10:24 PM, Jonathon Jongsma wrote:
> > When a guest is rebooted, the QXL driver gets unloaded at some
> > point in
> > the reboot process. When the driver is unloaded, the spice server
> > sets a
> > single flag to FALS
Hi Christophe, Yes, #2 may be incorrect. Let's change it to the following:
2. Qxl loaded (early in guest boot) -- Guest send max n monitor with one
enabled -- client can have n window, but only one enabled ("n" depends on the
guest)
This won't affect #3, where client get correct infor
Hi Jonathon, Let's talk about a real computer. There're multiple ways that I
can "turn off" a monitor, including 1. Turn off power of monitor; 2. Unplug the
display cable; 3. Switch off the corresponding display in the guest OS.
Now on the VM, when I close a window of virt-viewer, what hap
Hi Daimon, thanks for the input.
On Thu, 2017-02-23 at 05:03 +, Daimon Wang wrote:
> Hi,
> I'll go against the fix as I don't see any reason for the
> "assumption".
>
> Let's split the question into 2 things, max monitor number and
> which monitor is enabled.
> The max monitor nu
Hi,
On 01/31/2017 10:24 PM, Jonathon Jongsma wrote:
When a guest is rebooted, the QXL driver gets unloaded at some point in
the reboot process. When the driver is unloaded, the spice server sets a
single flag to FALSE: RedWorker::driver_cap_monitors_config. This flag
indicates whether the driver
On Thu, Feb 23, 2017 at 11:58:53AM +0100, Christophe de Dinechin wrote:
> Hi Daimon,
>
>
> In a real system, the connected monitors and their EDID provide information
> to the OS about how many monitors are available, the resolution they support,
> etc. That information is persistent for the OS
Hi Daimon,
In a real system, the connected monitors and their EDID provide information to
the OS about how many monitors are available, the resolution they support, etc.
That information is persistent for the OS, i.e. it is still there even when the
OS is down. Where do you plan to get the “av
Hi, I'll go against the fix as I don't see any reason for the "assumption".
Let's split the question into 2 things, max monitor number and which
monitor is enabled.
The max monitor number seems correct now, controlled by qemu together with
qxl. And it's used to control the client menu
Is it possible to make the max number of monitors something persistent (e.g.
set / get that using libvirt), so that the behavior would be consistent between
a first boot and a reboot?
Christophe
> On 20 Feb 2017, at 15:49, Jonathon Jongsma wrote:
>
> On Thu, 2017-02-02 at 10:30 -0600, Jonatho
On Thu, 2017-02-02 at 10:30 -0600, Jonathon Jongsma wrote:
> On Thu, 2017-02-02 at 05:29 -0500, Frediano Ziglio wrote:
> > >
> > > When a guest is rebooted, the QXL driver gets unloaded at some
> > > point in
> > > the reboot process. When the driver is unloaded, the spice server
> > > sets a
> >
On Thu, 2017-02-02 at 05:29 -0500, Frediano Ziglio wrote:
> >
> > When a guest is rebooted, the QXL driver gets unloaded at some
> > point in
> > the reboot process. When the driver is unloaded, the spice server
> > sets a
> > single flag to FALSE: RedWorker::driver_cap_monitors_config. This
> > f
>
> When a guest is rebooted, the QXL driver gets unloaded at some point in
> the reboot process. When the driver is unloaded, the spice server sets a
> single flag to FALSE: RedWorker::driver_cap_monitors_config. This flag
> indicates whether the driver is capable of sending its own monitors conf
When a guest is rebooted, the QXL driver gets unloaded at some point in
the reboot process. When the driver is unloaded, the spice server sets a
single flag to FALSE: RedWorker::driver_cap_monitors_config. This flag
indicates whether the driver is capable of sending its own monitors config
messages
13 matches
Mail list logo
